Agentic Development Part 6: Multi-Agent Workflows

The previous five articles in this series covered how a single agent works — autonomy (Part 1), its anatomy (Part 2), task design for a single agent (Part 3), the context it needs (Part 4), and the guardrails that keep it safe (Part 5). But there’s a class of work that a single agent can’t sufficiently complete, no matter how well the tasks and context are designed — work that’s large in scale, involves different domains each needing specialization, or spans naturally separated stages from raw requirements to deployment-ready code. This article discusses how several agents work together in a coordinated way, with a pipeline from PRD to deliverable as the central case study — a topic that was previously discussed as a separate discussion before this series was reorganized to explicitly include it here.

When One Agent Is No Longer Enough

Part 2 already covered the sub-agent-within-one-task pattern — temporary delegation for parallel exploration whose results are immediately absorbed back by the main agent within one working session. The multi-agent workflow discussed in this article differs from that pattern in three fundamental ways:

Role independence. Every agent in the workflow has a clear, distinct responsibility — not just the same instance run in parallel to speed up exploration, but agents with different functional roles: one translates requirements, one executes implementation, one verifies results.

Longer duration. Sub-agents within one task are usually short-lived, done as soon as their sub-job completes. Agents in a multi-agent workflow often live through an entire stage of the pipeline, sometimes across sessions.

The need for an explicit coordinator. Once there’s more than one agent with independent roles that must work consistently with each other, a layer is needed to manage ordering, distribute work, and merge results — a role that in the simple sub-agent pattern is implicitly held by the main agent.

Research comparing single-agent versus multi-agent performance on equivalent tasks found an important finding to note: on the majority of benchmarks, a single agent with the same tools and context actually matched or outperformed multi-agent systems, with multi-agent only giving a small accuracy advantage at roughly double the cost. The implication is clear — multi-agent isn’t an automatically better default, but a trade-off that only makes sense when the work’s complexity genuinely requires specialization or parallelism that a single agent can’t achieve. The end of this article covers concrete criteria for evaluating this trade-off.

The more appropriate question before building a multi-agent workflow isn’t “can this be split into several agents”, but “is a single agent with well-designed tasks (as covered in Part 3) genuinely insufficient for this work”. The added complexity of multi-agent orchestration is only worth it if the answer is clearly no.

Orchestration Pattern: Orchestrator-Worker

Of the various orchestration patterns that have developed, the orchestrator-worker pattern (also often called the supervisor pattern) is the most widely used in production because of its predictability and ease of debugging. One coordinator agent holds the overall plan and delegates sub-jobs to worker agents, then merges the results back.

flowchart TD
    A[Coordinator: Holds the Overall Plan] --> B[Worker 1: Sub-job A]
    A --> C[Worker 2: Sub-job B]
    A --> D[Worker 3: Sub-job C]
    B --> E[Coordinator: Merge Results]
    C --> E
    D --> E
    E --> F{Complete & Consistent Results?}
    F -- Yes --> G[Done]
    F -- No --> A

The reason this pattern is the default choice over alternatives like a peer-to-peer mesh (where every agent can communicate directly with any other agent without a mediator) lies in traceability and debugging ease. In a mesh pattern, tracing why a decision was made requires following communication among many freely interacting agents — the number of possible communication paths grows quickly as agents increase. In the orchestrator-worker pattern, all decisions about ordering and work distribution pass through a single point, keeping the decision flow linearly traceable even as the worker count grows.

Other variations are also commonly used depending on the shape of the work: sequential pipelines for work with a fixed order where each stage depends fully on the previous stage’s output (fitting the requirements-to-deliverable pipeline discussed next), and fan-out/fan-in for work that’s truly independent and can be done in parallel before being merged back. These three patterns — orchestrator-worker, sequential pipeline, fan-out/fan-in — are often combined within the same workflow, not chosen exclusively as just one.

Start with the orchestrator-worker or sequential pipeline pattern as the default. More complex patterns like free peer-to-peer communication among many agents should only be considered after a real need exists that simpler patterns can’t meet — added complexity must be justified by need, not chosen because it sounds more sophisticated.

Case Study: From PRD to Deliverable

This is the pipeline that forms the backbone of this article — how raw business requirements, which are often technically under-specified, are translated step by step into a consistent deliverable, through explicit control points along the way.

