Single-Agent vs. Multi-Agent Reasoning: Accuracy, Latency, and Cost

AI agents combine reasoning with tools to inspect evidence, perform calculations, and make decisions. The promise of organizing them into teams is better decision-making. Specialists can examine different constraints, competing teams can develop complete solutions in parallel using different strategies, and a coordinator can select the strongest candidate or synthesize their findings.

Consider a business choosing which initiatives to fund. A financial analysis may favor one portfolio, an engineering review may reveal a dependency, and an operational check may expose overlapping benefits. Each perspective can change the decision. Bringing them together is where collaboration could earn its value, provided the final plan improves enough to justify the work involved.

For builders, that creates a practical choice. When should one capable agent handle the whole problem? When would competing teams, specialist collaboration, or synthesis produce a better outcome? Answering those questions means evaluating decision quality alongside the time and computational cost required to deliver it.

In this post, I compare a single agent with four team configurations, keeping the model and nine structured decision problems fixed. All five configurations achieved high accuracy. The single-agent workflow had the lowest average completion time and resource use. This experiment did not establish a general or repeatable accuracy advantage from additional agents. For comparable tasks, the practical takeaway is:

Optimize for better decisions, not more tokens. Start with one capable agent, and add coordination when measured gains justify the extra time and cost.

Five ways to organize AI agents

My recent posts explored model and reasoning selection, evaluating multi-agent workflows, and subagent delegation. Here, the model stays fixed while the organization changes.

Every configuration uses GPT-6.1 Sol with medium reasoning effort. A team means the unit responsible for producing one complete candidate answer. It can contain one agent or several agents working together.

Figure 1. Team count and collaboration within a team are separate design choices. Each of the five teams in V1, V2, and V4 attempts the whole problem. The dynamic-team sketches are conceptual; the model chooses actual subagent counts and roles.

V1, V2, and V4 follow a hackathon concept: five competing teams tackle the same challenge simultaneously, each pursuing a different strategy. The goal is to compare their complete solutions and select the strongest candidate. Each team works in a separate context and does not exchange findings with other teams during candidate generation. Their errors can still be correlated because they share the same model and evidence. Each strategy guides a complete solution:

V1 tests competing teams with one agent per team. V2 adds specialist collaboration within each competing team.

Predefined specialists

For each problem, V2 uses four predefined specialist roles. All five competing teams use the same roles for that problem, each guided by a different strategy.

The runner assigns the specialist roles and runs them concurrently. Their notes then feed the builder, followed by critique and revision.

roles = self.protocol["organizations"]["V2"]["parallel_specialists"]
notes = await asyncio.gather(*[
    self.stage(
        f"V2-{name}-{role}",
        philosophy=strategy,
        profile=role,
        note=True,
        additions={"role": role},  # Role instructions omitted here.
    )
    for role in roles
])

Dynamically organized teams

The runner launches five competing coordinators under different strategies:

teams = await asyncio.gather(
    *(self.dynamic_team(name, strategy)
      for name, strategy in self.protocol["five_strategies"].items())
)

Inside each dynamic_team, the coordinator starts with native delegation enabled:

result = await self.stage(
    f"V3-{name}",
    philosophy=strategy,
    native=True,
    profile="generalist",
    additions={
        "instruction": self.protocol["prompts"]["v3_initial_request"]
    },
)

In V3 and V4, each coordinator chooses its team’s specialist roles, assignments, and size for that run. The source’s internal V3 identifier corresponds to V4 in this article.

This matters because “multi-agent” can describe very different workflows. Comparing five competing single-agent teams with one coordinated team asks a different question from comparing one agent with twenty predefined specialists.

API, transport, and tool execution

All five configurations use the Responses API over WebSocket transport. V3 and V4 additionally enable its Multi-agent beta capability. OpenAI handles spawning, messaging, and coordination; the root agent integrates the results and returns the final answer. The model chooses subagent assignments and team size.

Earlier experiments used the Agents API with hosted sandboxes. I switched this study to Responses because its native subagents could call the same local Python tools as their coordinators. Those tools read evidence, check constraints, validate backup chains, and simulate schedules. The Agents API implementation used earlier did not support that same subagent function-tool path. Both APIs support delegation.

