Back to Blog
    Agentic AI8 min read

    The AWS Well-Architected Agentic AI Lens: a working reference

    September 21, 2026

    AWS published the Well-Architected Agentic AI Lens on 10 June 2026, and states that it will be updated as the field matures and new patterns emerge from production deployments. Cite the publication date whenever you reference it in a standard or a review record, because the content is expected to move.

    What the Well-Architected Framework is

    The AWS Well-Architected Framework is a set of foundational questions used to check whether an architecture matches cloud best practice. It gives a consistent method for evaluating a system against the properties expected of modern cloud workloads, and it points to improvements based on the current state of that architecture.

    The framework rests on six pillars: operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability.

    Pillar priorities are not fixed. When designing a workload you trade pillars against each other according to business need, and those business decisions set engineering priority. A development environment may accept lower reliability to reduce cost. A mission-critical system may accept higher cost for reliability. An ecommerce system may prioritize performance because customer satisfaction drives revenue. Security and operational excellence are the two that are generally not traded away.

    A lens extends the framework to a specific workload type, keeping the same six-pillar structure and adding questions, best practices and implementation guidance for that domain.

    Why agentic systems need a lens of their own

    Existing cloud and generative AI guidance does not address five properties that agentic systems introduce. Each one changes which architectural questions matter.

    Agents reason, they do not only respond. One user request can produce several inference calls, tool invocations, memory retrievals and messages between agents. Every step adds latency, cost and a new failure surface. Request-response optimization does not describe an iterative reasoning loop, so capacity, timeout and cost models built for single-call services do not transfer.

    Agents act autonomously. They invoke tools, modify data and reach external systems without a human instruction at each step. That requires permission boundaries, security controls and human oversight designed for autonomous operation rather than for a user clicking a button.

    Agent behavior is stochastic. LLM-driven decisions are non-deterministic: the same input can produce different output across invocations. Reliability therefore depends on behavioral monitoring, evaluation frameworks and graceful degradation, not on deterministic test suites alone.

    Agents collaborate. Multi-agent systems add coordination overhead, handoff complexity and distributed failure modes. Orchestration patterns, communication protocols and conflict resolution become architectural concerns rather than implementation details.

    Agents remember. Persistent memory across sessions supports personalization and learning, and it introduces data integrity, privacy and cost questions that stateless applications never had to answer.

    The six pillars as the lens adapts them

    Each pillar keeps its framework meaning and gains agent-specific scope.

    Six pillars of the AWS Agentic AI LensOperational excellence: Prompt lifecycle, Behavioural monitoring. Security: Agent identity, Tool permissions. Reliability: Failure recovery, Graceful degradation. Performance efficiency: Reasoning latency, Model and memory choices. Cost optimization: Reasoning-loop costs, Cost visibility. Sustainability: Resource reuse, Human expertiseAWS WELL-ARCHITECTEDSix pillars. Agent-specific scope.One workload, six architectural perspectives.AGENTIC WORKLOADReasoning · tools · memory · coordinationOperationalexcellencePrompt lifecycleBehavioural monitoringSecurityAgent identityTool permissionsReliabilityFailure recoveryGraceful degradationPerformanceefficiencyReasoning latencyModel and memory choicesCost optimizationReasoning-loop costsCost visibilitySustainabilityResource reuseHuman expertiseScope summaries adapted from the AWS Agentic AI Lens.Use alongside the AWS Well-Architected Framework.Six pillars of the AWS Agentic AI LensOperational excellence: Prompt lifecycle, Behavioural monitoring. Security: Agent identity, Tool permissions. Reliability: Failure recovery, Graceful degradation. Performance efficiency: Reasoning latency, Model and memory choices. Cost optimization: Reasoning-loop costs, Cost visibility. Sustainability: Resource reuse, Human expertiseAWS WELL-ARCHITECTEDSix pillars.Agent-specific scope.One workload, six architectural perspectives.AGENTIC WORKLOADOperational excellencePrompt lifecycleBehavioural monitoringSecurityAgent identityTool permissionsReliabilityFailure recoveryGraceful degradationPerformance efficiencyReasoning latencyModel and memory choicesCost optimizationReasoning-loop costsCost visibilitySustainabilityResource reuseHuman expertiseScope summaries adapted from AWS.Use alongside the Well-Architected Framework.
    PillarScope in this lens
    Operational excellenceRunning and improving autonomous agents through systematic practice: prompt lifecycle management, behavioral monitoring, human-in-the-loop governance
    SecurityAgent identities, tool access and data flows, with protection against prompt injection, privilege escalation and manipulation of autonomous operations
    ReliabilityPredictable task execution, automatic recovery, and partial functionality maintained under adverse conditions
    Performance efficiencyCognitive pipelines, model selection, memory access and multi-agent coordination, tuned for responsiveness and scale
    Cost optimizationCost as a primary design input: right-sized model and memory capability, and full cost visibility
    SustainabilityModular, reusable architectures that maximize resource efficiency and keep adoption sustainable

    Practices are identified as AGENT plus a pillar code plus a number, so AGENTSEC03 is the third security practice and AGENTCOST01 the first cost practice. Individual best practices inside a practice carry a BP suffix, as in AGENTREL02-BP05. Pillar pages group their practices under focus area names, and those names are phrased differently from the question titles: the reliability focus area "Predictable task execution" holds the question titled "Design for atomic tasks, least-privilege permissions, and clear instruction protocols". Both forms appear in the documentation, so decide which one your internal standard quotes.

    How to use the lens

    The lens is used alongside the Well-Architected Framework, not instead of it. Each pillar contains focus areas with guiding questions, best practices, implementation guidance and code examples specific to agentic workloads. Four situations call for it:

    • Designing a new agentic system, or adding agentic capability to an existing application
    • Reviewing a deployed agentic system for architectural improvement
    • Evaluating the reliability, security or cost profile of an agent-based workflow
    • Setting organizational standards for agentic development and operations

    For a team working through the lens the first time, AWS sets out five steps: read the design principles to understand what drives decisions across the pillars; agree the definitions so the vocabulary is shared; work through each pillar's focus areas and best practices, taking high-risk practices first; use the implementation guidance and code examples as starting points and adapt them to your stack; then run recurring Well-Architected reviews with this lens as the system changes.

    A custom lens definition is available in the aws-samples custom lens repository, in the `agentic-ai-lens` directory alongside the other published lenses. Download the lens file, then in the Well-Architected Tool open Custom lenses, choose Create custom lens, then Import lens and upload the JSON. The Tool's preview experience lets you walk the questions before attaching a workload. That turns the lens from a document into a score against a named workload, which is the difference between reading guidance and recording a review.

    Responsible AI is distributed, not appended

    The lens does not isolate responsible AI in its own chapter. It states five principles and names the practice that implements each one, which is the part worth copying into an internal standard because it turns a principle into a control someone can test.

    PrincipleStatement in the lensPractice
    Bounded autonomyEvery agent operates within explicitly defined scope boundaries, with guardrails that constrain behavior regardless of inputs receivedAGENTSEC04
    Transparency and explainabilityAgent decisions are logged, traced and auditable, so teams can reconstruct exactly what happened during any executionAGENTOPS05
    Human oversightTiered oversight models match the level of human review to the risk and reversibility of each agent actionAGENTREL02-BP05
    Goal alignmentEvaluation frameworks continually assess whether agents achieve intended objectives rather than pursuing misaligned goalsAGENTOPS06
    Organizational sustainabilityAgent adoption preserves critical human expertise and institutional knowledgeAGENTSUS03

    The tiered oversight model is defined concretely: low-risk actions proceed autonomously, medium-risk actions trigger notification, high-risk actions require explicit approval. Risk and reversibility are the two axes, which is a more usable test than a blanket human-in-the-loop requirement, because it forces a per-action classification rather than a policy statement.

    Reading paths

    AWS does not expect every team to implement every practice. The lens defines four reading paths by deployment stage. The titles below are quoted from the roadmap.

    Four reading paths through the AWS Agentic AI LensBuilding your first agent: AGENTOPS01 Roles and handoffs; AGENTREL02 Task boundaries; AGENTSEC03 Identity and access; AGENTSEC08 Input / output validation. Moving to production: AGENTOPS05 Tracing and monitoring; AGENTOPS06 Testing and evaluation; AGENTPERF02 Pipeline performance; AGENTCOST01 Reasoning-loop costs; AGENTCOST02 Model and token costs. Scaling to multi-agent systems: AGENTREL04 Coordination and fallback; AGENTPERF05 Orchestration performance; AGENTSEC06 Inter-agent security; AGENTCOST05 Workflow cost attribution. Hardening an existing deployment: AGENTSEC04 Guardrails and oversight; AGENTSEC07 Oversight protection; AGENTREL06 Legacy-system resilience. Reading priorities are not release gates.AWS AGENTIC AI LENSChoose your reading pathStart with the situation you are reviewing.Building your first agentDefine scope and boundariesAGENTOPS01Roles and handoffsAGENTREL02Task boundariesAGENTSEC03Identity and accessAGENTSEC08Input / output validationMoving to productionMake operation measurableAGENTOPS05Tracing and monitoringAGENTOPS06Testing and evaluationAGENTPERF02Pipeline performanceAGENTCOST01Reasoning-loop costsAGENTCOST02Model and token costsScaling to multi-agent systemsCoordinate agents reliablyAGENTREL04Coordination and fallbackAGENTPERF05Orchestration performanceAGENTSEC06Inter-agent securityAGENTCOST05Workflow cost attributionHardening an existing deploymentStrengthen controls and resilienceAGENTSEC04Guardrails and oversightAGENTSEC07Oversight protectionAGENTREL06Legacy-system resilienceReading priorities, not release gates.Apply relevant security and oversight controls from the start.AWS roadmap IDs; descriptions shortened.Four reading paths through the AWS Agentic AI LensBuilding your first agent: AGENTOPS01 Roles and handoffs; AGENTREL02 Task boundaries; AGENTSEC03 Identity and access; AGENTSEC08 Input / output validation. Moving to production: AGENTOPS05 Tracing and monitoring; AGENTOPS06 Testing and evaluation; AGENTPERF02 Pipeline performance; AGENTCOST01 Reasoning-loop costs; AGENTCOST02 Model and token costs. Scaling to multi-agent systems: AGENTREL04 Coordination and fallback; AGENTPERF05 Orchestration performance; AGENTSEC06 Inter-agent security; AGENTCOST05 Workflow cost attribution. Hardening an existing deployment: AGENTSEC04 Guardrails and oversight; AGENTSEC07 Oversight protection; AGENTREL06 Legacy-system resilience. Reading priorities are not release gates.AWS AGENTIC AI LENSChoose yourreading pathStart with the situation you are reviewing.Building yourfirst agentDefine scope and boundariesAGENTOPS01Roles and handoffsAGENTREL02Task boundariesAGENTSEC03Identity and accessAGENTSEC08Input / output validationMoving to productionMake operation measurableAGENTOPS05Tracing and monitoringAGENTOPS06Testing and evaluationAGENTPERF02Pipeline performanceAGENTCOST01Reasoning-loop costsAGENTCOST02Model and token costsScaling tomulti-agent systemsCoordinate agents reliablyAGENTREL04Coordination and fallbackAGENTPERF05Orchestration performanceAGENTSEC06Inter-agent securityAGENTCOST05Workflow cost attributionHardening anexisting deploymentStrengthen controls and resilienceAGENTSEC04Guardrails and oversightAGENTSEC07Oversight protectionAGENTREL06Legacy-system resilienceReading priorities, not release gates.Apply relevant security and oversightcontrols from the start.AWS roadmap IDs; descriptions shortened.

    Building your first agent. Establish scope, security boundaries and predictable behavior.

    • AGENTOPS01 Define agent roles, success criteria, and handoff procedures
    • AGENTREL02 Design for atomic tasks, least-privilege permissions, and clear instruction protocols
    • AGENTSEC03 Establish agent identity, least-privilege access, and strong authentication
    • AGENTSEC08 Validate inputs and filter outputs before going to production

    Moving to production. Add observability, evaluation, cost control and pipeline optimization.

    • AGENTOPS05 Implement tracing, anomaly detection, and operational dashboards
    • AGENTOPS06 Establish testing and evaluation frameworks with LLM-as-judge
    • AGENTPERF02 Optimize cognitive pipelines, model selection, and execution paths
    • AGENTCOST01 Control reasoning loop costs and multi-agent coordination overhead
    • AGENTCOST02 Right-size model selection and optimize token consumption

    Scaling to multi-agent systems. Orchestration reliability, coordination security, workflow performance.

    • AGENTREL04 Implement arbiter patterns, capability taxonomies, and fallback mechanisms
    • AGENTPERF05 Optimize orchestration patterns and multi-agent collaboration models
    • AGENTSEC06 Secure inter-agent communication, trust boundaries, and coordination
    • AGENTCOST05 Implement cost attribution across multi-agent workflows

    Hardening an existing deployment. Security controls, resilience, human oversight.

    • AGENTSEC04 Implement guardrails and human-in-the-loop for critical decisions
    • AGENTSEC07 Protect human oversight and detect rogue agents
    • AGENTREL06 Integrate with legacy systems reliably with fallbacks and idempotency

    Read as a sequence, the four paths describe a maturity order: scope and identity first, then evidence and cost, then coordination, then containment. A deployment that skipped the first path rarely benefits from starting at the fourth.

    The principles AWS expects to outlast the content

    The lens states five principles as durable regardless of how the technology changes, and each has a concrete reading in the document.

    • Modularity. Systems built from specialized single-purpose agents with clear interfaces are easier to test, debug, scale and optimize than monolithic agents. The actor model, where each agent encapsulates one capability and communicates only through messages, is named as the reference pattern.
    • Observability. Unexpected behavior is inevitable with stochastic components, so distributed tracing, structured logging, behavioral baselines and anomaly detection are designed in from the start rather than added after an incident.
    • Graceful degradation. Every critical dependency has a defined fallback that activates automatically, and reduced capability is communicated rather than hidden.
    • Human oversight. Tiered by risk and reversibility, with the stated goal of applying human judgment where it matters instead of removing it.
    • Cost awareness. Token-based pricing combined with iterative reasoning makes cost a design concern rather than a post-deployment optimization.

    Where the lens stops

    Three boundaries are worth stating, because they determine how much of a review the lens can carry on its own.

    It is architecture guidance, not an operating model. AGENTOPS01 requires agent roles, success criteria and handoff procedures to be defined; it does not assign ownership inside an organization, nor specify who approves a given class of agent action. That allocation is organizational and has to be written per agent.

    It does not produce audit evidence. The security and operational pillars require identity, tracing and non-repudiation, which are the mechanisms evidence is built from. Mapping each control to an artifact a regulator or auditor will accept is separate work, and in validated environments it is usually the larger part.

    It does not decide portfolio economics. Cost attribution across multi-agent workflows is in scope as a practice, and the lens defines an agent portfolio with tracked ownership, cost profiles and lifecycle state. Deciding which agents earn their cost, and retiring the ones that do not, stays a management judgment outside the document.

    Sources

    Back to BlogDiscuss on LinkedIn