In an AWS blog post co-authored by Mauro Rallo and Patrick van der Plas from the Dutch retail chain HEMA, the company outlined how it built an internal knowledge layer on top of Amazon Bedrock AgentCore and the Model Context Protocol (MCP). HEMA, which has operated for 100 years and runs over 750 stores across multiple countries, supports its operations through a technology organization comprising engineers, product owners, and business analysts. When engineers at HEMA needed an answer, they went portal-hopping, navigating disconnected wikis, service catalogs, and IT portals to find it. To reduce this friction, the retailer developed an internal assistant named HAL to unify information and make it accessible directly within the teams' existing working tools.
The Challenge of Knowledge Fragmentation and Portal-Hopping
According to the post, the organization's knowledge problem was divided into two primary layers. The first layer, consisting of structured infrastructure knowledge, was in good condition: over the years, the company maintained a service catalog mapping people to teams, teams to services, and services to the APIs they expose and the business capabilities they support. Structured data from systems such as the product information management (PIM) engine and data-mesh tables had been imported and organized, so that for anything about what exists and who owns it, the answer was usually available to whoever knew where to look.
The second layer represented the main gap: knowing what exists is not the same as knowing how to perform specific tasks. Procedural questions, such as how to request API access, provision a new group, or follow internal rules, had no single home. As the engineering organization expanded and onboarded new engineers, the informal model of directly asking peers in the room ceased to function, and written documentation was scarce. This situation led to slow onboarding for new hires, inconsistent answers, and constant switching across three or four different portals—a process that sometimes spanned an entire afternoon.
Choosing MCP and Amazon Bedrock AgentCore
HEMA's solution was structured around two complementary goals. The first goal, assigned to the HAL assistant, was to consolidate fragmented knowledge into a single, governed source of truth. The second goal, addressed via the MCP protocol, was to deliver that knowledge directly to users within the tools they already use, rather than requiring them to visit another portal.
The adoption of MCP provided a standardized interface between AI clients and backend capabilities, allowing each knowledge source to be exposed once as an MCP tool and consumed by various clients (such as the HAL chat UI, Kiro, Claude, and other agents) without requiring bespoke integrations for each tool. Concurrently, Amazon Bedrock AgentCore allowed the company to build and connect agents without having to set up and operate dedicated MCP server infrastructure. The platform capabilities utilized in the project included Gateway (directly converting OpenAPI specifications and AWS Lambda functions into MCP tools), Identity (managing inbound JWT authentication and outbound OAuth2 to internal APIs), Runtime (hosting the Strands-built agent as a container), as well as memory components and Amazon Bedrock Guardrails for content filtering and Dutch-language support.
Development Stages: From Standalone Assistant to Daily Tool Integration
The development of HAL took place in two primary stages:
-
Standalone Assistant: The initial version consisted of a Next.js web chat interface connected directly to an internal agent (a Strands agent running as a Linux/ARM64 container on AgentCore Runtime). At this stage, the agent accessed knowledge along two paths: direct semantic search over knowledge bases using local Strands tools that call the Amazon Bedrock Retrieve API without an intermediate gateway, and a connection over MCP to an AgentCore Gateway (authenticated via AWS IAM SigV4) for live data queries, OpenAPI specifications, and the service catalog. The knowledge bases built on Amazon Bedrock Knowledge Bases included IT documentation, API specifications, Kafka topics and Avro schemas, Data Consolidation Layer (DCL) channels, and the service catalog. Retrieval quality was enhanced using Bedrock reranking and metadata filtering by team ID.
-
Opening Access to External Tools via MCP: To allow external tools such as Kiro and Claude to access knowledge without distributing AWS credentials, a second AgentCore Gateway was established. Because a gateway supports only a single inbound authentication type, the second gateway was configured with Microsoft Entra ID authentication (using a custom JWT) for external clients, sharing read-only knowledge bases without sharing code with the internal gateway.
Authentication Mechanism and Handling DCR
To enable authentication for external clients without AWS credentials, an MCP Auth Proxy (built on Amazon API Gateway v2 HTTP API and a single Lambda function) was deployed in front of the Entra Gateway. This component bridges the MCP OAuth specification with Entra ID requirements: it serves OAuth discovery documents, rewrites the requested scope, strips the legacy resource parameter unsupported by Entra v2.0, appends response_mode=query to capture authorization codes in desktop applications, and proxies requests to the /mcp route along with the Bearer token.
Furthermore, because MCP clients expect Dynamic Client Registration (DCR) support, the proxy returns a fixed, pre-provisioned client ID by emulating a POST /register call rather than implementing actual dynamic registration. This setup allows end users to configure only the proxy URL and an empty scopes list, complete a browser login on the first connection, and benefit from automatic token refresh.
Testing, Deployment, and Cross-Role Usage
The project infrastructure was defined using the AWS Cloud Development Kit (AWS CDK) in a single TypeScript monorepo with configurations retrieved from AWS Systems Manager (SSM). Prior to production deployment, the system was deployed to a staging environment and tested for one month by engineers and business users to validate response quality and information coverage.
Today, HAL serves a broad range of roles across HEMA:
- Engineers and Developers: Utilize the technical surface, including documentation, API specifications, Kafka topics, the service catalog, and DCL channels from within Kiro and the chat UI.
- Product Owners: Rely on the assistant for procedural information and process documentation that previously lacked a centralized source.
- Business Analysts: Use it to retrieve infrastructure data from the service catalog, such as service mappings, APIs, and team ownership.
Internal distribution of capabilities is managed via an "Everyone Skill" and steering files maintained within the company's monthly AI Development Forum.
The Next Step: From Answers to Actions
While HAL currently operates in a read-only capacity to provide answers to questions, the planned next phase involves turning it into an action layer. Because the organization's existing portals already support APIs and integrate with Microsoft Entra ID Single Sign-On, the assistant will be able to expose these operations as MCP action tools under the same Active Directory group-based authorization model. The primary example highlighted is provisioning a new AWS account: rather than an engineer logging into a dedicated portal, the request could be executed directly from the chat interface or MCP-enabled agent tools. And because HAL already serves product owners and business analysts, the same action pattern extends naturally beyond developer operations to the wider set of operational requests those roles make every day. The lesson is that the read architecture earns the write step: by getting identity, multi-client access, and governance right for answers, the groundwork has been laid for actions.