Designing AI Agents you own this product

Principles, patterns, and best practices

Jia Huang

MEAP began May 2026
Last updated September 2026
Publication in Spring 2027 (estimated)

ISBN 9781633433632
375 pages (estimated)

Included with a Manning Online subscription

printed in black & white

catalog / AI / AI Agents

resources: Source code Book forum Source code on Github

table of content

Part 1 Foundations

1 The agent paradigm shift

1.1 What exactly is an agent?

1.2 From fixed control flow to model-directed control

1.2.1 What breaks and why

1.2.2 Uncertainties of agent systems

1.3 What makes agent patterns fundamentally different

1.3.1 What this changes for developers

1.4 Designing agents through cognitive functions

1.4.1 Argus reviews a pull request

1.4.2 How this book turns design choices into evidence

1.5 Summary

1.6 References

2 Turn a task into an agent architecture

2.1 Choose the capabilities the task requires

2.1.1 The agent capability stack

2.1.2 Design the cognitive engine: The Perception-Reasoning-Action loop

2.2 Turn capabilities into a system architecture

2.2.1 How information flows through cognitive modules

2.2.2 Runtime virtual machine

2.2.3 The external world boundary

2.2.4 How production systems instantiate the architecture

2.3 Use the two-axis map to compare pattern choices

2.3.1 The execution topology axis

2.3.2 Why you need both dimensions

2.3.3 The complete pattern map

2.3.4 Scope and limitations of the map

2.3.5 The pattern selection card

2.3.6 How to read the rest of this book

2.4 Decide when to scale beyond one agent

2.4.1 Start with the single-agent default

2.4.2 Scale only after hitting a structural wall

2.4.3 What multi-agent costs you

2.5 Set trust boundaries before granting autonomy

2.6 Apply the decisions: The Argus skeleton

2.6.1 The PRA loop in 50 lines

2.6.2 Try it yourself

2.6.3 The same pattern, different frameworks

2.7 Summary

2.8 References

Part 2 The seven cognitive functions

3 Perception: What your agent sees determines what it does

3.1 The context window as a treatment budget

3.1.1 How attention varies by position

3.1.2 The three-way squeeze

3.1.3 How production agents solve this

3.1.4 Measuring perception quality

3.2 Pattern: Context triage

3.2.1 The emergency room

3.2.2 The four tiers

3.2.3 Context triage in Claude Code

3.2.4 Building it

3.2.5 When it breaks

3.3 Pattern: Semantic compaction

3.3.1 The moment the window fills

3.3.2 Three levels of compression

3.3.3 Protect decision-critical evidence

3.3.4 Building it

3.3.5 When it breaks

3.4 Pattern: Progressive discovery

3.4.1 From an entry point to working context

3.4.2 Forage, then focus, then deepen

3.4.3 The production spectrum

3.4.4 Building it

3.4.5 The progressive disclosure connection

3.4.6 When it breaks

3.5 Pattern: Multi-modal fusion

3.5.1 When text is not enough

3.5.2 The representation decision

3.5.3 Building it

3.5.4 When it breaks

3.6 Putting it all together: The perception pipeline

3.6.1 Claude Code’s perception cycle in action

3.7 Upgrading Argus: From blind reviewer to context-aware analyst

3.8 Summary

3.9 References

4 Memory: What your agent remembers shapes what it becomes

4.1 What is memory? State, persistence, and knowledge across sessions

4.1.1 The memory hierarchy analogy

4.1.2 The memory lifecycle

4.1.3 How production agents handle memory today

4.1.4 Measuring memory quality

4.2 Pattern: Hierarchical Retention

4.2.1 Three tiers and the eviction question

4.2.2 In production: Claude Code’s scoped memory sources

4.2.3 Building it

4.2.4 Before and after: What eviction looks like

4.2.5 Argus integration

4.2.6 When it breaks

4.3 Pattern: RAG Pipeline

