The Multi-Agent Architecture That Actually Ships

Most multi-agent systems never leave the demo

Factory AI's engineering team walked on stage at the AI Engineer World's Fair and showed something the audience did not expect: a multi-agent system that ships production code. Not a demo. Not a research prototype. A system processing thousands of coding tasks per day, with real customers depending on the output. The talk has accumulated over 119,000 views because it answered a question most teams were stuck on: how do you move from "agents that impress in demos" to "agents that work on Tuesday at 3am when nobody is watching?"

According to product.engineer's guide, a multi-agent architecture is a system design where multiple specialized AI agents coordinate to complete complex tasks, each agent owning a distinct responsibility within a larger workflow. Unlike a single monolithic agent that attempts everything, a multi-agent system decomposes work across purpose-built components that communicate through defined interfaces. This is the architecture pattern that separates production AI from science fair projects.

The answer Factory presented was not magic. It was engineering. Specifically, the kind of engineering that a product engineer does every day: decomposing ambiguous problems into shippable components, building systems that fail gracefully, and obsessing over the user outcome rather than the technical novelty. The multi-agent architecture they described works not because the individual agents are smarter, but because the system design constrains them into reliability.

I have spent years building systems where coordination is the hard part. At AWS, I watched teams struggle with distributed systems where the individual services worked fine in isolation but fell apart at integration boundaries. Multi-agent architecture has the exact same failure mode. The agents are not the problem. The coordination is the problem. Factory figured this out, and their solution is instructive for anyone building production AI systems today.

Why single-agent systems hit a ceiling

Single-agent architectures dominated the first wave of AI coding tools. Give one model a task, let it think, let it write code. Cursor, GitHub Copilot, the early versions of Devin. They work remarkably well for bounded tasks. Write a function. Fix a bug. Generate a test.

They break on compound tasks.

Research on multi-step software engineering tasks using the SWE-bench dataset shows that multi-agent configurations with specialized roles for planning, implementation, and verification significantly outperform single-agent systems. The improvement comes from architecture alone, with no model improvement.

The reason is fundamental. A single agent managing a complex task must hold planning context, implementation details, and verification criteria in a single context window simultaneously. As tasks grow in complexity, these concerns compete for attention. Planning degrades because the model is distracted by implementation details. Implementation suffers because the model is still reasoning about the plan. Verification becomes an afterthought because the context window is saturated.

Multi-agent architecture solves this by separation of concerns. The same principle that makes microservices work over monoliths. The same principle that makes Unix pipelines powerful. Small, focused components doing one thing well, connected through clean interfaces. It is not a new idea. It is an old idea applied to a new substrate.

The ceiling for single-agent systems is roughly correlated with context window utilization. Once a task requires more than 60% of a model's effective context window for complete reasoning, single-agent performance degrades non-linearly. Factory's architecture avoids this by distributing the cognitive load across multiple specialized agents, each operating well within their context budget.

Factory's production architecture, decomposed

Factory's multi-agent architecture, as presented at AI Engineer, follows a pattern they call "Drafter, Reviewer, Integrator." product.engineer's framework for multi-agent systems maps this to three classes of agents, each with a specific role, coordinating through a shared workspace. Let me break down what actually runs in production.

The Drafter agent

The Drafter receives a task specification and produces candidate code changes. It operates with a focused context: the task description, relevant file contents, and coding conventions. Nothing else. No review history. No deployment context. No integration concerns. This constraint is deliberate. The Drafter's job is to produce plausible solutions, not perfect ones.

Factory reported that their Drafter agents produce viable first-pass code in 84% of cases. The remaining 16% require iteration, but critically, that iteration is handled by a different agent with different context and different objectives. The Drafter never sees its own failures because giving it failure context would contaminate its generative focus.

The Reviewer agent

The Reviewer receives the Drafter's output along with a different context window: coding standards, security policies, test coverage requirements, and historical patterns from the codebase. Its job is pure criticism. It identifies issues, flags potential problems, and produces structured feedback.

This separation is crucial. When a single agent both writes and reviews code, it exhibits confirmation bias. It tends to approve its own work. By splitting these roles across agents with different system prompts and different context, Factory eliminates this bias structurally. The Reviewer has never seen the task specification in its original form. It sees only the code and the standards it must uphold.

The Integrator agent

The Integrator handles the coordination layer: merging changes, resolving conflicts, running tests, and managing the final pull request. It operates with the broadest context but the narrowest action space. It can merge, reject, or request re-drafting, but it cannot write code itself.

