Polylane Replaced an AI Agent Team With One. Then Pull Requests Arrived Faster.

The AI industry has spent the last couple of years trying to make software look suspiciously like an org chart.

One agent is the manager. Another investigates. Another writes code. Another reviews everybody else. Eventually, after enough digital delegation, somebody is supposed to get some work done.

Polylane recently tried the opposite approach: it deleted most of the org chart.

In a September 14 engineering post called “Sub-agents are just wrong”, authors Aleksandr Diamond and Boris Tane described replacing an incident-remediation workflow that could involve up to 18 agents and sub-agents with one agent responsible for the job from initial triage through pull-request creation.

Polylane reports a striking change.

Median time from detecting an issue to opening a pull request fell from 2.2 hours to 35 minutes. The 90th-percentile time dropped from nine days to under two hours. The share of detected issues resulting in a PR rose from 0.6% to 4.2%. Average model spending per PR fell from $111 to about $18 during the first nine days of the new setup.

Those numbers make a tempting story: one AI agent beat a whole team.

Polylane's experiment points toward a more useful lesson. Extra agents create value when they add genuinely independent work, evidence, or judgment. When several agents need to understand the same tightly coupled problem, every handoff creates another place to lose information.

And Polylane's numbers expose a second problem the agent industry will have to confront: producing more AI work isn't necessarily the same thing as producing better outcomes.

A pull request is still only a proposed fix.

Polylane's AI org chart looked reasonable on paper

Polylane monitors infrastructure by analyzing logs, metrics, traces, and alerts for signs that something has gone wrong.

Its original autofix architecture divided the response across specialists.

A triage agent decided whether an issue was real. A coordinator created possible explanations. Up to 15 sub-agents investigated those hypotheses from different starting points. Their findings were combined through confidence-weighted voting and summarized for the coordinator. If the system identified a likely root cause, another coding agent received a plan and attempted the fix.

The design made sense when Polylane built it in March.

At the time, the company says frontier models weren't consistently capable of handling an investigation from beginning to end, and Polylane says its own agent harness—the software surrounding the model—wasn't mature enough either. Breaking the problem into smaller pieces gave each agent a narrower job.

But specialization created another problem.

The agents weren't all working from the same evidence.

Hypothesis agents investigated pieces of the incident, then summarized what they found. The coordinator worked from those summaries and produced a plan. The coding agent received the plan, but not necessarily the original issue or evidence that produced it.

Polylane says agents regularly repeated work and that the final coding agent produced subpar PRs that often attacked symptoms instead of root causes. Individual stages could even pass their evaluations while the overall result remained weak because the failures occurred in the handoffs between them.

That's a nasty evaluation problem.

A dashboard can tell you every worker is performing correctly while the factory still produces the wrong thing.

One continuous investigation changed the workflow

On September 3, Polylane replaced the multi-agent pipeline with one continuous agentic run.

That agent gathers evidence, investigates competing hypotheses, decides whether the issue needs a code change, edits the code when appropriate, runs its sandbox validation, and opens the pull request.

Polylane's explanation for the improvement is straightforward: the agent making the final decision now retains the investigation that produced it.

There is no coordinator compressing evidence into summaries and no final coding agent receiving only a plan.

Across Polylane's comparison periods, the share of detected issues resulting in a PR rose from 0.6% under the multi-agent pipeline to 4.2% under the single-agent setup. Median time to PR fell from 2.2 hours to 35 minutes, while the p90 fell from nine days to under two hours.

That's meaningful production evidence.

It still isn't a controlled experiment.

Polylane explicitly says it was “actively iterating on every aspect” of the product during the transition. The new system also starts every run on a stronger model, which means model capability changed alongside architecture. The company itself warns that its fall in cost per PR cannot be attributed exclusively to removing sub-agents.

The strongest conclusion, then, is narrower than Polylane's headline.

Its old architecture created enough coordination overhead and context loss that simplification coincided with dramatically better operating metrics.

Whether every multi-agent architecture shares that problem is a different question.

Anthropic has evidence for the opposite result

One of the clearest counterexamples comes from Anthropic.

Its multi-agent Research system uses a lead agent to break broad questions into separate research tasks, then sends sub-agents searching in parallel.

Anthropic reported that a lead Claude Opus 4 agent paired with Sonnet 4 sub-agents outperformed a single Opus 4 agent by 90.2% on one internal research evaluation.

The architecture works because research often contains genuinely independent work.

Ask one agent to identify executives at 50 companies and it searches sequentially. Give subsets of the companies to several agents and much of the job happens at the same time.

Anthropic also describes the price of that performance. Its multi-agent systems use roughly 15 times as many tokens as normal chat interactions, and the company specifically warns that domains requiring heavily shared context or containing many dependencies are poor fits for multi-agent architectures.

Anthropic has also built mechanisms specifically to reduce the information-loss problem Polylane encountered. Its research agents can store persistent artifacts and pass references to those artifacts rather than repeatedly squeezing entire investigations through summaries. Anthropic describes the goal as reducing the “game of telephone” between agents.