4.3.1 Two governed paths: Compile and assemble

4.3.2 In production: Claude Code’s tool-based retrieval

4.3.3 Building it

4.3.4 When it breaks

4.4 Pattern: Progress tracking

4.4.1 The checkpoint chain

4.4.2 In Production: Three approaches compared

4.4.3 Building it

4.4.4 When it breaks

4.5 Pattern: Failure journals

4.5.1 Failure fact, candidate lesson, published lesson

4.5.2 In production: Model-written notes as candidate memory

4.5.3 Building it

4.5.4 When it breaks

4.6 Composing memory patterns

4.7 Memory and collaboration: A boundary

4.8 Argus checkpoint: What Argus can do now

4.9 Summary

4.10 References

5 Reasoning: How your agent decides what to do next

5.1 What is reasoning? From represented state to an inspectable decision

5.1.1 Private reasoning, decision records, and execution traces

5.1.2 How the reasoning landscape changed

5.1.3 What remains an architectural decision

5.1.4 The reasoning patterns at a glance

5.1.5 Testing and observing reasoning

5.2 Pattern: Chain-of-Thought

5.2.1 Making the decision path explicit

5.2.2 In production: Separate the decision record from the action trace

5.2.3 Building it

5.2.4 Argus integration

5.2.5 When it breaks

5.3 Pattern: Complexity-Based Routing

5.3.1 Route on difficulty, override on consequence

5.3.2 In production: Route the decision, not only the model

5.3.3 Building it

5.3.4 Argus integration

5.3.5 When it breaks

5.4 Pattern: Parallel Exploration

5.4.1 A concrete branch decision: Independence before concurrency

5.4.2 Branching, scoring, and pruning

5.4.3 Building it

5.4.4 When it breaks

5.5 Pattern: Iterative Hypothesis Testing

5.5.1 The hypothesis-experiment loop

5.5.2 In Production: How coding agents actually debug

5.5.3 Building it

5.5.4 Argus integration

5.5.5 When it breaks

5.6 Composing reasoning patterns around the decision

5.7 Reasoning branches and collaboration

5.8 Argus checkpoint: What the agent can do now

5.9 Summary

5.10 References

6 Action: How your agent acts is where strategy meets consequences

6.1 What is action?

6.1.1 Success has layers

6.1.2 The action gap

6.1.3 Risk follows the effect

6.1.4 Four ways to constrain action

6.2 Pattern: Prompt Chaining

6.2.1 The seam is the design surface

6.2.2 Build artifacts before retries

6.2.3 Retry only when something changes

6.2.4 When Prompt Chaining breaks

6.3 Pattern: Tool Dispatch

6.3.1 Eligibility comes before selection

6.3.2 Reveal capability in layers

6.3.3 Build the executable surface

6.3.4 When Tool Dispatch breaks

6.4 Pattern: Plan-and-Execute

6.4.1 The interruption test

6.4.2 Make the plan an execution record

6.4.3 Persist before asking the model to remember

6.4.4 Recover effects before retrying calls

6.4.5 Keep replanning local

6.4.6 When Plan-and-Execute breaks

6.5 Pattern: Guardrail Sandwich

6.5.1 Return to the payroll result

6.5.2 Admission, containment, and verification

6.5.3 Build a fail-closed guarded path

6.5.4 Verify the effect, not the story

6.5.5 When the Guardrail Sandwich breaks

6.6 Composing action patterns

6.7 Testing the Action boundary

6.8 Argus checkpoint: Action

6.9 Summary

6.10 References

7 Reflection and evaluation: How your agent audits and learns from itself

7.1 What is reflection?