This constraint prevents a common failure mode where an integration agent "fixes" issues by writing patches, introducing subtle bugs that neither the Drafter nor the Reviewer would have produced. The Integrator is a coordinator, not a contributor.

Comparison: single-agent vs. multi-agent patterns

The multi-agent architecture coordination protocol that ships

Agents alone are not architecture. The coordination between them is the architecture. Factory's presentation revealed three coordination patterns that distinguish their production system from academic multi-agent research.

Pattern 1: Typed handoffs

Every agent-to-agent communication uses a typed schema. The Drafter does not pass "some code" to the Reviewer. It passes a structured object with fields for: changed files, rationale for each change, confidence scores per file, and explicit assumptions about the codebase. The Reviewer consumes this structure, not raw text.

This matters because untyped communication between agents is the primary source of cascading failures. When Agent A passes ambiguous output to Agent B, Agent B must interpret it, and interpretation introduces error. Typed handoffs eliminate interpretation. They are the API contracts of multi-agent systems.

Pattern 2: Bounded retry with escalation

When a Reviewer rejects Drafter output, the system does not loop indefinitely. Factory implements a bounded retry protocol: the Drafter gets at most two attempts to address feedback. If both attempts fail, the task escalates to a human engineer with full context: the original task, both attempts, and the specific failure reasons.

This bounded retry pattern is what makes the system production-safe. Unbounded retry loops are the most common way multi-agent systems waste compute and produce increasingly incoherent output. Each retry degrades output quality because the model is reasoning about its own failures, which consumes context that should be dedicated to the solution.

Factory reported that 91% of tasks complete within the first attempt. 7% require one retry. The remaining 2% escalate to humans. This distribution is healthy. It means the system knows its limits.

Pattern 3: Shared workspace, isolated context

All agents operate on the same codebase (shared workspace) but see different slices of it (isolated context). The Drafter sees the files relevant to its task. The Reviewer sees those files plus the style guide and test expectations. The Integrator sees the full dependency graph and CI status.

This is analogous to how human engineering teams work. The developer sees the code. The reviewer sees the code plus standards. The release engineer sees the system state. Same artifact, different perspectives. The multi-agent architecture encodes this organizational pattern into software.

What this means for product engineers

If you are a product engineer building AI-powered features, Factory's patterns offer concrete lessons you can apply today. This is not abstract architecture astronautics. These are patterns that ship.

Lesson 1: Decompose by cognitive mode, not by task type. The Drafter, Reviewer, Integrator split is not about "planning, coding, testing." It is about "generating, criticizing, coordinating." These are fundamentally different cognitive modes. When you design multi-agent systems, split agents by how they think, not what they do. A product engineer who understands this will build more reliable systems than one who splits agents by task taxonomy.

Lesson 2: Constraints enable shipping. Factory's agents are heavily constrained. The Drafter cannot review. The Reviewer cannot code. The Integrator cannot write patches. These constraints feel limiting, but they are what makes the system predictable enough to run in production. Every constraint you add to an agent is a class of failure you eliminate. This connects directly to the principle of making your codebase agent-ready: the more structured your system, the more reliably agents can operate within it.

Lesson 3: Human escalation is a feature, not a failure. That 2% escalation rate is not a bug. It is a design choice. The system is explicitly designed to recognize when it cannot solve a problem and route it to a human with full context. This is what distinguishes production systems from demos. Demos never fail. Production systems fail gracefully.

Lesson 4: Monitor agent-to-agent boundaries, not just agent outputs. The bugs in multi-agent systems live at the boundaries. The Drafter produces good code. The Reviewer makes good criticisms. But the handoff between them loses information because the typed schema does not capture some nuance. Factory instruments every handoff, measuring schema completeness, round-trip time, and information loss. If you are building multi-agent systems, your observability layer must cover the spaces between agents, not just the agents themselves.

Patterns you can steal today

You do not need Factory's scale to apply multi-agent architecture. Here are concrete patterns that work at any team size, distilled from their approach and validated against what I have seen work at AWS and in my own projects.

The Draft-Review loop for any AI feature

Instead of asking one model to "write and review" code, split it into two separate calls with different system prompts. The first call generates with a creative, solution-focused prompt. The second call evaluates with a critical, standards-focused prompt. Different temperature settings, different context, different objectives. You can implement this in an afternoon and it will immediately improve your AI output quality.

// Pseudocode for a minimal multi-agent pattern
const draft = await model.generate({
  systemPrompt: "You are a code generator. Focus on correctness and clarity.",
  context: [taskSpec, relevantFiles],
  temperature: 0.7
});
 
