The Pulse

AWS publishes seven-layer framework for enterprise AI agents

AWS has published a seven-layer reference architecture for building and operating multi-agent applications. Its example implementation routes a retail customer’s order-status and refund questions to specialist agents.

AI.info Team · Written with AI · fact-checked · 2026-11-10

A blueprint for production systems

A seven-layer reference architecture for multi-agent applications was published by AWS on Nov. 9, with AWS describing it as a way to move agent systems from prototypes into production. The framework assigns a distinct responsibility and a stable contract to each layer, while allowing organizations to choose alternatives to the services used in its example implementation.

The layers run from data and knowledge, model and inference, and orchestration through security and guardrails, application, observability, and agentic operations. The framework is presented by AWS as a composable blueprint rather than a required vendor stack, with each layer intended to connect through defined interfaces.

Specialists, security and controls

For orchestration, AWS recommends matching the setup to the work: a single agent for straightforward tasks, or a supervisor that delegates complex workflows to specialist agents. The post cautions that accumulating tools, instructions and context in one agent can increase latency and harm accuracy; it advocates limiting each specialist to its granted tools.

The architecture also calls for a centralized registry of agents, their tools, skills and owners, so supervisors can discover and invoke specialists using protocols such as MCP or A2A. On security, AWS advises treating external content as untrusted, authenticating each request and using fine-grained access controls before tool calls. It also recommends temporary, scoped credentials, masking sensitive information, tamper-evident audit trails, human approval for high-impact actions and circuit breakers for anomalous behavior.

The application layer is described by AWS as a thin interface for presenting conversations and passing requests to orchestration, rather than a place for business logic. A decision model can score whether a request is in scope, requires a person or is urgent, returning probabilities for the application to act on.

Monitoring and a retail example

The framework calls for observability from the start, including logs, metrics and end-to-end traces to assess whether agents completed tasks correctly. Teams should also collect per-request cost and token use, time to first token and security information, and monitor latency, errors and spending, AWS says. Its operations layer adds continuous evaluation: the post recommends scoring production sessions for groundedness, accuracy and safety, with a regression gate to catch quality drops.

A ready-to-run retail customer-support example for order status and refund eligibility is included. A supervisor delegates a refund request to Order and Refund agents: the first retrieves delivery and purchase details from DynamoDB, while the second checks policy rules and calculates eligibility using delivery date, current date and customer loyalty tier. Calls pass through the AgentCore Gateway for access control, and the example traces them through the observability layer.

Designed to be changed

Stable contracts between layers allow teams to replace underlying technologies without redesigning the whole system, AWS says. Organizations can keep existing inference, security and observability tools, fill gaps and adopt other capabilities incrementally; the sample implementation can also be adapted with different domain logic, the post says.

The workshop and public sample repository are starting points; the implementation does not replace production security hardening, testing or review, the post warns.