Lesson 07. The Least Agentic Pattern That Works

A logistics firm's procurement team bought an "AI crew" to answer supplier security questionnaires. Five agents: a planner, a researcher, a writer, a critic and a sender, each with its own prompt and its own view of the task. The demo was impressive. In production, the questionnaires arrived in three known formats, every answer came from the same forty-page compliance binder, and a human reviewed every response before it went out. The critic and the writer disagreed about tone for an hour on a Tuesday night and burned through the month's budget by Wednesday. When the firm's counsel asked why a questionnaire claimed a certification the firm did not hold, nobody could say which agent had introduced the sentence, because the answer had passed through four contexts and three rewrites. The vendor's fix was a sixth agent. Decide now: which of the five agents would you keep, and what would the others become?

Illustrative composite. The crew ran about four times the cost of a three-step pipeline that produced the same reviewed answers, and one unbounded critic-writer loop consumed a third of a month's token budget in a single night. The figures are a teaching device built from patterns the course authors have seen, not a measurement of a real company.

This lesson gives you an agent specification for your case: the pattern chosen and why, the loop with its exits, and a tool catalogue with schemas, idempotency rules and risk ratings. It is the fourth decision in the Decide stage of the Frame / Decide / Prove / Run loop, and it sits in your Dossier as 05-agent-spec.md, right after the augmentation ADR from Lesson 06.

What is actually going on

A workflow is code that calls a model at fixed points. An agent is a model that chooses its own next step. Everything between those two is a ladder, and every rung hands the model one decision that code used to make: which path to take, how to split the work, whether the output is good enough, what to do next. Each decision you hand over stops being something a unit test can check and becomes a distribution you can only measure with an eval. That is the whole trade. You buy flexibility with predictability, explainability and tokens, and you pay on every request.

The vendor's crew sat on the top rung for a task that lived on the bottom one. The questionnaire requirement had a fixed shape: classify the format, retrieve from the binder, draft answers, hand to a human, send. Nothing in it said "the steps are unknown until runtime," which is the only fact that justifies letting a model plan. The guidance most teams cite for this, Anthropic's Building effective agents (observed 2026-09-09), names five workflow patterns and one agent pattern and tells you to use the simplest composition that works. Almost nobody does, because the crew demos better.

Read the ladder below from the top down. Each edge label is the fact about your requirement that forces you up one rung; if you cannot state that fact, you stay where you are.

The picture shows six patterns, not two camps. Routing and parallelization are still workflows: code decides the shape, the model fills in the boxes. From rung four upward the model starts deciding the shape, and that is where explainability drops off. If you want the discipline for drawing a workflow's real dependencies, which edges are data dependencies and which are habit, Lecture 01 of the graph course covers it in one sitting and this lesson does not repeat it.

The rule and its condition

Use the lowest rung whose condition your requirement meets; climb one rung only when you can write down the observable fact the rung below cannot satisfy; otherwise stay. The fact must be observable in your own system: a classifier eval that shows three input classes, a dependency graph that shows independent branches, a log of tasks whose subtasks could not be enumerated in advance. "It felt limiting" is not a fact.

The second decision hides inside the last row: one agent or several? Multi-agent buys breadth, not depth. Anthropic's own research system, a lead model with parallel sub-agents, beat a single agent by 90.2% on an internal breadth-first research eval while using about 15x the tokens of a chat turn, and token usage explained about 80% of the variance in performance (Anthropic engineering, multi-agent research system, observed 2026-09-09). The gain is real when the task is many independent leads; it is a token bonfire when the task is a dependent chain.

The failure side is measured too. MAST, the multi-agent failure taxonomy from Cemri and colleagues, catalogues 14 failure modes in three categories from expert-annotated traces across seven frameworks: specification and system-design issues account for 41.8% of failures, inter-agent misalignment for 36.9%, and task verification for 21.3% (arXiv 2503.13657, observed 2026-09-09). Read that first number slowly. The largest class of multi-agent failure is the architect's specification, not the model. Go multi-agent when the work is breadth-first over independent leads or exceeds one context window, and only with a hard per-agent token budget and an explicit verifier; otherwise stay single.

