Do you need AI agents for treasury?

"Agent" is the word of the year, and treasury keeps getting pitched as a prime candidate for full automation. On paper it makes sense. Treasury is data-heavy, repetitive, and full of the kind of gather-reconcile-summarise work that language models are good at. It is also a function where an omitted zero can cost a company a great deal, where a regulator has opinions, and where "the model was confident" is not an acceptable answer to a question about last quarter's numbers.

I joined Palm in June as an AI Engineer. Being new to treasury, I spent my first weeks developing an understanding of the domain and its challenges, and I'm still learning it from my colleagues and our customers. What follows is my reflection on the domain and its outlook in the Agentic AI era.

Aligning on definitions

With the speed at which industry changes, the definition of an agent is sometimes lost or left to interpretation. So we'll stick to the basics.

An AI agent is an LLM equipped with tools to improve its understanding of context and to take actions rather than just propose them.

On one end we have copilots: agents that explore and propose, and a person is present for every turn. At the other sits full autonomy: an agent that decides what to look at and what to do, and informs you afterwards. Most of what is being shipped as a treasury agent today sits somewhere on that line, and where exactly it sits is usually the thing a demo doesn't show you.

So what are agents really good at?

Give an LLM access to your treasury data and it will ingest far more of it than a person has time to. It will find patterns that may not show up as fast to a human eye. That is real work, and it is work that mostly does not get done today because nobody simply has the time.

However, they need to be backed with the right tools. A model asked to hold a few thousand rows of Excel data in its head and produce a variance figure will produce a figure, and it will be plausible, but it will sometimes be wrong in ways that don't look wrong. And that is dangerous.

How do we tackle this at Palm? Our agents are backed with several data-related tools that allow an agent ground its responses in factual data. We find in particular that driving arithmetic through code execution tools (fancy word for calculators) produce more accurate results than synthesising large amounts of data within the model. The reasoning about what to compute stays with the model and the computing itself goes to something deterministic.

Where things become tricky

Consequently, we see agents taking up repetitive, somewhat boring tasks that cost treasurers precious hours like building reports. You give a model a prompt and some data tools, and you ask it for a cash flow report. It writes some queries, runs them, produces something good. You're impressed. You schedule it.

It runs again next week. But this time, the underlying data has changed like a new entity was onboarded, a category was remapped or a bank connection started returning a field differently. The agent, being an agent, adapts. It writes slightly different queries. It produces a report with different numbers, and it produces it confidently, because from inside its context window (what the model sees) nothing is wrong. Nothing told it something changed. You can't really blame the model for this because it's doing what you asked. But you now have a report you can't reconcile against last week's, and no way to tell whether the delta is a real business change or an artefact of the agent re-deciding, and no audit trail that distinguishes the two. In treasury this is disqualifying, not a rough edge to be smoothed out later. Reproducibility, accuracy, traceability and explainability aren't nice properties of the output; they're the reason anyone is allowed to trust it. You need to be able to say that your cash flow agent that ran yesterday will run the same way today, and that if anything material changed, you were informed about it.

How we build agents at Palm

This shapes how we build agents at Palm. We split the agent's life into two phases. At build time, the agent behaves like a treasurer's copilot, and it is fully agentic: it explores and queries that data, iterates, and assembles a workflow that answers what the treasurer asked for. The user sees the data and resulting output, interrogates it, pushes back if needed, and eventually approves it. At run time, that exploration is over. We freeze the queries the agent arrived at, and those are the queries that run on schedule — with relative time windows respected, so "last month" still means last month. The agent isn't re-deciding what to compute every morning when it needs to deliver your cash flow report. It's executing something a human looked at and signed off on. Is that still an agent? I'd say yes, and that the intelligence is being spent in the right place. The hard part of these workflows is composing them: figuring out which tables, which joins, which entities, which definition of a cash position a particular treasurer means. That's the part the model is good at, and that's the part we allow it to do. With the approved workflow validated on every run, when the agent can no longer execute against the data as it stands, it fails loudly rather than adapting quietly. The user is told which agent broke, what changed underneath it, and what the workflow was trying to do, so they can update and re-approve it.

With this design, a human stays in the loop with the authority to approve or require changes, and every scheduled run can be traced back to something a treasurer understood and accepted.

So, do you need agents to run treasury?

Agents are great for the part of treasury you don't have the time for like the questions that go unasked because pulling the data alone takes an afternoon. Agents are genuinely good at this exploratory stage. Anything beyond that requires guardrails – grounding, determinism, lineage, and a human whose approval carries weight. Everything I've described is about narrowing what a treasurer needs to focus on. It doesn't remove the need for the critical eye. That instinct for when a number looks off — the treasurer who glances at a figure and says that can't be right — is not something we're building our way past, and I don't think we should want to. That critical eye that is able to spot when things look off - that gut instinct will always be needed in Treasury.