Agent Design Patterns for Code Automation

The patterns did not arrive fully formed from a single research lab. There are at least three overlapping lineages in active use: Andrew Ng's foundational four, Anthropic's five workflow patterns, and a growing body of reliability and memory patterns that have emerged from real deployments in 2025 and 2026. The fact that multiple lineages converged on roughly the same primitives is actually reassuring — like three different mapmakers independently drawing the same coastline. It means these patterns reflect something real about the problem, not just one team's preferences.

A consolidated taxonomy groups them by what job they do:

• Reasoning patterns. How the agent thinks through a task. ReAct, Reflection, and Plan-and-Execute all live here.
• Extension patterns. How the agent interacts with the world beyond the model itself. Tool Use and MCP are the main ones.
• Control patterns. How humans stay in the loop without becoming a bottleneck.
• Coordination patterns. How multiple agents divide and combine work. Orchestrator-Worker, Fan-Out/Fan-In, and Role-Based Cooperation are the three you will encounter most.

These are not stages in a pipeline. They are not mutually exclusive. Real workflows compose across all four tiers at once. A planning pattern sits inside a multi-agent architecture that uses tool-use throughout, while a human-in-the-loop checkpoint guards the one action you cannot undo.

Why does taxonomy matter? Without it, every agent build feels like original research. Every team re-solves the same problems in slightly different ways, ships slightly different failure modes, and then wonders why the thing breaks at scale. With a shared vocabulary, an engineering team can audit what their system is actually doing and spot the failure modes before they hit production. That is a genuinely useful thing to be able to do.

ReAct: The Core Loop That Makes Iterative Code Work Possible

ReAct stands for Reason plus Act. The agent writes a snippet, executes it, observes the output or error, and refines. It cycles through that loop without human intervention until it converges on something that works, or hits a stopping condition you defined.

Here is why this matters specifically for code: code is executable. Unlike prose, it gives you deterministic feedback on every attempt. You do not have to guess whether the output is good. You run it. That makes the observe-refine loop tighter and more reliable for code tasks than for almost any other domain. A model without ReAct is a one-shot generator. It produces something, hands it to you, and stops. With ReAct, it becomes an iterative engineer that keeps going until the tests pass — less "here's my answer" and more "hold on, let me check my work."

Where it breaks down is worth being direct about. Long chains of self-directed reasoning can drift. The agent repeats steps, or converges on a solution that is locally coherent but globally wrong. It found a path that satisfies the test case in front of it and completely missed the broader requirement. That is the natural ceiling of a loop that has no external check on its own reasoning quality. Reflection and Planning exist specifically to raise that ceiling.

Reflection: Forcing an Agent to Critique Its Own Output Before Shipping It

Reflection adds a second pass. The agent generates output, evaluates that output against criteria, and only then presents results. The evaluation can come from the same model (self-reflection) or from a separate critic model.

The benchmark number here: Reflection alone can push coding accuracy from around 80% to 91%. That is an 11-point lift from a single architectural decision, not from switching to a bigger model or throwing more compute at the problem.

The two implementation forms behave differently in practice:

• Self-reflection. The same model critiques its own generation. Cheaper and faster, but susceptible to consistent blind spots. If the model has a systematic misconception, it will both make the error and approve it. The blind spot is invisible to both the generator and the critic because they share the same assumptions.
• Critic-agent. A separate model reviews the output. Higher overhead, but it catches errors the generator systematically misses precisely because it does not share the generator's starting assumptions.

That 80-to-91% figure comes from a single benchmark context, so treat it as directional. The real-world value compounds when Reflection gets paired with Tool Use. The agent can re-run the test suite to verify its own critique, which turns a self-evaluation from an opinion into a measured result.

If your agent is producing output that looks plausible but keeps failing on edge cases, the missing pattern is almost always Reflection. A second pass is the right first move, not a bigger model or more prompt engineering.

Plan-and-Execute: Decomposing Multi-Step Tasks So Agents Don't Drift

Without explicit planning, agents on long tasks lose track of intermediate state. They repeat steps. They over-commit to an early approach and cannot back out gracefully. This is not a model quality problem. It is a structural one.

Plan-and-Execute separates the plan from the execution. The model first outputs a structured decomposition of the task, then executes step by step against that plan rather than improvising its way through.

Three prompt-level techniques implement this in practice:

• Chain-of-Thought (CoT). The agent makes its intermediate reasoning steps explicit in the output. You can read what it was thinking at each stage, which is genuinely useful when something goes wrong.
• Self-Planning. The model generates its own sub-task list before acting. The plan becomes an artifact you can inspect and hand off.
• Tree-of-Thought (ToT). The model explores branching solution paths rather than committing to a single chain. Useful when the problem space has multiple viable approaches and you want the agent to compare them before picking one.