The loop, its memory and its exits

When the requirement does put you on rung six, three loop shapes cover most of what you will see. ReAct interleaves a reasoning trace, an action and an observation on every step (Yao et al., ReAct, observed 2026-09-09); it adapts fastest to an unpredictable environment and is the hardest to audit, because the plan is never written down. Plan-and-execute writes the plan first, executes each step, and replans only on failure; it is cheaper per step and gives you a plan artefact a reviewer can read. Reflection has the model critique its own output and retry (Shinn et al., Reflexion, observed 2026-09-09); it is the evaluator-optimizer rung folded into one agent, and it only works when the critique has a criterion to critique against. Use plan-and-execute when the audit trail matters, ReAct when the environment surprises you, reflection only when you can write the grading rubric.

Memory is three different things and each needs its own rule. Working memory is the context window and it is governed by the budgets you set in Lesson 05. Episodic memory is what the agent writes down between steps: progress notes, a scratch file, a checkpoint; the Claude memory tool, for example, exposes a client-side file store the model reads and edits between turns (memory tool docs, observed 2026-09-09). Semantic and procedural memory is what you extract into a store and retrieve later, and the moment you do that it becomes grounding data with an owner, an access rule and a freshness rule, exactly as Lesson 06 defined. Memory that another user's task can read is a data leak with a friendlier name.

The exits are the part teams forget. An agent loop needs a step budget, a token budget, a wall-clock budget, a tool-call budget and a repetition detector, and the runtime enforces them, not the prompt. A prompt that says "stop after ten steps" is a suggestion; a runtime counter is a guarantee. For tasks that outlive a request, the loop also needs durable execution: every model call and tool call recorded as a step in a journal so a crashed worker replays history to the last completed step instead of starting over, and every human approval stored as a durable signal with a timeout and an escalation path. Runtimes such as Temporal and Restate do this natively, and most agent frameworks now ship a checkpointer that does a lighter version of it.

Watch the diagram for two things: the loop has exactly one path back to planning, and every other transition is an exit with a named trigger.

Every arrow into "Stopped" is a metric you will chart in Lesson 14: how often the budget fires, how often the gate rejects, how often the repetition detector trips. If those counters are zero after a month, either the loop is trivial or the guards are not wired.

Tools are the interface you actually design

A tool is not a function signature. It is a schema, a description that says when to use it and when not to, an idempotency rule, a risk rating and an owner. The schema uses typed parameters, enums where the values are finite, and identifiers where the real system has them; a free-text customer field where a customer_id exists is an invitation to act on the wrong record. The description is prompt text and deserves the same care as the system prompt, because it is the only thing the model reads before choosing.

The idempotency rule answers one question: what happens if this call runs twice? Reads are idempotent by nature. Writes need an idempotency key derived from the task, so a retry after a timeout reproduces the same booking instead of a second one. When the external system offers no key, the tool must check before it acts and record what it did, and you write that down in the catalogue because the next engineer will not guess it.

The risk rating decides who approves. Low: a read of non-sensitive data, or a reversible internal write. Medium: a reversible write to a system of record, or a read of sensitive data. High: anything irreversible, anything that leaves the organisation (email, payment, a public post), anything with legal weight. The approval policy follows the rating, and it starts strict: low runs, medium runs with logging and a sampled review, high waits for a human every time. Lesson 15 covers the evidence that lets you loosen a gate; until then the gate stays.

Human-in-the-loop triggers beyond the rating are worth listing once so they stop being improvised:

Protocols now carry these gates natively: the current MCP specification returns an input_required result type for a tool that needs mid-call confirmation, and Lesson 08 shows the consent flow around it. The catalogue below is the shape your Dossier expects; every tool in your case gets one entry.

