AI Agent Orchestration Patterns: Sequential, Parallel or Manager-Led?

Pick the pattern from the dependencies, then give every step an owner and a reviewer. If each step needs the last one’s output, run them in sequence; if steps can start from the same agreed inputs, run them in parallel and name someone to reconcile them; if the next step depends on what a finding turns up, let a manager agent route the work and review what comes back.

This guide walks through those choices with one example: reviewing a proposed API change. The guide is not a framework comparison. For where frameworks, harnesses, runtimes and control planes sit, see Agent harness vs. framework vs. runtime vs. control plane.

What is a multi-agent workflow?

A multi-agent workflow splits one piece of work across more than one agent, where each agent owns a step and the steps connect through handoffs. The pattern is the shape of those handoffs: a line, a fan-out that joins back up, or a tree a manager extends as it learns more.

What makes it a workflow, rather than several agents running at once, is that the outputs have to come back together into something a person can accept or reject. So ownership and review matter more than how many agents you run.

Do you need more than one agent?

Often not. If one agent can produce the finished output, and that output gives the human enough evidence to judge it, keep one agent. A separate human review doesn’t require a second agent. Microsoft’s agent design pattern guidance puts it as “Use the lowest level of complexity that reliably meets your requirements.”

Split the work when you can name what the split makes possible: a distinct specialist review, a handoff the work requires, or an investigation whose next owner depends on what it finds. “More eyes” doesn’t tell anyone what to produce or when to stop.

How do you choose between agent orchestration patterns?

Ask one question of every step: what does it need before it can start? Write the answers down and the pattern usually picks itself.

Two rules hold across every row. Each step has exactly one owner. And as a working practice, no agent reviews its own output.

Worked example: an API-change review

For example, let’s say you are an API owner trying to decide whether a proposed service change can ship, but several specialist reviews have to come back as one memo you can sign. Here’s how to approach it.

The output is a review memo that recommends accepting, revising or holding the change, with every finding tied to a requirement and a sample. You make the decision.

Start by freezing one review packet that every agent works from. Fill in these slots for your change:

Give the packet a name, such as api-review-v1. If the criteria don’t exist yet, have an agent propose them from the requirements and approve them yourself before any review starts. A reviewer who finds a missing rule reports the gap instead of quietly changing the test.

Then draw the map. An arrow means the next step needs the previous step’s output:

Requirements → proposed criteria → API owner approves packet
                                         |
                           +-------------+-------------+
                           |                           |
                  Compatibility review        Error-response review
                           |                           |
                           +-------------+-------------+
                                         |
                               Reconcile review memo
                                         |
                              Human acceptance decision

The map gives a sequence (criteria before reviews), two parallel branches (the reviews) and a join (the memo). Nothing in the map needs a manager yet.

When should agents work sequentially?

When step B can’t start until step A has produced something. Here, neither review can begin until the criteria are approved: if nobody has settled whether legacy requests must keep working, the compatibility reviewer can’t judge whether rejecting them is acceptable.

Review at the handoff, before the next agent builds on the output. A wrong assumption in the criteria costs more with every step after it. The cost of a sequence is waiting, so don’t make a step wait for something it doesn’t use: the error-response review doesn’t need the compatibility review’s findings.

In Paperclip, a task can be marked as blocked by another task, and agents treat a task with an unresolved blocker as not yet startable. For this map, record packet approval as its own task, make each review blocked by it, and make reconciliation blocked by both reviews. The relation records the arrows; the reconciliation owner still checks that the findings exist and refer to api-review-v1.

When should agents work in parallel?

When each step has everything it needs from the shared inputs. Once the packet is approved, two reviews can run from it:

• The compatibility reviewer checks whether previously valid requests stay valid.
• The error-response reviewer checks whether each invalid input has a documented response.

Neither finding is shaped by the other, so neither review has to wait for unrelated work. Each returns the packet name, criterion, sample, finding, evidence and any open question. If compatibility finds that the proposal would reject requests that are valid today, and error-response finds an invalid sample with no documented response, those are separate findings against the same packet, not a reason for either review to wait.

