DEV Community

Cover image for We Split One Research Loop Across Three Agents. The Handoffs Became the Work.
yidao
yidao

Posted on

We Split One Research Loop Across Three Agents. The Handoffs Became the Work.

I recently tried to turn a difficult research workflow into a small AI team.

The task involved improving an SVG reconstruction system. A researcher would inspect failures and propose a cause. An engineer would change the implementation. An evaluator would examine the result and decide whether another round was needed.

On paper, the roles looked sensible:

Researcher -> Engineer -> Evaluator
Enter fullscreen mode Exit fullscreen mode

In practice, the team became very good at producing handoffs.

Six execution and handoff files grew to 12,757 lines. Over two days, five core workflow files received 125 commits; 116 of those commits repaired orchestration, bindings, evaluation state, or other workflow mechanics rather than advancing the reconstruction method itself. One version of the workflow called the full Researcher 47 times and spent 12,813 seconds doing so. We could identify only one call that produced a useful new algorithmic conclusion.

Those numbers come from one internal experiment, not a general benchmark. But they made the failure mode hard to ignore: the system was spending more effort preserving the appearance of a team than preserving the reasoning needed to solve the problem.

The task was one loop, not three jobs

The mistake was easiest to see after we stopped looking at the agent roles and looked at the information flow.

The real loop was:

observe an output
-> form a causal hypothesis
-> change the algorithm
-> inspect the new output
-> revise the hypothesis
Enter fullscreen mode Exit fullscreen mode

Each step depends heavily on the previous one. A small visual detail can change the explanation. A code change can reveal that the original diagnosis was wrong. The next useful action often depends on something that is obvious while looking at the output but awkward to encode in a handoff document.

We had divided the loop according to familiar human job titles. We had not divided it according to independent information boundaries.

That distinction mattered. The Researcher compressed an observation into a report. The Engineer had to reconstruct the observation from that report before making a change. The Evaluator then reconstructed both the hypothesis and the intent of the change from another bundle of files. Every transition discarded context and introduced another opportunity for the agents to interpret the same state differently.

The reports kept getting longer because we tried to solve information loss by adding more information. That only made the contracts more expensive to produce and validate.

We used language models for compiler work

A second problem was more mundane.

Agents were repeatedly asked to maintain case identifiers, file paths, manifests, hashes, schema fields, evaluation bindings, and status records. These are exact transformations with exact failure conditions. They belong in ordinary code.

Instead, the system sometimes called an expensive reasoning agent to discover that a path was stale or a required field was missing. The agent would repair the record, explain the repair, and pass the corrected record to the next agent. The workflow looked active, but no research had happened.

Once we separated the calls by purpose, many of the so-called research iterations turned out to be handoff repair. A useful rule emerged:

If a machine can verify the answer exactly, do not make an agent negotiate it through prose.

We moved IDs, paths, hashes, schemas, manifests, and basic evaluation contracts into deterministic checks. Agent time was reserved for interpreting evidence and choosing what to try next.

More agents were maintaining different versions of reality

The third problem was state.

Research work changes its own premises. After each experiment, the best explanation of the defect may change. In our design, several agents were operating on compressed snapshots of that moving state. None of them had quite the same picture, and each handoff could lag behind the actual implementation.

This resembles what Cognition describes in its discussion of multi-agent coding: parallel writers make implicit choices that can conflict, while context does not naturally move between agents. Their useful pattern is closer to one writer receiving intelligence from other agents, followed by an independent review.

The comparison helped us see that our problem was not insufficient communication. It was shared decision authority over one changing implementation.

The replacement was deliberately less theatrical

We replaced the role-based team with one continuous owner of the research loop:

Research Lead
├─ inspect the real output
├─ form and revise the causal model
├─ implement one candidate
└─ optionally open two isolated hypothesis lanes
             |
             v
deterministic checks + independent evaluator
             |
             v
human perceptual review
Enter fullscreen mode Exit fullscreen mode

The Research Lead is the only decision owner and the only writer for the active implementation. It keeps observation, hypothesis, implementation, and immediate inspection in the same working context.

This is not an argument for one enormous prompt or an agent that runs forever. The context has a lifecycle. It stays continuous while investigating one defect or one causal question. Once that question is resolved, rejected, or blocked, we archive the evidence and begin the next investigation with a cleaner context.

We still use additional agents, but their authority is narrower.

A read-only agent can search documentation or inspect a separate part of the repository. If two causal explanations can be tested independently, we can open two isolated lanes and compare their evidence. An evaluator receives a frozen target, the candidate output, the diff, and a rubric, but not the Lead's reasoning history. It can reject a candidate or report uncertainty; it cannot silently rewrite the implementation.

The final visual judgment remains human. A deterministic evaluator can detect empty output, structural damage, regressions, or missed constraints. It cannot reliably declare that a reconstruction simply looks right.

Multi-agent systems work when the work is actually parallel

This experiment did not convince me that multi-agent systems are useless. It made the boundary clearer.

Anthropic reports that its multi-agent Research system outperformed a single agent by 90.2% on an internal research evaluation. The example is breadth-first search: multiple subagents can investigate independent directions at the same time. Anthropic also notes that the architecture consumes substantially more tokens, so the extra coordination needs to buy something real. That is a good fit for parallel discovery, not necessarily for a tightly coupled implementation loop. The full account is worth reading in How we built our multi-agent research system.

A controlled study across 180 agent configurations found a similar task dependency. Centralized coordination improved performance on parallelizable tasks, while every tested multi-agent variant degraded performance on sequential reasoning tasks. The paper, Towards a Science of Scaling Agent Systems, is useful because it treats topology as a property to match to the task rather than a maturity ladder where more agents must be better.

OpenAI's practical guide makes a simpler recommendation: maximize a single agent's capabilities first, then split when complex logic or tool selection actually requires it.

That is now our default. Parallelize across independent repositories, pages, migrations, searches, audits, or falsifiable hypotheses. Keep writes single-threaded when several steps depend on the same evolving mental model.

Measure conclusions, not activity

The original workflow generated plenty of visible motion: calls, reports, commits, validations, and candidate outputs. None of those was a good measure of research progress.

For the next comparison, we care about a smaller set of outcomes:

  • time to the first human-validated improvement
  • cost per useful causal conclusion
  • percentage of agent calls spent repairing handoffs
  • workflow failure rate
  • quality improvement under an equal token and time budget

Throughput still matters when tasks are independent. In a tightly coupled research loop, it can be actively misleading. Ten candidates produced from the same broken causal model are not ten times the progress.

The main lesson was not that we needed a better manager agent, a stricter schema, or another reviewer. We had placed parallelism at the level of roles, where the information dependencies were strongest.

The better design was to keep one owner for the changing explanation and move parallelism outward, toward work that could genuinely be isolated.


*AI assistance disclosure: AI tools assisted with drafting and editing this article. The experiment data, architecture decisions, and final review are the author's.

Top comments (0)