# 05-agent-spec.md, section 4: tool catalogue (one entry per tool)
tools:
  - name: get_policy_clauses
    owner: policy-content-team
    description: >
      Return the clauses of a policy wording that match a claim type.
      Use for grounding correspondence. Do not use to decide coverage.
    schema:
      type: object
      required: [policy_id, claim_type]
      properties:
        policy_id: { type: string, pattern: "^POL-[0-9]{8}$" }
        claim_type: { type: string, enum: [water, fire, theft, liability] }
        max_clauses: { type: integer, minimum: 1, maximum: 12 }
    idempotency: read-only; safe to retry
    risk: low
    approval: none
    data_classes_touched: [policy-wording]
    runs_as: caller (on-behalf-of)
  - name: book_adjuster_visit
    owner: field-ops
    description: >
      Create a calendar hold for an adjuster at a claimant's address.
      Use only after the claimant has proposed a slot in the conversation.
    schema:
      type: object
      required: [claim_id, adjuster_id, slot_start, idempotency_key]
      properties:
        claim_id: { type: string }
        adjuster_id: { type: string }
        slot_start: { type: string, format: date-time }
        idempotency_key: { type: string, description: "sha256(claim_id + slot_start)" }
    idempotency: keyed write; the same key returns the existing booking
    risk: high
    approval: human gate, every call, adjuster or supervisor approves
    data_classes_touched: [claimant-pii, adjuster-calendar]
    runs_as: caller (on-behalf-of)

Worked case: Harbor Mutual

Harbor Mutual wants an assistant that drafts claim correspondence grounded in the policy wording and can book an adjuster visit when the claim needs one. The constraint register from Lesson 03 carries four lines that matter here: every outgoing letter must cite the clauses it relies on; the legal team signs off on the first release and wants to see why any sentence was written; adjuster bookings touch a shared calendar that field operations owns; and the audit obligation requires a record of who approved each customer-facing action. The NFR budget from Lesson 02 puts p95 latency for a draft at eight seconds and cost per drafted letter under a figure the CFO will read in Lesson 11.

Three proposals reached the architect. Option A, from the incumbent vendor: a crew of five agents mirroring the claims department's roles. Option B, from the internal team: one agent with every tool (retrieve clauses, read the claim, draft, book, send) and a system prompt describing the process. Option C: a router in front of a prompt chain with one evaluator step and human gates on the two high-risk tools. Decide now, with the ladder in front of you, before you read on.

Walk the edges. Do inputs need different paths? Yes: a first-notice acknowledgment, a coverage-position letter and a visit-scheduling message are three classes with different prompts and different clause sets, and a classifier eval on last year's correspondence shows the classes separate cleanly. Routing is justified. Are the parts independent? Within one letter, no: retrieve, then draft, then check. Parallelization is not justified. Are the subtasks unknown until runtime? No: the claims manual lists them. Orchestrator-workers is not justified. Can a grader score the output? Yes: "every factual sentence cites a clause that exists in this policy" is checkable by code plus a small model call, and iteration improves it. One evaluator step is justified, with a maximum of two retries. Does the next step depend on tool results? Only in one place: the booking, where the slot the claimant proposed determines whether a hold can be made. That is a single conditional branch, not an agent loop.

So the pattern is routing into a prompt chain with an evaluator step and a conditional booking branch, and the two tools that leave the building sit behind human gates. Option A fails on explainability alone: the legal team's question "why this sentence" has no answer when four contexts touched it, and MAST's largest failure class, specification and design, is exactly the crew's blind spot. Option B fails on predictability: an agent that can send before it has retrieved will do so on some fraction of runs, and a fraction is what the audit obligation cannot accept.