flowchart TD
    A[PRD / Business Requirements] --> B[Technical Spec: ERD, API Contract, State Model]
    B --> C[Plan: Breakdown into Tasks/Tickets]
    C --> D[Agent Execution per Task]
    D --> E[Deliverable: Code, Tests, PR]
    B -.agreed & human-reviewed.-> B

Each stage in this diagram deserves separate discussion, because each has its own characteristics and risks.

PRD to Technical Spec. This stage is where business ambiguity is highest and needs translating into concrete technical decisions. An agent (usually acting as coordinator or a dedicated early-stage agent) can propose a draft ERD, API contracts, and state model from the PRD automatically — but this draft is explicitly not a final result to be executed directly. This is the direct answer to the question that drove this article’s reorganization: a pure PRD isn’t specific enough to guarantee consistent implementation, because it explains what’s needed from a business viewpoint, not how data is modeled or how contracts between components are defined.

Technical Spec as a Mandatory Checkpoint. This is the most critical control point in the entire pipeline, and it’s deliberately designed as the point needing the most human involvement, not the one most suitable for full automation. Once the ERD and API contracts are agreed and saved as reference files — exactly like the OpenAPI schemas and JSON Schemas covered in Part 3 of the Spec-Driven Development series — those files become the fixed contract that every subsequent agent in the pipeline reads, preventing each agent from “reinventing” its own technical design differently.

Technical Spec to Plan. After the spec is agreed, the coordinator breaks it into individual tasks following the granularity and dependency principles covered in depth in Part 3 — including identifying which tasks are independent and can be done in parallel by different workers, and which must wait for other tasks to finish first.

Plan to Multi-Agent Execution. The broken-down tasks are distributed to workers — either one generalist agent working through the tasks sequentially, or several agents with different specializations working in parallel (discussed in more detail in the role specialization section). Every worker still references the same technical spec as the source of truth, not each one’s own assumptions.

Execution to Deliverable. The results from every worker are merged by the coordinator, passing through the guardrail layers covered in Part 5 — automated tests, contract tests against the spec, and if needed an independent reviewer agent — before being considered a ready deliverable, whether a pull request, a deployment-ready build, or another artifact depending on the project context.

The biggest temptation in building a pipeline like this is fully automating the PRD-to-technical-spec stage for speed, assuming the agent-produced draft is “good enough”. This stage is precisely the riskiest to skip human review on — ERD or API contract design errors not corrected here will propagate into every subsequent task built on top of them.

Orchestration Components: Decomposer, Registry, State Manager

Behind the simple-looking orchestrator-worker diagram, three components make this coordination actually work in practice, not just as a concept on paper.

Task decomposer — the component that breaks a large goal (in the case study above, the agreed technical spec) into a list of concrete work items. Its function resembles the task design discipline covered in depth in Part 3, but it runs as an explicit part of the orchestration system, not done manually once at the start. A good decomposer produces well-formed work items — each with clear scope and executable without additional ambiguity, exactly the previously discussed principle of tasks cut along naturally independent boundaries.

Agent registry — the list mapping which agent has which capabilities. In the PRD-to-deliverable pipeline, this means the coordinator knows a certain task (for example, a database schema migration) should be delegated to a worker configured for backend work, while another task (client-side form validation) is delegated to a worker configured for frontend. This registry prevents the coordinator from delegating work to an agent that lacks the right context or tools to complete it well.

State manager — the component storing context and results between stages, preventing information loss at every agent handoff. This is crucial especially for long-running or cross-session pipelines: without an explicit state manager, one agent’s work results can lose their context once passed to the next agent, forcing the receiving agent to re-guess information that already exists.

flowchart LR
    A[Goal: Agreed Technical Spec] --> B[Task Decomposer]
    B --> C[List of Work Items]
    C --> D[Agent Registry]
    D --> E{Which Worker Fits?}
    E --> F[Backend Worker]
    E --> G[Frontend Worker]
    F --> H[(State Manager)]
    G --> H
    H --> I[Coordinator: Merge with Full Context]

These three components complement each other: the decomposer determines what must be done, the registry determines who does it, and the state manager ensures what’s already been done doesn’t lose its trace throughout the journey from one agent to the next.

Preventing Divergent Implementations: Contracts as the Consistency Guard

This is the direct answer to the concern that drove this series’ restructuring: without an explicit technical spec, implementations produced from the same PRD can differ every time they run — even by the exact same agent in different sessions, let alone by several agents working in parallel within one pipeline.

