· ARJUN · WRITING
The Value of a Multi-Agent System Depends on How You Split the Work
One agent can review a pull request from start to finish, or several agents can check different parts in parallel. The second approach is worth considering when the work can be separated and the results can be handed off clearly.
Imagine a large pull request. Before merging it, someone needs to check whether the API remains compatible and whether the tests and documentation reflect the changes. A single agent could do those checks in sequence. Another option is to assign the checks to two agents and combine their findings afterward.
The difference is not the number of role names. A multi-agent system changes who sees which material, who makes each judgment, and how the separate results are combined. A good split keeps each agent’s context focused and allows parallel work. A poor split adds model calls and a trail of messages that is harder to trace.
Check whether one agent is enough
A single agent can use several tools and, when its orchestration supports it, call tools in parallel. Needing concurrency does not, by itself, require more agents. If the steps are fixed, application code can handle the workflow while an agent handles the parts that require interpretation or judgment.
In this article, an agent is a unit that can select tools, examine material, and make a judgment within its assigned check. Calling a model twice in a predetermined sequence and joining the answers is still a fixed workflow. Giving those calls separate role names does not, by itself, create meaningful task boundaries.
Multiple agents become worth considering when one agent has to handle substantially different kinds of work: it has so many tools that tool selection suffers; separate subtasks require large, unrelated bodies of context; or independent checks can run at the same time. LangChain’s multi-agent documentation names context management, parallelization, and capability boundaries as motivations, while noting that a complex task does not automatically need multiple agents.
This is an architectural opportunity, not a quality guarantee. Calling one prompt a “code reviewer” and another a “documentation reviewer” will not automatically make either review more accurate. The input material, tools, and acceptance criteria still matter.
Define the handoffs in a PR review
Start by defining the comparison. The PR’s base and head commit SHAs pin down the code diff. To assess external compatibility, you also need to say whether the baseline represents a released version and provide the API contract, compatibility rules, and known callers. Otherwise, Agent A may read the entire diff without knowing whether a change breaks an existing contract. Agent B needs the acceptance criteria, relevant documentation, and regression tests. Its job is to check whether the relevant tests and documentation reflect the change, not to chase an abstract coverage percentage.
The coordinator gives A and B the same base and head commits along with the material each needs. They can run independently: A reviews public interfaces and their callers; B reviews the related regression tests and documentation. They do not need to share their full conversation histories. The coordinator can be application code rather than another LLM agent.
The handoff can be short, but “looks fine” is not enough. For example, one of A’s result records could use this format:
Check: API compatibility
Version: <base SHA> → <head SHA>
Status: checked (issue found) / checked (no issue found) / incomplete
Finding: <specific change and potentially affected callers>
Evidence: <API contract, file location, or test result>
Open question: <condition the available material cannot establish>B can return the same fields. This keeps “checked, with no issue found” separate from “not finished.” The coordinator can deduplicate findings and attach each side’s evidence to conflicting conclusions. Questions it cannot verify remain for a person to decide; it should not silently pick a winner.
Not every step needs to become an agent. Running tests, reading a diff, and locating files are deterministic operations better handled by tools. Agents are useful for interpreting the material and assessing risk, not for replacing a test command.
Account for both parallelism and handoff costs
Context isolation lets each agent work with only the material relevant to its check, rather than putting both checks’ intermediate work into one model context. Parallel work may also reduce waiting time. If A and B really can run independently, the critical path is roughly the slower check plus dispatch and aggregation time, rather than the sum of both checks. LangChain’s subagents documentation describes this isolation and the ability to invoke subagents in parallel.
In a different task, B might have to wait for A’s conclusion before starting. They cannot run in parallel in that case. If the coordinator repeatedly asks both agents to redo their work, total latency and token usage may exceed the single-agent version. There is no general rule that adding agents makes a workflow a fixed number of times faster.
Handoff costs are easy to underestimate. If A finds that an API change may affect older clients, the coordinator needs to know which interface is involved, which versions were compared, and where the evidence is. It does not need A’s entire reasoning transcript. Too little information invites mistakes during aggregation; too much erases the benefit of context isolation.
Shared state also needs explicit update rules. In LangGraph, nodes can update State, and a reducer determines how updates to a field are combined. Without a reducer, a new value in a later step replaces the old one. If parallel nodes write to the same field without a reducer that can combine their updates, LangGraph raises an error. State carries data through the graph; it does not guarantee that business-level information stays consistent. See the LangGraph state documentation and concurrent-update error guide.
Retries and debugging add another layer of work. If one check times out, do you rerun that check or the whole workflow? Can you combine results produced from different commits? At minimum, you need to trace the input version each agent saw, the tools it called, and the evidence it returned. Debugging does not necessarily become “exponentially” harder, but the search now spans several execution paths and their handoffs.
To decide whether this split is worthwhile, compare it with a single-agent review on the same set of PRs and acceptance criteria. Record the number of findings a person confirms, the false alarms, the time to a usable result, and the total model-call cost. One fast run is not evidence that the architecture is generally faster.
Choose orchestration based on task dependencies
In this PR review, the assignments and dependencies are known in advance: ordinary code dispatches A and B in parallel, collects their results, and leaves the merge decision to a person. A fixed pipeline or directed graph is enough; an LLM coordinator adds little here. A supervisor or handoff becomes useful when the next handler must be chosen from intermediate results. Choose a framework to implement that task relationship, not the other way around.
Return to the work itself
This PR review can run as two checks only if A and B can work independently, use the same comparison versions, and return results the coordinator can combine. If the checks depend heavily on each other, or their inputs and outputs are still unclear, improve the single agent’s tools and workflow before adding roles.