Multi-agent orchestration in finance, and when to avoid it

A finance workflow benefits from multiple agents when two subtasks need different tools, different permissions, or context that will not fit in one window, and when the thing passed between them can be written down and checked. Everywhere else, a single agent with a good tool set costs less and stays easier to audit, and it rarely loses a number in transit.

Most multi-agent demos solve a problem the demo invented. A “researcher” hands to a “writer” hands to a “critic,” and the whole thing looks organized. In a real finance system the interesting failures rarely happen inside an agent. They happen at the seam between two of them, where a figure gets silently rounded or a “done” gets reported for work that was never finished. That seam is what you are actually designing when you choose to orchestrate.

What a handoff has to carry

An agent handoff is a data contract, and finance is unforgiving about data contracts. When one agent passes work to another, the receiving side needs enough to be correct on its own. A paragraph of prose summarizing the state will not do that. The receiving agent needs the state itself.

For a reconciliation task that means the receiving agent gets the ledger lines, the source system each came from, the as-of timestamp, and the tolerances already applied. For an exposure calculation it gets the positions with their point-in-time marks, not marks the upstream agent happened to fetch at a different second. If the handoff is prose, you have introduced a lossy compression step between two systems that both needed the exact figures.

So the first test we run on any proposed split is boring: can the handoff be a typed artifact you would be willing to store and replay? If yes, the boundary is probably real. If the only thing crossing the boundary is a summary that the next agent will re-interpret, you have added a place for figures to drift silently without adding any capability. Collapse it.

Where splitting genuinely pays

There are a few boundaries where separate agents earn their cost, and they tend to share a property: the two sides have different authority or different failure modes.

• Different tool permissions. A drafting agent that reads a data warehouse and a posting agent that writes journal entries should not be the same actor. Splitting them lets you scope credentials narrowly and put a human or a rules gate on the write path. This is authorization, expressed as architecture.
• Different context needs. Entity resolution across a messy counterparty list is its own job with its own reference data. Isolating it keeps a hundred thousand tokens of alias tables out of the window of the agent that only needs the resolved IDs.
• Different eval sets. A classifier that flags transactions for review and a summarizer that explains the flag have separate quality bars. You measure the first against a false-positive budget and the second against factual accuracy. Keeping them apart lets each have its own eval set and its own drift monitoring, rather than one blended metric that hides both.
• Genuinely parallel work. Pulling filings for forty portfolio companies at quarter-end is embarrassingly parallel. Fanning it out across worker agents is a throughput decision, not an intelligence one, and it is fine as long as the fan-in step reconciles what came back.

Notice what is not on that list: “the task is complicated.” Complexity alone is an argument for better tools and a longer context, not for more agents. A single planner-executor loop handles a great deal of finance work, because the plan is usually short and you can read it before anything runs.

Where a single loop is safer

The planner-executor pattern is where teams get seduced. A planner writes a multi-step plan, executors carry it out, and it feels like you have built something autonomous. The trouble is that a planner will confidently emit a step no tool can satisfy, and a downstream executor will do its best to satisfy it anyway. Now you have a plausible action taken on an instruction that was never grounded in a real capability.

In a finance setting that shows up as fabricated intermediate values. The planner decides step three is “adjust for intercompany eliminations,” no tool actually performs that adjustment, and the executor produces a number that looks like an adjustment but is a guess. Nothing errors. The audit trail records a completed step. You find it at quarter-end, if you find it.

For that reason we keep a single agent, single loop, when:

• The work is one coherent judgment that should not be chopped into steps that each look defensible in isolation. A credit assessment reasons over the whole picture; splitting it invites each piece to be locally reasonable and jointly wrong.
• Lineage matters more than throughput. One actor with one tool log is far easier to reconstruct than a tree of agents whose interactions you have to stitch back together after the fact.
• The false-positive cost is high and latency is not the constraint. Coordination between agents adds its own failure surface, and for a compliance decision that surface is not worth a few seconds saved.

The honest default is one agent with a well-designed tool set and a strict schema on every tool’s output. Reach for orchestration when you hit a wall that more tools cannot climb: a permission boundary you must enforce, a context you cannot fit, or a parallelism you want to exploit.

Building for the seam

If you do split, design the seam first. Give every handoff a version, a schema, and a validator that rejects malformed or out-of-tolerance artifacts before the next agent touches them. Make the orchestrator’s own decisions logged actions, so “agent A chose to route to agent C” is a record you can replay, not an emergent behavior you reconstruct from timestamps.

Keep the topology flat. Deep chains of agents calling agents compound two problems at once: latency you can measure and error propagation you cannot, because a small distortion at the top gets treated as ground truth all the way down. A shallow graph with strong contracts at each edge beats a clever hierarchy almost every time.

And measure the whole thing end to end, not per agent. An orchestration where every component passes its own eval and the joint output is still wrong is the normal failure, not the exotic one. The number that matters is whether the final artifact reconciles against source, survives replay, and holds its point-in-time correctness. If it does not, no amount of internal agent politeness will save the close.