10.1 One loop, five dials
Five parameters decide how an agent behaves in a domain. They’re part of the harness, which Chapter 7 showed does more for production results than the bare model does. The last row is what they add up to.
Use this table as a design review checklist. If you can’t fill in a cell for your environment, the agent can’t either.
10.2 Complexity: the pillar the pager answers to
Incident response is the hardest case in this book. The question is open-ended (“why is checkout slow?”), the system is failing while you investigate, and proving a fix means probing a live service, not reading a bill. That’s why benchmark results in Chapter 7 are weakest here, and why this pillar earns autonomy slowly. Four rules follow from that.- Diagnosis is the product. Track how often on-call engineers accept the agent’s root cause. That number unlocks everything else.
- Fix the cause, not the symptom. Chapter 7 showed agents passing mitigation tests with restart loops. In production, escalate any fix that doesn’t cite a diagnosed cause, or that repeats inside its own cooldown window.
- Act through runbooks. A runbook with pre-checks, typed steps, and a post-check turns an open-ended action into a bounded, auditable one.
- Measure against your own baseline. Track MTTR change, diagnosis acceptance rate, escalation rate, and repeat-incident rate. The last one tells you whether incident memory (Chapter 2) is learning.
10.3 Cost: where autonomy is earned fastest
Cost flips the profile. Verification is nearly free, since the bill either moved or it didn’t. Most actions reverse cleanly: you can resize an instance back, restore a volume from a snapshot, or re-enable a schedule. Cheap proof plus reversible action is the promotion test Chapter 12 formalizes, so cost is usually the first domain where an agent acts on its own and tells you afterward. Three traps still need engineering.10.4 Security: highest stakes, clearest split
Security has the sharpest gap between reading and writing. The read side is large, recurring work with cheap verification: triaging findings, checking whether a vulnerability is actually reachable in your environment, and gathering evidence. Automate it first. The write side (patching, quarantining workloads, revoking credentials, changing IAM) has the worst blast radius in this book. An over-broad quarantine is a self-inflicted outage, and a bad IAM change can lock out your responders. Run the Chapter 6 approval machinery at its strictest here. Make enforcement actions ask a person by default (Manual, or an Ask first Rule), and loosen that one narrow action class at a time. Two habits matter most in this domain.- Fix in code, not in the console. If IaC manages the resource, a console fix is undone by the next apply and the finding comes back. Propose the change to the IaC source and let CI be the verification gate.
- Keep evidence current, not reconstructed. Configuration snapshots, access reviews, and change records are read-only and easy to verify. Collecting them continuously saves the scramble before an audit, and it’s often the easiest deployment to get approved.
10.5 One harness, three packs
Per domain, you change four things: the tool pack, the context pack, the policy defaults, and the evaluation set. Keep the harness itself shared: one policy engine, one approval surface, one trace store, one evaluation method. The anti-pattern is a separate product per domain, each with its own console, permissions, and audit trail. It rebuilds the swivel-chair problem one layer up and triples the attack surface from Chapter 5. Worse, it hides the cases that cross domains, such as a cost change that causes an incident, or a security finding caused by a change the reliability agent made.In practice: one platform, three modulesCloudThinker maps these pillars to modules that share one set of connections, one Approvals system, and one audit log.
Every write, in any module, passes the same Rules and the same Manual or Auto Approval mode, so you set the policy once. One exception: Review’s Apply fix and Fix all findings commit to the source branch when a person clicks them, without going through Approvals.