Choose the shape: five questions before you pick an architecture

From plan to worker promoted a proven run into a job for a worker. Before you write its spec, decide what shape the worker should have. The AI Agent Factory names a production failure that costs weeks: engineers reach for the pattern that looks impressive, usually several agents talking to each other, when the task calls for a fixed pipeline that would not need a model in three of its five steps. The opposite failure is just as real: one agent with a long prompt for a task that genuinely needed decomposition, collapsing under context that does not fit one mental model. ¹

The discipline is not "always pick the simplest pattern". It is: pick the simplest pattern that matches what the task actually requires, and add complexity only when you can name the specific task property that demands it. ¹ This room builds one of the five shapes, the single agent with tools. This page tells you whether that is the right shape for the run you counted, and what to watch for if it is not.

Every pattern is a bet about the task

Pattern selection is architectural fit, not capability matching. Do not ask "what is the best pattern?"; there is none. Ask "what does this task actually require, and what is the smallest pattern that provides it?" Each of the five patterns is betting something about the task, and when the bet is wrong the pattern becomes overhead: ¹

Two failure modes happen with roughly equal frequency in production. Overshooting picks a more elaborate pattern than the task needs: three agents for one post, planning on a fixed workflow, reflection without checkable criteria. It is hard to undo, because after six months the orchestration is load-bearing. Undershooting picks a simpler pattern than the task needs: one agent handling billing, technical and account issues in a 4,000-token prompt, a loop where a pipeline belonged, no verification on outputs that needed it. It ships something brittle that survives by manual oversight or luck. A team that learns to avoid overshooting but never recognises undershooting has learned half the discipline. ¹

The five questions

Questions 1 to 3 pick the core pattern. Questions 4 and 5 are layers on top, applied only when their assumptions hold. ¹

Q1 is the most important question, because it decides whether you need an agent at all. Three tests, in order: can you write a flowchart of the steps before seeing the input; do the steps repeat unchanged across runs; when the input changes, do the steps change? The heuristic: if you had to write this as a plain function with no model calls, would you know how to structure it? If yes, the path is probably known and the model is needed only at specific moments. Teams get this wrong in both directions: "process refund requests" sounds like four fixed steps and is actually adaptive (disputes, policy lookups, escalations, disambiguation), while "find me a good restaurant tonight" sounds open-ended and is actually parse, query with filters, return five. ¹

Q2 separates known from stable. A path can be known in principle but vary in practice: a research assistant that sometimes answers one fact, sometimes synthesises many sources, sometimes analyses an uploaded document. Look at a representative sample of real inputs and ask whether the step sequence stays the same. If you can list the variants on one hand and they do not change often, use a branched workflow with explicit routing. If you cannot, treat the path as unknown. The trap is treating "known on average" as "known and stable": the workflow is built for the 80 percent case, patches accumulate for the rest, and eventually the patches are the workflow. ¹

Q3 asks about shape, not steps. Structure means the stages and their dependencies, not the steps inside them. Market research has articulable stages (gather, analyse, synthesise, report) even though which sources and analyses are unknown. A support investigation does not: depending on what the agent finds it might be one lookup or five, a policy check and an escalation, and it completes when it completes. Try to draw the work as a phase diagram before seeing any input. Planning helps when the shape of the work is predictable but the content is not; ReAct alone is right when even the shape depends on what you discover. Forcing a plan where none exists produces a planner whose plans execution immediately diverges from. ¹

Q2 and Q3 trip even experienced teams because both ask about predictability. Q2 asks whether the exact step sequence is fixed at runtime. Q3 asks whether the major stages can be described on a whiteboard while the model still decides what to do within each. Invoice intake is Q2 yes: the same five steps every time. A market research report is Q2 no, Q3 yes. A support investigation is Q2 no, Q3 no. ¹

Q4 has two conditions and both must hold. Would a response two to five times slower be acceptable for a meaningfully better output? Can you write down, in five to ten specific bullet points, exactly what good output means, such that a different model could check the output against them? "Make sure this is good" is not a criterion. "Verify the SQL parses, hits only the listed tables, and does not use SELECT *" is. Adding reflection because critics sound rigorous, or using the same model and prompt style for both generator and critic, produces a rubber stamp. If quality matters but the criteria are not checkable, the right fix is human review, not a second model. ¹

Q5 is the most consequential, because multi-agent systems are the most expensive to build and the most expensive to remove. Three distinct claims, each tested separately: can you name the specific expertise that justifies a specialist ("it would be cleaner" does not count); will the context exceed what one agent can effectively use; does the work genuinely parallelise with measurable throughput gain? If at least one gets a strong yes, multi-agent is justified. If all three get "maybe" or "it would be nice for organisational reasons", stay single-agent. Designing the agents around the org chart is almost always wrong, and multi-agent debugging is roughly an order of magnitude more expensive. ¹

Replace judgement with measurement where you can. The book's rough triggers: tool-routing errors concentrated in specific knowledge domains on the order of a third of runs in the affected category (specialization); accuracy on a hold-out set degrading materially as context grows, roughly ten points across a sweep from fifteen thousand to forty-five thousand tokens (context); more than five independent sub-tasks per run and single-agent latency exceeding the budget by more than two times (scale). The hierarchy of evidence, strongest first: production traces showing the bottleneck, hold-out measurements, written specialist-role specifications, and last, "feels like specialists", which is where overshoot lives. The self-check: what is the smallest single-agent design we could ship first, and what specific failure would force us to multi-agent later? Multi-agent is rarely the wrong endpoint; it is almost always the wrong starting point. ¹

