This book is a capability-led field guide to the architectures that make modern AI agents actually work. It includes code, failure modes, and illustrative composite case studies for every pattern.
About This Book
The first wave of agent literature was organized by domain. It told you how to build a healthcare agent, a finance agent, or a coding agent, as if the discipline were a set of vertical recipes.
That framing was useful while the field was young. But it can now be misleading. The healthcare agent and the coding agent, when you look past the prompts and the toolsets, are running the same five or six architectural patterns. The variation is cosmetic. The substance is capability.
This book reorganizes agent engineering around the capabilities themselves. There are eight that matter: perception, reasoning, planning, memory, tool use, coordination, learning, and alignment.
Every working agent on the planet, from the cron-job-with-a-prompt that summarizes your inbox to the multi-agent system that drafts merger documents, is a composition of these eight, in different ratios and at different fidelities.
If you understand the patterns inside each capability, you can build any agent on demand. But if you understand only the domain templates, you’ll spend the rest of your career rediscovering the same architectures with slightly different prompts.
The number sixty in the subtitle is not a marketing flourish. It’s the number of distinct, named patterns this book defines. Some are well-known under other names, while many are formalized here for the first time. Each pattern is presented with eight things:
- A one-line tagline.
- The problem in technical detail: what specifically goes wrong without this pattern.
- Why naïve approaches fail: the false fixes that look reasonable and aren’t.
- The mechanism: the architectural moves that define the pattern, in enough depth that you can implement it.
- A code skeleton: a working Python sketch, schematic rather than runnable, that captures the load-bearing structure.
- Trade-offs and alternatives: when not to use the pattern, and what to use instead.
- Production failure modes: what breaks first, and how to detect it.
- A case study: a real-world deployment shape, with concrete numbers where they exist, demonstrating the pattern’s value.
A pattern entry ends with a Pairs with line that names the patterns it most often appears alongside in real systems, because composition is the point.
The book has no chapter on “AI agents in healthcare” or “AI agents in finance.” Those chapters write themselves once you have the underlying capabilities in hand.
Instead, every domain example is folded into the case studies attached to individual patterns. A clinical decision-support workflow appears under the Provenance Tracker Agent and the Refusal Calibrator Agent, not under a “healthcare” heading. A contract-analysis pipeline appears under the Hierarchical Decomposer Agent, the Constraint-Satisfaction Agent, and the Side-Effect Auditor Agent.
Domain is a lens through which capabilities are exercised, never a substitute for understanding them.
A note on framing: this book treats agents as software artifacts, not as quasi-people. An agent is a system with a defined input contract, a defined output contract, an internal control loop, and a set of side effects. It’s built, tested, observed, and decommissioned.
The mystification that surrounds the word “agent” in popular writing has cost the field years. So this book strips it back to engineering. The cognitive metaphors (perception, memory, reasoning) are useful as taxonomy, not as ontology. None of the systems described here perceive anything in the way a person does, and pretending otherwise produces both bad code and bad ethics.
A second note: the patterns here are deliberately model-agnostic. Where a specific large language model is mentioned, it’s for concreteness, not endorsement. The shape of these architectures has been remarkably stable across three generations of frontier models, and there’s no reason to expect that to change.
Throughout this book, substrate refers to the underlying technology layer an agent is built on: the model, the embedding model, the vector store, and the tool-execution environment beneath the agent’s own code. Chapters 4A and 4B look at how that layer has been shifting. The substrate gets better, and the patterns persist.
Code samples in this book are schematic. They are written to make the pattern legible, not to drop into production.
Specifically:
- Error handling is elided unless it’s the point being made
- Type hints are present but not exhaustive
- Imports are at the top of each block but framework dependencies aren’t pinned
- Concurrency primitives are illustrative
- Where a real production implementation would use a particular vendor SDK, the code here uses a placeholder
llm.call(...)ortool.invoke(...). You’re expected to adapt these to your stack.
Read this book linearly if you’re new to the field. Treat it as a reference if you’re not. Each pattern is self-contained, and the cross-references at the end of each entry will lead you to its natural collaborators.
Foreword: Why Capabilities, Not Domains?
Every classification system is a hypothesis about how the world cleaves. Domain classification — “healthcare agents,” “finance agents,” “coding agents” — embeds the hypothesis that the determining variable for how an agent is built is the industry it operates in.
This hypothesis was reasonable when agents were primarily prompt-engineering exercises wrapped around a single model call. But today, it’s no longer reasonable.
Consider three agents from three industries: a clinical-decision-support agent, a credit-underwriting agent, and a code-review agent. Their prompts are extremely different. Their toolsets are extremely different. Their evaluation criteria are different. But their architectures, if you draw them, are nearly identical.
Each one perceives a complex document, decomposes it hierarchically, retrieves comparable cases from a curated memory, reasons via a self-consistency vote, attaches provenance to every claim it makes, escalates to a human at decision points the constitution flags, and audits every state-modifying action it takes.
Replace the prompt and the toolset and you’ve moved an agent across industries without changing its design.
The implication is practical: an engineer who has internalized the eight capabilities and the sixty patterns within them can build any of those three agents in a similar amount of time. An engineer who has memorized “how healthcare agents are built” has to relearn the work to move sideways. Capability literacy generalizes, while domain literacy does not.
The capability axis is also where the actual engineering decisions live. When you build a real agent, you don’t lie awake at night deciding whether yours is “really a finance agent or a coding agent.” You lie awake deciding whether your retrieval should be embedding-based or hybrid, whether your planner should produce a plan upfront or interleave with action, whether your safety enforcement should sit before or after the model call, or whether your memory should be flat or hierarchical.
These decisions are capability decisions. The catalog in this book is a vocabulary for naming them precisely and a record of the choices other engineers have made.
A final reason: the alignment chapter has nowhere to live in a domain taxonomy. Provenance, refusal calibration, off-switch compatibility, and drift detection aren’t “the alignment chapter for healthcare agents and a separate alignment chapter for coding agents.” They’re the same patterns, applied to the same problems, and they belong in one place: adjacent to the patterns they compose with. The domain taxonomy hides this, but the capability taxonomy makes it visible.
What Domain Does Determine
The argument above is that capabilities are the primary axis — but that’s not the same as saying domain is irrelevant. Domain shapes at least four things that capabilities alone don’t capture, and a serious agent design has to address them up front.
First, regulatory constraints determine which alignment patterns are mandatory rather than optional. HIPAA forces Privacy-Preserving (57) into the structural core of a healthcare agent. SOX and equivalent regimes force Provenance Tracker (55) into financial-reporting agents. GDPR forces Persistent Identity (29) with deletion to be a first-class concern in any EU-touching deployment. A coding agent has none of these structural mandates and can ship with looser versions.
Next, the risk profile of mistakes ranges across orders of magnitude. A wrong-code commit is minutes-of-impact and easily reverted, but a wrong clinical recommendation can be years-of-impact and irreversible. A wrong trade is dollars-of-impact in seconds.
The risk profile sets the cost ceiling for alignment patterns. In low-risk domains, lighter patterns are sufficient, while in high-risk domains, more thorough composition is justified.
Evaluation harness shape is also domain-determined. Coding has formal correctness (does it compile, does it pass tests?). Medicine has expert-review-driven ground truth. Trading has market-reality feedback. Customer support has user-rating feedback. The available evaluation signal shapes which learning patterns are tractable and how quickly an agent can improve in production.
Understanding what domain determines — and what it doesn’t — lets you carry architectural knowledge across industry boundaries while still respecting the constraints that make each deployment context genuinely different.