I chose WebSockets so that the Python experiment runner could return each function’s result as it became available while other agents continued working. All five configurations used the same transport. Native subagent creation is provided by Multi-agent, which also supports HTTP.

Separate exploration from answer processing

In these workflows, the five completed candidates from V1, V2, and V4 feed three distinct operations:

• Selection identifies one existing candidate to deliver.

• Synthesis constructs an answer using all five candidates.

• Refinement checks and revises only the selected candidate.

The selected candidate is preserved unchanged; synthesis and refinement produce separate answers. Refinement does not revise the synthesized answer.

Figure 2. Selection, synthesis, and refinement reuse the same five candidates, so their results are not independent experiments. Complete-workflow totals include candidate generation and all three processing operations.

How synthesis is defined

Synthesis receives the complete candidate pool, including available work notes, the selector’s choice, and the rationale. It must resolve conflicting findings and assess whether combining them yields a better, more coherent decision. The prompts below expand the stage instructions to make their responsibilities explicit.

self.stage(
    f"{mode}-synthesis",
    additions={
        "role": "synthesizer",
        "candidates": anonymous,
        "selection": choice,
        "instruction": """
Produce one complete decision using the original problem, the five candidate decisions and their available work notes, and the selector's choice and rationale.

Your goal is the strongest supported answer under the original requirements, objective, and tie-breakers. Synthesis is useful only when combining findings
improves the result; retaining an existing candidate is acceptable.

1. Assess the candidates. Identify useful findings, supported calculations, missing requirements, and potential errors. Distinguish claims from demonstrated evidence. Agreement among candidates does not establish correctness. Examine the selector's recommendation against the evidence.

...

Return only the complete decision in the original required JSON schema, including the required evidence references. Do not add commentary, evaluation scores, or fields outside the schema. Work without creating subagents.
""",
    },
)

How refinement differs from synthesis

Selection preserves an existing answer:

winner = anonymous[choice["winner_index"]]
outcomes["selected"] = winner["decision"]

The refinement branch receives only that winner:

self.stage(
    f"{mode}-refinement",
    additions={
        "role": "winner-only refiner",
        "candidate": winner,
        "instruction": """
Review and improve the selected candidate using its supplied work notes, the original problem, public evidence, and available tools.

Your goal is to make a more accurate, better-supported decision under the original requirements, objective, and tie-breakers. Preserve sound work. Returning the selected decision unchanged is acceptable when further checking supports it.

1. Audit the proposed decision. Check its interpretation of the problem, evidence references, assumptions, calculations, dependencies, and resource constraints. Look for omitted requirements, unsupported claims, double counting, and violations that appear only when the complete plan is considered.

...

Return only the complete final decision in the original required JSON schema, including the required evidence references. Return the entire decision even if only one part changed. Do not add commentary, evaluation scores, or fields outside the schema. Work without creating subagents.
""",
    },
)

Refinement checks and potentially revises the selected answer, while synthesis draws from the full pool. The runner executes synthesis and refinement concurrently as separate branches.

There are two quality questions here. Does exploring several candidates improve on the single-agent answer? Does combining their findings improve on the strongest candidate already available?

The second question needs a careful comparison. Beating a poorly selected candidate would demonstrate a useful recovery but would not establish that synthesis created an answer better than every member of the pool. I compare synthesis with the strongest candidate, identified by deterministic grading after answer generation, with no grading feedback provided to the agents.

Verifiable decision problems

Each of the five configurations tackled nine fixed decision problems five times, producing 225 completed workflows. The tasks require more than producing a plausible explanation. They ask for decisions that satisfy interacting rules, calculations, and evidence requirements.

These are constructed scenarios with fictional source documents and known scoring rules. The underlying benchmark cases are pinned to a specific revision.

The tools let agents inspect evidence, calculate quantities, and check proposals. These are developer-defined functions: the model requests a call, and the application validates the arguments and permissions, executes the function, and returns the result. The Responses API handles hosted collaboration actions such as spawning and messaging subagents.

