Agent Architecture Patterns
The Core Loop: Reason, Act, Observe
Strip away the framework branding and every agent is the same machine: a model in a loop with tools. The model reasons about the task, chooses an action (a tool call), the runtime executes it, and the result is fed back into the context for the next iteration. That feedback loop is the entire difference between an agent and a chatbot — the model's output changes the world, and the world's response changes the model's next decision. Everything else in this module — orchestration, protocols, security, observability — is engineering around this loop. Understanding it precisely matters because each stage is a distinct failure point: reasoning can go off-plan, actions can be wrong or unsafe, and observations can carry hostile content back into the context.
- Reason: the model plans against the task, the conversation so far, and prior tool results
- Act: it emits a structured tool call — the only way an LLM affects anything outside its context
- Observe: tool output re-enters the context and steers the next reasoning step
- Termination is a design decision: goal check, step limit, budget cap, or human stop — never assume the model halts on its own
The Workflow-to-Agent Spectrum
The industry's most expensive confusion is treating "agent" as a binary. In practice there is a spectrum of autonomy. At one end sit workflows: LLM calls composed through predefined code paths — prompt chaining, routing to specialised prompts, parallel fan-out with an aggregation step, or an evaluator-optimiser loop where one call critiques another. The control flow is written by an engineer and the model fills in the steps. At the other end sit true agents: the model itself decides which tools to call, in what order, and when the task is done. Workflows are more predictable, cheaper, and easier to test; agents handle open-ended tasks no flowchart anticipates. Most production systems that get called agents are workflows — and that is usually the right call.
- Prompt chaining: fixed sequence of calls, each transforming the last output
- Routing: a classifier call dispatches to specialised downstream prompts
- Orchestrator-workers: a model decomposes the task and delegates, but within engineered rails
- Full agent: model-directed control flow — maximum flexibility, maximum variance
Single Agent vs Orchestrator-Subagent
A single agent with a well-chosen toolset is the right default: one context, one place to debug, no coordination overhead. Multi-agent designs earn their complexity in two situations. First, context isolation — a subagent can burn thousands of tokens searching or reading files, then return only a distilled answer, keeping the orchestrator's context clean for decision-making. Second, genuine parallelism — independent subtasks explored simultaneously. The orchestrator-subagent pattern keeps one agent accountable for the plan while workers handle bounded jobs. What fails in practice is the peer-to-peer "society of agents" — shared mutable state, circular delegation, and error attribution that becomes archaeology. Hierarchies debug; meshes don't.
- Default to one agent; add subagents when context bloat or parallelism forces it
- Subagents should return conclusions, not transcripts — the payoff is context compression
- Keep topology hierarchical: an orchestrator that owns the plan beats a mesh of equals
- Every added agent multiplies non-determinism — the coordination tax is paid in debugging
When NOT to Build an Agent
The most senior engineering judgement in this field is currently refusing to build agents. An agent trades cost, latency, and predictability for flexibility — so if you can enumerate the steps of the task, write a workflow and keep the guarantees. Ask three questions. Is the task valuable enough to justify tokens spent on exploration and retries? Is it complex enough that fixed logic genuinely cannot cover it? And is the cost of an error recoverable — can a wrong action be undone, caught by review, or sandboxed? A customer-refund process fails all three: the steps are known, errors are expensive, and a workflow with one approval gate does the job. Deep research across messy sources, or debugging an unfamiliar codebase, pass all three. Autonomy is a budget you spend where the task truly needs it.
- If you can draw the flowchart, build the flowchart — agents are for tasks that resist one
- High-volume, low-value tasks rarely justify agent economics
- Irreversible or costly errors demand workflows plus gates, not open-ended autonomy
- Start as a workflow, promote to an agent only where the rails demonstrably break
- This is the orientation view — Agent Engineering on this site takes the loop, budgets, termination and stuck-run detection to production depth
Prefer slides, quizzes, and saved progress? Read this lesson in the library — free, no sign-up.