Agentic AI in finance, explained

"Agentic AI in finance" is on every vendor homepage this year, which is usually a sign that a term has stopped meaning anything. Underneath the fog there is a real, fairly precise distinction — and you can test for it in a live demo in minutes. Here is what "agentic" actually means, what it looks like inside a finance system, why finance needs a higher safety bar than other functions get away with, and how to adopt it without betting the ledger.

Start with the baseline: a chatbot. A chatbot takes your question, consults what it knows — training data, plus maybe some documents you attached — and produces text. That is the whole loop. It can explain a variance methodology, summarize a lease policy, even reason about numbers you paste in. What it cannot do is touch your systems. It answers; it does not act. Most "AI in finance" shipped to date is exactly this: a text box bolted onto software that was never designed for a model to operate.

An agent adds three things: tools, loops, and permissions. Tools first. An agent is a model connected to functions it is allowed to call — query this table, update that driver, run this forecast, export that report. Instead of only producing prose, the model produces a decision: call this tool with these arguments. The system executes the call and hands the result back for the model to read. That one change moves the model from narrator of your software to operator of it.

Loops second. Real finance work is rarely one step. "Why is gross margin down?" is a read, then a drill-down, then another read, then a comparison. An agentic system runs a loop: act, observe the result, decide the next action, repeat until the task is finished or blocked. The loop is what turns "answer my question" into "carry this task through to a result." It is also the thing to watch for in a demo — a chatbot making a single canned tool call is not an agent.

Permissions third, and this is the part finance should care about most. An agent acts inside a system of record, so the question "acting as whom, allowed to do what?" needs a hard answer. In a sound design, every tool call runs under a specific user's identity with that user's access rights, enforced by the server — not by the model's own restraint. An agent whose limits live only in its prompt has no limits.

Here is what those three properties look like against a real planning cube. Reads: fetch the trial balance, query fact tables, pull audit-log entries, list scenarios. Writes: update a headcount driver, write a member formula, create a scenario. Analysis: run forecast algorithms, compare error metrics on a holdout window, rank variance movers by financial impact instead of raw percentage. In NashOS — the worked example here, because it is the system we can describe precisely — the agent has 43 tools covering the day-to-day work in the app, across four categories: Read, Plan, Forecast and Decide. The grids are still there, but they are the fallback, not the primary interface.

Chaining is where an agent earns its keep. Take the request "Hire 3 engineers and show the runway impact." The agent updates the HEADCOUNT_ENG driver, a member formula recomputes engineering salaries, the runway forecast reruns, and the result renders as a card — each step streaming in as it happens, with the user ratifying the final commit. One sentence replaces what would otherwise be a run of grid edits and a manual model rerun. Nothing in that chain is exotic; every step is a capability the software already had. The agent's contribution is sequencing them correctly without being walked through it.

Now the part that separates finance from every other department adopting agents: the cost of a wrong action. In marketing, a bad agent output is an awkward email. In finance, it is a wrong number flowing into a board pack, a covenant calculation, or an audit sample — often silently, because the downstream totals still foot. Language models are probabilistic; ledgers are not. So the bar is not "usually right." The bar is "provably controlled": wrong outputs must be catchable before they commit, and everything that commits must be reconstructable afterward.

Three primitives clear that bar, and you should refuse to run agents on financial data without all of them. Primitive one: draft-before-commit. The agent never mutates the database directly. Every write it proposes becomes a draft that a named human reviews and approves, and the backend re-validates the draft at commit time, so a stale or malformed draft cannot land either. In NashOS this is literally a card: the agent drafts, you read it, you click Post, the server checks it again, and only then does it commit. The model's fluency never becomes authority.

Primitive two: scoped permissions. Tool calls execute with the calling user's permissions, checked at the API layer, and the model never holds credentials. Your analyst's agent can do exactly what your analyst can do, nothing more. Primitive three: audit trails. Every mutation is logged with actor, timestamp, and before-and-after values, so "what did the agent change in March?" is a query, not an investigation. Add operational controls on top — watching the agent work step by step, interrupting it mid-task, a kill switch — and you have something an auditor can live with.

What are agents genuinely good at today? Mechanical work over structured data. Answering "what moved and why" straight from the cube. Ranking variance movers by impact so commentary starts from a ranked list instead of a blank page. Running the forecast comparisons no analyst has time for — NashOS ships 15 algorithms and scores them on holdout R², RMSE, MAE, and MAPE, and the useful part is not the count, it is that the agent runs the full comparison and you pin the winner. Chaining routine multi-step tasks like the hiring example. Drafting a first pass of almost anything.

What should stay human? Judgment and commitment. Materiality calls, accounting policy choices, and the final approval on any write. Anything that leaves the building — board packs, filings, guidance — gets human sign-off, full stop. Forecasting a business with no history is still a human modeling problem; no algorithm recovers signal that does not exist. And never let an agent be the final reviewer of its own work: the human review step is the control, so staffing it with the agent defeats the design.

The adoption path that works is deliberately boring. Phase 1 — read-only. Give the agent query access and nothing else. Let the team ask questions for a few weeks and check the answers against reports they already trust. This calibrates confidence with zero risk of mutation, and it surfaces where the agent misreads your data before a misreading can write anything. Phase 2 — drafted writes on low-stakes surfaces. Scenarios and drivers before actuals, every write through the draft queue with a named approver. Phase 3 — widen scope as the audit trail accumulates evidence. Notice what you are actually rolling out: not a model, a review workflow.

The takeaway is a three-question test you can run on any vendor, including us. One: can it act, or only answer — ask to watch it chain tool calls on live data, not slides. Two: what sits between the model's intention and your database — if the answer is not "a human approval plus server-side re-validation," keep walking. Three: can you reconstruct, six months later, exactly what changed, who approved it, and what the values were before. Agentic AI in finance is worth adopting precisely to the degree that the answers to those three questions are boring.