The engineering implication that gets undersold: Plan-and-Execute is what makes agent behavior auditable. The plan is explicit and inspectable. When something goes wrong, you can look at the plan and see exactly where the reasoning failed, instead of reverse-engineering the failure from the output alone.

It is also the natural bridge to multi-agent architectures. When the plan itself grows too large for one agent to execute reliably, you distribute it. You do not discard it.

Tool Use and MCP: Connecting Agents to the Systems Where Code Actually Lives

Tool Use turns an LLM from a text generator into a reasoning engine that can query databases, run code, call APIs, and trigger actions. The difference between an agent that advises and one that executes is Tool Use.

The proliferation problem hits fast. As the number of connected tools grows, loading all tool definitions upfront and passing intermediate results through the context window slows agents and inflates costs. A system with a few dozen tools starts to feel it. A system with hundreds becomes impractical.

MCP, the Model Context Protocol, is Anthropic's answer to this. Introduced in November 2024, it is an open standard defining how AI systems connect to external tools and data sources. It solves what you might call the M-times-N problem. Without a standard, every model-tool pair needs a custom integration — a tangle of one-off wires rather than a single clean socket. MCP collapses that to a single interface. Anthropic donated it to the Linux Foundation's Agentic AI Foundation in December 2025, co-founded alongside Block and OpenAI. Cross-industry buy-in matters here. It signals convergence rather than fragmentation.

One efficiency pattern worth knowing: present MCP servers as code APIs rather than direct tool calls. The agent writes code to interact with MCP servers, loads only the tools it needs, and processes data in an execution environment before passing results back to the model. Token overhead drops as tool counts grow.

The security surface deserves a direct mention, because it often does not get one. MCP's design prioritizes simplicity, and that tradeoff has costs. Known threat vectors include tool poisoning (malicious tool descriptions that redirect agent behavior), silent definition mutation, and cross-server tool shadowing, where one server's tool definition overrides another's. Enterprise deployments need to account for these before scaling, not after the fact.

Human-in-the-Loop: The Two Modes of Keeping Humans Meaningfully in Control

Human-in-the-loop has two distinct implementations with genuinely different cost-benefit profiles. Conflating them is one of the more common mistakes teams make when designing agent workflows.

Interrupt-based HITL. The agent pauses at a predefined checkpoint and waits for human approval before continuing. Right choice for irreversible, high-stakes actions: deploying to production, deleting records, sending external communications. The agent cannot proceed until a human says so.

Async-review HITL. The agent executes without blocking and logs its decisions for later human review. Right choice when throughput matters and an audit trail is sufficient to catch problems before they compound.

The design decision is which specific actions warrant blocking versus logging, and at what granularity. Getting this wrong in either direction is expensive. Too many interrupts kill the throughput advantage that made you want an agent in the first place. Too few, and you lose the visibility needed to catch compounding errors before they become somebody's bad day.

For organizations scaling from one agent to dozens, this decision needs to be a policy, not a per-workflow judgment call. Ad-hoc decisions per agent do not survive team growth. OpenHands lets teams define and enforce these policies at the infrastructure level rather than inside each agent's prompt, so visibility and guardrails become platform properties instead of things every agent has to re-implement from scratch.

Multi-Agent Orchestration: When a Single Agent Reaches Its Limits

Every single agent hits a ceiling. Context window limits, sequential execution, and the cognitive load of holding a large plan in-model all degrade performance as task complexity grows. Multi-agent orchestration is the architectural response.

Three coordination patterns show up in practice:

• Orchestrator-Worker. A lead agent manages the process and delegates to specialized subagents running in parallel. The most common enterprise pattern, for good reason.
• Fan-Out / Fan-In. Tasks broken into independent workstreams, each owned by one agent, results consolidated at the end. Works best when subtasks have no dependencies on each other mid-execution.
• Role-Based Cooperation. Agents assigned persistent roles (code writer, reviewer, test author, and so on). Research on LLM-based multi-agent systems for software engineering found this is the most frequently used pattern among the 16 catalogued in that study, most commonly applied to code generation tasks.

The performance payoff is measurable. Anthropic's internal evaluation found a multi-agent system with Claude Opus 4 as orchestrator and Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2% on internal research evaluations. That is Anthropic's own internal benchmark, not a neutral third-party test, so take the specific number with some skepticism. The directional finding — that orchestrated teams outperform solo agents on complex tasks — holds up across the broader literature.