The root of the problem, as touched on in this article’s opening, is that an agent receiving pure business requirements fills technical design gaps with its own assumptions in the moment. In a multi-agent workflow context, this problem multiplies: if the backend worker and the frontend worker each independently guess the shape of the API contract without a shared reference, the results will almost certainly not match once merged.

flowchart TD
    subgraph NoContract["Without an Explicit Contract"]
        A1[Backend Worker] -->|guesses its own response shape| B1[API v1]
        A2[Frontend Worker] -->|guesses a different response shape| B2[Different Assumption]
        B1 -.doesn't match.-> B2
    end
    subgraph WithContract["With a Contract Agreed Up Front"]
        C[Technical Spec: API Contract] --> C1[Backend Worker]
        C --> C2[Frontend Worker]
        C1 -.both reference the same contract.-> C2
    end

This is why the technical spec checkpoint discussed in the previous case study isn’t an administrative step skippable for speed, but a core mechanism that makes multi-agent workflows reliable at all. Once the contract — ERD, API schemas, state definitions — is agreed and saved as a file all agents reference, every worker has the same source of truth to follow, regardless of when and by which agent the task is executed. This is directly an application of the API contract principle covered in Part 3 of the Spec-Driven Development series, only now seen from the angle of why it’s essential specifically for multi-agent coordination, not just documentation tidiness.

A pipeline that jumps straight from PRD to multi-agent execution without an explicit technical spec layer is a recipe for conflicting implementations. The more agents involved in parallel, the more expensive it becomes to reconcile implementations that have already diverged in assumptions — far more expensive than agreeing on contracts up front before execution begins.

Agent Specialization by Role

Workers in a multi-agent workflow can be designed as generalists (one same agent type handling whatever tasks are delegated) or specialists (agents with narrow roles and context tailored to specific domains). Both have clear trade-offs.

A pattern commonly used in production pipelines follows five functional roles that appear relatively consistently across reliable multi-agent systems, regardless of the specific domain: producer (breaking ambiguity into well-formed work items — the role the task decomposer holds in the PRD case study above), consumer/worker (executing those work items), coordinator (managing the overall flow), critic (raising findings without decision authority — similar to the reviewer agent covered in Part 5), and judge (deciding binarily whether results pass or fail).

An often-overlooked but important separation: producer and consumer roles shouldn’t be mixed. The producer’s job is translating ambiguity into clear work items; the consumer’s job is executing those already-clear work items. Mixing both roles in one agent is one of the most common causes of tangled prompts and uncontrolled token bloat, because the same agent is forced to bounce between “thinking about what should be done” and “actually doing it” without a clear boundary for when to switch modes.

Likewise, critic and judge should be role-separated: the critic raises suggestions without gate authority, while the judge decides pass or fail decisively. Mixing them — a critic that also holds decision authority — can create deadlock where the process never truly finishes because “one more suggestion” keeps being raised without a clear decision limit.

For a newly built pipeline, start with the minimum reasonable number of specialist roles — for example just producer, consumer, and judge — then add other roles (like a separate critic) when there’s real evidence that the additional role solves an actually occurring problem, rather than added speculatively up front.

Typical Multi-Agent Workflow Failures

Understanding the failures typical of multi-agent systems helps diagnose problems accurately, instead of adding complexity layers that make things worse.

Drift between agents due to separate contexts. Workers operating with their own separate context windows can develop slightly different understandings of the same task, especially if the technical spec meant to be the shared reference isn’t actually re-read by every worker at the start of its task. The mitigation was already covered in the contracts-as-consistency-guard section — make sure every worker genuinely references the same contract file, not relying on a summary that may have lost important details.

Deadlock or unclear handoff waiting. Happens when task dependencies (covered in Part 3) aren’t defined explicitly in the orchestration system, so a worker waits for input from another worker without a clear mechanism for when and how that handoff happens. A good state manager, as covered in the orchestration components section, should make these dependencies explicit and tracked, not assumed to “happen on their own”.

Duplicate work. Two workers work on overlapping tasks because the task decomposer didn’t break the work down with clear enough boundaries, or because the registry wrongly mapped the same task to two different workers. This produces wasted effort plus the risk of conflicting results when merged.

One agent’s failure breaking the whole pipeline without isolation. If one worker’s failure (for example, producing erroring code) isn’t well isolated, it can propagate into the result-merging process and fail the entire pipeline, even though other workers completed their work correctly. The per-task guardrails covered in Part 5 — including automated gates before results move to the next stage — act as circuit breakers isolating this failure so it doesn’t spread further than it should.