====7.1.1 Why another pass is not enough === 7.2 Pattern: Generator-Critic ====7.2.1 One artifact, a different line of inquiry ====7.2.2 Design the Critic before adding iterations ====7.2.3 Building Generator-Critic ====7.2.4 When Generator-Critic breaks === 7.3 Pattern: Self-Heal Loop ====7.3.1 Recovery requires permission and responsibility ====7.3.2 The fail-diagnose-fix-verify loop ====7.3.3 Building Self-Heal Loop ====7.3.4 When Self-Heal Loop breaks === 7.4 Pattern: Skill Package ====7.4.1 A successful run creates a candidate ====7.4.2 One active Skill or conditional coexistence ====7.4.3 Route in layers ====7.4.4 Building Skill Package ====7.4.5 Maintain the library from operating evidence ====7.4.6 When Skill Package breaks === 7.5 Pattern: Experience Replay ====7.5.1 From an execution trace to a replayable lesson ====7.5.2 Feedback latency changes the admission test ====7.5.3 Record, admit, and recall ====7.5.4 Building Experience Replay ====7.5.5 When Experience Replay breaks === 7.6 Composing reflection patterns ====7.6.1 A current-task coordinator === 7.7 Evaluation belongs beside the change ====7.7.1 Build and protect the evaluation set === 7.8 Argus checkpoint: Reflection === 7.9 Summary === 7.10 References

8 Collaboration: When one agent is not enough

8.1 What collaboration changes

8.2 Pattern: Handoff Chain

8.2.1 Walking through an airline-support handoff

8.2.2 A chain in a coding agent

8.2.3 When Handoff Chain breaks

8.3 Pattern: Fan-Out/Gather

8.3.1 When apparent parallelism collapses

8.3.2 Gathering without hiding the minority

8.3.3 Parallel work in coding agents

8.3.4 When Fan-Out/Gather breaks

8.4 Pattern: Adversarial Review

8.4.1 Three mechanisms that look like review

8.4.2 Evidence from code review systems

8.4.3 Running a bounded review

8.4.4 When Adversarial Review breaks

8.5 Pattern: Hierarchical Delegation

8.5.1 What the manager and workers need from each other

8.5.2 Hierarchical delegation in coding agents

8.5.3 When Hierarchical Delegation breaks

8.6 Testing and observing collaboration

8.7 Composing collaboration patterns

8.8 The implementation layers: Where control lives

8.8.1 Three communication channels

8.8.2 MCP and A2A are the plumbing

8.9 Argus checkpoint: Collaboration

8.10 Summary

8.11 References

9 Governance: Constraints that enable freedom

9.1 What is governance? Autonomy without accountability is a liability

9.1.1 The governance spectrum

9.1.2 Constraints enable freedom

9.2 Pattern: Approval Gate

9.2.1 Risk classification and the approval ladder

9.2.2 Classifying action risk

9.2.3 In production: Claude Code’s permission modes

9.2.4 Approval is a contract across time

9.2.5 Building it

9.2.6 When it breaks

9.3 Pattern: Blast Radius Control

9.3.1 Nested containment: Sandbox inside sandbox

9.3.2 Layer 1: Capability restriction (least privilege)

9.3.3 Layer 2: Execution isolation (sandboxing)

9.3.4 Layer 3: Damage limitation

9.3.5 Building it

9.3.6 When it breaks

9.4 Pattern: Progressive Commitment

9.4.1 Earning trust through evidence

9.4.2 Human sovereignty triggers

9.4.3 Enforcing the current trust boundary

9.4.4 A configured baseline and an earned trust level

9.4.5 Building it

9.4.6 When it breaks

9.5 Pattern: Observability Harness

9.5.1 Making the invisible visible

9.5.2 The observability platform landscape

9.5.3 What to observe: Metrics locate the problem; trajectories explain the path

9.5.4 In production: Claude Code’s observability stack

9.5.5 Building it

9.5.6 From evidence to improvement

9.5.7 When it breaks

9.6 Composing governance patterns

9.7 Governance standards and the regulatory landscape

9.7.1 The emerging governance ecosystem

9.8 The Argus checkpoint: From code reviewer to governed system

9.9 Summary

9.10 References

