The Pattern Index
Appendices · Appendix B
"A field guide is only useful if you can navigate it. This index is the navigation layer."
This index lists every chapter and pattern in the book by part, by category, and by the problem they address. Use it to:
- Find a chapter you half-remember
- Discover all chapters relevant to a particular problem
- Navigate by archetype or by phase of the practice
Part 1 — Decisions
The decisions you commit to before you start.
| Title | Key question |
|---|---|
| Pick an Archetype | What kind of system is this — Advisor, Executor, Guardian, Synthesizer, or Orchestrator? |
| The Advisor | Information-surfacing archetype: full specification |
| The Executor | Bounded-action archetype: full specification |
| The Guardian | Constraint-enforcement archetype: full specification |
| The Synthesizer | Composite-output archetype: full specification |
| The Orchestrator | Multi-agent coordination archetype: full specification |
| Calibrate the Four Dimensions | How much autonomy, agency, responsibility, and reversibility does this system get? |
| Four Dimensions of Governance | How do agency, risk, oversight, and reversibility interact in formal governance terms? |
| The Archetype Selection Tree | How do you choose the right archetype when the answer isn't obvious? |
| Composing Archetypes | How do multiple archetypes work together in a single deployment? |
| Governed Archetype Evolution | How do you update the archetype catalog as the technology and your domain change? |
| Multi-Agent Governance | How do you govern an N-agent system as a system, not as N individually-specified components? |
| Intent vs. Implementation | When something goes wrong, was the spec wrong, or did the agent fail to execute it? |
| Failure Modes and How to Diagnose Them | What are the seven failure categories, and how do you diagnose them? |
| The Intent Design Session | What is the time-boxed working ritual that turns the framework into a session a team can run? |
| What Changes for the Senior Engineer | If late judgment was the senior engineer's value-add, what is the value-add now? |
Part 2 — The Spec
How to write the artifact the agent executes against.
| Title | Key question |
|---|---|
| Spec-Driven Development | What is SDD and how is it different from requirements writing? |
| The Spec as Control Surface | How does a spec actually control what an agent does? |
| The Spec Lifecycle | What phases does a spec move through from intent to validation? |
| Writing for Machine Execution | What makes an agent-executable spec different from a human-readable one? |
| The Living Spec | How do specs evolve after execution and capture learning? |
| The Canonical Spec Template | What does a complete spec look like? |
| Architectural Decision Records | How do ADRs and specs relate; when to write each; the canonical ADR format with Spec Mapping section |
| SpecKit | How does the SpecKit toolchain support spec-driven development? |
Part 3 — The Agent
What agents are structurally, what capabilities they need, how to bound them.
| Title | Key question |
|---|---|
| What Agents Are | What precisely is an agent, and what are its operational limits? |
| Autonomy Without Agency | Why does the autonomy/agency distinction matter in practice? |
| The Executor Model | How do agents relate to the intent encoded in specs? |
| Least Capability | How do tool manifests and MCP define what an agent can reach? |
| Portable Domain Knowledge | What are SKILL.md files and how do they carry domain context? |
| Coding Agents | How do the framework's archetypes, spec, and oversight apply to the most-deployed agent class (Cursor, Cline, Devin, Claude Code)? |
| Computer-Use Agents | How do the framework's disciplines apply to GUI-acting agents (Claude Computer Use, OpenAI Operator, Gemini computer use); the new Cat 7 Perceptual Failure category |
Knowledge & Context
| Title | Purpose |
|---|---|
| The System Prompt | The agent's constitution at runtime |
| The Skill File | Encoding domain knowledge the agent can reference |
| The Tool Manifest | Declaring what tools the agent can access |
| Per-Task Context | Task-scoped context provision |
| Retrieval-Augmented Generation | Grounding outputs in retrieved content |
| Long-Term Memory | Cross-session memory patterns |
| Context Window Budget | Managing context window allocation |
| Grounding with Verified Sources | Constraining outputs to verified facts |
Tools and MCP
| Title | Purpose |
|---|---|
| The Model Context Protocol | Protocol overview |
| Designing MCP Tools | Designing tools that enforce intent rather than expose raw capability |
| MCP Safety | Safety considerations for MCP tool design |
| The Read-Only Tool | Boundary pattern for read-only access |
| The State-Changing Tool | Pattern for stateful operations |
| The Idempotent Tool | Idempotency guarantee pattern |
| The MCP Server | Standard MCP server design |
| Direct Function Calling | Tool calling protocol |
| Code Execution Sandbox | Safe code execution boundary |
| File System Access | File I/O patterns |
Part 4 — Oversight, Safety & Operations
| Title | Purpose |
|---|---|
| Proportional Oversight | The four oversight models (Monitoring / Periodic / Output Gate / Pre-authorized) |
| Human-in-the-Loop Gate | Structured decision gate before consequential actions |
| Retry with Structured Feedback | Structured retry that improves first-pass execution |
| Escalation Chain | Escalation hierarchy design |
Safety
| Title | Purpose |
|---|---|
| Prompt Injection Defense | Multi-layer defense for any externally-facing agent |
| Output Validation Gate | Tiered validation (programmatic → Guardian → human) |
| Sensitive Data Boundary | PII/secret handling pattern |
| Graceful Degradation | Partial-failure handling |
| Rate Limiting and Throttle | Preventing runaway execution |
| Blast Radius Containment | Limiting the consequence of a single failure |
Observability
| Title | Purpose |
|---|---|
| Structured Execution Log | Auditable execution trace |
| Cost Tracking per Spec | Cost attribution per agent and spec |
| Distributed Trace | Tracing multi-agent flows |
| Health Check and Heartbeat | Agent health monitoring |
| Anomaly Detection Baseline | Anomaly detection setup |
Testing & Validation
| Title | Purpose |
|---|---|
| Spec Conformance Testing | Making spec constraints testable and verifiable |
| Adversarial Input Test | Robustness testing |
| Multi-Agent Integration Test | Testing agent coordination |
| Evaluation by Judge Agent | Using an agent to validate another agent's output |
Part 5 — Ship
| Title | Purpose |
|---|---|
| Canary Deployment | Safe spec rollout |
| Rollback on Failure | Reverting a broken spec |
| Spec Versioning | Managing spec versions |
| Model Upgrade Validation | Re-validating when the underlying model changes |
| Agent Deprecation Path | Sunsetting old agents and specs |
| Proportional Governance | The lightest governance structure that prevents both chaos and bureaucracy |
| Intent Review Before Output Review | Spec review as a practice |
| Four Signal Metrics | What to measure, what not to |
| Evals and Benchmarks | The four-level eval stack: unit asserts, spec acceptance, regression, production sampling |
| Red-Team Protocol | Four red-team batteries (pre-launch, per-release, monthly regression, quarterly fresh-attacks) feeding the spec gap log |
| Cost and Latency Engineering | Model-tier selection, prompt caching strategy, latency budget decomposition, anti-patterns |
| Cacheable Prompt Architecture | Prompt caching as architecture, not optimization: layered prompt structure, cache breakpoints, prompt-stability spec constraint, eval-time pre-warm, cache_hit_rate as first-class telemetry |
| Production Telemetry | The integrated telemetry stack: what to instrument, what to retain, alerts vs monitors, OpenTelemetry GenAI semantic conventions |
| Adoption Playbook | How to introduce SDD discipline to a team without big-bang rollout, spec theater, or governance over-investment; CI/CD wiring with hard-gate / soft-gate / observe tiers |
| Minimum Viable Architecture of Intent | The floor of the discipline for small systems: when is the IDS too heavy, what's the smallest set of artifacts that still does work, when should an MVP graduate to the full framework |
| Signs Your Architecture of Intent Is Degrading | The 12-anti-pattern catalog of how the discipline itself decays — spec theater, oversight kabuki, metrics theater, citation theater, prompt-patch drift, archetype drift, the retrofit IDS — and the quarterly discipline-health audit that surfaces them |
| Mapping the Framework to the DevSquad 8-Phase Cadence | Phase-by-phase mapping of the book's artifacts and disciplines into Microsoft DevSquad Copilot's 8-phase iterative cycle |
| Co-adoption with DevSquad Copilot | The minimum additions from this book that give a DevSquad team the most leverage; vocabulary translation; 30-day co-adoption plan |
| Multi-Tenant Fleet Governance | The four structural moves a platform team needs to scale single-system governance to a fleet of tenant teams sharing infrastructure: constraint inheritance hierarchy, cross-tenant isolation contract, fleet-partitioned telemetry, platform-tier failure-locus rule |
Part 6 — Worked Pilots
| Title | Demonstrates |
|---|---|
| How to Use These Examples | Reading guide |
| Designing an AI Customer Support System | Multi-agent Orchestrator + Executor + Guardian + Advisor |
| Selecting the Archetypes (Example 1) | Five-archetype evaluation worked through |
| Writing the Spec (Example 1) | Annotated SDD spec for the Account Executor |
| Agent Instructions (Example 1) | Operational instructions derived from spec |
| Validating Outcomes (Example 1) | 14-test acceptance suite |
| Post-mortem Through Intent (Example 1) | $0.00 refund incident — spec gap traced and closed |
| A Code Generation Pipeline | Synthesizer-Executor-Guardian pipeline with no live human |
| Selecting the Archetypes (Example 2) | Orchestrator rejected; Synthesizer as primary coordinator |
| Writing the Spec (Example 2) | Annotated spec for the Scaffold Synthesizer |
| Agent Instructions (Example 2) | Non-conversational instructions for all three agents |
| Validating Outcomes (Example 2) | 9-test pipeline acceptance suite |
| Designing an AI Coding Agent | In-loop coding agent for an internal repo; Executor with Synthesizer composition; explicit decision against Devin-style autonomy |
| Selecting the Archetypes (Example 3) | Decision-tree walk for a coding agent; the "why not Orchestrator-over-self" decision recorded explicitly |
| Writing the Spec (Example 3) | Full canonical spec with coding-agent specifics: file-system scope, dependency allowlist, test-set protection |
| Agent Instructions (Example 3) | System prompt + tool manifest with capability minimalism (no general shell, no web fetch, no merge/close) |
| Evals and Acceptance (Example 3) | The four-level eval stack instantiated; 75-issue golden set construction methodology |
| Post-mortem Through Intent (Example 3) | The deleted-test incident; spec v1.1 → v1.2 change with constraint-library entry |
Cross-Cutting Patterns
Coordination and state patterns to consult once your pilot is running. Most patterns in the book live inside Parts 3–5 alongside their parent chapters; this section gathers the cross-cutting ones.
Coordination
| Title | Purpose |
|---|---|
| Sequential Pipeline | Linear pipeline pattern |
| Parallel Fan-Out | Parallel execution pattern |
| Conditional Routing | Decision-based routing |
| Event-Driven Agent Activation | Event-based coordination |
| Supervisor Agent | Supervisor agent pattern |
| Agent-to-Agent Contract | Contracted agent-to-agent interaction |
State & Memory
| Title | Purpose |
|---|---|
| Session Isolation | Multi-user isolation |
| Shared Context Store | Context sharing between agents |
| Checkpoint and Resume | Long-running execution pattern |
| Conversation History Management | Storing conversation state |
| Agent Registry | Registry of agent capabilities |
| Artifact Store | Storing agent-produced artifacts |
Repertoire
| Title | Purpose |
|---|---|
| The Organizational Repertoire | Why repertoires exist and how they compound |
| The Intent Archetype Catalog | Decision-ready archetype catalog entries |
| Spec Template Library | Organized spec templates |
| Feature Spec Template | Template for feature-development tasks |
| Agent Instruction Template | Template for system-prompt instructions |
| Integration Spec Template | Template for integration and API tasks |
| Constraint Library Template | Template for reusable constraint sets |
| Validation & Acceptance Templates | Reusable acceptance test templates |
Code Standards
| Title | Purpose |
|---|---|
| Standards as Agent Skill Source | How code standards are structured for agent validation |
| Standards for .NET / C# | .NET constraints, patterns, and validation rules |
| Standards for TypeScript / Node | TypeScript constraints and patterns |
| Standards for Python | Python constraints and patterns |
| Standards for REST APIs | REST API design constraints |
| Standards for Infrastructure as Code | IaC constraints for Bicep, Terraform, YAML |
Pattern Justification Map
For each of the ~50 patterns in the book, the spec section of the Canonical Spec Template that pulls it. A pattern that cannot be mapped to a spec section is inventory, not infrastructure — either remove it or amend the spec template to add the missing section. A spec section that needs patterns it doesn't currently name is a candidate for elaboration.
This is the audit that prevents the "pattern inventory" anti-pattern in Signs Your Architecture of Intent Is Degrading: patterns adopted from a generic best-practice catalog rather than from what one specific spec requires.
Capability patterns (Knowledge & Context, Tools)
| Pattern | Justified by | Why this spec section pulls it |
|---|---|---|
| The System Prompt | §11 Agent Execution Instructions | The runtime constitution the agent reads each turn — §11 is where it gets specified |
| The Skill File | §5 Functional Intent + §11 | Encodes the domain knowledge the agent's functional intent depends on |
| The Tool Manifest | §8 Authorization Boundary | The manifest is the expression of what tools the agent may reach |
| Per-Task Context | §11 Agent Execution Instructions | Per-step context provision is §11's territory |
| Retrieval-Augmented Generation | §5 Functional Intent + §11 | Grounds output in a retrieved source the spec names as authoritative |
| Long-Term Memory | §6 Invariants + §11 | What persists across sessions is an invariant; how it's accessed is in §11 |
| Context Window Budget | §7 Non-Functional Constraints (Cost Posture) | The latency/cost budget that the context budget operationalizes |
| Grounding with Verified Sources | §6 Invariants | "Outputs grounded in verified sources" is an invariant clause |
Integration patterns (Tools and MCP)
| Pattern | Justified by | Why this spec section pulls it |
|---|---|---|
| The Read-Only Tool | §8 Authorization Boundary | The boundary that distinguishes read from write |
| The State-Changing Tool | §8 Authorization Boundary | The boundary on what state the agent may mutate |
| The Idempotent Tool | §6 Invariants + §8 | Idempotency is an invariant the tool enforces |
| The MCP Server | §8 Authorization Boundary | The protocol-layer instantiation of §8 |
| Direct Function Calling | §8 Authorization Boundary | Tool-calling protocol; alternative to MCP |
| Code Execution Sandbox | §8 Authorization Boundary + §6 Invariants | Sandbox boundary is §8; "no escape" is an invariant |
| File System Access | §8 Authorization Boundary | File-system scope is part of §8 |
Coordination patterns (Sequencing, Routing, Oversight)
| Pattern | Justified by | Why this spec section pulls it |
|---|---|---|
| Sequential Pipeline | §4 Composition Declaration + §11 | Linear composition shape; declared in §4, executed per §11 |
| Parallel Fan-Out | §4 Composition Declaration + §11 | Parallel composition shape |
| Conditional Routing | §11 Agent Execution Instructions | Per-step routing decisions |
| Event-Driven Agent Activation | §11 Agent Execution Instructions | Trigger-to-step mapping |
| Supervisor Agent | §4 Composition Declaration | Orchestrator-over-Executors composition |
| Agent-to-Agent Contract | §4 Composition Declaration + §6 Invariants | Cross-mode invariants between composed agents |
| Human-in-the-Loop Gate | §11 + §6 Invariants | When the gate fires is in §11; the invariant that it must fire is §6 |
| Retry with Structured Feedback | §11 Agent Execution Instructions | The retry rhythm is per-step instruction |
| Escalation Chain | §11 + §6 Invariants | Escalation triggers in §11; the invariant that escalation must occur in §6 |
Safety patterns
| Pattern | Justified by | Why this spec section pulls it |
|---|---|---|
| Prompt Injection Defense | §6 Invariants | Invariants must hold under adversarial input |
| Output Validation Gate | §9 Acceptance Criteria + §12 Validation Checklist | Defines what passes the gate |
| Sensitive Data Boundary | §6 Invariants + §8 Authorization Boundary | PII/secret invariants; auth-boundary restrictions |
| Graceful Degradation | §6 Invariants + §11 | Partial-failure invariants; degradation rhythm |
| Rate Limiting and Throttle | §7 Non-Functional Constraints | Cost/availability budget |
| Blast Radius Containment | §6 Invariants + §8 Authorization Boundary | Containment as invariant; scope as boundary |
Observability patterns
| Pattern | Justified by | Why this spec section pulls it |
|---|---|---|
| Structured Execution Log | §12 Validation Checklist | Audit trail the validation step reads |
| Cost Tracking per Spec | §7 Non-Functional (Cost Posture) + §12 | Cost ceiling enforcement and reporting |
| Distributed Trace | §12 Validation Checklist | Multi-agent flows need cross-agent traces to validate |
| Health Check and Heartbeat | §7 Non-Functional + §12 | Availability budget; validation that the agent is up |
| Anomaly Detection Baseline | §12 Validation Checklist | Drift detection in production |
Testing patterns
| Pattern | Justified by | Why this spec section pulls it |
|---|---|---|
| Spec Conformance Testing | §9 Acceptance Criteria + §12 | Makes acceptance criteria executable |
| Adversarial Input Test | §6 Invariants | Tests invariants under adversarial conditions |
| Multi-Agent Integration Test | §4 Composition Declaration + §9 | Tests cross-mode invariants between composed agents |
| Evaluation by Judge Agent | §9 Acceptance Criteria + §12 | Judge agent operationalizes subjective acceptance criteria |
State & Memory patterns
| Pattern | Justified by | Why this spec section pulls it |
|---|---|---|
| Session Isolation | §6 Invariants + §8 Authorization Boundary | Cross-session isolation is both an invariant and a boundary |
| Shared Context Store | §11 + §6 Invariants | Cross-agent state-sharing rhythm; consistency invariants |
| Checkpoint and Resume | §11 + §6 Invariants | Long-running rhythm; transactional invariants on restart |
| Conversation History Management | §11 Agent Execution Instructions | What history the agent reads each turn |
| Agent Registry | §4 Composition Declaration + §8 | Registry expresses composition graph and authorization scope |
| Artifact Store | §11 + §6 Invariants | Where outputs land; integrity invariants |
Deployment patterns
| Pattern | Justified by | Why this spec section pulls it |
|---|---|---|
| Canary Deployment | §7 Non-Functional (Availability) + §6 Reversibility invariants | Phased rollout preserves reversibility |
| Rollback on Failure | §6 Reversibility invariants | Rollback is the reversibility mechanism |
| Spec Versioning | §10 Assumptions & Open Questions | Spec evolution requires versioning |
| Model Upgrade Validation | §9 Acceptance Criteria + §12 | Re-validation when the model underneath shifts |
| Agent Deprecation Path | §6 Reversibility + §10 | Sunsetting must preserve reversibility; documented in §10 |
Audit results
All 50 patterns in the book map to at least one section of the canonical 12-section spec template plus the Composition Declaration sub-block (§4). No pattern is unjustified inventory. The pattern density per spec section is uneven — §11 (Agent Execution Instructions), §8 (Authorization Boundary), and §6 (Invariants) pull the most patterns; §1 (Problem Statement) and §2 (Desired Outcome) pull none, which is correct because those sections are framing rather than enforcement.
When you add a new pattern to the book, add a row to this map first. If you cannot name the spec section that pulls the pattern, the pattern does not belong in the book — or the spec template needs a new section to justify it. Either is a real design decision; neither is "ship the pattern anyway."
Cross-Reference: By Problem
Find patterns by the problem you're trying to solve.
"I don't know which archetype to use"
- Pick an Archetype
- The Archetype Selection Tree
- Archetype Quick-Select Card
- Selecting the Archetypes (Example 1)
- Selecting the Archetypes (Example 2)
"I don't know how to write a good spec"
- Spec-Driven Development
- The Spec as Control Surface
- Writing for Machine Execution
- The Canonical Spec Template
- Writing the Spec (Example 1)
- SpecKit Quick Reference
"I don't know what constraints to include"
"I'm trying to calibrate how much autonomy to give"
"Something went wrong and I need to diagnose it"
- Failure Modes and How to Diagnose Them
- Intent vs. Implementation
- Post-mortem Through Intent
- The Living Spec
"I need to design oversight for this agent"
"I need to set up safety controls"
"I need to set up governance"
- Proportional Governance
- Intent Review Before Output Review
- Four Signal Metrics
- Roles & Responsibilities (RACI) Card — the canonical role-to-activity ownership matrix
"I need to measure and report on the practice"
"I need to design a multi-agent system"
- Multi-Agent Governance
- Composing Archetypes
- Orchestrator Archetype
- Designing an AI Customer Support System
- A Code Generation Pipeline
"I'm building a coding agent (Cursor / Cline / Devin / Claude Code style)"
- Coding Agents
- Designing an AI Coding Agent
- Multi-Agent Governance (if going Devin-style)
"I need to red-team my system"
"My agent program's cost or latency isn't penciling"
- The Canonical Spec Template — §4 Cost Posture sub-block — the upstream surface where model-tier, latency budget, prompt-stability invariant, per-call ceiling, and cost-incident escalation get committed before deployment
- Calibrate Agency, Autonomy, Responsibility, Reversibility — Cost is not a fifth dimension — the structural rationale for why cost is a §4 sub-block instead of a fifth dimension
- Model-Tier Quick-Select Card — per-step decision matrix and step-to-tier defaults
- Cost and Latency Engineering — full treatment with vendor pricing and a worked case study
- Cacheable Prompt Architecture — caching as architecture, not optimization; the largest single lever for systems running 100+ tasks/day
- Four Signal Metrics — cost-per-correct-output is the metric this work moves
- Context Window Budget
"I need real production observability for my agents"
"I'm trying to introduce this framework to my team"
- A Miniature Pilot, End-to-End — start here; show the framework on one screen before asking anyone to read three parts of a book
- The Intent Design Session — the working ritual; run this for the first system that matters
- Adoption Playbook
- The Canonical Spec Template
- The Living Spec
- The worked examples (Customer Support, Code Gen Pipeline, Coding Agent)
- The Companion Paper — give skeptical stakeholders the executive-summary version; the paper is shorter and structured for evaluation rather than adoption
"I'm evaluating the framework, not yet adopting it"
- The Companion Paper — the arXiv-format distillation; ~15,000 words; structured for a reader who needs to decide whether the larger investment in the book is worth their time
- What is the Architecture of Intent? — the one-page prose definition
- The framework on one page — the canvas summary
- A Miniature Pilot, End-to-End — the canvas applied to one concrete pilot
- Honest scope: what this book is, and what it isn't — what the framework does not promise
"I'm a senior engineer wondering what this all means for me"
- Prologue: What Changed and What's at Stake — the framing
- What Changes for the Senior Engineer — where late judgment goes, what is honestly lost, what is gained, and the career-ladder gap
- The Intent Design Session — the operational ritual where the upstream-judgment work actually lands
- Roles & Responsibilities (RACI) Card — which of the seven canonical roles best matches your actual leverage
"My system is too small for the full framework"
- Minimum Viable Architecture of Intent — the one-page MVP and the five thresholds that say it's the right shape; the five graduation triggers that say it isn't anymore
- The Intent Design Session — what the MVP graduates to when any threshold crosses
- A Miniature Pilot, End-to-End — the contrast case: small but production-bound systems that warrant the full canvas anyway
"My team has been using the framework for a while and something feels off"
- Signs Your Architecture of Intent Is Degrading — the 12-anti-pattern catalog and the quarterly discipline-health audit
- The Living Spec — is the spec evolution log accumulating entries?
- Four Signal Metrics — is anyone actually looking at the metrics?
- Intent Review Before Output Review — has output review absorbed all the cost while spec review fell away?
"My team already uses Microsoft DevSquad Copilot"
- Co-adoption with DevSquad Copilot
- Mapping the Framework to the DevSquad 8-Phase Cadence
- Architectural Decision Records
"I'm building a computer-use / browser-use agent (Claude Computer Use / Operator / Gemini)"
- Computer-Use Agents
- Red-Team Protocol — Computer-use-specific test patterns
- Multi-Agent Governance — A2A protocols
"I need to design safe agent tools"
"I need to ship safely without making the change irreversible"
"I need to build or expand a team repertoire"
- The Organizational Repertoire
- The Intent Archetype Catalog
- Spec Template Library
- Validation & Acceptance Templates
Cross-Reference: By Archetype
Find all chapters relevant to a specific archetype.
| Archetype | Definition | Used in example | Governance | Constraints |
|---|---|---|---|---|
| Advisor | advisor.md | Example 1 (Policy Advisor) | Proportional Governance | Spec template library |
| Executor | executor.md | Example 1 (Account Executor), Example 3 (Coding Agent) | Proportional Governance | Validation templates |
| Guardian | guardian.md | Example 1 (Compliance Guardian), Example 2 (Standards Guardian) | Proportional Governance | Least Capability |
| Synthesizer | synthesizer.md | Example 2 (Scaffold Synthesizer) | Proportional Governance | Spec template library |
| Orchestrator | orchestrator.md | Example 1 (Inquiry Orchestrator) | Proportional Governance | Proportional Oversight |
Cross-Reference: By Agent Class
Find all chapters relevant to a specific deployment class. The book treats archetypes (Advisor / Executor / Guardian / Synthesizer / Orchestrator) and agent classes (coding agents, computer-use agents, multi-agent systems) as orthogonal — every agent class is a composition of one or more archetypes.
| Agent class | Primary chapter | Worked example | Specific failure modes | Specific red-team patterns |
|---|---|---|---|---|
| Conversational support agent | The Five Archetypes (Advisor or Executor depending on action authority) | Designing an AI Customer Support System | Cat 1–6 (general taxonomy) | OWASP LLM01, LLM07, LLM02 (system-prompt extraction, sensitive-data disclosure) |
| Code generation pipeline | Multi-Agent Governance (Synthesizer + Executor + Guardian composition) | A Code Generation Pipeline | Cat 5 (compounding) particularly relevant | OWASP LLM05 (improper output handling) |
| Coding agent (in-loop) | Coding Agents (Executor with Synthesizer composition; can escalate to Orchestrator-over-self) | Designing an AI Coding Agent | Test deletion (Cat 1+3), dependency typosquat (Cat 2), hallucinated APIs (Cat 6), scope-creep refactors (Cat 3) | Supply-chain (LLM03), excessive agency (LLM06), coding-agent-specific patterns in Red-Team Protocol |
| Computer-use / browser-use agent | Computer-Use Agents (deployment-posture-dependent: Advisor / Executor / Orchestrator-over-self) | (no worked example yet — under-served chapter) | Cat 1–6 plus Cat 7 (Perceptual Failure) with 4 sub-categories | Computer-use-specific test patterns in Red-Team Protocol: lookalike domains, visual instruction injection, modal popup interception, etc. |
| Multi-agent system | Multi-Agent Governance (any composition; supervisor / pipeline / peer patterns) | Both Example 1 and Example 2 | MAST 14-category empirical taxonomy applies; the book's Cat 5 (compounding) is the dominant shape | Cross-agent injection, handoff manipulation, A2A protocol-layer attacks |
Cross-Reference: By 2024–2026 Innovation
Find where each significant 2024–2026 development is addressed, and how the framework responds to it. This is the practitioner's "what's new and where do I read about it" index. The full citations live in the References appendix.
| Innovation | Year | Where addressed in the book | What the book contributes around it |
|---|---|---|---|
| Anthropic MCP + cross-vendor adoption (OpenAI, Google, Microsoft) | 2024–25 | The Model Context Protocol, Designing MCP Tools, MCP Safety, Least Capability | The protocol layer through which Least Capability becomes operationally enforceable; capability-gating discipline at the tool layer |
| GitHub spec-kit | 2024–25 | Spec-Driven Development, SpecKit | Direct ancestor of the canonical spec template; the book extends spec-kit's discipline with the archetype framework and the failure taxonomy |
| Microsoft DevSquad Copilot | 2026 | DevSquad Mapping, Co-adoption with DevSquad, Architectural Decision Records | A complete bridge: phase-by-phase mapping, vocabulary translation, ranked addition list, 30-day co-adoption plan, ADRs as a first-class artifact |
| Anthropic Computer Use | Oct 2024 | Computer-Use Agents, Red-Team Protocol | New agent class chapter with archetype mapping by deployment posture; new Cat 7 (Perceptual Failure) added to the diagnostic protocol; four structural controls (sandboxed environment, auth scope minimization, domain allowlist, high-consequence confirmation gate); computer-use-specific red-team patterns |
| OpenAI Operator / Gemini computer use | 2025 | Computer-Use Agents | Same chapter — three implementations of the new class, all subject to the same structural controls and Cat 7 framework |
| Reasoning-tier models (o1, o3, Claude extended thinking, Gemini reasoning) | 2024–25 | Cost and Latency Engineering | Distinct model tier in the per-role selection table; explicit cost/latency profile (2–10× cost, 5–60s latency); when-to-use vs when-not-to budgeting discipline |
| Anthropic Constitutional Classifiers | 2025 | Prompt Injection Defense | Treated honestly as a probabilistic perimeter, not a fix; documented escape rate and over-refusal cost made explicit |
| Anthropic prompt caching / OpenAI cached input / Gemini context caching | 2024–25 | Cacheable Prompt Architecture, Cost and Latency Engineering | Caching as architecture (layered prompt with cache breakpoints; prompt-stability as a spec constraint; cache-hit-rate as first-class telemetry); 40–70% input-cost reduction is normal when treated architecturally |
| Google Agent2Agent (A2A) Protocol | 2025 | Multi-Agent Governance | Protocol-layer counterpart to MCP at the tool layer; the governance question for protocol-mediated multi-agent systems |
| OpenTelemetry GenAI semantic conventions | 2024–25 | Production Telemetry | Vendor-neutral observability standard; the book recommends emitting OTel-compliant spans alongside vendor SDK telemetry for portability |
| OWASP LLM Top 10 (2025 update) | 2025 | Prompt Injection Defense, Red-Team Protocol, Computer-Use Agents | Baseline coverage for the four red-team batteries; instantiation per deployment specifics |
| MAST taxonomy (Cemri et al.) | 2025 | Failure Modes and How to Diagnose Them, Multi-Agent Governance | Empirical 14-category multi-agent failure partition; complementary to (not replacing) the book's seven-category fix-locus taxonomy |
| Indirect prompt injection (Greshake et al. 2023) + the lethal trifecta (Willison) | 2023, ongoing | Prompt Injection Defense | The structural defense (trifecta reduction; capability gating) is centered on the indirect injection class that cannot be filtered at the prompt layer |
| SWE-bench Verified, AgentBench, τ-bench, GAIA, BFCL, WebArena, OSWorld, ScreenSpot-Pro | 2023–25 | Evals and Benchmarks, Coding Agents, Computer-Use Agents | External calibration benchmarks; the book recommends using public benchmarks for harness calibration and team-built golden sets for actual task fit |
| Open-source eval / red-team frameworks (Inspect, OpenAI Evals, Promptfoo, PyRIT, Garak) | 2024–25 | Evals and Benchmarks, Red-Team Protocol | The toolchain layer the book recommends adopting rather than building custom |
| Production observability stacks (LangSmith, Langfuse, Phoenix, Helicone, Datadog LLM) | 2024–25 | Production Telemetry | Vendor-stack landscape with a clear "which to choose if you have X" decision rule |
| Coding agent platforms (Cursor, Cline, Aider, Devin, Claude Code, Codex CLI) | 2023–25 | Coding Agents, Designing an AI Coding Agent | Treated as deployment-posture-dependent compositions; explicit decision-against-Devin-style-autonomy criteria documented in Example 3 |
| Anthropic Skills as deployable artifact | 2025 | Portable Domain Knowledge | The maturation of "domain knowledge as packaged context" — skills as versioned, distributed deployment units |
| Lost in the Middle long-context attention degradation (Liu et al. 2023) | 2023, ongoing | Coding Agents, Cost and Latency Engineering | Empirical grounding for the long-context anti-pattern; informs context-budget discipline and the warning against long-context dumping |
| NIST AI RMF / ISO 42001 / Anthropic RSP / OpenAI Preparedness Framework | 2023–25 | Calibrate Agency, Autonomy, Responsibility, Reversibility | Compliance-layer reference points; the book's four-dimensions framing is compatible with each |