flowchart TD
    A[Worker A Fails] --> B{Isolated with a Gate?}
    B -- Yes --> C[Only Worker A's Task Is Delayed]
    C --> D[Workers B, C Keep Going Independently]
    B -- No --> E[Failure Spreads into the Merging Process]
    E --> F[Entire Pipeline Fails Even Though Other Workers Are Correct]

Beyond the four functional failures above, there’s also a real operational cost consideration: coordination between agents adds overhead — both in latency (extra time for inter-agent communication) and token consumption (additional context that needs sharing and reprocessing by every agent in the pipeline). This overhead isn’t just a financial cost, but also a factor to weigh when assessing whether multi-agent is truly worth it for a given job — discussed further in the next section.

When Multi-Agent Helps vs. Is Overkill

Recalling the finding at the start of this article that a single agent with the same tools and context often matches multi-agent system performance at far lower cost, the decision to build a multi-agent pipeline needs to be based on clear signals, not the assumption that more agents are always better.

Signals indicating a multi-agent workflow is worth building:

• Genuinely independent sub-jobs that can run in parallel — like backend and frontend worked on simultaneously after the API contract is agreed, where parallelism truly cuts completion time significantly
• Real domain specialization needs — tasks requiring very different contexts and conventions (for example, security auditing versus feature implementation) where forcing one generalist agent produces lower quality in both domains
• A pipeline that will be used repeatedly — the investment in building a decomposer, registry, and state manager makes more sense if this pipeline will serve many future features, not a one-off
• Large work volume — when the number of tasks to execute is substantial enough that parallelism yields meaningful time savings, not just two or three small tasks

Signals indicating multi-agent is actually overkill:

• Truly sequential tasks — if every step depends fully on the previous step’s result, parallelism brings no benefit, and coordination overhead (added latency and tokens, as covered in the failures section) is purely cost without speed compensation
• Small work volume — for work a single agent can easily complete in one reasonable session, the complexity of building and maintaining an orchestration system isn’t worth the benefit
• Teams or projects without mature technical specs — recalling the dangers covered in the contracts-as-consistency-guard section, building a multi-agent workflow without a solid spec foundation only scales up the implementation drift problem, not solves it
• Simple debugging needs — multi-agent systems are inherently harder to debug than a single agent, because problems can come from one agent’s logic, inter-agent communication errors, or the orchestration layer itself

Build a multi-agent workflow after trying a single agent with well-designed tasks and finding it genuinely insufficient — not as a first step because it sounds more sophisticated or more “agentic”. The added complexity of multi-agent orchestration is a real cost that must be justified by concrete need, exactly like the same warning applies to raising autonomy levels in Part 1 — both are temptations that feel progressive but aren’t necessarily worth their cost.

Summary

• A multi-agent workflow differs from sub-agents within one task (Part 2) in three ways: role independence, longer duration, and the need for an explicit coordinator
• Research shows a single agent often matches or outperforms multi-agent systems at far lower cost — multi-agent is only worth it when the work’s complexity genuinely requires it, not an automatic default
• The orchestrator-worker pattern (or sequential pipeline, fan-out/fan-in) is preferred over peer-to-peer meshes because of far better traceability and debugging ease
• The PRD-to-deliverable pipeline passes through a critical control point mid-way: the technical spec (ERD, API contracts) agreed and human-reviewed before execution — this is the point needing the most human involvement, not the one most suitable for full automation
• Three orchestration components make coordination actually work: the task decomposer (breaking goals into work items), the agent registry (mapping capabilities to tasks), and the state manager (preventing context loss at every handoff)
• An agreed technical spec contract up front is the main consistency guard preventing cross-agent implementations from diverging — without it, every worker fills technical design gaps with its own independent assumptions
• Five functional roles consistently found in reliable multi-agent systems: producer, consumer, coordinator, critic, judge — producer/consumer and critic/judge roles shouldn’t be mixed to prevent tangled prompts and decision deadlock
• Typical failures: drift between agents from separate contexts, deadlock from non-explicit dependencies, duplicate work, and one agent’s failure spreading without adequate guardrail isolation
• Build multi-agent only after a single agent with well-designed tasks is proven insufficient — consider independent sub-jobs, real specialization needs, and work volume proportionate to the coordination overhead that will certainly appear