Skip to content

AWS 2026-09-17 Tier 1

Read original ↗

How DHI Group accelerates generative AI workloads from idea to production using hackathons

Summary

AWS partnered with DHI Group (talent-acquisition company behind ClearanceJobs and Dice) on a structured three-day Hackathon Acceleration Package (HAP) to compress the path from generative-AI idea to shippable prototype. The post is half delivery-process narrative (four-phase hackathon: Preparation → Enablement → Hackathon → Path to production) and half a genuine agentic AI reference architecture — the winning "ClearanceJobs MCP Server + AgileATS" use case that unifies two disparate talent systems behind a single agent. The architecture is the reusable part: an Amazon Bedrock AgentCore agent orchestrates tools exposed by an MCP server running on AWS Lambda, spanning two AWS accounts, with controlled VPC egress and persistent session memory. This is a customer case study, not a system-internals deep-dive: it is a concrete instance of the MCP-as-centralized-integration-proxy pattern rather than a new pattern.

Key takeaways

  • MCP server as the unified integration layer over two systems. Rather than build point-to-point integration between ClearanceJobs and AgileATS, the winning team exposed ClearanceJobs capabilities as discrete tools through an MCP server, and let an AI agent orchestrate them behind a single natural-language interface (e.g. "Find top cleared software engineers with strong GitHub profiles and add them to my pipeline"). The agent decomposes the multi-step request into tool calls automatically — a textbook instance of MCP as centralized integration proxy. (Source: this article)
  • AgentCore is the orchestration layer. Bedrock AgentCore supplies the full agent infrastructure: Agent Runtime (session management + reasoning loops), Gateway — an MCP gateway with IAM authentication and semantic search for tool discovery and routing — and McpBearerToken for authenticating to downstream MCP servers. An IAM role scopes the agent's permissions. (Source: this article)
  • Tools run on Lambda in a private subnet with controlled egress. The ClearanceJobs MCP Server is an AWS Lambda function in a private subnet inside a VPC, exposing search_candidates (clearance/skills filtering) and get_candidate (profile retrieval). It reaches the ClearanceJobs pilot environment through a NAT gateway with a WAF-allowlisted egress IP, so only authorized traffic reaches the production APIs. Credentials and base URLs live in AWS Systems Manager Parameter Store. (Source: this article)
  • External enrichment is isolated in a separate Lambda. A distinct ProfileLookup Lambda (find_github_profile) enriches candidates with GitHub data, routed through an internet gateway to the GitHub Users API — kept separate from the private-subnet tool Lambda so the two egress paths (internal APIs vs public internet) have different network postures. (Source: this article)
  • Session memory persists recruiter context across turns. CJRecruiterAgent memory (a capability of AgentCore memory) persists session state and recruiter preferences across conversations, letting the agent recall past searches, preferred candidates, and workflow patterns — agent memory in production. (Source: this article)
  • Cross-account split by trust boundary. The architecture spans two AWS accounts: the AgileATS account houses AgentCore, the foundation model, and a Bedrock Adapter Lambda (an alternate MCP JSON-RPC path for classic Bedrock agent integration); the ClearanceJobs account houses the MCP Server + ProfileLookup Lambdas in a VPC, the NAT gateway, and CloudWatch Logs. Communication between accounts is MCP over HTTPS with bearer auth and custom headers for tenant identification. (Source: this article)
  • Foundation model is Claude 3.5 Haiku via Bedrock. Anthropic's Claude 3.5 Haiku in Amazon Bedrock is the reasoning layer — interpreting recruiter intent, decomposing requests into tool calls, and synthesizing results. (Source: this article)
  • The other two hackathon prototypes. A real-time Employer Analytics Dashboard (AgentCore + Strands) automating QBR reporting that today demands 3+ QBRs/week across 250 customers; and an intelligent candidate matching system combining Amazon OpenSearch Service semantic search
  • Bedrock matching intelligence + Kiro for rapid frontend. (Source: this article)
  • Hackathon-as-production-accelerator (delivery-process claim). DHI's three-day event with 20 participants across 3 teams shipped a production-ready architecture validated during the event, compressing what "would typically take more than three months." Reported org outcomes: Kiro usage +84% post-event, 33% of developers reported increased interest in the AI-enabled SDLC. These are self-reported customer metrics, not benchmarked. (Source: this article)

Systems / concepts / patterns extracted

Systems (all pre-existing wiki pages — no new pages minted):

  • Bedrock AgentCore — orchestration layer (Runtime + Gateway + memory).
  • AgentCore Gateway — MCP gateway with IAM auth + semantic tool discovery/routing.
  • AgentCore memory — persistent session state / recruiter preferences.
  • Model Context Protocol (MCP) — the tool-exposure + orchestration protocol; MCP over HTTPS with bearer auth as the cross-account transport.
  • AWS Lambda — MCP Server (private subnet), ProfileLookup, and Bedrock Adapter functions.
  • Amazon Bedrock — hosts the Claude 3.5 Haiku foundation model.
  • Amazon OpenSearch Service — semantic search in the candidate-matching prototype.
  • AWS IAM — Gateway authentication + agent permission scoping.
  • AWS Systems Manager Parameter Store — credentials + base URLs.
  • Amazon CloudWatch Logs — structured observability in the ClearanceJobs account.
  • Strands — agent framework in the analytics-dashboard prototype.
  • Kiro — DHI's productivity tool of choice; rapid frontend + codebase analysis.

Concepts (mapped to existing pages, tags only):

  • Agent memory — session-scoped recruiter preferences persisted across turns.
  • Tenant isolation — custom headers for tenant identification on the cross-account MCP path.
  • Least-privileged access — IAM-scoped agent role; WAF-allowlisted single egress IP.

Patterns (mapped to existing pages, no new pages):

  • MCP as centralized integration proxy — the winning architecture is a concrete instance: one MCP server tier fronting ClearanceJobs, agent speaks intent, server implements the tool calls.
  • Prototype before production — the HAP's "sprint-ready not demo-ready" success criteria and decision-makers-on-the-panel principle.

Operational numbers (all customer-reported, illustrative)

  • Hackathon: 3 days, 20 participants, 3 teams, headquarters in Des Moines, Iowa.
  • QBR pain point automated by the analytics prototype: 3+ QBRs/week across 250 customers.
  • Org outcomes: Kiro usage +84% post-event; 33% of developers reported increased AI-SDLC interest; time-to-prototype compressed from >3 months → 3 days.
  • Foundation model: Anthropic Claude 3.5 Haiku on Bedrock.

Caveats

  • This is a customer case study / delivery-process post, not a system-internals retrospective. It contains no throughput/latency numbers, no failure modes, and no benchmarks — the org-transformation metrics (Kiro +84%, 33% dev interest) are self-reported and unqualified.
  • The architecture is described from a single diagram + prose; component boundaries (which Lambda sits where, which account) are stated but not exhaustively specified. Numbers like "3+ QBRs/week across 250 customers" describe the problem, not the system's measured performance.
  • Per the taxonomy gate, no new concept/pattern/system pages were minted — every entity maps into existing canonical vocabulary. "Hackathon-as-production-accelerator" is a delivery-process opinion, not reusable design vocabulary, so it is recorded as prose + tags here only.

Source

Last updated · 766 distilled / 2,225 read