Parallel work only stays separate if the agents don’t write to the same thing. Two agents editing the same specification, the same files or the same checkout can collide. Separate branches or worktrees move the collision to merge time; they don’t remove it. This approach avoids the collision by asking for read-only findings, and still names one reconciliation owner before the branches start, with a join rule: both reviews return findings against api-review-v1 or say why they can’t. A missing review makes the memo incomplete, not a pass. Running branches at once also isn’t automatically faster in total; reconciling them takes time too.

In Paperclip, the execution policy docs note that “only one agent run can be active per issue at a time.” That limit is one reason to give each review its own child task. Runs on a project’s shared checkout follow a shared workspace concurrency setting (Auto, Serialize or Allow). Giving each task run its own git worktree is an experimental feature that must be switched on per instance and per project. Either way, someone still owns the merge.

When should a manager agent split the work?

When a finding changes what work comes next. Suppose a compatibility review finds that the proposal mentions an exception for who may keep using the old contract, but never defines who qualifies. The next step might be a documentation fix or a full migration review, and you can’t know which yet.

A manager agent can take that question with a bounded assignment: find the missing rule, ask the authorized owner one targeted question, update the recommendation, and hand any policy decision back to you. Its output keeps the question, who answered and whether the packet changed. If it did, the affected review reruns against the new packet; an old finding doesn’t carry over automatically. For one question, you could route it yourself. A manager earns its place when there’s real routing to do within a clear limit.

Microsoft’s Agent Framework orchestration docs separate fixed sequential and concurrent patterns from one where “A manager agent dynamically coordinates specialized agents.” Framework patterns don’t establish how any particular runtime behaves.

In Paperclip, delegation starts with a strategy you approve; the CEO agent then creates tasks for its reports, and every task links back to the goal through a parent hierarchy. Under the org structure, each agent has one manager, managers break tasks into subtasks for their reports and review the completed subtasks, and blockers escalate up the reporting line. If an agent tries to delegate work back to the agent that created a still-open ancestor task, Paperclip refuses with a delegation_cycle conflict.

How do you reconcile agents that disagree?

Against the criteria, not by vote. Suppose one reviewer recommends accepting because the new request matches the proposal, and another recommends revision because a previously valid request would now fail. A valid new request doesn’t satisfy a rule that existing callers keep working. The reconciliation owner keeps both findings, explains the conflict and recommends revision unless you approve a versioned breaking change.

The human gets one memo with the packet name, a finding per criterion with its evidence, conflicts resolved and still open, missing evidence and what it means for the decision, and a recommendation to accept, revise or hold. A missing error definition is a documentation gap; untested runtime behavior is a verification gap. Agreement between agents turns neither into a pass.

Who should review each step?

Someone other than the owner, who can say “this is right” or “send it back” with a reason. Choose reviewers by what a mistake would cost:

Approving a task’s output is not the same as authorizing a tool action. Approving the memo doesn’t let an agent change the API. In Paperclip, each connector action is set to Allowed, Ask first or Off, new connections start as Allowed, and those settings don’t govern shell commands. Check them separately from your review setup.

A written instruction to get review is different from a review the runtime enforces. With a Paperclip execution policy, a task the executor marks done moves to in_review and goes to the named reviewer, then to an approver if you add an approval stage. The docs set a default cap of 3 consecutive agent change requests, adjustable with maxReviewRounds; after that the review goes to the responsible human, and a human’s own change request resets the count. Every decision is recorded with actor, outcome, comment and run ID. A stage pair from the docs looks like this:

{"stages":[
  {"type":"review","participants":[{"type":"agent","agentId":"qa-agent-id"}]},
  {"type":"approval","participants":[{"type":"user","userId":"manager-user-id"}]}
]}

Verify the policy in your own installation before relying on it.

Plan your next task

Fill this in before you assign anything:

Decision the human needs to make:
Final output and acceptance criteria:
Frozen inputs and their names:
Why one agent is enough, or why the work needs a split:
Steps that need an earlier output:
Steps that can use the same inputs independently:
Questions whose next owner depends on a finding:
Owner, input and output for each step:
Reviewer for each step (never its owner):
Who reconciles, and which outputs must arrive:
What happens on a conflict or a missing output:
Limit for stopping or escalating to a human:

Frequently asked questions

Related reading

• What is an AI agent control plane?
• Manage multiple Claude Code and Codex sessions
• Assign and review AI agent work without a terminal