Part 3: Composition

10 Composing patterns: From framework to field

11 Patterns in the wild: Three end-to-end case studies

Appendixes

Appendix A: Pattern reference card

Overview

9 Governance: Constraints that enable freedom

```html

Governance in this chapter is presented as the set of constraints that make agent autonomy usable rather than dangerous. Once an agent can edit files, call APIs, send messages, or delegate work, the central issue is no longer whether it can act, but what it is allowed to do, what evidence must accompany that choice, and where the hard limits remain. The chapter argues that safety is a system property, so clear boundaries, not vague trust, are what let organizations delegate work while still staying accountable.

The chapter organizes governance into four complementary patterns. Approval Gate routes proposals into deny, allow, or human review based on risk and policy; Blast Radius Control limits the damage a mistaken or compromised action can cause through capability restrictions, sandboxing, and quantitative ceilings; Progressive Commitment earns or withdraws autonomy through staged verification and observed results over time; and the Observability Harness preserves the trace, metrics, decisions, and outcome evidence needed to reconstruct and audit what happened. Together, these patterns turn autonomy into something graduated, measurable, and reversible where possible.

The practical lesson is that governance should be designed into the agent lifecycle, not added as a final checkbox. The chapter shows how these controls can be composed in a production-style system, using Argus as an example of a reviewer upgraded into a governed agent with routing, containment, trust escalation, and evidence capture. It also connects these mechanisms to operational and regulatory concerns, emphasizing that organizations need a control plane, durable records, and human sovereignty for critical, sensitive, or insufficiently evidenced actions.

```

Approval Gate. Part A: route the frozen proposal to deny, allow, or human review.

(continued) Part B: review and revalidate before execution. Changed proposals return to part A.

Three-layer blast radius control. Nested containment from broad capability restriction to fine-grained damage limitation.

Progressive Commitment. Freeze the proposal, stage cheaper checks, and revalidate the same proposal before commit.

The trust ladder. Each level requires demonstrated reliability before escalation.

The Observability Harness. A coordinating orchestrator correlates logs, metrics, traces, evaluations, and replay artifacts within one trace boundary.

The governance pipeline. Four patterns coordinate one action from proposal to recorded outcome.

Summary

Governance begins when a person or organization delegates choices to an agent but retains responsibility for their effects. Clear boundaries can create more room to act: once an organization knows what may proceed, what must stop, and how far a mistake can spread, it can delegate work that would otherwise remain manual.
Autonomy is a degree, not a switch. Table 9.1's levels 0–4 describe operating arrangements, and level 5 marks a research horizon. Levels 1–3 are the practical deployment range.
Approval Gate (Governance × Route) inspects the concrete proposal along with the caller's credentials, then routes it to allow, deny, or ask.
Blast Radius Control (Governance × Hierarchy) assumes an authorized action can still be wrong and limits the largest effect before anyone can react.
Progressive Commitment (Governance × Chain) expands and contracts autonomy from observed evidence while keeping a hard ceiling around every level.
Observability Harness (Governance × Orchestrate) coordinates the evidence needed to reconstruct a run, change trust, and assign responsibility.
The four patterns answer different questions about the same action. Approval Gate routes the proposal; Blast Radius Control enforces the hard ceiling; Progressive Commitment stages commitment as evidence accumulates; Observability Harness connects decisions, execution, and observed outcomes in one causal record.
No single pattern proves compliance. Laws, standards, and governance frameworks impose or recommend different obligations; the engineering question is what evidence an organization can produce for the ones it claims to satisfy. That evidence includes agent registry entries, policy versions, approval records, execution traces, incident history, and the basis for changes in autonomy.

FAQ

