The six pillars, one screen
Lesson 2 of 5 in The Well-Architected Agentic AI Lens: 41 Questions Worth Borrowing.
Here is the whole lens at a glance. The counts are AWS’s own summary table; the last column is this course’s reading of what each pillar is really for.
Two numbers are worth staring at. Reliability carries the most best practices (33) even though security has more questions — reliability is where the lens does the most engineering. And security has the most questions (9), which is the lens admitting that an agent is a system that reads untrusted text and then acts with real credentials, and that this generates more distinct problems than anything else in the architecture.
| Pillar | Questions | Practices (High risk) | What it is really about |
|---|---|---|---|
Operational excellence — AGENTOPS01–07 | 7 | 26 (18 High) | How you run the agent after the demo. Who owns it, how the prompt and tool schemas change under version control, whether you can reconstruct a run hours later, and what happens in the first five minutes when the agent is the incident. Almost none of it is needed to build a convincing prototype, which is exactly why teams have the least of it. |
Security — AGENTSEC01–09 | 9 | 30 (19 High) | Identity for a non-human caller, permissions that hold when the model is talked into something, memory that cannot be poisoned, and oversight that survives being manipulated. Note where the lens lands the same conclusion this course does: authorisation is decided by the runtime, not requested in the prompt. |
Reliability — AGENTREL01–08 | 8 | 33 (18 High) | Reliability cannot mean “same input, same output” here, so it means bounded behaviour: stay inside the task, retry without duplicating side effects, degrade to something defined instead of improvising, resume from a checkpoint. Mostly ordinary distributed-systems engineering with one new twist — the component that picks the next step is non-deterministic. |
Performance efficiency — AGENTPERF01–07 | 7 | 24 (16 High) | Agent latency is dominated by the number of loop iterations, not the speed of any one call. So the work is doing fewer turns, carrying less context, running independent subtasks in parallel, and streaming to hide the latency you cannot remove. |
Cost optimization — AGENTCOST01–07 | 7 | 24 (14 High) | Agents spend money by thinking, so a bug is a bill. The dominant cost is not price per token but how many times you resend a growing context — which makes most cost work identical to latency work, plus two things latency does not need: attribution (whose run was that?) and hard cutoffs (what stops a runaway?). |
Sustainability — AGENTSUS01–03 | 3 | 13 (5 High) | The narrowest pillar and the most misread. Part of it is resource efficiency. The larger part is organisational durability: keeping the specifications and the human expertise that let a team still understand its own agents after the authors leave, and decommissioning agents nobody uses. |
Now the two pillars that get skipped, and why skipping them is expensive.
Cost optimization gets skipped because it looks like finance. It is not — it is a containment control with a dollar sign on it. A reasoning loop has no natural budget: nothing in the architecture stops an agent from calling one more tool, re-reading a document it has already read, or delegating to a subagent that delegates back. Each iteration resends the entire growing context, so spend does not grow linearly with the work done, it grows with the square of a conversation that will not end. A daily spend alert is useless against this: a looping agent can burn a month of budget in an hour, and the alert fires after. The control that actually works is a hard per-run ceiling — tokens, iterations, tool calls — that halts the run rather than notifying a human, which is AGENTCOST07-BP01 and which reads much more like a kill switch than like a budget.
Sustainability gets skipped because everyone assumes it means carbon. Exactly one of its thirteen practices is about environmental footprint (AGENTSUS02-BP04, Medium). The pillar’s real content is that an agent nobody understands is a liability with credentials.
Three ideas in it are worth more than their placement suggests. Specifications (AGENTSUS03-BP03, High): the agent’s intended behaviour has to be written down somewhere other than the prompt, or the prompt becomes the only spec and nobody can say whether a change is a fix or a regression. Retained human competence (AGENTSUS03-BP01, High): a team that has automated away a skill can no longer supervise the automation — the reviewer who has not read a contract in a year cannot meaningfully approve the agent’s contract summary. And decommissioning (AGENTSUS03-BP04): an unowned agent still holds credentials, still has tool access, and still runs. Agent sprawl is not untidiness, it is an unmonitored attack surface with a payment method attached.
Cost: the failure mode
What happens. A research agent is given a broad question and a web-search tool. It searches, reads, decides it needs more, searches again. Nothing in the loop is wrong. Nothing errors. There is no stopping condition it can satisfy, because “enough research” is not checkable, so it runs until something external stops it — and the only external thing is the token budget of the underlying API, one call at a time.
Why the bill is non-linear. Turn 40 does not cost what turn 4 cost. The context now carries 39 turns of prior reasoning and tool output, and every turn resends all of it. Doubling the turn count roughly quadruples the spend.
What the lens asks for. Per-run ceilings that halt execution (AGENTCOST07-BP01, High), anomaly detection on spend patterns (AGENTCOST07-BP02, High), and token cost carried on the trace so you can attribute it per run, per agent and per tenant (AGENTCOST05). The attribution point is the one teams underrate: without it, one invoice line says “model inference” and you cannot tell a runaway from growth.
Where we teach it: Cost and latency budgets in the evals domain, and Rollout and kill switches in AgentOps.
Sustainability: the failure mode
What happens. Eighteen months in, a company has forty agents. Six are load-bearing. Four are owned by people who have left. Nobody can produce a list of which ones can reach customer data, because each was built by the team that needed it, and the only description of what any of them does is its own system prompt.
Why it is a security problem, not a tidiness problem. Every one of those forty holds credentials and tool access. The four unowned ones are running unmonitored with permissions nobody is reviewing — the exact conditions under which a prompt injection against a low-status internal agent becomes a serious incident.
What the lens asks for. Written specifications kept current (AGENTSUS03-BP03, High), organisational skills deliberately maintained rather than allowed to atrophy (AGENTSUS03-BP01, High), and unused agents actively decommissioned (AGENTSUS03-BP04). Note that this is the same fleet-inventory concern AGENTOPS03-BP04 raises from the operations side — the lens asks it twice from two directions, which is a fair signal of how often it goes wrong.
Where we teach it: partly. AgentOps org patterns covers agent inventory and portfolio management, which is the fleet half of this question. Specifications, retained human competence and decommissioning we reference here and do not teach — see the gap list in lesson 4.
Interactive sorting exercise: Ten real review findings. Sort each into the pillar whose questions would surface it. Some are deliberately ambiguous — the explanation says why the answer is where it is.
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.