Agent Architectures & Patterns

When one agent isn't enough

A single agent with tools handles most IDE workflows. Multi-agent architectures appear when:

• Tasks require specialized expertise (research agent + code agent + review agent)
• Steps are independently parallelizable (analyze 5 services simultaneously)
• Context isolation prevents one agent's mistakes from polluting another's
• Cost optimization — fast/cheap model for triage, strong model for implementation

But multi-agent adds complexity tax: orchestration bugs, handoff data loss, compounded latency, and harder debugging. Default to single-agent; escalate to multi-agent when measured need exists.

Core architectures

1. Supervisor (orchestrator)

One agent delegates to specialists:

User request → Supervisor Agent ├── Research Agent (search docs, codebase) ├── Code Agent (implement changes) └── Review Agent (check output) ← Supervisor synthesizes results → User

Best for: complex tasks with distinct phases; user-facing workflows where one entity owns the response.

Risk: supervisor becomes bottleneck; misroutes tasks to wrong specialist.

2. Pipeline (sequential)

Fixed chain, each agent's output is next agent's input:

Spec Agent → Implementation Agent → Test Agent → Review Agent → Done

Best for: well-defined workflows (codegen pipelines, doc generation); CI automation.

Risk: error propagation — agent 2 can't fix agent 1's mistakes if context is truncated.

3. Swarm (parallel)

Multiple agents work independently, results merged:

┌→ Agent A (analyze service-1) ─┐ User request → Fan ─┼→ Agent B (analyze service-2) ─┼→ Merge → Summary └→ Agent C (analyze service-3) ─┘

Best for: embarrassingly parallel analysis (incident triage across services, multi-file audit).

Risk: merge logic is hard; conflicting agent outputs need resolution.

4. Handoff (dynamic routing)

Agent decides mid-task to transfer to another agent:

Triage Agent → "This is a database issue" → DBA Agent → "This is a frontend bug" → Frontend Agent

OpenAI's agents guide formalizes this as handoffs — one agent explicitly transfers control with context.

Best for: support/triage workflows where task type isn't known upfront.

Anthropic's guidance: workflows vs agents

Anthropic distinguishes:

	Workflow	Agent
Control flow	Predefined (you code the steps)	Dynamic (model decides steps)
Predictability	High	Lower
Flexibility	Low	High
When to use	Known process, high reliability needed	Open-ended tasks, exploration

Senior take: start with workflows (pipelines). Add agent autonomy only where the workflow can't enumerate all paths. Most "agent" products are workflows with an LLM step.

Handoff design

Pass structured payloads (typed schemas), not chat transcripts. Include: task, ruled-out hypotheses, relevant artifacts, explicit state. Receiving agent must work from the handoff alone.

The complexity tax

Before building multi-agent, measure whether single-agent + better tools suffices:

Multi-agent cost	Mitigation
3–5× token usage (each agent has own context)	Share retrieved docs, not full transcripts
Latency compounds (sequential agents)	Parallelize where possible
Debugging "which agent failed?"	Log agent boundaries; trace IDs
Handoff data loss	Structured payloads; validate on receive
Non-determinism multiplies	Eval each agent independently + end-to-end

Interview framing

"I default to single-agent with good tools. Multi-agent when tasks need specialized context isolation or parallel analysis. I'd start with a pipeline workflow for predictable steps, add dynamic handoffs only where task routing is genuinely ambiguous. Always measure the complexity tax against single-agent baseline."

Senior signal: Name the architecture pattern for a specific workflow. Explain why you rejected the alternatives. Quantify the complexity tax (latency, cost, debug difficulty).