HEMA’s engineers used to spend afternoons hunting answers across wikis, service catalogs, and IT portals. The Dutch retailer, with more than 750 stores, built an internal assistant called HAL on Amazon Bedrock AgentCore to collapse that search into seconds. The interesting part for builders isn’t the chatbot. It’s how HEMA split one knowledge layer across two MCP gateways because authentication types don’t mix.
The knowledge existed; the path to it didn’t
HEMA’s service catalog already mapped people to teams, teams to services, and services to the APIs and business capabilities behind them. Structured data from the PIM engine and data-mesh tables was imported and organized. The gap was procedural knowledge: how to request API access, how to get a group provisioned, what the rule is for a given case. When the organization was small, people just asked the person next to them. As it grew, that stopped scaling, and little written documentation existed to fall back on.
According to the AWS Machine Learning Blog write-up, co-written with Mauro Rallo and Patrick van der Plas of HEMA, the result was slow onboarding, inconsistent answers, and constant context-switching. Answers that once took three or four portals now arrive inside the IDE or a chat window.
Two gateways, because one auth type isn’t enough
HAL started as a standalone Next.js chat UI backed by a Strands agent running as a Linux/ARM64 container on AgentCore runtime, with AgentCore memory for short-term context and Bedrock Guardrails for filtering. The agent reaches knowledge two ways: local Strands tools call the Bedrock Retrieve API directly over Knowledge Bases, while live APIs, OpenAPI specs, service-catalog lookups, and people queries go over MCP to an AgentCore Gateway authenticated with IAM SigV4.
Step two was opening that knowledge to external MCP clients like Kiro and Claude without handing out AWS credentials. An AgentCore Gateway supports only one inbound authentication type, so HEMA added a second gateway authenticated through Microsoft Entra ID with a custom JWT. The two gateways share only the read-only Knowledge Bases. No shared code means the external surface can change or fail without touching the internal agent.
That constraint is the practical takeaway. If you assume one gateway can serve every client, you’ll discover the auth limit late, after you’ve wired credentials into places you’d rather not. Splitting by audience is a design decision you can make on day one.
Where the shortcut shows up in the tool definitions
HEMA points AgentCore Gateway at existing OpenAPI specifications and a Lambda function for semantic search. There’s no custom MCP server code to write or run. The team is explicit that this isn’t the ideal end state: an API designed for system-to-system use doesn’t always map cleanly onto a tool an agent can reason about, and they plan to refactor those definitions into more agent-friendly tools. For now, exposing the APIs as-is delivered high value for little effort.
Retrieval uses a two-step pattern: an initial Knowledge Base search answers most questions, and fetch_full_document pulls the whole document when a chunk isn’t enough. Bedrock reranking improves semantic queries, and team_id metadata filtering handles team-scoped lookups.
This is the same tradeoff that shows up whenever you give an agent a tool surface: the interface you expose shapes what the model can do with it. If you’re weighing how much to invest before shipping, the earlier post on giving your coding agent deployment facts instead of just a model name makes a similar case for investing in the tool contract rather than the model choice.
What’s confirmed, and what’s still ahead
Confirmed: HAL runs on AgentCore runtime with Strands, Entra ID OAuth for external clients, read-only access today, access control driven by existing Active Directory groups, EU inference regions, and Dutch-language support. HEMA describes the architecture as the foundation for turning HAL from a read-only knowledge layer into an action layer. The supplied source doesn’t detail how that action layer will be governed, so treat write access as an open design question rather than a shipped capability.
If you’re building something similar, the sequencing is worth copying: prove the assistant in its own UI first, then open it to the tools people already use. The gateway split is the part that’s easy to get wrong and cheap to get right early.
Sources
AI-assisted summary compiled from the sources above, reviewed by a human before publishing.