const review = await model.generate({
  systemPrompt: "You are a code reviewer. Focus on bugs, security, style violations.",
  context: [draft.output, styleGuide, securityPolicy],
  temperature: 0.2
});
 
if (review.approved) {
  return draft.output;
} else {
  // One bounded retry
  const revision = await model.generate({
    systemPrompt: "You are a code generator. Address this specific feedback.",
    context: [taskSpec, relevantFiles, review.feedback],
    temperature: 0.5
  });
  return revision.output;
}

The Coordinator pattern for complex workflows

When you have multi-step workflows (onboarding flows, data pipelines, deployment sequences), designate one agent as the coordinator that cannot perform work itself. It can only dispatch to worker agents and manage state. This is the Integrator pattern applied to any domain. The coordinator holds the global state. Workers hold local context. No single agent holds everything.

Linear uses a variant of this pattern in their AI project management features. The coordination agent understands project structure and team allocation. Worker agents handle specific tasks like writing updates, triaging bugs, or drafting specifications. The coordinator never writes content itself. It routes, prioritizes, and escalates.

The Verification agent for production safety

Add a final verification agent to any pipeline that produces user-facing output. This agent receives the final output plus a set of invariants that must be true. "Response must not contain PII." "Code must pass type checking." "Summary must reference the original document." The verification agent has one job: confirm or reject. It is cheap to run, fast to execute, and catches the class of errors that slip past generation and review.

Stripe uses this pattern in their documentation pipeline. Generated docs pass through a verification agent that checks technical accuracy against their API specifications. The verification agent catches roughly 12% of outputs that would otherwise ship with subtle technical errors.

The economics of multi-agent vs. single-agent

A common objection to multi-agent architecture is cost. "You are making three API calls instead of one." This framing misunderstands the economics.

Factory shared production economics in their talk. Their multi-agent system costs approximately 2.3x per task compared to a single-agent baseline. But their success rate is 3.1x higher. And their rework rate (tasks that need human intervention after initial completion) is 74% lower. When you account for the fully-loaded cost of an engineer re-doing failed AI work, the multi-agent system is roughly 40% cheaper per successfully completed task.

The cost equation:

• Single agent: $0.12 per task, 31% success rate = $0.39 per successful task
• Multi-agent: $0.28 per task, 96% first-pass success = $0.29 per successful task

These numbers are from Factory's production system circa early 2026. Your numbers will vary, but the ratio holds. Spending more on inference to get higher reliability is almost always cheaper than spending human time fixing unreliable output.

Research on agent economics supports similar findings. Multi-agent configurations with 3-5 specialized agents consistently outperform single-agent systems on cost-per-successful-completion metrics, despite higher raw inference costs. The breakeven point is approximately a 15% improvement in success rate. Anything above that, and multi-agent pays for itself.

My experience with agent coordination at scale

Having coached over 12,000 engineers through various programs and hired more than 600 during my career, I have seen a consistent pattern: the teams that ship reliable AI features are not the ones with the most sophisticated models. They are the ones with the most disciplined architecture. The multi-agent patterns Factory describes map directly to what I have observed at AWS, where distributed system thinking is table stakes.

The teams I have worked with that struggle most with AI integration are those that treat the model as a monolithic oracle. "Ask it to do everything, hope for the best." The teams that succeed treat AI calls like service calls in a distributed system: bounded, typed, retriable, observable. They build collaborative AI engineering workflows where the system is designed for graceful degradation, not perfect performance. This is the product engineer's superpower. You think in systems, not in prompts.

As a product engineer, your job is to ship outcomes, not to impress people with the complexity of your agent architecture. Multi-agent systems are powerful precisely because they make complex behavior emerge from simple, constrained components. Each agent is boring. The system is interesting. That is the entire lesson.

Common failure modes and how to avoid them

After studying Factory's approach and implementing variations of it across multiple projects, I have identified the failure modes that kill multi-agent systems in production.

The infinite loop. Two agents ping-pong feedback indefinitely. Agent A drafts, Agent B rejects, Agent A revises, Agent B rejects again. Fix: hard limits on retries. Factory uses two. I have seen teams succeed with three. Never more than five. If five attempts cannot solve it, a human needs to look.

The context leak. Agent A receives information meant only for Agent B. This happens when you share a single conversation thread across agents. Fix: strict context isolation. Each agent gets its own context window, populated only with the information relevant to its role.

The authority conflict. Two agents give contradictory instructions to a third. The Reviewer says "add error handling." The performance agent says "remove the try-catch, it is too slow." Fix: clear hierarchy. In Factory's system, the Integrator breaks ties. There is always exactly one agent with final authority.