What this room builds, and what the tree says about it

This room builds the second row: a single agent with a handful of typed tools, run in a loop until the task is done, with approval on the tools that change the world. On the book's own tree, a support worker lands there: the path is unknown (which lookup depends on the customer), the structure is not articulable (investigation completes when it completes), reflection is not justified at conversational latency, and no specialization bottleneck has been measured. The most likely production failure the book predicts for that shape is looping on ambiguous cases, and the fix is explicit stop conditions and a clear line between "investigate further" and "escalate". ¹

So before you build here, walk the five questions on the run you counted:

• If Q1 and Q2 are both yes, you do not need this room's loop. Build the pipeline, put a model call only at the steps that need interpretation, and skip the agentic harness entirely. The book's onboarding example is that case: provision, configure, seed, invite, schedule, send, the same every time, meaningfully cheaper to run. ¹
• If Q1 is no and Q3 is no, this room fits as written.
• If Q3 is yes, this room still fits for each stage; a planner that produces a typed plan sits above it, and that is the book's next shape, not this room's.
• If Q4 is yes, add a critic with a different model or a fundamentally different framing, and measure whether it changes outputs before you keep it. The SDK's output guardrail is the lightweight form; a critic-and-refine loop is the heavier one. ¹
• If Q5 fires with evidence, the room's worker becomes one specialist among several, and the coordination becomes its own design.

The SDK primitives map onto the shapes directly, and choosing between them is itself a pattern decision: the Agent is the atomic unit of every pattern; Runner.run runs the reason-act-observe loop so nobody hand-rolls it; @function_tool exposes a function; handoff passes the conversation to a specialist that takes over; Agent.as_tool keeps a coordinator in charge and calls a specialist like a function; output_guardrail wires a critic into an agent's output path. An Agent with a typed output and no tools is the SDK's idiomatic way to call a model once with a typed response, which is exactly what a sequential workflow's interpretation steps need: using the SDK without using the loop. ¹

Five failure signals

You chose a shape and the system runs. Five runtime symptoms say the bet was wrong, and each has a cheapest fix to try before touching the architecture: ¹

The principle is to fix at the smallest scope that works: prompt tightening before tool contracts, tool contracts before architecture, architecture before a rewrite. The exception: a signal that recurs after prompt and contract fixes is evidence the architecture is genuinely wrong. Distinguish "I can keep patching this" from "I keep patching this and it keeps failing in new ways". The fifth signal has no single metric; detection needs a baseline comparison, and if the simpler version performs within roughly ten percent of the complex one, the complex architecture is not earning its cost. ¹

One production rule sits under all of this: never let the step budget default to infinity. A loop with no cap will eventually meet an input that makes it loop forever. The book calls 25 a reasonable default, some tasks need 50, very few need 100, and hitting the cap is a signal to investigate, not a limit to remove. ¹ In this room that is max_turns on every run, on build the text agent.

When the tree is wrong

Three situations where the first answer stops being right: task properties change after deployment (a stable pipeline becomes adaptive once personalisation and history-awareness are added); different sub-tasks need different patterns (lookups are workflow-shaped, refund investigations are loop-shaped, and a coordinator routing to pattern-specific sub-systems is the honest composition); and constraints exclude the pattern the tree would pick. For the third, write it down: "the tree pointed at multi-agent, but we chose single-agent because the cost ceiling required it; known limitation: specialization-driven failures will be more common." A constraint-driven choice that is visible is one you can revisit when the constraint changes. ¹

Cost and latency are part of the choice

Write the latency and cost budgets down before walking the tree. The book's rough profiles, orders of magnitude rather than measurements: ¹

A multi-agent system with reflection on top can cost 30 to 60 times a sequential workflow for the same volume. When the multiplier is justified by quality, fine. When it is justified by aesthetics, it is a budget catastrophe waiting to happen. If the chosen pattern breaks a budget, you have three options: change the constraints, change the scope, or accept worse fit, and you document which one you chose and why. ¹

Deployment follows the shape too: a sequential workflow skips the sandbox and the background-worker machinery entirely; a single agent uses most of the stack and keeps its reasoning trace as the primary debugging artefact; a planner adds plan persistence and longer runs; reflection often introduces a second model provider; multi-agent demands per-specialist tracing, routing audit logs and per-role cost attribution, because the end-to-end rate is the product of specialist quality, routing accuracy and integration quality, and without three separate scoreboards you cannot tell which layer to improve. ¹

Composition, and the objection test

Real systems compose patterns at different layers: a planner at the top, a loop with tools inside each stage, reflection on the final synthesis. The rule is that each layer's choice is justified by the same five questions applied at that layer's scope. Do not compose because composition sounds sophisticated; compose because each layer's task properties demand it. Test a composition by removing the topmost layer: if outputs do not degrade, the layer was not earning its cost. ¹

Before locking in a choice, run the book's self-check: if a senior engineer reviewed my choice, what is the most likely objection they would raise? If you cannot predict and defend against it, you have not made a principled choice yet. ¹ Write the answers to the five questions, the objection and your defence into the spec, so the shape is reviewed with the behaviour.

With the shape chosen, continue to design the experience.

Footnotes

1. Choosing Agentic Architectures: A Decision-Driven Crash Course. The AI Agent Factory, Panaversity, 2026. ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶ ↩¹⁷ ↩¹⁸ ↩¹⁹ ↩²⁰ ↩²¹ ↩²² ↩²³ ↩²⁴ ↩²⁵