AI Agent Design Patterns: The Practical Catalogue (2026)
Most AI agents fail in production for design reasons, not because the model is weak. The right design depends on the job, the risk and where the data lives. This catalogue covers the single-agent patterns you will actually use, the latest evidence on when several agents beat one, and the orchestration patterns that let agents collaborate without chaos. It ends with worked team designs and a 30-day plan. Updated October 2026.
Why agents fail: four design mistakes
| Mistake | What it looks like | The fix |
|---|---|---|
| Wrong level of autonomy | A fully autonomous agent where a copilot with approval would be safer, or the reverse | Choose a rung on the autonomy ladder and earn the next one with data |
| Weak grounding | The agent cannot reach the right data, so it guesses | Connect the system of record through retrieval, queries or tools |
| Messy integrations | Overlapping tools, broad permissions, unstructured outputs | Few distinct tools, read and write separated, typed outputs |
| No control loop | No evaluation, budgets, guardrails or human checkpoints, so behaviour drifts | Evals, stop conditions, verifiers and tracing from day one |
Multi-agent systems add a new class of failure. A 2025 Berkeley study (MAST) analysed over 200 execution traces from seven open-source multi-agent frameworks and grouped the failures into three families.
The building blocks every pattern rewires
Every pattern below is a different way of wiring the same parts: a trigger, a model with instructions, tools, retrieval, memory and an output. Around them sit the control parts that make it safe: evaluators, verifiers, budgets, human checkpoints and tracing.
Single-agent patterns: the catalogue
Start here. Anthropic’s guidance and OpenAI’s guide to building agents agree on one point: get as far as you can with one well-equipped agent before adding more.
| Pattern | What it does | Use it for | Watch out for |
|---|---|---|---|
| Prompted assistant | Generates from prompt and context, no tools | Drafts, summaries, brainstorming | No access to live facts |
| Tool-calling copilot | Picks and calls one tool, then answers | Look up an account, create a ticket | Tool schemas and permissions |
| ReAct loop | Act, observe, decide, repeat | Troubleshooting, open-ended research | Needs stop conditions |
| Plan and execute | Writes a plan, then works through it | Known multi-stage jobs | Blindly following a bad plan |
| Adaptive re-planning | Re-plans when results contradict the plan | Procurement, travel, operations | Clear re-plan triggers |
| Task decomposition | Splits a question into sub-questions | Market analysis, requirements | Over-splitting wastes steps |
| Reflection | Drafts, critiques against a rubric, revises | Proposals, summaries, code | Cap the number of rounds |
| Evaluator and optimiser | A separate critic scores and returns feedback | Compliance content, structured output | Extra cost and latency |
| Verifier or guardrail | Checks arguments, policy and risk before acting | Refunds, deletions, customer emails | Must sit in front of every write |
| Multi-path reasoning | Explores several solutions and picks the best | Diagnosis, hard trade-offs | Expensive, use selectively |
| Self-consistency voting | Samples several answers and votes | High-stakes recommendations | Cost grows with samples |
| Retrieval (RAG) | Grounds answers in retrieved documents | Policy and product questions | Chunking, freshness, permissions |
| Structured query | Writes SQL or API queries against the source of truth | KPIs, finance, inventory | Schema grounding, row-level security |
| Knowledge graph | Reasons over entities and relationships | Root cause, dependencies, lineage | Needs clean entity IDs |
| Code execution | Writes and runs code in a sandbox | Calculations, data cleaning, forecasts | Sandboxing and limits |
| Router | Sends each request to the best tool or prompt | Support triage, many systems | Clean interfaces between routes |
| Skills library | Packages proven procedures the agent can load | Purchase orders, PDF extraction | Version skills like code |
| Memory | Keeps working, factual and episodic memory | Account management, repeat workflows | What to keep, expiry, privacy |
| Event-driven | Runs a playbook when a trigger fires | Incidents, SLA breaches, alerts | Throttling and audit logs |
| State machine or graph | Explicit states, transitions, retries and fallbacks | Claims, onboarding, compliance | More engineering upfront |
| Budgets and stop rules | Caps calls, tokens, time and retries | Every production agent | Define the graceful fallback |
| Human checkpoint | Pauses for approval at decision points | Irreversible or customer-facing actions | Make it a decision, not an FYI |
When should you use more than one agent? The latest evidence
The debate moved fast between 2025 and 2026. The evidence now points to a clear rule: multiple agents pay off when work can be split into independent parts, and hurt when every step depends on the last.
| Source | What they found | What it means for your design |
|---|---|---|
| Anthropic, multi-agent research system (June 2025) | A lead agent running 3 to 5 parallel subagents beat a single agent by 90.2% on research tasks. Token use explained 80% of performance differences, and parallel work cut research time by up to 90% | Use orchestrator and workers for broad, parallel research. Scale the number of subagents to the difficulty of the question |
| Cognition, Don’t build multi-agents (June 2025) | Actions carry implicit decisions. Agents working from partial context make conflicting choices | For tightly coupled work, prefer one agent with full context, or pass full traces, not short instructions |
| Berkeley MAST study (2025) | Over 40% of failures come from unclear specifications, and over a third from agents misaligning | Write explicit role, task and stop specifications. Add a dedicated verification step |
| Google Research, scaling agent systems (January 2026) | 180 configurations: +80.9% on parallel tasks, −39 to −70% on sequential ones. A model predicted the best design for 87% of unseen tasks | Decide by task structure. Prefer a central coordinator over independent agents |
| Cursor, scaling long-running agents (January 2026) | Hundreds of agents built a web browser over about a week, writing over 1 million lines of code, using planners, workers and a judge | At scale, hierarchy beats a flat crowd. Give agents specifications and tests to check against |
| Claude Code agent teams (February 2026) | A team lead, independent teammates, a shared task list with dependencies and direct messaging between teammates | Use subagents when only the result matters. Use teams when agents need to share findings and challenge each other |
The standards layer is settling too. MCP connects agents to tools and data, with over 10,000 published servers, and the Agent2Agent protocol (A2A) lets agents from different vendors delegate to each other, backed by over 150 organisations. Both now sit under the Linux Foundation. Microsoft’s Agent Framework names five standard orchestrations: sequential, concurrent, group chat, handoff and magentic.
Multi-agent orchestration patterns
| Pattern | How it works | Best for | Guard against |
|---|---|---|---|
| Sequential pipeline | Agent A hands a typed output to B, then C | Repeatable deliverables: research, write, edit | Errors flowing downstream. Validate between stages |
| Concurrent fan-out and merge | Several agents work in parallel, a merger combines results | Wide research, multi-angle reviews | Duplicate work and a weak merge step |
| Orchestrator and workers | A lead plans, briefs workers, then synthesises | Breadth-first research and analysis | Vague briefs. Use objective, format, tools and boundaries |
| Hierarchical planner, workers and judge | Planners create tasks, workers execute, a judge decides if done | Very large, long-running projects | Workers colliding. Give each clear ownership |
| Handoff (triage and routing) | A front agent passes the conversation to a specialist | Customer service, multi-department assistants | Context lost in the handoff. Pass a summary and history |
| Group chat or debate | Agents discuss under a moderator, a judge decides | Decisions, red-teaming, reviews | Endless rounds. Cap turns and use a rubric |
| Magentic (task ledger) | A manager keeps a live ledger of facts, plan and progress, and re-plans | Open-ended problems with no fixed path | Drift. Re-check the ledger each cycle |
| Peer team with shared task list | Agents claim tasks from a shared board and message each other | Parallel builds with dependencies | Two agents editing the same thing. Lock or assign files |
| Cross-company agents (A2A) | Your agent delegates to another organisation’s agent | Bookings, quotes, supplier coordination | Trust and identity. Verify and log every exchange |
Pick the right orchestration in five questions
| Question | If yes | If no |
|---|---|---|
| Can one agent with good tools do it? | Stop here: single agent plus guardrails | Continue |
| Do the subtasks run independently? | Fan-out or orchestrator and workers | Sequential pipeline or a single agent with full context |
| Do agents need each other’s findings mid-task? | Peer team, group chat or task ledger | Subagents that only return results |
| Do different requests need different specialists? | Handoff or router | One generalist agent |
| Is the work huge and long-running? | Hierarchy: planners, workers, judge | Keep the team flat and small |
Ten design rules for agents that collaborate
| Rule | Why it matters | How to apply it |
|---|---|---|
| 1. Brief like a manager | Vague delegation causes duplicated work and gaps | Every handoff states objective, output format, tools, sources and boundaries |
| 2. Pass context deliberately | Agents with partial context make conflicting choices | Return condensed summaries for independent work, and full traces for coupled work |
| 3. One owner per artefact | Two agents editing one file or record collide | Assign files, records or sections to a single agent |
| 4. Keep one source of truth | Agents drift without shared state | A task list or ledger every agent reads and updates |
| 5. Separate doing from checking | Agents grade their own work generously | A verifier or judge with a rubric decides what is done |
| 6. Scale effort to the task | Early systems spawned many agents for simple questions | Set rules: one agent for lookups, a few for comparisons, more for deep research |
| 7. Set budgets and stop rules | Loops and step repetition are the top failure | Cap turns, tokens, time and retries per agent and per team |
| 8. Least privilege per agent | A compromised or confused agent should not reach everything | Scope tools and permissions to each role, with writes behind a verifier |
| 9. Trace everything | You cannot fix what you cannot see | Log every message, tool call and decision, with a run ID across agents |
| 10. Evaluate end states | Many valid paths can reach the right outcome | Start with about 20 real cases and judge the final result, not each step |
Worked examples: multi-agent teams you can copy
Due-diligence research team
Agents: a lead that splits the question into market, competitors, financials and risks, four parallel researchers, and a citation checker.
Contract: each researcher returns a 1,000-word brief with sources in a fixed template.
Measure: claims backed by a source, time to first draft, cost per report.
Customer support desk
Agents: a triage agent routes to billing, technical or returns specialists. A policy verifier checks every refund, and a human approves anything above a set amount.
Contract: handoffs carry the customer summary, history and intent.
Measure: resolution without a human, reopen rate, refund errors.
Month-end close
Agents: parallel reconciliation agents, one per bank or ledger account, feed a variance analyst, then a reviewer that drafts journals for approval.
Contract: each reconciler outputs matched, unmatched and explained items in one schema.
Measure: days to close, unexplained differences, manual adjustments.
Software feature delivery
Agents: a planner writes tasks from the spec, implementers each own separate files, a test agent runs the suite, and a judge reviews against the spec.
Contract: a shared task list with dependencies, and nothing merges without passing tests.
Measure: tasks completed per day, test pass rate, rework after review.
Outbound sales
Agents: an account researcher, a message writer, a compliance and tone checker, and a CRM agent that logs activity.
Contract: the researcher passes three verified facts per account, and the writer may only use those facts.
Measure: reply rate, compliance rejections, time per account.
Incident response
Agents: an alert triggers a commander agent that runs parallel diagnostics on logs, metrics and recent changes, then proposes a fix. A human approves rollbacks.
Contract: diagnostics return evidence and a confidence level, and only the commander acts.
Measure: time to diagnose, time to recover, false alarms.
Climb the autonomy ladder one rung at a time
| Rung | What the agent does | Move up when |
|---|---|---|
| 1. Assistant | Drafts and suggests, a human does everything | Outputs are accepted with light edits most of the time |
| 2. Copilot | Prepares actions, a human approves each one | Approvals are almost always yes on your evaluation set |
| 3. Supervised agent | Acts on low-risk steps, asks on high-risk ones | Error rate and escalations stay within agreed limits |
| 4. Limited autonomy | Runs whole workflows inside budgets and policies | Weekly audits show stable quality and no serious incidents |
| 5. Multi-agent team | Several agents coordinate under an orchestrator and a verifier | One agent hits a ceiling that splitting the work clearly lifts |
A 30-day plan to design your first multi-agent system
- Days 1–5: Pick one workflow and baseline it. Choose a job with a measurable outcome. Collect 20 real cases and record time, cost and error rate today.
- Days 6–10: Build the best single agent. Connect the system of record, keep tools few and distinct, add a verifier in front of every write and set budgets. Score it on your 20 cases.
- Days 11–15: Find the split. Look for subtasks that run independently or need different tools and permissions. If there are none, stop: your single agent is the answer.
- Days 16–22: Add orchestration. Choose the pattern from the five questions above. Write a brief template for every handoff, assign ownership and set up a shared task list and run ID.
- Days 23–27: Evaluate end to end. Run the 20 cases through both designs and compare outcome quality, cost and time. Read traces for repeated steps, lost context and weak checks.
- Days 28–30: Ship at the right rung. Launch as a copilot or supervised team, set weekly review of traces and escalations, and agree the evidence needed to climb a rung.
Closing thought
The best agent systems look less like a swarm and more like a well-run team: clear roles, written briefs, one source of truth, someone who checks the work and a manager who knows when to stop. Start with one strong agent, add collaborators only where the work truly splits, and let evaluation, not enthusiasm, decide how much autonomy each agent earns.
ActivoRules puts these patterns into production: AI agents that detect, suggest and learn around versioned, auditable business rules, with people in the loop. Explore ActivoRules →
We design and build specialist AI agents and multi-agent teams, connect them through MCP and A2A, and put verification, budgets and tracing in place from day one.
AI models and agents Get in touchSources: Anthropic, How we built our multi-agent research system · Anthropic, Building effective agents · Cognition, Don’t build multi-agents · Cemri et al., Why Do Multi-Agent LLM Systems Fail? · Google Research, Towards a science of scaling agent systems · Simon Willison on Cursor’s long-running agents · Addy Osmani on Claude Code agent teams · Linux Foundation, Agentic AI Foundation · Linux Foundation, A2A one year on.
