When One Agent Becomes Three

Everyone is shipping multi-agent features this month.

JetBrains Air dropped into public preview — assign tasks to multiple AI agents simultaneously from a single desktop interface. Claude Code Agent Teams lets you split large tasks across parallel agents with shared context. Copilot Squad runs coordinated agent fleets natively inside your repository. Cursor’s Composer 2 brings the whole thing in at a dramatically lower price point.

The sales narrative is consistent: parallel execution, faster delivery, developers freed from repetitive work to focus on architecture. And that narrative is accurate — as far as it goes.

Here’s what it doesn’t cover.

Orchestration multiplies what you already have

A single agent on a scoped task is a tractable oversight problem. You define the task, you watch the output, you review and merge. The mental model maps reasonably well onto how you’d supervise a new engineer on a constrained ticket.

Multiple agents running in parallel, making decisions that interact in a shared codebase, is a different class of problem. It’s not harder by a constant — it’s harder by a multiplier. The same permission model you didn’t fully audit for one agent now applies to three. The scope ambiguity that let one agent touch files it shouldn’t is now being interpreted simultaneously by multiple agents against the same fuzzy boundary. The review process you kept mostly unchanged after your initial AI rollout now needs to handle output that’s been generated, processed, and modified by multiple agents before it reached you.

Orchestration amplifies your process discipline the same way it amplifies your throughput. If that number is low, do the math.

The patterns that break first

We’ve watched enough agentic deployments go sideways to recognize the failure modes. With multi-agent systems, they accelerate.

Scope drift compounds. One agent making an autonomous decision about what’s in scope is a single problem to unwind. Three agents independently interpreting a loose task definition can produce changes across four repos before anyone notices. The classic story: a test migration task that started in one directory and ended in a shared utility library, then the integration tests, then a config file that conflicted with production. Nobody did anything wrong — each decision was locally reasonable. The scope was just never tight enough to prevent it.

Audit trails get thin. With a single agent, you can at least reconstruct what happened from the git history and the agent’s session context. With parallel agents, the reconstruction problem scales. What did Agent 2 decide while Agent 1 was working on the module it later read from? What assumptions were shared between them, and what did each one bring independently? The log of what happened gets distributed across multiple runs, and the reasoning that informed the decisions often lives nowhere.

Trust calibration falls behind. The first week of multi-agent use tends to go well — the demos land, the tasks complete, engineers are enthusiastic. It’s month three that’s telling. That’s when the edge cases accumulate, when the assumption baked into an early agent run quietly stops being true in production, when the subtle errors that passed validation start surfacing in customer reports. Trust calibration isn’t “did it work this time” — it’s “do I have enough evidence to know what the failure mode looks like, and will I catch it?”

What the teams getting it right actually do

They treat multi-agent as infrastructure, not a feature.

The decision to run three agents in parallel isn’t a setting you enable. It’s an architectural decision that carries the same weight as any other system design choice: what are the boundaries, what are the permissions, what does failure look like, who’s responsible when something goes wrong.

Concretely, that looks like:

Explicit scope before any agent starts. Not “refactor the auth module” — that’s an intent, not a scope. Which files are in scope. What behavior is changing. What done looks like. What the agent is not allowed to touch. Define this before the run, not during it.

Permission models that match actual risk. Agents inherit ambient permissions by default. That default is wrong for multi-agent systems at any meaningful scale. Each agent should have access to what it needs for its specific task and nothing else. This is the principle of least privilege applied to AI systems, and it’s load-bearing.

Audit logging from day one. What did each agent do during its run? Not just the output — the decisions. The files touched, the interpretations made, the places where the agent hit ambiguity and resolved it without checking in. If you can’t reconstruct a run, you can’t debug a failure. Build logging before you deploy, not after.

Human checkpoints at decision boundaries. There are decisions that are fine to delegate — boilerplate, scaffolding, test coverage for known behavior. There are decisions that need a human in the loop — anything touching business logic, security, or system boundaries that weren’t explicitly in scope. Map those boundaries before you start. The agent won’t map them for you.

The last mile is longer

There’s a version of this post that ends with “don’t use multi-agent AI.” That’s not the point.

The tooling is genuinely getting better. Agent Teams and Air and Squad are real productivity gains for teams that have built the right scaffolding around them. Parallel execution on well-defined tasks is powerful. The ability to divide and conquer large codebases across coordinated agents — when the coordination is designed, not hoped for — is the future of how significant software gets built.

The point is that the last mile of multi-agent deployment is longer than the last mile of a single agent. Not insurmountably — but meaningfully. The operational model has to scale with the capability.

The question isn’t whether to run multiple agents. It’s whether your permission model, your scope discipline, your audit infrastructure, and your review process are ready for what orchestration multiplies.

That work isn’t the exciting part. It’s the part that makes the exciting part sustainable.

The tools are ready. The last mile is yours to build.