That distinction matters.

The alternative to Polylane's single-agent architecture is not necessarily another system where agents pass lossy summaries to one another.

A second agent can bring an independent context window, different tools, separate permissions, another model, adversarial review, or genuinely parallel work.

The architectural question becomes sharper:

What does the additional agent contribute that the first agent does not?

Anthropic's compiler experiment makes the dividing line unusually clear

Anthropic's own experiments with coding agents show both sides of that equation.

In February, researcher Nicholas Carlini described using 16 Opus 4.6 agents working against a shared codebase to build an experimental C compiler. Across nearly 2,000 Claude Code sessions and just under $20,000 in API costs, the agents produced roughly 100,000 lines of code and a compiler capable of building Linux 6.9 across x86, ARM, and RISC-V, though Anthropic disclosed remaining limitations including reliance on GCC for one 16-bit x86 stage and its assembler and linker.

Multiple agents worked well when the test suite offered lots of independent failures.

Each agent could pick a different broken test. Later, different workers tackled separate open-source projects, performance improvements, documentation, duplicated code, and architecture reviews.

Then they tried compiling the Linux kernel.

The parallelism collapsed.

Every agent hit the same blocking bug. They started trying to repair the same problem and overwriting one another's changes.

Sixteen workers stopped helping because the task had stopped splitting.

Carlini redesigned the testing harness so different agents could once again isolate and repair separate subsets of failures. Parallelism became useful again.

That suggests a better rule than “one agent” versus “many agents.”

Ask whether another agent adds independent work, independent evidence, or independent judgment.

If it does, coordination overhead buys you something.

If it doesn't, the extra coordination can simply recreate work and compress context without adding much capability.

Researchers are questioning the AI org chart, too

A January 2026 preprint titled “Rethinking the Value of Multi-Agent Workflow: A Strong Single Agent Baseline” tested a related idea across seven benchmarks spanning coding, math, question answering, domain reasoning, planning, and tool use.

The researchers focused largely on homogeneous multi-agent systems: architectures where several workers use the same underlying model but receive different prompts, tools, or positions in a workflow.

Their results showed that a single model maintaining context across multiple turns could reach the performance of the tested homogeneous workflows while benefiting from efficiency gains such as reusing previously processed context. The team proposed a method called OneFlow for converting such workflows into single-agent execution.

The paper stops short of making that a universal rule.

Its authors explicitly distinguish homogeneous systems from genuinely heterogeneous ones involving different models. Different capabilities, tools, permissions, and perspectives can give additional agents a reason to exist.

So “specialist” needs to mean more than a new system prompt and a job title.

The more important problem is what we're measuring

Polylane's architecture story is interesting.

Its measurement story may be more important.

The company reports how many detected issues become pull requests, how quickly those pull requests appear, and how much model inference costs per PR.

All three improved sharply after the architecture change.

But those metrics end at the moment the AI produces something.

They don't tell us from Polylane's public data how many PRs were accepted without substantial changes, how many were rejected, how much human review each required, how many were later reverted, whether any introduced regressions, or whether the original incident stayed fixed.

Imagine a system that previously produced 10 excellent PRs and now produces 70 mediocre ones.

PR throughput skyrockets.

Cost per PR collapses.

The dashboard looks incredible.

The humans reviewing those 70 PRs may have a different opinion.

This problem gets more important as AI makes producing intermediate work nearly free.

Code. Reports. Tickets. Research. Designs. Emails.

When generation becomes cheap, counting generated artifacts becomes a progressively weaker measure of productivity.

More of the bottleneck shifts toward verification.

That's also the idea behind The Neuron's recent look at Lauren Tan's pstack system for trustworthy coding agents. Its most useful principle is that an agent shouldn't merely say it completed a task. It needs machinery capable of interacting with the real product, checking what happened, recognizing failure, and producing evidence that the result works.

For Polylane, the most revealing metric would therefore sit further downstream than PR creation:

How many safe, reviewed, merged, durable fixes does the system produce—and how much human work does each one require?

That would tell us whether the AI became better at fixing software, rather than simply better at creating proposed fixes.

Build the smallest organization that earns its complexity

This doesn't require abandoning multi-agent systems.

It requires making every extra agent justify itself.

Anthropic's older guidance for building effective agents recommends essentially that: begin with the simplest solution that can handle the job, measure it, and introduce complexity only when the added machinery demonstrably improves outcomes.

A second worker earns its place when it provides something genuinely additive: independent exploration, another model, separate tools, a security boundary, adversarial review, more context capacity, or parallel work that actually proceeds independently.

Polylane's experience shows what happens when those benefits fail to outweigh coordination.

Its old workflow gave different agents narrow responsibilities but repeatedly compressed the evidence flowing between them. The simpler replacement kept investigation and action together, and Polylane reports substantially better operating numbers.

The next step is proving those faster outputs become better fixes.

Because the agent-swarm boom has borrowed heavily from the language of human organizations: managers, specialists, delegators, reviewers, teams.

Sometimes that's exactly the right abstraction.

And sometimes you've just automated the bureaucracy.