V0 receives the full tool catalog. V2 specialists receive role-appropriate subsets, while the integration and answer-processing stages receive the full catalog. V1, all dynamic coordinators, and subagents also have the full catalog. Every workflow has access to the complete task evidence.

Each attempt starts fresh. The runner requests Structured Outputs using a JSON schema that specifies required fields and types. Schema compliance is only the first check; it does not establish that the values or decision are correct. Deterministic graders, implemented as code-based checks, assess the requested decision, authoritative evidence, calculations, feasibility, and optimality where required. An answer can be perfectly formatted and still choose the wrong plan.

High accuracy across configurations

The single agent returned 43 correct answers in 45 attempts; the other configurations returned 45 correct answers in 45 attempts. The single agent solved every repetition of eight problems. Its two misses were both on transformation planning. All answers from the other four configurations were correct.

Figure 3. Each cell represents five completed workflows for a single fixed problem. V0 scores 43/45 overall; V1 through V4 score 45/45. For configurations with competing teams, the original winners and the selected, synthesized, and refined answers are equally correct.

The observed gap is 4.4 percentage points, concentrated in one task. Nine additional single-agent runs, one per problem, were recorded separately. All nine were correct, including the additional transformation-planning attempt.

The observed difference is limited to a single task within a small, deliberately selected set. It does not establish a general or repeatable accuracy advantage or formal equivalence between configurations.

Feasible isn’t always optimal

The transformation task asks the agent to select initiatives within an $80,000 capital budget and 7 units of engineering capacity. Some initiatives depend on others; two are incompatible. Benefits overlap within beneficiary groups, so adding every listed benefit would overstate value. The objective is to maximize net present value, calculated here as discounted future benefits less the upfront investment, using a 10% discount rate.

Two portfolios illustrate why the evaluation must check optimality:

Figure 4. Both portfolios satisfy the resource limits. The $22,933.88 objective gap accounts for the two single-agent failures because the task requires the highest-value feasible portfolio. The difference is in value within the fictional task.

V0 chose the lower-value portfolio twice and the optimum three times in the main comparison. The multi-agent answers reached the optimum throughout.

This example gives the aggregate accuracy number a concrete meaning. Checking arithmetic and budget compliance would have accepted the lower-value answer. Requiring the best feasible portfolio exposes the decision error. The objective gap is not realized business value or a deployment return-on-investment estimate.

Workflow time, tokens, and cost

Timing tells a clearer story than the small accuracy gap. The single-agent workflow had the lowest mean completion time on every problem. Across the nine tasks, it averaged 7.9 seconds; the other configurations averaged between 30.1 and 63.6 seconds.

Figure 5. Means cover 45 completed workflows per configuration, with the nine tasks weighted equally. V1, V2, and V4 include all five candidate teams and selection, synthesis, and refinement. V0 and V3 return one direct answer.

As described earlier, V1, V2, and V4 each produce selected, synthesized, and refined answers. V1 provides an example of the elapsed time and estimated cost as each result becomes available:

The five-team workflows perform several kinds of work, so their totals should not be read as the minimum cost of every possible multi-agent design. A deployment that stops after selection would spend less than one that also generates synthesis and refinement.

V3 helps examine that distinction. It uses a single dynamic team and returns a single integrated answer, with no external selection, synthesis, or refinement. Its mean time was still 34.0 seconds, compared with V0’s 7.9 seconds. All 45 V3 coordinators delegated, creating 92 observed subagents.

Figure 6. Resources cover complete workflows. Costs were estimated by applying published model pricing to recorded token usage. The ranges reflect the pricing assumptions used in the cost estimates. Local tool processing and development labor are excluded.

Parallel work was enabled. Each dynamic coordinator’s request allowed up to 10 active subagents within its delegation tree, excluding the coordinator itself, and V4 launched its 5 candidate teams concurrently. The setting limits simultaneous activity rather than requiring a particular team size. These timings therefore do not come from a design that required every agent to work sequentially.

