The short version: The first thing most finance teams do with agents is give one agent a very long prompt. It works until the answer needs to be right. Running several agents — a retriever, an analyst, a checker, a writer, and a supervisor — isn't sophistication for its own sake; it's the only structure that puts an independent set of eyes on work before it reaches a deliverable, which is exactly why your own department is organized that way.
Somewhere in the second month of using AI on NetSuite data, a pattern shows up. The prompt that started as three sentences is now two pages. It has a section on which subsidiaries to include, a section on how to handle the intercompany eliminations, a paragraph about the custom field the previous controller added, and a stern instruction near the bottom to always double-check the numbers.
It does not always double-check the numbers.
That two-page prompt is a job description for a role nobody would ever staff with one person: pull the data, interpret it, challenge the interpretation, write it up for the board, and decide whether the CFO needs to hear about it tonight. Finance departments split that work across people for reasons that have nothing to do with typing speed. The same reasons apply to agents.
This is a practitioner's look at what running more than one actually involves: the roles worth separating, what a handoff has to carry to be worth anything, the specific failure classes a second agent catches, how oversight and escalation work when the work is distributed, what it costs, and how to start without building an org chart for robots.
Why one agent hits a ceiling
Three separate limits, and they compound.
Conflicting objectives collapse into one. A long prompt inevitably asks for things in tension — be exhaustive and be concise, flag anything unusual and don't cry wolf, be conservative and give a clear recommendation. A person negotiates that tension out loud and tells you which way they went. A single agent resolves it silently, differently each run, and you find out when two months' commentary contradict each other.
Self-review is structurally weak. An agent that misread a join and double-counted transaction lines will review its own output using the same misreading. Self-checking reliably catches surface problems — a missing period label, a total that doesn't foot — and reliably misses the reasoning error that produced the number in the first place. This isn't a model-quality issue that gets solved by a better model; it's the same reason auditors aren't allowed to audit their own work.
Context is a budget, and raw ERP data spends it fast. Point one agent at a general-ledger extract and a materials-heavy prompt and the instructions that matter compete for room with thousands of rows. Real NetSuite data doesn't fit a context window — that's the constraint underneath most hand-rolled setups, and it's the same wall a DIY MCP server hits at close. Splitting the work means the analyst never sees the rows the retriever already summarized, and the writer never sees the SuiteQL at all.
The market has converged on the same answer. Several FP&A platforms now ship named rosters rather than a single assistant — Pigment with a Modeler, an Analyst, and a Planner; Datarails splitting its FP&A layer into reporting, planning, and strategy agents; BlackLine adding a supervising "team lead" agent above its Verity suite. Different products, same structural bet: narrow roles, explicit handoffs, one agent whose job is oversight.
The five roles worth separating
You don't need five agents to start. You need to know which five jobs are actually different, so that when you split, you split along a seam instead of through the middle of one.
| Role | Gets | Produces | Must not |
|---|---|---|---|
| Retriever | A precise question and NetSuite access | Rows, with the exact query and the filters used | Interpret, summarize away detail, or decide what's material |
| Analyst | The retriever's packet | A read: what happened, why, with the evidence attached | Re-query to find better-looking numbers |
| Checker | The question and the analyst's packet — never the analyst's reasoning as authority | A challenge: what's wrong, what's unsupported, what's untested | Agree by default, or rewrite the analysis itself |
| Writer | The agreed result | The deliverable in house voice — memo, commentary, summary | Introduce a number that isn't in the packet |
| Supervisor | Everything, plus the escalation rules | Routing, sequencing, and the decision to involve a human | Resolve a disagreement between analyst and checker on its own |
Two of those rows carry most of the value. The checker is the reason to build a team at all — it's the independent review that a solo agent structurally cannot perform on itself. The supervisor is what keeps a team from becoming a group chat: something has to decide the order of work and when to stop, and if that's nowhere, it's implicitly in whichever agent talks last.
The retriever/analyst split does real work too, and it's the one people skip. Keeping the agent that writes SuiteQL separate from the agent that interprets results means the interpretation can't quietly change the query to fit the story. That's a control, not an optimization.
The handoff is the product
Most multi-agent setups that disappoint fail here, not in the roles. Agents pass each other prose, the downstream agent re-derives the upstream reasoning from a summary, and the error survives the trip intact with a fresh coat of confidence on it.
A handoff worth the name is a workpaper. It carries:
- The question as understood — the upstream agent's restatement, which is where scope drift becomes visible before it becomes expensive.
- The exact tool call — the SuiteQL that ran, verbatim. Not "queried the GL."
- The result — rows, or a faithful summary that includes counts. A summary without a row count hides an empty result.
- Every assumption — accounting period and whether it's closed, subsidiary set, currency and rate basis, what was included and excluded and on what rule.
- A confidence level, with a reason. "High — matches the prior three periods' pattern" is usable. A bare "high" is decoration.
- The unresolved list — what the agent couldn't determine and what it would need to. This is the field teams cut first and miss most.
Structured handoffs also give you the audit trail for free. If every hop is a record of question, query, result, assumptions, and decision, then reconstructing why the team said what it said three months later is a lookup rather than an archaeology project — which is the difference between a workflow a controller can sign off on and one they can't.
What a second agent actually catches
Abstract arguments about redundancy are unconvincing. Here are four failure classes that a checker with a different job catches routinely, all of them specific to NetSuite finance work, none of them things a solo agent tends to catch in itself.
The plausible join. A query joins transaction to transactionline and doesn't handle the main line, so every transaction's total gets counted once per line. The syntax is valid, the query returns, the number is roughly the right order of magnitude and wrong by a factor that tracks average line count. A checker told to independently verify the total against a second path — a trial balance figure, a period summary — catches it. An analyst reviewing its own work sees a total it already believes.
The open period. The analysis runs against a period that's still open, or spans the boundary into one that is. Numbers move under it, and next week's rerun disagrees with this week's commentary for reasons nobody can reconstruct. A checker whose assumption list includes "period closed: yes/no" catches this before it becomes a credibility problem.
The subsidiary gap. Consolidated figures that either include intercompany transactions that should have eliminated, or exclude a subsidiary that joined the structure last quarter and doesn't appear in a hardcoded list. This one is invisible in the output — the total simply looks like a total. It's caught only by an agent explicitly asked to enumerate which entities are in scope and compare that against the current subsidiary list. Consolidation is where this bites hardest; the mechanics are in multi-entity consolidation.
The silent zero. A filter references a custom field that was renamed, so the query returns nothing, and the analyst faithfully reports that there were no exceptions this month. Zero exceptions is the most dangerous result an operations workflow can produce, because it looks like good news. A checker rule as crude as "if the result set is empty, verify the filter matches at least one record on any period" catches nearly all of these.
Note what these have in common: each is a correct-looking answer. That's the category a second pass exists for. Formatting errors and arithmetic slips get caught anyway. Plausible wrongness is what costs a finance team its trust in the whole system, and it takes an agent with a different assignment — not a better prompt on the same one — to find it.
Oversight, and when a human gets involved
The hard question about agent teams isn't how they collaborate. It's when they stop and get a person. Three triggers, all mechanical, none requiring anyone to eyeball a queue:
- Disagreement. The checker and the analyst reach different conclusions and don't converge in one round. Both readings go to a human, with evidence. Never let the supervisor break a substantive tie — a tie is signal, and a tiebreaker agent just launders the uncertainty out of the record.
- Confidence below threshold. The team states a confidence and the threshold is set in advance. Below it, the output routes to a person instead of into the deliverable. Set the threshold per workflow: a flux narrative can run looser than a rev-rec cutoff exception.
- Materiality, regardless of confidence. Above a stated line, a human reviews even when the team is certain. The variance playbooks use a workable default — anything over 25 percent or over $100,000 is critical — and that's a reasonable place to start before you tune it to your own thresholds.
Two rules make the triggers stick. No silent retries: an agent that fails and reruns leaves both attempts in the log, because a workflow that quietly retries until it gets a clean answer is selecting for clean answers, not correct ones. And one named human owner per workflow — the failure mode of distributed work, in software and in finance, is that responsibility distributes with it until nobody has any. A team of agents with no owner is a dashboard, and dashboards get ignored.
Where those triggers sit on the broader autonomy question — read, propose, act with approval, act unattended — is the same ladder that governs any single agent, covered in agentic ERP operations. Teams don't change the ladder. They change how much arrives at each rung already investigated.
What it costs
An honest section, because the tradeoff is real and most write-ups skip it.
A five-agent team on one question costs several times a single agent's tokens and takes noticeably longer — each hop re-reads a packet, the checker duplicates work on purpose, and the supervisor adds a round trip. For an ad hoc question in a chat window, that's a bad trade: you're the checker, you're right there, and you want the answer in seconds.
Teams earn their cost on work that is recurring, reused, or consequential. A monthly board commentary that ten people read. A close-status summary the controller acts on. An exception queue that runs every morning whether anyone is watching. Anything that lands in a deliverable someone signs. The rule of thumb: if the output gets forwarded, staff it as a team; if it gets read once and closed, one agent is fine.
How teams fail
Four failure modes, all of which look like success from the outside for a while.
Consensus theater. The checker agrees with everything. This happens when the checker is shown the analyst's reasoning as authority, or when its prompt asks it to "review" rather than to find what's wrong. Give it the question and the packet, tell it its job is to break the answer, and measure its challenge rate. A checker that has never disagreed isn't a checker.
Over-decomposition. Eleven agents where three would do. Every hop is a place for context to be lost and latency to be added; splitting a role that has no seam in it just adds handoffs. Split when two jobs genuinely conflict — producing versus challenging, querying versus interpreting — not because the diagram looks better.
Ownership diffusion. Covered above, and worth repeating because it's the one that kills programs rather than answers.
Garbage upstream. A team amplifies whatever data problem it's built on — five agents confidently reasoning over a mis-mapped account is worse than one, because the output looks more thorough. Most early disagreements in a shadow run trace to undocumented conventions and drifted fields, not to model failure. That's data foundation work, and it comes first.
Where to start: two agents, one deliverable, one period
- Pick one recurring deliverable someone already produces by hand. The AR aging commentary, the monthly flux narrative, the close-status summary. Recurring matters — you need repetitions to learn anything.
- Staff two roles, not five. An analyst and a checker. Skip the retriever, the writer, and the supervisor until the first handoff is boring.
- Write the handoff schema before either prompt. Question, query, result with row count, assumptions, confidence with a reason, unresolved list. If you can't specify what crosses the boundary, you don't yet have two roles — you have one job cut in half.
- Run it in shadow for a full period, alongside the human version, changing nothing about how the deliverable actually gets produced.
- Measure the disagreement rate, not the accuracy. How often does the checker challenge the analyst, and how often is it right when it does? A challenge rate near zero means you have consensus theater. A challenge rate near half means the analyst's job is underspecified. Somewhere in between is a working team, and the disagreements themselves are the most valuable output of the pilot — each one is either a data problem or an undocumented convention.
- Add the third role only where the pain is. Deliverable inconsistent in tone? Add the writer. Handoffs going in circles? Add the supervisor. Query quality drifting? Split out the retriever.
Two agents and a real handoff schema beat five agents and a group chat, every time.
The bottom line
Agent teams aren't a more advanced way to use AI. They're the minimum structure required to put independent review between a model and a number a CFO signs — and independence is the whole point, because a single agent reviewing itself is a control that doesn't exist.
Separate the jobs that genuinely conflict. Make the handoff a workpaper instead of a paragraph. Escalate on disagreement, low confidence, and materiality, mechanically. Give every workflow one human owner. Then start with two agents on one deliverable and let the disagreements tell you what's actually wrong with your data.
The goal isn't a finance department staffed by agents. It's that by the time a person looks at the work, someone has already tried to break it.
If you want to see a multi-agent workflow running against live NetSuite data — the handoff packets visible, every query auditable, escalation set where you set it — request a walkthrough. Bring the monthly deliverable your team least enjoys producing; that's the one to staff first.
