Where it agrees with this course, and where it does not

Lesson 4 of 5 in The Well-Architected Agentic AI Lens: 41 Questions Worth Borrowing.

Two independent attempts to describe the same problem converge more than they diverge, which is genuinely reassuring — it suggests the field has found real structure rather than fashion. The lens and this course agree on the load-bearing claims: authorisation belongs in the runtime rather than the prompt; a passing run is not evidence; the prompt is a versioned artifact; oversight has to be tiered by reversibility; and a second agent buys you coordination failure modes you did not have.

Here is the map. Where the lens asks a question, this is the module that teaches you how to answer it — and the last column is where the emphasis differs, because that is the useful part.

Lens questions crosswalked to this curriculum — and where the emphasis differs
Lens question	Where we teach it	Difference in emphasis
AGENTOPS01 — operational practices, roles, success criteria	What Is an Agent? · When NOT to Build an Agent · Human-in-the-Loop	The lens assumes you are building one and asks you to scope it. We spend a whole module on whether you should build one at all — a question the lens has no place for, since a lens is applied to a workload that already exists.
AGENTOPS02 — prompt and configuration lifecycle	Deploying and Versioning Agents · Regression Suites in CI	Close agreement. The lens adds drift detection as a named High-risk practice, which is a sharper framing than we give it — a model version upgraded underneath you invalidates your evals without changing a line of your code.
AGENTOPS03 — lifecycle, deployment, portfolio governance	Release Validation Gates · AgentOps Org Patterns	Same thesis, and both of us say the gate is a pass rate over N runs rather than a boolean. The lens is stronger on fleet-level portfolio governance (BP04); we are stronger on what a gate actually contains.
AGENTOPS05 — observability and monitoring	Trace Anatomy · Observability in Production	Full agreement, different order. The lens lists tracing among five practices; we make reading one trace end to end a whole module, because the skill is the bottleneck rather than the tooling.
AGENTOPS06 — testing, evaluation, validation	Eval Fundamentals · LLM-as-Judge	Agreement on structure, and the lens is unusually blunt in the right way: BP03 requires a named subject-matter expert to sign the score. We add the calibration discipline — a judge is an instrument you validate against human labels, not an oracle.
AGENTOPS07 — operational recovery, break-glass	Monitoring and Incident Response · Rollout and Kill Switches	Strong agreement, and BP04 is the sentence to quote at a sceptical team: break-glass means halting without a deploy. If stopping the agent requires a release, you have a plan, not a switch.
AGENTSEC02 — controlling and securing tool usage	Tool Scoping and Least Privilege · Supply Chain and MCP Security	The lens reaches our conclusion from the identity direction: authorisation is evaluated outside the model, and tool output is untrusted input. This is the row where a vendor framework and a security curriculum agree word for word.
AGENTSEC03 — identities, permissions, privilege escalation	Agent Identity, Auth, and Secrets	Agreement, and the lens is more explicit than most references about separating agent and human permissions (BP02) — the failure it prevents is an agent whose service identity is wider than any of the users it acts for.
AGENTSEC06 — multi-agent orchestration security	Multi-Agent Systems · A2A and Agent Interop	The lens is arguably ahead of us here. BP04 — monitor for coordination anomalies — names a failure class we treat mostly as a reliability concern: agents looping on each other or ratcheting each other’s scope.
AGENTSEC07 — protecting human oversight, rogue agents	Human-in-the-Loop · Rollout and Kill Switches	Both of us treat reviewer fatigue as a design parameter rather than a training problem. The lens files it as cognitive load management (BP01, Medium); we argue it is the single most common way a gate silently stops being a control, and would rate it higher.
AGENTSEC08 — validating and securing inputs and outputs	Prompt Injection · The Agent Threat Model	Where we disagree. The lens answers prompt injection with input validation and output filtering — two practices, both filters. We hold that filtering is a layer and containment is the strategy. See below; this is the most important paragraph in the module.
AGENTREL06 — integrating with existing systems	Reliability Plumbing · Tools and Tool Use	Near-identical content: idempotency, breakers, capability toggles. The lens frames it as protecting the incumbent system from the agent, which is the framing most likely to get you budget from the team that owns the legacy API.
AGENTPERF03 — memory, context windows, RAG	Memory Architectures · RAG for Agents	Agreement, with one useful reframing from the lens: context is a recurring cost, because you resend it every turn. That single observation turns memory design from an architecture debate into an arithmetic one.
AGENTCOST07 — cost governance and cutoffs	Cost and Latency Budgets · Rollout and Kill Switches	Agreement, and the lens is the better-shaped version: BP01 asks for cutoffs that halt the run, not alerts that notify a human. That is a containment control, and it belongs in the same mental bucket as a kill switch.
AGENTSUS03 — durable patterns, skills, decommissioning	AgentOps Org Patterns — the fleet-inventory half only	The lens is ahead of us, and this is the row where we cover least. We teach agent inventory and portfolio thinking; retained human competence and current written specifications are rated High and we treat both as good practice rather than as risks, and decommissioning (BP04) we do not teach at all. Its argument is better than ours: a team that has automated away a skill can no longer supervise the automation.

Now the honest part, in both directions.

What we do not teach. Forty of the 41 questions map to at least one module in this curriculum. That is not full coverage, for two reasons: a mapping can be thin, and one question maps to nothing at all. Six areas are genuinely underserved here, and if you are running a real review you should expect our material to run out:

