AWS's seven-layer reference architecture for production agents

Four AWS solutions architects published a post on 9 November 2026 describing the Pluggable Agentic AI Framework, a reference architecture for taking multi-agent applications from prototype to production on Amazon Bedrock AgentCore. The authors say the services named in each layer are examples from their reference implementation, not required choices. The post is vendor-published and contains no customer results.

The seven layers

The authors list the layers as data and knowledge, model and inference, orchestration, security and guardrails, application, observability, and agentic operations. Each has what they call a stable contract, so a team can swap the technology underneath without redesigning the rest.

• Model and inference: choose models by configuration, not hard-wired logic. Use smaller, faster models for simple tasks and larger ones for harder requests, evaluated on realistic business data. The post names LiteLLM as one proxy that gives a common interface across providers.
• Orchestration: use a single agent for straightforward tasks and a supervisor with specialists for cross-domain work. The authors warn that one do-everything agent grows its context window, latency and tool sprawl, and can push agents past their intended boundaries.
• Security: authenticate every request from a user, agent or workflow; check each tool call against fine-grained policy before it executes; grant temporary scoped credentials rather than persistent secrets; mask PHI (personal health information) and PII (personally identifiable information); keep a tamper-evident audit trail; route high-impact actions through human approval; add circuit breakers.
• Observability: collect end-to-end traces, cost and token use per request, time to first token and error rates, and have dashboards ready before launch.
• Agentic operations: score every production session for groundedness, accuracy and safety, with a regression gate that catches quality drops before release.

The reference implementation

The sample is a retail customer-support agent. A supervisor receives a refund request and hands it to an Order agent, which looks up delivery and purchase details in Amazon DynamoDB, and a Refund agent, which reads tier-based policy rules from a knowledge base and computes eligibility from the delivery date, today's date and the customer's loyalty tier. The authors say every tool call passes through AgentCore Gateway, where policy is enforced, and is traced end to end so a wrong calculation can be pinned to a layer.

The post also suggests a cheap decision model at the application boundary that scores in one call whether a request is in scope, needs a human or is urgent, so the full agent loop runs only when it adds value. It also says an agent registry should catalogue each agent's tools, skills and owner.

What the post leaves out

It reports no deployment, no cost per conversation, no latency and no accuracy or refusal rates, so none of its design choices is shown to pay off. It is also written to showcase AWS services such as AgentCore Identity, Guardrails and Evaluations. The authors say the sample is not a substitute for production security hardening, testing and review.

What a team can take from it

The portable parts are the controls. Give each agent a narrow tool list and name an owner for it. Check authorisation per tool call, not per session. Log every significant decision somewhere tamper-evident. Put a regression gate on quality before each release, and track cost per request from day one. A team can test any of these on its own stack without buying the AWS products the post names.