```html

What is governance in AI agents, and why does it come after capability?

Governance is the layer that controls what an agent is allowed to do once it can act in the world. It comes after capability because each new skill—like editing files, calling APIs, or delegating work—creates more ways for mistakes to escape the model and affect external systems. Governance sets the boundary, evidence requirements, and accountability needed to make that autonomy safe.

What does the chapter mean by “constraints enable freedom”?

Constraints can create more useful autonomy by reducing uncertainty about what is allowed. When an agent has clear boundaries, it can act more often without asking for permission on every small step. The same boundary also prevents drift, so the system can delegate more work while keeping risk under control.

What is an Approval Gate?

An Approval Gate is a governance pattern that decides whether a proposed action may proceed, must be denied, or needs human review. It routes actions based on risk, reversibility, and policy rules. The idea is to avoid both approval fatigue and dangerous unchecked actions.

How does the Approval Gate classify risk?

Risk classification starts with the action’s impact and reversibility, not just the tool name. Low-impact, reversible actions may be auto-allowed, while high-impact or irreversible actions usually require review. The gate can also apply explicit deny and allow rules before falling back to a human review path.

What is Blast Radius Control?

Blast Radius Control limits how much damage an approved or compromised action can cause. It uses nested containment layers such as capability restriction, execution isolation, and damage limitation. The goal is to keep a wrong decision from becoming a large incident.

Why is sandboxing not enough on its own?

A sandbox limits where code runs and what technical resources it can reach, but it does not decide whether a specific business action is appropriate. It cannot, by itself, determine whether a customer should get a coupon, a record should be changed, or a message should be sent. That is why sandboxing must be combined with policy and approval controls.

What is Progressive Commitment?

Progressive Commitment is the pattern of earning trust through staged verification and observed outcomes. An agent proves itself with cheaper, reversible actions before being allowed to make more consequential commitments. Over time, trust can increase or decrease based on evidence from real tasks.

What are the human sovereignty triggers in this chapter?

Even trusted agents must defer to humans for critical operations, insufficient evidence, and ethically sensitive actions. Examples include large financial amounts, irreversible data changes, privacy-sensitive actions, or compliance-heavy decisions. These triggers remain in force regardless of trust level.

What is an Observability Harness?

An Observability Harness is the evidence layer that makes agent actions reconstructable and attributable. It connects logs, metrics, traces, evaluations, and replay artifacts so an incident can be debugged or audited later. The point is to preserve the causal record of what happened, not just the final outcome.

How do the four governance patterns work together in a production agent?

Approval Gate decides whether a proposal may proceed, Blast Radius Control limits the worst possible damage, Progressive Commitment adjusts autonomy based on evidence, and the Observability Harness records what happened. Together, they create a governed control plane for agent actions. In Argus, these patterns turn a capable reviewer into a production system with boundaries, accountability, and auditability.

```

pro $24.99 per month

access to all Manning books, MEAPs, liveVideos, liveProjects, and audiobooks!
choose one free eBook per month to keep
exclusive 50% discount on all purchases
renews monthly, pause or cancel renewal anytime

lite $19.99 per month

access to all Manning books, including MEAPs!

team

5, 10 or 20 seats+ for your team - learn more

eBook

pdf, ePub, online

$55.99 $27.99

you save $28.00 (50%)

pro $24.99 per month

access to all Manning books, MEAPs, liveVideos, liveProjects, and audiobooks!
choose one free eBook per month to keep
exclusive 50% discount on all purchases
renews monthly, pause or cancel renewal anytime

lite $19.99 per month

access to all Manning books, including MEAPs!

team

5, 10 or 20 seats+ for your team - learn more

eBook

$55.99 $27.99

you save $28.00 (50%)

eBook

pdf, ePub, online

$55.99 $27.99

you save $28.00 (50%)

pro $24.99 per month

access to all Manning books, MEAPs, liveVideos, liveProjects, and audiobooks!
choose one free eBook per month to keep
exclusive 50% discount on all purchases
renews monthly, pause or cancel renewal anytime

lite $19.99 per month

access to all Manning books, including MEAPs!

team

5, 10 or 20 seats+ for your team - learn more