Parallel execution can reduce elapsed time when enough work can proceed independently. Assigning work, exchanging findings, and integrating them also take time. Coordination overhead and limited independent work are plausible explanations here, but the experiment does not isolate their causal contributions. Instructions, work allocation, and execution across separate blocks also differ.

Figure 7. Each row is one fixed problem, with mean complete-workflow seconds across five runs. The single agent has the lowest mean in every row. These observations do not estimate production tail latency.

Cheap winners, costly workflows

V1’s winning agent looks attractive in isolation. It used an average of 2,506 reported tokens, compared with 2,687 for V0, and had a lower estimated inference cost. Its own solve time averaged 8.6 seconds, versus 7.5 seconds for V0.

But the system did not know which candidate to choose before generating the pool. It paid for five attempts, then paid for processing. The full V1 workflow averaged 24,800 tokens and an estimated $0.0432–$0.0475.

Figure 8. The winning-team ranges include only the team that created the chosen candidate. Complete-workflow ranges include all candidates and processing stages. V0 and V3 each have one team, so the two measurements have the same inference cost.

The winning-team measurement shows how the chosen candidate was produced. The complete-workflow measurement includes the resources spent generating alternatives and processing their answers.

This is a question of token economics: connecting token consumption to the value of the result. Valuemaxxing asks whether better outcomes justify the resources needed to produce them; tokenmaxxing treats greater consumption as progress.

Extra reasoning, teams, and checks can be worthwhile when they improve the delivered result enough to justify their cost.

The accounting boundary should follow the product. If users receive only a selected answer, measure that path. If the application generates alternatives and runs additional checks, retain those resources during system evaluation. Quoting only the winning agent’s cost understates the cost of the five-team design.

Synthesis tied the best candidate

Across V1, V2, and V4, there were 135 candidate pools containing 675 candidates. Of those candidates, 671 were fully correct. Every pool contained at least one correct answer, and the selection delivered a correct candidate from every pool.

Synthesis tied the highest task-success score in all 135 pools. It improved the primary score in zero pools and reduced it in zero pools. This is an accuracy ceiling. Once one candidate satisfies all task requirements, synthesis cannot earn a higher binary score. It might improve an explanation, but explanation quality was not measured here. These tasks cannot tell us how synthesis behaves when every candidate is imperfect.

V1 also shows why competition between teams and collaboration within a team should be evaluated separately. Its five competing single-agent teams produced 221 correct candidates out of 225; each pool retained a correct answer, and selection found one. That is an observed successful workflow. It does not isolate the contributions of strategy diversity, repeated sampling, or specialist collaboration at equal computational cost.

What to test next

For a comparable structured decision task, I would begin with a single capable agent, give it tools to retrieve evidence and evaluate proposals, and establish a task-specific evaluation set that catches consequential mistakes.

Then inspect failures and add the mechanism most likely to address them.

These are mechanisms to evaluate in follow-up work; their benefits were not measured in this experiment. Different authority or information needs may justify multiple agents, but those boundaries require enforced tool permissions and access controls. A prompted role alone does not create them. Test both access controls and successful authorized completion.

To test whether agent organization improves accuracy, match the computation budget and control other differences. When choosing a deployment system, evaluate its delivered quality, latency, and cost against the application’s requirements.

Scope and limitations

The experiment covers nine deliberately selected, fixed scenarios, five repetitions per configuration, and one model at one reasoning setting. Repetitions reveal variability on those inputs; they do not create additional problem families. Configurations ran in separate execution blocks and used unequal amounts of computation. Three interrupted attempts required fresh replacements; the completed-workflow comparison does not count those interruptions as successful responses or zero-cost work.

The graders assess structured decisions with checkable constraints, leaving open-ended research and writing outside the scope of these results.

For these tasks, a single tool-using agent was an efficient starting point, and additional organization increased resource usage. Define what a correct answer must satisfy, measure the full path that delivers it, and add coordination where the evidence warrants it. Judge the extra token spend by the improvement it delivers.

This blog represents my viewpoints, not those of my past or current employers. All product names, images, logos, and brands are the property of their respective owners.