Multi-Agent Orchestration: Coordinating AI Agents Through One Project Plan

One AI agent connected to your project is an assistant. It answers questions, drafts a document, maybe updates a task when you ask it to. Add a second agent, from a different ecosystem, working the same project at the same time, and you no longer have an assistant problem. You have a coordination problem: which agent claims which task, what happens when both try to update the same record, and how a human stays the actual decision-maker when two or three non-human workers are moving through the backlog in parallel.

That coordination problem is what multi-agent orchestration actually names. It isn't a bigger, faster version of chat-based AI help. It's a distinct capability, one project plan as shared state, multiple independent agents reading and writing against it, and a set of rules that keeps them from stepping on each other.

TL;DR. Multi-agent orchestration means several AI agents, often from different ecosystems (Claude, ChatGPT, Cursor, a vendor's own AI), work against the same project plan concurrently instead of one assistant working alone in a chat window. The plan itself, with task ownership, status transitions, and an audit log, is the shared state that makes this safe: agents claim work by changing status, write idempotently so retries don't duplicate actions, and hand off to a human at defined approval gates rather than acting on everything unsupervised. Skip the coordination layer and multi-agent setups produce duplicate work, conflicting edits, and agents that quietly loop on their own output.

One Agent Is an Assistant. Several Agents Is a Different Problem

A single agent in a chat panel has an easy job: hold the conversation, answer from context, maybe make one change when explicitly told to. There's no coordination question because there's nothing else acting on the same data at the same time.

The moment a second agent enters the picture, everything changes, even if neither agent is doing anything wrong individually. Say a PM uses Claude to plan a migration and ChatGPT to draft the customer-facing communications for it. Both agents, unless something stops them, might reasonably look at the same task list, both decide a particular task needs updating, and both write a conflicting status. Neither agent did anything unreasonable in isolation. The failure is structural: nothing coordinated the two of them.

This is why an open connection standard matters here in the first place. MCP, the Model Context Protocol, is what lets agents from genuinely different vendors, Claude, ChatGPT, Cursor, connect to the same external system through one open interface rather than a proprietary integration built for a single client. Multi-agent orchestration across ecosystems is only possible because that connection layer is standardized; without it, every agent vendor would need its own bespoke integration; with it, any MCP-compliant client can read and write the same plan.

This is also the part most "AI agent" pitches skip, because a demo with one agent looks impressive and a demo with three agents fighting over the same task looks broken. The three-agent case is the more honest picture of where the category is actually heading. Agent-native project management covers what makes a single connected agent trustworthy: token-bounded scope, verify-before-done, server-side audit. Multi-agent orchestration is the layer on top of that, for when more than one trustworthy agent is active on the same plan at once.

Why the Plan, Not a Chat Thread, Is the Right Shared State

The instinctive design for connecting multiple agents is to give them a shared conversation: a channel or thread where each agent posts what it did so the others can catch up. This does not scale past the first few messages, and it fails for a specific reason: a conversation is not a queryable, structured record of who owns what and what state anything is currently in. An agent joining mid-project would have to read the entire scrollback to reconstruct the current state, and even then, natural language descriptions of "who's doing what" drift from what's actually true within days.

The alternative is to make the project plan itself, tasks, sprints, milestones, dependencies, an audit log, the substrate every agent reads from and writes to, rather than a side channel the agents narrate into. When an agent moves a task, flags a risk, or drafts a status report, the change lands on the plan itself, under the same permission checks, idempotency guarantees, and audit trail a human edit would get. The conversation an agent has with its own user is disposable. The plan is what persists, and it's what the next worker, human or a completely different agent, picks up.

This is precisely why Onplana's agent surfaces (an MCP server plus an in-app Run-with-Agent flow) both write into the same project data instead of maintaining separate agent-specific state: a task Cursor moves to DONE mid-coding is immediately visible to Claude checking overdue items five minutes later, because both are reading and writing the same plan, not two different logs that need reconciling. The agent skills announcement covers how a single agent's planner and runner skills use this plan-as-substrate model; multi-agent orchestration is what happens when more than one client does this at once.

How Do You Stop Two Agents From Claiming the Same Task?

You need an exclusive claim handed out by the server, in the same call that picks the task. Anything looser has a race in it, including the answer that looks obvious.

Why status-as-a-claim is not enough. The intuitive approach is to let the status transition be the signal: an agent moves a task to IN_PROGRESS before starting, and everyone else polling for open work sees it and skips. That works until two agents poll at the same moment. Both read the task as open, both decide to take it, both write IN_PROGRESS, and the second write succeeds because nothing was checking. The window is small and it is real, and it widens exactly when you scale up the number of agents, which is the situation the design is for. Worse, the natural response to losing that race is to poll again, so a near-miss turns into a polling loop.

A lease, granted in the same call that selects the work. The fix is a conditional claim: one request both picks the next available task and takes an exclusive lease on it, and the server grants it to exactly one caller. Listing and then claiming in a second call reintroduces the gap. Onplana exposes this as a single next_task call, with claim_task for the case where the agent already knows which task it wants.

The lease belongs to the run, not the user. This is the part that surprises people. Two Claude Code sessions connected to the same workspace authenticate as the same agent persona, so a lock keyed to the user identity would consider them the same claimant, and one session could renew or release the other session's work. The lease is therefore keyed to the individual run. Ask any vendor this specific question, because a per-user lock looks correct right up to the moment a team runs two sessions.

Leases expire, and completion hands them back. A crashed agent must not hold a task forever. Leases lapse on their own, so the task returns to the pool without an administrator intervening, and an agent that is still working renews. Finishing a task or marking it blocked releases the lease immediately rather than waiting out the clock, and ending a session releases everything that run still holds.

Idempotent writes. Network calls get retried. An agent's client might time out and resend a request that actually succeeded the first time. If "mark task done" isn't idempotent, a retried call could double-log time, duplicate a comment, or re-trigger a downstream automation. Every write an agent makes against the plan needs to be safe to receive twice without changing the outcome the second time.

Ownership at the record level, not just the task level. The same discipline extends to Issues, Risks, and Change Requests. If Agent A files an issue about a broken build and Agent B, running a similar sweep an hour later, doesn't check for existing open issues first, you get duplicate issues describing the same problem from two different angles, which is worse than no automation because a human now has to reconcile them.

Self-loop avoidance. A subtler failure: an agent scanning for new comments or updates needs to skip messages it authored itself, and advance its own "since I last checked" timestamp on every poll. Without this, an agent can end up replying to its own note from an earlier pass, looping on itself indefinitely, or worse, treating its own comment as new human feedback and acting on it a second time.

None of these mechanisms are exotic. They're the same concurrency-control patterns any multi-writer system needs, applied to a project plan instead of a database table, which is exactly the point: a project plan built to be a serious shared substrate for agents needs the same rigor a backend engineer would demand of any system with concurrent writers.

Three Coordination Patterns Worth Naming

Not every multi-agent setup needs the same topology. Three patterns cover most real cases.

Peer. Multiple agents pick up independent, non-overlapping work from the same backlog, each taking an exclusive lease on the task it starts, with no agent supervising another. This is the shape shown in the agent skills demo: ChatGPT, Claude, and Onplana's own AI each execute their own tasks (copy, build, publish) against one shared plan, with no agent aware of or dependent on the others' internal reasoning, only on the plan state they leave behind.

Pipeline. One agent's output is explicitly the next agent's input, sequenced by task dependencies rather than free-for-all claiming. A planner agent decomposes a goal into a task tree; a runner agent only picks up tasks whose predecessors show DONE. The dependency graph itself does the sequencing, the same mechanism that already prevents a human from starting downstream work before an upstream deliverable is ready.

Supervisor. One agent (or a human) reviews and ratifies the outputs of several worker agents before anything ships externally. This is the pattern for higher-stakes work: a status report drafted by one agent, a risk assessment drafted by another, both landing as proposals a human reviews together rather than either shipping unsupervised.

Most real setups combine these: peer claiming for independent task pickup, pipeline sequencing where dependencies genuinely exist, and a supervisor gate before anything customer-facing goes out.

The diagram below shows the peer pattern in the shape it actually takes in production: three different agent ecosystems, one shared plan as the control plane, and a human approval gate before anything external ships.

Where Human Approval Fits in a Multi-Agent Sweep

Multi-agent orchestration is not the same thing as removing humans from the loop. The pattern that holds up under real use is propose-ratify: agents draft plans, populate task trees, write status report drafts, and flag risks; a human reviews and either accepts, edits, or rejects before anything with external consequences (a customer email, a scope change, a budget commitment) actually ships.

The gate matters more than the frequency. A team new to running multiple agents typically starts with a tighter gate, reviewing every agent proposal before it lands, then loosens the gate as the acceptance rate stays consistently high. This mirrors the guided-versus-high autonomy distinction covered in the agent skills post: guided mode pauses for a human go-ahead before each step; high autonomy acts and reports, pausing only at defined guardrails. Multi-agent setups need the same dial, just applied across however many agents are active, not per agent in isolation.

What stays firmly on the human side regardless of how many agents are running: financial commitments, baseline sign-off, performance reviews, vendor selection, and termination decisions. Adding more agents doesn't expand what agents are trusted to decide; it just means more of the low-judgment, high-volume work moves off a human's plate at once. The full act, suggest, stay-out model covers where those lines sit in detail.

Where Multi-Agent Orchestration Actually Breaks

Three failure modes account for most of the pain teams report after their first month running more than one agent.

Ambiguous ownership. An agent claims a task by moving its status, but if a second agent (or a human) doesn't check current status before acting, both can end up working the same item. The fix is procedural, not clever: every agent's sweep should always check current status immediately before acting, not rely on a stale read from earlier in its own session.

Duplicate issue filing. Two agents independently discover the same underlying problem and each files its own issue describing it slightly differently. A human triaging the backlog now has to notice the duplication and merge it, which is exactly the kind of overhead multi-agent orchestration is supposed to remove, not add. The mitigation is a search-before-file step: an agent checks for existing open issues matching the failure signature before creating a new one.

Orchestration overhead exceeding the benefit. For a small team with light task volume, running three separate agents with their own coordination logic can cost more in setup and monitoring than it saves. Multi-agent orchestration earns its complexity when task volume, or diversity of tooling (a team already using Claude for planning and Cursor for code, for instance) makes single-agent coordination the actual bottleneck. Below that threshold, a single well-configured agent is the simpler and often faster choice.

Evaluating a Multi-Agent Setup Before You Rely On It

Before turning on more than one connected agent against a live project, check for these five things.

1. Confirm the shared state is the plan itself, not a chat log. If two agents can only "know" what the other did by reading a conversation transcript, the setup will drift.
2. Confirm writes are idempotent. Ask what happens if any single action is submitted twice; the answer should be "nothing changes the second time," not "it duplicates."
3. Confirm task claiming has a real mechanism. A status transition, a lock field, something enforced server-side, not an informal convention agents are supposed to follow.
4. Confirm there's a search-before-create step for issues and similar records. Otherwise duplicate filing is a matter of when, not if.
5. Confirm the human approval gate is explicit and where it should be. Not every action needs a human, but every externally consequential one does, and the boundary should be a written rule, not a judgment call made differently by each agent.

Multi-agent orchestration is where AI-augmented project management is actually heading, past the single chat-sidebar assistant and into a mode where several agents genuinely divide the work. The coordination discipline that makes it safe, shared state in the plan, ownership through status, idempotent writes, and a human gate at the points that matter, is not exotic engineering. It's the same discipline that already makes human teams work, applied consistently enough that software can enforce it instead of hoping everyone remembers the convention.