The critical failure mode is something Anthropic identified directly: vague task descriptions at the orchestrator level cause subagents to duplicate work or miss coverage entirely. Short instructions like "research the semiconductor shortage" led subagents to perform identical searches or misinterpret scope. Detailed task descriptions are load-bearing. The orchestrator's prompt quality sets the ceiling for the entire system, and there is no clever architecture that compensates for a vague brief.

How These Patterns Combine in Production: A Large-Scale Parallel Migration as a Worked Example

Jarred Sumner, creator of Bun, used Claude Code's parallel subagent orchestration to port roughly 750,000 lines of Zig to Rust. Faithfully, file by file, with the existing test suite required to pass at completion. Six days. Think of it as moving an entire city block, building by building, while keeping the power on the whole time.

What made that possible was a composed architecture, not any single clever trick:

• Plan-and-Execute decomposed the migration file by file, producing a plan that could be inspected and rerun.
• Fan-Out orchestration ran independent file migrations in parallel across subagents rather than sequentially, which is where the time compression actually came from.
• Tool Use made the existing test suite the verification loop, providing deterministic feedback at each step.
• Dynamic Workflows used a JavaScript script to orchestrate subagents at scale, keeping the session responsive. The orchestration logic became code, not prompt.

Claude Code supports up to 1,000 agents per workflow run, with 16 running concurrently to bound local resource use.

The design rationale for externalizing orchestration into code is worth sitting with. The model does the reasoning. The code decides order, model tier, routing, and stopping conditions. The fragile parts (memory of the plan, self-policing) move out of the model's context window and into a system that can actually enforce them. That is not a minor implementation detail. It is the reason the thing worked at scale.

Cost routing is part of this too. Research and search subtasks can run on a smaller, faster model tier. Subtasks that write code or make consequential decisions inherit the main model. The right split is workload-specific and should be measured rather than assumed.

What Benchmarks Like SWE-Bench Measure and Where They Mislead

SWE-bench is the dominant evaluation standard for coding agents right now. It draws 2,294 task instances from real GitHub issues and pull requests across 12 widely used open-source Python repositories. It is execution-based, not multiple-choice, which puts it meaningfully ahead of most benchmarks on face validity.

Recent top-line numbers: the strongest models reach roughly 75% on SWE-Bench Verified. SWE-agent 1.0 with Claude 3.7 achieved above 40% on Verified and above 30% on the full test set in early 2026, in a single-agent configuration with no task-specific scaffolding.

The benchmark saturation signal is already visible. Gains on isolated tasks are diminishing, and the community is actively developing successor benchmarks that better capture multi-file, multi-step, and collaborative engineering work. The current leaderboard measures something real. It does not measure everything.

There is also a specific inflation caveat before you take a vendor number at face value. Models on SWE-Bench Verified show substantial relative overestimation, with realistic-mutation success rates meaningfully lower, consistent across Python, TypeScript, and internal C# task sets. A vendor quoting a SWE-bench number is not lying. The number just predicts real-world task success less cleanly than it appears.

One finding that should give you pause about elaborate scaffolding: a roughly 100-line Python agent scored highly on SWE-bench Verified. Beyond a certain threshold, careful pattern selection and model choice matter more than architectural complexity. That is worth keeping in mind the next time you are tempted to add another layer.

The right evaluation for your specific codebase is running the agent against your own real tasks. Leaderboard extrapolation is a starting point, not a conclusion.

Choosing and Combining Patterns: The Decisions That Determine Whether a System Scales

The patterns covered here are not a checklist. You do not implement all of them. You pick the ones that match the failure mode you are actually trying to solve.

Start with the task type. Single-step, deterministic tasks do not need multi-agent orchestration. Layering coordination complexity onto a simple workflow adds overhead without adding value. The pattern should match the problem.

Add Reflection before you add a bigger model. If output quality is the issue, a second pass is almost always cheaper and faster than a model upgrade.

Use Plan-and-Execute when tasks span multiple files, steps, or sessions. If your agent keeps losing track of where it is, the missing pattern is planning, not more memory.

Add Tool Use when the agent needs to do something, not just say something. Adopt MCP if you are connecting to more than a handful of tools and you want that investment to hold up over time.

Define your HITL policy before you scale. Decide which actions block and which actions log. Write it down. Enforce it at the infrastructure level, not inside each agent's prompt.

Graduate to multi-agent when a single agent reliably fails above a certain task size. Orchestrator-Worker is the right starting point for most teams. Fan-Out works when your subtasks are truly independent. Role-Based Cooperation works when you want specialization across the workflow.

Evaluate on your own tasks. SWE-bench gives you a comparison axis. Your production codebase gives you the actual answer.

The teams that build agent systems that hold up are the ones who knew which patterns they were using, why they chose them, and what would break first in each one. Everything else is details.