The observability gap. You can see what each agent produced but not why the system behaved the way it did. The bug lives in the interaction between agents. Fix: log every handoff, every schema, every decision point. Your observability must cover the spaces between agents, not just the agents themselves.

The premature scaling trap. You add more agents because "multi-agent is better" without validating that the decomposition improves outcomes. Fix: start with one agent. Add a second only when you can measure a specific failure that the second agent would prevent. Factory started with one agent and added components only when production data showed specific failure modes that decomposition would address.

Where multi-agent architecture is heading

The multi-agent architecture pattern Factory demonstrated is version one. Several developments will shape how this evolves over the next 12 to 18 months.

Smaller, cheaper specialized models. Running GPT-4 class models for every agent is expensive. The trend toward capable smaller models (Mistral, Phi, Llama variants fine-tuned for specific tasks) means you can run specialized agents on purpose-built models. Your Drafter might use a large creative model. Your Reviewer might use a smaller model fine-tuned on code review data. The Integrator might use a reasoning model optimized for decision-making.

Standardized agent protocols. The Model Context Protocol (MCP) from Anthropic, the Agent Protocol from the AI Engineer Foundation, and OpenAI's function calling specification are converging on standard interfaces for agent communication. Within a year, you will be able to compose agents from different providers with typed, interoperable interfaces.

Agent observability tooling. Companies like LangSmith, Helicone, and Braintrust are building observability specifically for multi-agent systems. Tracing that spans agent boundaries, cost attribution per agent, and performance benchmarking across configurations. This tooling will make multi-agent systems as debuggable as traditional distributed systems.

The product engineer who understands multi-agent architecture today will be building the next generation of AI-powered products tomorrow. Not because the technology is novel, but because the patterns are proven. Decompose. Constrain. Coordinate. Ship.

Key takeaways

• Multi-agent architecture separates specialized agents by cognitive mode (generating, criticizing, coordinating), not by task type
• Typed handoffs between agents eliminate the ambiguity that causes cascading failures
• Bounded retry with human escalation makes systems production-safe; unbounded loops are the primary failure mode
• Multi-agent systems cost more per task but less per successful outcome; the breakeven is roughly a 15% improvement in success rate
• Start with one agent and add decomposition only when production data reveals specific failure modes that justify it
• Monitor boundaries between agents, not just agent outputs; that is where production bugs live

FAQ

What is multi-agent architecture in software engineering?

Multi-agent architecture is a system design pattern where multiple specialized AI agents coordinate to complete complex tasks. Each agent owns a distinct responsibility (such as drafting code, reviewing code, or coordinating integration) and communicates with other agents through typed interfaces. This pattern mirrors microservice architecture in traditional software: small, focused components connected through clean APIs.

How is multi-agent architecture different from a single AI agent?

A single AI agent attempts to handle all aspects of a task within one context window, which leads to cognitive overload on complex tasks. Multi-agent architecture distributes the cognitive load across specialized agents, each operating within a focused context. Research from Princeton's NLP Group shows multi-agent configurations achieve 2.4x higher success rates on real-world software engineering tasks compared to single-agent approaches.

When should I use multi-agent architecture instead of a single agent?

Use single-agent systems for bounded, well-defined tasks that fit comfortably within a model's context window (writing a function, answering a question, generating a test). Switch to multi-agent architecture when tasks require multiple cognitive modes (generating AND evaluating AND coordinating), when single-agent success rates drop below acceptable thresholds, or when you need structural guarantees like preventing confirmation bias in code review.

How does Factory AI's multi-agent system work in production?

Factory AI uses a "Drafter, Reviewer, Integrator" pattern. The Drafter generates candidate code changes with creative focus. The Reviewer evaluates those changes against standards and policies with a critical focus. The Integrator coordinates merging, testing, and deployment without writing code itself. They achieve 96% first-pass success with bounded retries and human escalation for the remaining cases.

Is multi-agent architecture more expensive than using a single agent?

Multi-agent systems cost more in raw inference (approximately 2-3x per task), but they are cheaper per successfully completed task because their success rates are dramatically higher. Factory reports their multi-agent system produces successful outcomes at $0.29 per task versus $0.39 per task for their single-agent baseline. The breakeven point is roughly a 15% improvement in success rate, which well-designed multi-agent systems consistently exceed.

Related reading

• What Is a Product Engineer?
• Don't Build Agents, Build Skills
• Context Engineering: The Skill That Replaced Prompt Engineering
• No Vibes Allowed: Solving Hard Problems in Complex Codebases
• Collaborative AI Engineering