Discovery, artifact retention and cold-start economics — AGENTCOST06, all three practices, and the one question in the lens our crosswalk maps to no module. The nearest thing we have is Deploying and versioning agents, which teaches deployment topologies, versioning and rollback — not what discovery costs per call, how long to keep versioned artifacts, or what a cold start adds to the first request. Mapping it here would be a match on vocabulary, so the crosswalk leaves the row empty and says so.
Cost allocation as a business function — AGENTCOST05-BP03 (tenant-aware allocation for agent-as-a-service pricing, High) and BP04 (chargeback and ROI reporting). We teach per-run cost measurement and budgets; we do not teach chargeback, showback, or how to price an agent product. If you are building agents as a service, that gap is yours to fill.
Environmental footprint — AGENTSUS02-BP04. We have no material on measuring the environmental cost of an agent workload. The lens does not have much either, but at least it asks.
Capacity planning and adaptive provisioning — AGENTOPS03-BP03 and AGENTREL01-BP05. We cover latency budgets and multi-tenant isolation; we do not cover scaling policy design for spiky agent traffic, which on any platform is where the infrastructure bill is actually decided.
Organisational skill retention — AGENTSUS03-BP01/BP02. We reference this and do not teach it. It is a workforce and training question that a technical curriculum is badly shaped to answer, which is not the same as it being unimportant.
Decommissioning and agent sprawl — AGENTSUS03-BP04. AgentOps org patterns gets you as far as an inventory and a portfolio view, which is the half of AGENTSUS03 we do cover. Retiring an agent — revoking its identity and secrets, unwiring its tools, and proving afterwards that it is actually gone — we do not teach, and it is the step that decides whether the inventory shrinks or just grows a column.

Two more places the lens is simply stronger: the arbiter pattern as the named answer for adjudicating disagreement between agents (AGENTREL04-BP01, High), which is more specific than our supervisor-worker treatment; and coordination anomaly detection (AGENTSEC06-BP04) as a security monitoring target rather than a reliability nuisance.

Where we disagree: AGENTSEC08 files prompt injection under input validation

The lens answers how do you validate and secure agent inputs and outputs? with exactly two practices: multi-layer input validation and prompt injection defense (BP01, High) and output filtering for sensitive information (BP02, High). Both are filters. Both sit at the edge of the system. Neither changes what the agent can do once a payload gets through — and a payload will get through, because instructions and data arrive in the same channel and no filter that inspects surface strings can reliably classify meaning the model will act on. Base64, homoglyphs, translation, text inside an image, a payload split across turns: each preserves the instruction and changes what the filter sees.

Our position: detection is a layer, containment is the strategy. Filtering is worth doing — it raises attacker cost, it catches the lazy attempts, and it gives you an alerting signal. It is not a boundary. The load-bearing controls are the ones that make a successful injection not matter: tool permissions narrow enough that the dangerous action is not available; an approval gate on anything irreversible; egress control so exfiltration has nowhere to go; and never assembling the lethal trifecta — private data, untrusted content, and an external communication channel — in one agent context.

Why this is more than a filing dispute. The lens has those controls. They live in AGENTSEC02 (tool authorisation), AGENTSEC03 (least privilege), AGENTSEC04 (guardrails and human-in-the-loop) and AGENTREL02-BP02 (minimum permissions). But because they sit under different questions than the one titled prompt injection, a reviewer who works through the list in order can answer AGENTSEC08 with “yes, we run a prompt-injection classifier and a PII output filter”, mark it green, and move on believing the injection question is handled. Structure shapes conclusions. A checklist that asks about injection defence in a section made of filters will be answered with filters.

So when you run this review, answer AGENTSEC08 with a blast-radius argument, not a filter inventory. The question to make someone answer out loud is: assume the injection succeeded — what can this agent now do, and who would notice? If the answer is uncomfortable, no classifier accuracy figure fixes it.

Is this disagreement fair to AWS?

Fair in substance, and worth stating precisely. AWS is not claiming filters solve injection — the lens says elsewhere that guardrails should constrain behaviour regardless of inputs received, which is the containment argument almost verbatim. The criticism is structural: injection defence is scoped into a two-practice focus area about validation, so the reviewer’s attention lands on the filter and not on the permission boundary. That is a taxonomy consequence, not a false statement, and it is exactly the sort of thing you only notice when you read a framework against a different framework.

Does that mean skip AGENTSEC08?

No — answer it, and answer it well. Output filtering in particular is undersold rather than oversold: what an agent emits can carry exfiltrated data, or render as an attack in whatever UI displays it, and that is a real control with a real boundary (the renderer). The change we are asking for is one sentence in your notes: record the blast radius of a successful injection alongside your filter coverage, and treat the second number as the interesting one.

Are there other places the lens under-emphasises what we teach?

Three, all smaller. Reviewer fatigue is rated Medium (AGENTSEC07-BP01) and is in our experience the most common way a live control quietly stops being one. Sandboxing appears as scoped testing environments (AGENTSEC09-BP04) rather than as a runtime containment primitive for the agent’s own execution — we treat isolation as a production control, not just a test-lab one. And the decision to build an agent at all has no question anywhere in the lens, which is structurally inevitable: you apply a lens to a workload that already exists, so the cheapest available risk reduction — not building it — is off the table before the review starts.

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.