An FP&A analyst agent that never does the math

The finance team at a large, multi-site organization wanted analysts to ask questions in plain English — "how did average order value move last month versus prior year?" — and get an answer they could defend in a leadership meeting. The obvious approach, text-to-SQL over a warehouse, was the one they were most afraid of: a plausible-looking wrong number is worse than no number.

The design principle

The agent never does math. It classifies the question, confirms scope and time period if either is ambiguous, picks from a catalogue of parameterised queries that finance already trusts, runs them through MCP Toolbox against the source systems, and narrates the result with the timeframe and comparison basis stated explicitly.

Decisions worth stealing

• Ambiguous questions default to last closed month, year-to-date (relative to the last closed month, not the calendar), and prior-year comparison — and the answer says so.
• Tabular output by default. Finance people read tables.
• A "financial analyst" persona in the system instruction, with vocabulary standardised (AOV, not ASP) so the agent and the team say the same words.
• MCP Toolbox runs on VMs the client manages. No data is copied into a new warehouse first; the agent reads the systems of record.
• Every model or version change gets a head-to-head regression run before it goes live, on the same live path the deploy script itself uses to verify a release — no retries, no cherry-picking. One run compared the build in production against a newer build four days on: the older build passed all seven scenarios tested, the newer failed three, though the compute layer was correct in every case on both — every failure was in the narration layer turning a correct number into English. That run's recommendation, do not promote the newer build, is why the older one is still live.

What we learned

The hard part was not the model. It was credentials and network paths to three different databases owned by three different teams, and a Gemini Enterprise trial licence that registers as consumed at the billing-account level. Our weekly update format — what we achieved, what's next, blockers with an owner and a date on each — is what kept the engagement moving through those weeks.

How we evaluate "correct" matters as much as building the agent. We graded the regression run against the system's own written rules — every driver has to sum to the headline number, the fiscal-year basis has to be stated explicitly — not a golden-answer rubric. A separate validation workbook checked every number against the source table directly, and it matched exactly, with one exception, revealing rather than damning: a tool field was mislabeled, so the answer that followed our own rule to the letter got marked wrong by a human reviewer, and the answer that broke it got marked right, because the field had the bug, not the model.

All case studies