Book 4 of The Architect’s Playbooks
The AI Architect’s Playbook
Designing, Governing, and Assuring Systems That Reason and Act
An AI agent is a new kind of constituent system. Bound its autonomy, govern its boundaries, and prove the governance works.
About the book
A new kind of constituent system.
Three months into a planning agent’s deployment inside a logistics system, an engineer reviewing an incident kept saying the same thing every time he was asked why the agent had made a particular call: it depended. Not on this specific input, the way a traditional system’s behavior depends deterministically on its input — on what the agent had reasoned about the last several requests, on priorities it had weighted against each other in a way nobody had explicitly programmed. It was reasoning, and reasoning doesn’t leave the same kind of trail code does.
That gap is what this book is about. An AI agent is not complex software. It is a different kind of constituent system, with a governance consequence that extends the system-of-systems work: in a multi-agent orchestration, the agent’s behavior at runtime is effectively independent of what any specific person directly authored — and the person accountable for the outcome isn’t the person who can point to the specific line of reasoning that produced it.
The AI Architect’s Playbook is the fourth volume of The Architect’s Playbooks. Drawing on four decades of mission-critical defense, space, and intelligence work, Dr. Daryoush Tehranchi shows engineers, architects, and leaders how to:
- Decide honestly, first, whether a role needs an agent at all — using a four-gate diagnostic: genuine ambiguity, bounded cost of error, actual governance capacity, and whether the case survives once demo value is removed
- Sort every autonomy decision by stakes and reversibility, not risk alone — and write the authority boundary down explicitly before deployment
- Build real oversight, not oversight theater: a falsifiable claim about what a specific human will catch
- Treat orchestration as its own architectural layer with failure handling and conflict adjudication — not a thin routing function
- Specify only what genuinely doesn’t vary at a probabilistic interface, and enforce hard bounds outside the agent’s own reasoning
- Capture what an agent actually retrieved and used at decision time — provenance across the whole multi-agent chain
- Verify properties and boundaries, not the agent’s unenumerable internal reasoning
- Govern the boundary between two organizations’ AI systems as its own object, with a named accountable party
- Introduce AI into legacy systems safely: surface the interface’s unwritten assumptions before the agent goes live
Tool-agnostic and grounded in anonymized cases from real defense and aerospace programs, it ends with the book’s 13 Rules — compressed for the moment a real decision about an agent’s authority can’t wait for a full reread.
Key takeaways
Six ideas worth keeping.
Takeaway 01
An AI agent is a different kind of constituent system, not unusually complex software.
Treating an agent as a software module invites the wrong question — “what does it do under every input I can enumerate?” A well-built specialist agent has operational independence: it’s useful and complete on its own, and its moment-to-moment behavior is effectively independent of what any person directly authored. The right question is what it’s capable of on its own, and what boundary it needs around that capability. (Chapter 1)
Takeaway 02
Sort every autonomy decision by stakes and reversibility, not risk alone.
A rare, catastrophic, slow-to-correct decision belongs with a human even if it looks minor most of the time; grant real authority where both stakes and reversibility are favorable. And demand an explicit, written authority boundary before deployment — when three engineers finally wrote their mental models down side by side, they didn’t match in exactly the ambiguous cases that mattered most. (Chapter 2)
Takeaway 03
Real oversight is a falsifiable claim — not a presence claim.
A reviewer who approved 211 consecutive decisions saw engagement drop steadily and invisibly across the session, so the 212th — the one that actually warranted scrutiny — got the same few seconds as the routine ones. Track time spent per decision relative to decision complexity across a session, cap sessions, and treat a pre-agreed escalation authority as a safeguard working, never a mistake to explain. (Chapter 5)
Takeaway 04
Specify only what genuinely doesn’t vary — and enforce hard bounds outside the agent’s reasoning.
A probabilistic interface’s format, hard bounds, and fields can be specified; everything else has to be governed as a continuously maintained relationship, with a specific owner watching for drift. A guarantee that depends on the agent reasoning its way to respecting its own limits is no guarantee at all. (Chapter 4)
Takeaway 05
Verify what you can actually verify — properties and boundaries.
A 200-case test suite with a clean pass rate told one team nothing when production produced a response that didn’t match any test case and wasn’t clearly wrong. Build property-based checks and run continuous drift monitoring alongside periodic adversarial campaigns — each catches a failure class the other structurally misses, and neither substitutes for the other. (Chapter 6)
Takeaway 06
A governance metric is only real if it would visibly move the moment governance stopped working.
Apply the disable-and-check test: if governance were secretly disabled, would this metric visibly change, and soon enough to matter? One program’s primary drift threshold, redefined four times for individually reasonable reasons over two years, had cumulatively tripled in width — nobody evaluated the cumulative effect until a new reviewer asked to see the adjustment history. (Chapter 12)
Who it’s for
For the people responsible for agents in real systems.
Questions
Before you ask.
Do I need to have read the first three books in The Architect’s Playbooks?
No. The book builds directly on the systems-of-systems literature and restates what it needs from the earlier volumes — the key extension (an agent’s runtime behavior creates governance consequences structurally similar to independently-managed systems) is argued here from scratch.
Is this a book about building or training AI models?
No. It assumes the models exist and focuses on architecture and governance around them: authority boundaries, orchestration, interfaces you can’t fully specify, oversight, assurance, provenance, and cross-organizational governance. It’s written for the architects and leaders responsible for agents operating inside real systems, not for model developers.
How do I know whether a role even needs an agent?
Chapter 13 gives an explicit four-gate diagnostic: genuine ambiguity, bounded cost of error, actual governance capacity, and whether the case survives once demo value is removed. A well-reasoned decision not to use an agent is treated as a real deliverable, worth the same credit as a successful deployment.
Given how fast AI moves, won’t this be outdated quickly?
The book deliberately writes about the underlying governing principle — bounded autonomy, falsifiable oversight, chain-level provenance — precisely because the protocols and platforms will change. Specific claims that are likely to age are dated in the text rather than stated as timeless.
What makes this different from enterprise AI-governance frameworks?
Most published AI-governance material never touches the constraints of classified programs, government acquisition cycles, and missions that don’t forgive “fail fast.” This is written from inside defense, aerospace, and intelligence programs, around the complications those constraints create.
The author
Dr. Daryoush Tehranchi is an engineer, architect, educator, and author whose work focuses on complex systems, systems and software architecture, digital engineering, artificial intelligence, technical leadership, and the decisions that remain fundamentally human.
The Architect’s Playbooks
More from the series.
Connect with Daryoush