Illustrative composite. Modelled on the Anthropic price sheet fetched 2026-09-09 (Sonnet 5 at $2 per million input tokens, $0.20 per million cached-read tokens, $10 per million output tokens), one letter under option C runs four model calls: a small router call, a draft on a cached policy prefix, one evaluator pass and, on roughly one letter in five, one retry. Around 9,000 input tokens, of which 6,000 hit the cache, and 900 output tokens. Call it $0.016 per letter. Option B's single agent averaged eleven calls per letter in the internal team's own pilot log, with the full tool-result history re-sent each turn, at about $0.07 per letter and a long tail of forty-call runs. The crew was not costed because it never produced a stable per-letter number. These figures are a teaching device, not a benchmark.

The agent specification the architect filed is short. The full template is under Example Files; this is the filled version.

# 05 · Agent specification — Harbor Mutual claims correspondence

## 1. Pattern
Routing (3 classes: acknowledgment, coverage-position, visit-scheduling) into a
prompt chain (retrieve clauses → draft → evaluate) with one evaluator-optimizer
step (max 2 retries) and one conditional branch (book_adjuster_visit).
Rung 2 + rung 1 + rung 5, no agent loop.

## 2. Why not one rung higher
Subtasks are enumerated in the claims manual; no runtime discovery.
Only the booking step depends on a tool result, and it is a single branch.

## 3. The loop and its exits
- Router: confidence < 0.85 → human picks the class.
- Evaluator: every factual sentence must cite an existing clause id;
  fail twice → draft goes to a human with the evaluator's notes.
- Budgets (runtime-enforced): 6 model calls, 20k tokens, 30 s wall-clock per letter.
- Durable steps: each call journaled; approvals are signals with a 48 h timeout,
  then escalation to the claims supervisor queue.

## 4. Tool catalogue
get_policy_clauses (low, none) · get_claim (medium, log + sampled review) ·
draft_letter (low, none) · book_adjuster_visit (high, gate) · send_letter (high, gate)
Full entries in the yaml catalogue.

## 5. Memory
Working: context spec from 03-context-spec.md. Episodic: none (single-request task).
Semantic: none; clause retrieval is grounding data under 04-grounding-data.md.

## 6. Evidence this needs (Prove stage)
Router eval on 300 labelled letters; evaluator agreement with legal on 100 drafts;
gate approval-rate and time-to-approve dashboards before any loosening.

Faded case: Lumen

Skip to the open case if this is familiar.

Lumen sells a support agent to SaaS companies. Each tenant connects a help-centre knowledge base and a ticketing tool; the agent triages an incoming ticket, answers from the tenant's articles, escalates to a human when it cannot, and, for tenants who opt in, issues a refund under a tenant-set limit. One engineer owns the whole system, so anything that needs a durable workflow runtime is a real cost. Tenants churn when the agent answers confidently and wrongly, and they churn faster when it refunds twice.

Most of the ladder walk is done for you. Triage is routing with a classifier eval per tenant category set. Answering is a prompt chain: retrieve, draft, cite. Escalation is a conditional branch on router confidence and on a "cannot cite" evaluator result. That leaves two tools whose entries you must finish: close_ticket and issue_refund.

Open case

A public-sector benefits helpdesk wants an assistant for caseworkers. It answers eligibility questions from the published regulations, drafts replies to claimants, and can update a claimant's record with a new address or a changed household size. Regulations change quarterly. A wrong eligibility answer has statutory consequences; a wrong record update can stop a payment. The department has no engineers on call outside office hours, and every action on a claimant's record must be attributable to a named caseworker. Pick the pattern, list the tools with ratings, and place the gates. The first quiz question grades your answer.

Where this breaks

The ladder assumes you can state the requirement. A coding agent working on a repository, or a research task with no known steps, starts on rung six because the requirement is "figure it out," and then budgets and the tool interface are the entire design. That is a different course: what a harness actually is covers the coding-agent case, and this lesson's rule reduces there to "make every exit explicit."

Risk ratings are per tool, and the danger is composition. Reading private data is medium, reading an uploaded document is low, and sending an email is high; put all three in one agent and an injected document can walk private data out through the email tool without any single rating looking wrong. Lesson 12 names that combination and draws the boundary around it. Until then, treat any agent that holds all three as high regardless of its parts.

