When One Agent Becomes Eight: Accuracy and Risk in Multi-Agent Finance

A finance lead at a mid-market SaaS company described the moment it clicked. They had built a “team” of agents to produce the monthly board pack: one pulled revenue from the billing system, one pulled costs from the GL, one calculated gross margin, one wrote the commentary, one assembled the deck. It demoed beautifully. Then the controller checked the numbers and found that gross margin in the chart did not match gross margin in the narrative. Same metric, same month, two answers. Neither agent was “wrong” in isolation. They had simply each computed it from a slightly different slice of data, and nobody had reconciled the slices.

That is the quiet failure mode of multi-agent finance. The demo works. The math doesn’t tie out. And because the error sits between agents rather than inside any one of them, no single agent’s log explains it.

Why adding agents adds risk faster than it adds capability

The appeal of multi-agent orchestration is obvious. Decompose a hard workflow into specialists, run some of them in parallel, put a supervisor on top to route and synthesize. Recent benchmarking on financial document processing shows real wins from this when it’s done well, including routing strategies that cut cost by roughly half while holding accuracy, because cheap fields go to cheap models and hard fields go to strong ones.

But the same body of research is blunt about the downside. Production multi-agent LLM systems fail at uncomfortably high rates, and a large share of those failures are not individual reasoning mistakes. They are coordination failures: agents misread their role, duplicate work, lose history, or treat an upstream agent’s guess as established fact. UC Berkeley researchers catalogued this in 2025 as a taxonomy of failure modes, and “compounding errors” sits right in the middle of it.

Here is the mechanism that should worry a CFO specifically. When you chain agents, errors don’t cancel out. They pass downstream intact. A research agent produces a number that’s subtly off, the execution agent treats it as ground truth, and every step after that builds on a wrong foundation. One analysis found that closed-loop architectures with adversarial checking neutralized more than 40% of faults that would otherwise have compounded. Read that the other way: without the checking, those faults propagate all the way to the output you sign.

There’s a subtler version too. A 2025 paper on self-conditioning observed that when a model’s context contains its own earlier mistakes, it becomes measurably more likely to make further ones. An agent that miscalculated revenue once is now reasoning over its own bad number. The error doesn’t just persist. It breeds.

The real problem is not the agents. It is what they read.

Most teams respond to this by adding more orchestration. More supervisors, more critic agents, more retries. That helps with some failure classes. But it misdiagnoses the finance-specific problem, which is almost never that the agents coordinated badly. It’s that each agent built its own connection to source data and its own private version of the truth.

Picture the board-pack team again. The revenue agent hits the billing API and applies its own revenue-recognition logic. The margin agent hits the GL and nets things slightly differently. The commentary agent reads a cached export from last Tuesday. Three agents, three data paths, three definitions of the same figures. No amount of supervisor cleverness fixes this, because the supervisor is coordinating outputs that were never computed from the same base. You can orchestrate perfectly and still produce a report that doesn’t reconcile.

This is where the “eight agents” framing matters. Eight agents with eight connectors is eight chances to define revenue differently, eight points where a refresh can drift, eight calculation paths an auditor has to chase. The complexity isn’t linear. Every new agent that reads or writes its own version of the numbers adds another edge to the graph of things that can silently disagree.

One reconciled model, many agents

The architecture that actually holds up is unglamorous: every agent reads from, and writes to, a single reconciled financial model. Not a shared folder. Not a shared cache. A model that ties out to the ledger, where revenue means one thing, where each figure carries lineage back to source, and where the math runs through a deterministic engine rather than being re-derived by whichever LLM happens to be holding that subtask.

When the numbers layer is shared and reconciled, the orchestration question gets dramatically simpler. The margin agent and the commentary agent cannot disagree about gross margin, because neither of them computes gross margin. They both retrieve it from the same model, and the calculation that produced it ran once, deterministically, against reconciled inputs. Agents go back to doing what they’re genuinely good at: decomposing the request, deciding what to fetch, sequencing the work, drafting the prose, and the part they’re bad at, the arithmetic, leaves the LLM entirely. We make that separation the whole point of the design in why finance agents must call tools, not compute.

This also fixes the audit problem that multi-agent systems otherwise make worse. With private data paths, “who computed this and from what” has no clean answer; the figure was assembled across agents and connectors with no single record. With a shared reconciled model, every number traces to source regardless of which agent surfaced it. That traceability is what an auditor or a board actually needs, and it’s why the same principle runs through audit trails that record decisions, not just actions.

What this means before you scale the swarm

A few honest concessions. Multi-agent orchestration is real and useful. The supervisor-worker pattern is one of the safer ones for regulated workflows because routing, retries, and approvals stay in one controlled layer. Parallelism genuinely shortens wall-clock time. None of that is the issue.

The issue is sequencing. Standing up eight agents on top of eight private data connections doesn’t give you a finance team. It gives you eight independent ways to be confidently wrong, wired together so the errors compound. The order that works is the reverse: reconcile the numbers first, into one model that ties to the ledger and computes deterministically, then point as many agents at it as the workflow needs. The shared layer is what makes the orchestration trustworthy, not the other way around.

If your agents currently each carry their own definition of revenue, the number of agents isn’t your risk. The number of versions of the truth is. Collapse those to one, and orchestration becomes an accuracy multiplier instead of an error multiplier.

See how Rexfin gives every agent one reconciled model to read and compute against: book a demo and bring the report that didn’t tie out.