Turning Portal‑Hopping into Instant Answers: How HEMA Built HAL with MCP and Bedrock
According to the AWS blog post, HEMA – a 100‑year‑old Dutch retailer with more than 750 stores – replaced a maze of wikis, service catalogs and IT portals with a single AI assistant called HAL. The change turned multi‑hour searches into answers delivered in seconds, directly inside the tools engineers already use.
The Problem: Fragmented Knowledge in a Growing Engineering Org
HEMA had two layers of internal knowledge. The first – a detailed service catalog mapping teams, services, APIs and business capabilities – was well‑structured and kept up‑to‑date. The second layer, procedural know‑how such as “how do I request API access?” or “what is the rule for X?”, was scattered across ad‑hoc messages, personal notes and a handful of obscure portals. When the engineering staff grew beyond the “ask the person next to you” model, onboarding slowed, answers varied, and developers spent whole afternoons hopping between three or four internal sites.
How MCP and Bedrock AgentCore Work Together
Model Context Protocol (MCP) is a standardized API that lets an AI client call a backend “tool” – for example a knowledge‑base search or an internal REST endpoint – without writing custom glue code for each integration. An MCP‑compatible client (the HAL web chat, Kiro, Claude, etc.) sends a request, receives a JSON response, and can chain multiple tools together.
Amazon Bedrock AgentCore provides the runtime for agents, a managed retrieval‑augmented generation (RAG) service called Knowledge Bases, and out‑of‑the‑box features such as conversation memory, content guardrails and authentication helpers. The key pieces used by HEMA were:
- Gateway – automatically turns OpenAPI specs or Lambda functions into MCP‑compatible tools.
- Identity – supplies JWT‑based authentication (Microsoft Entra ID) and OAuth token handling.
- Runtime – hosts the agent container and its short‑term memory.
- Memory & Guardrails – keep the conversation context and filter content, with EU inference regions and Dutch‑language support.
Together, MCP gives a uniform “tool” surface, while AgentCore supplies the plumbing that turns those tools into a live, secure assistant.
Building HAL: Two‑Step Rollout
| Feature | Step 1: Standalone HAL | Step 2: MCP‑Enabled HAL |
|---|---|---|
| User interface | Dedicated Next.js chat page | Existing tools (IDE, Kiro, Claude) via MCP |
| Authentication | AWS IAM SigV4 for internal APIs | Microsoft Entra ID JWT for external clients |
| Knowledge sources | Direct calls to Bedrock Knowledge Bases; internal APIs via AgentCore Gateway | Same sources, exposed as MCP tools through an Entra‑authenticated Gateway |
| Extensibility | Limited to the web UI | Any MCP‑compatible client can be added without code changes |
| Deployment complexity | Single AgentCore runtime | Two Gateways (IAM and Entra) plus an auth‑proxy |
Step 1 – a self‑contained assistant
HEMA first packaged the Strands agent in a Linux/ARM64 container and served it through AgentCore runtime. The agent queried three Knowledge Bases – IT documentation, API specs, and Kafka schema catalog – via the Bedrock Retrieve API. For live data, the agent called internal APIs through an AgentCore Gateway that used IAM SigV4 signatures. Because the gateway could ingest OpenAPI definitions directly, no bespoke MCP server was needed. The result was a functional chat UI where engineers typed a question and received a concise answer in seconds.
Step 2 – opening HAL to daily tools
The web UI proved useful, but developers spend most of their day in IDEs or Slack‑like assistants. To avoid a new portal, HEMA added a second AgentCore Gateway that trusted Microsoft Entra ID instead of IAM. An MCP auth‑proxy in front of the gateway translated the standard MCP OAuth flow into Entra‑specific tokens, handling discovery documents, scope rewrites and a stubbed Dynamic Client Registration (DCR) endpoint. External clients now call the same Knowledge Bases and live APIs through MCP, but they never see AWS credentials. The proxy’s only responsibility is token exchange; all business logic stays inside AgentCore.
What Changes and What to Watch
The headline change is where knowledge is accessed, not what knowledge exists. By exposing the service catalog and procedural docs through MCP, HEMA eliminated the need for engineers to remember which portal holds which answer. In practice this means:
- Speed: Answers that previously required three‑hour portal navigation now appear in a chat window or IDE pop‑up within seconds.
- Consistency: The same agent powers every client, so the answer does not depend on which wiki a user opened.
- Security posture: Access is governed by existing Azure AD groups; no AWS keys leave the perimeter.
The trade‑off is added operational complexity. Two gateways and an auth‑proxy mean more moving parts to monitor, and the stubbed DCR endpoint is a shortcut that could become a maintenance burden if true dynamic registration is ever required. Also, exposing live APIs via MCP does not automatically make them “agent‑friendly”; HEMA plans to refactor some OpenAPI specs to provide higher‑level intents rather than low‑level CRUD calls. Finally, the solution relies on Bedrock’s EU inference regions and Dutch‑language guardrails – teams outside the EU or without multilingual support would need to evaluate latency and compliance.
Who should care? Small to mid‑size enterprises with an existing service catalog but fragmented procedural docs can replicate the pattern without building a full‑scale LLM platform. Large organizations that already run many internal portals may find the cost of maintaining multiple Gateways outweighs the speed gains. What to watch next are two emerging pieces: (1) the maturity of MCP as an open standard – if other vendors adopt it, cross‑cloud tool integration becomes easier; and (2) Bedrock Guardrails evolution, especially for non‑English languages, which directly impacts user trust in a production assistant.
Quick Start: Try a Similar Setup Today
- Gather a structured knowledge source – export a CSV or JSON of your service catalog, or point to an existing OpenAPI spec.
- Create a Bedrock Knowledge Base – upload the docs and enable the Retrieve API (no code required).
- Spin up an AgentCore runtime – use the AWS CDK template from the Bedrock examples; choose a small container image for a proof‑of‑concept.
- Expose the Knowledge Base via a simple Lambda – the Lambda just forwards the Retrieve request and returns the JSON payload.
- Add an MCP Gateway – configure the Gateway with your Lambda as a tool, and protect it with either IAM or an Azure AD‑issued JWT.
- Connect a client – a minimal Next.js chat page or a VS Code extension can now send a question to the MCP endpoint and display the answer.
Within a day you can replace one portal with a searchable AI assistant and measure the time saved. If the pilot works, iterate by adding more procedural docs, refactoring APIs for higher‑level actions, and gradually opening the gateway to more tools.