Durable execution is an operations commitment, and a two-person team may not carry it. The honest alternative is to accept task loss on a crash and make every tool idempotent so a restart from scratch is safe. What you cannot do is run long tasks inside a single HTTP request and hope.

Human gates decay. Approvers who see forty identical confirmations a day approve the forty-first without reading it. Measure approval rate and time-to-approve from the first week; a gate approaching one hundred percent approval in under two seconds is a gate in name only, and the fix is fewer, better-targeted triggers, not removing the gate.

Key Takeaways

• Climb the pattern ladder only on an observable fact; stay on the lowest rung that meets the requirement.
• Every rung climbed converts a unit-testable decision into an eval-measured distribution and costs tokens.
• Go multi-agent for breadth over independent leads with per-agent budgets and a verifier; otherwise stay single.
• Enforce step, token, wall-clock and repetition budgets in the runtime; the prompt is a courtesy copy.
• Give every tool a schema, an idempotency rule, a risk rating and an owner; high risk waits for a human.
• Journal every call for long tasks so a crash replays instead of restarting.

What You Have Now

An agent specification for your case: the pattern chosen and why, the loop with its exits, and a tool catalogue with schemas, idempotency rules and risk ratings. It lives at dossier/05-agent-spec.md, with the tool catalogue as a yaml block inside it, next to the augmentation ADR and grounding-data design from Lesson 06. It serves the Decide stage: the pattern and the ratings are decisions, each with the fact that justified it. Lesson 08 takes the catalogue and assigns each tool an identity and a boundary; Lesson 12 draws the trust boundaries around the same tools; Lesson 14 turns the loop's exits into dashboards; Lesson 15 decides, with evidence, which gates may loosen.

Example Files

# 05 · Agent specification — [system name]

## 1. Pattern
[rung(s) chosen, e.g. "routing into a prompt chain with one evaluator step"]

## 2. Why not one rung higher
[the fact the next rung would need, and the evidence it is absent]

## 3. The loop and its exits
- Router / classifier: [confidence threshold and fallback]
- Evaluator: [criterion, max retries, what happens after the last retry]
- Budgets (runtime-enforced): [calls] · [tokens] · [wall-clock] · [tool calls]
- Repetition detector: [rule]
- Durable steps: [journal / checkpointer, approval signal timeout, escalation]

## 4. Tool catalogue
[one line per tool: name (risk, approval); full yaml entries below or attached]

## 5. Memory
Working: [reference to 03-context-spec.md]
Episodic: [what the agent writes down, where, who can read it]
Semantic / procedural: [store, owner, access rule, freshness rule]

## 6. Human-in-the-loop triggers
[table: trigger → what the human sees → default on timeout]

## 7. Evidence this needs (Prove stage)
[evals, dashboards and gate metrics that must exist before the pilot]

Further Reading

• Building effective agents: the five workflow patterns and the "simplest composition" advice this lesson's ladder is built on.
• Why do multi-agent LLM systems fail? (MAST): the failure taxonomy and the numbers behind "specification is the largest failure class."
• How we built our multi-agent research system: the breadth-first gain and its token cost, from the team that paid it.
• ReAct and Reflexion: the two loop shapes most frameworks descend from, in their original form.
• Temporal documentation: durable execution concepts (workflows, activities, signals, replay) that the "journal every step" rule assumes.

Exercises

1. Take the tool list from your own case and write the catalogue entry for the riskiest tool in full: schema, description with a "do not use for" line, idempotency rule, rating, approval policy, owner. Then write the entry for the safest tool and compare the two descriptions; the safe one is usually the one the model misuses.
2. Walk your case up the ladder edge by edge. For each edge, write the observable fact that would justify climbing and whether you have it. Stop at the first edge you cannot justify and write the pattern down; that is section 1 of your agent specification.
3. Draw the loop for your case as a state diagram with every exit named, then list the metric each exit produces. Any exit without a metric is an exit you will not notice firing.

Check your understanding