What a lens is, and what this one is for
Lesson 1 of 5 in The Well-Architected Agentic AI Lens: 41 Questions Worth Borrowing.
AWS Well-Architected is not a product. It is a review instrument: a fixed list of questions you answer about a workload, out loud, with the people who built it in the room. You do not pass it. You work through it, and the output is a list of risks you have now named — some of which you fix, some of which you accept in writing.
The framework has six pillars — operational excellence, security, reliability, performance efficiency, cost optimization, sustainability — and each pillar asks a handful of questions with best practices underneath. A lens narrows that instrument onto one kind of workload. There are lenses for serverless, for data analytics, for machine learning, for SaaS. A lens adds workload-specific questions to the generic pillars and drops the ones that do not apply.
On 10 June 2026 AWS published the Agentic AI Lens, and it is the most complete public checklist yet written for the question what changes when software starts acting on its own? Six pillars, 41 focus-area questions, 150 best practices. Every practice carries a risk rating, and the distribution is the tell: 90 High, 59 Medium, 1 Low. Sixty percent of this lens is marked High risk, which is AWS quietly saying that most agent deployments in 2026 are missing structural things, not polish.
That density is also the module’s reason to exist. Nobody reads 150 best practices, so the lens gets skimmed, bookmarked, and quoted at rather than used. The 41 questions are the part with leverage — they fit on two screens, and you can walk a real system through them in an afternoon.
Now the part the document cannot say about itself, and the reason this module sits in a vendor-neutral course.
The questions travel. The answers mostly do not. How do you secure inter-agent communication? is a question any team on any platform has to answer. Use this managed service with Cedar policies is an answer that exists on exactly one cloud. The lens interleaves the two, because it is AWS’s document and its job is to make AWS workloads better — which is legitimate, and worth reading with your eyes open. Read the 41 questions as an agenda. Read the implementation guidance as one vendor’s implementation.
And a completed review is not a certificate. There is no pass mark, no score, no badge. A finished Well-Architected review is a record of conversations you had and decisions you made, including the risks you looked at and chose to live with. Nothing about completing it makes a system secure, reliable, or compliant. If someone tells you an agent is safe because it went through the lens, they have described a meeting, not a property of the system.
Agents reason, not only respond
One user request can fan out into several model calls, a handful of tool invocations, some memory retrievals, and messages to other agents — each of them adding latency, cost, and a new way to fail. Request-response thinking assumes one call in, one answer out, so every intuition it gives you about capacity, timeouts and cost per request is calibrated wrong by an order of magnitude.
Why a normal cloud review misses it: it asks how fast an endpoint responds. It has no question for how many times did the system talk to itself before answering.
Agents act autonomously
The agent invokes tools, changes data, and calls other systems without a human authorising each step. That is the whole value proposition and the whole problem: your controls can no longer assume a person reviewed this specific action.
Why a normal cloud review misses it: conventional least privilege scopes permissions to a service. An agent needs permissions scoped to a service and an approval gate on the subset of actions that are irreversible — a distinction the base framework has no question for.
Agent behaviour is stochastic
The same input can produce different outputs on different runs. Non-determinism is not a bug to be configured away; it is the operating condition. So reliability has to be argued statistically — behavioural monitoring, evaluation over many runs, graceful degradation — rather than by deterministic testing alone.
Why a normal cloud review misses it: it asks whether you have tests. It does not ask whether a passing test means anything, which for a stochastic component is the only question that matters.
Agents collaborate
Add a second agent and you have bought coordination overhead, handoff complexity, and distributed failure modes — plus a new one that distributed systems do not have: one agent’s output is another agent’s instructions. Orchestration patterns, communication protocols and conflict resolution stop being implementation details and become architecture.
Why a normal cloud review misses it: microservice guidance assumes services agree on a contract. Two agents can both follow the contract and still deadlock, loop, or talk each other into scope neither was granted.
Agents remember
Persistent memory across sessions is what makes an agent feel useful — and it introduces data integrity, privacy and cost problems that stateless applications never face. Every stored sentence is instruction-shaped input on a future turn, and everything you keep you pay to carry in the context window again and again.
Why a normal cloud review misses it: it treats a datastore as a datastore. It has no question for what happens when a false or hostile fact is written into memory and then retrieved with authority for a month.
Key terms: agent, autonomy, non-determinism, memory, multi-agent system, approval gate
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.