Apps, not agents: where the real opportunity lies for finance teams

In one of my first articles I highlighted the opportunity being afforded to the finance professional to create discrete tools to improve their own efficiency. I want to explore this in a bit more detail, because there is a distinction I think needs drawing between building a software application and deploying agentic AI. The two are being talked about as if they were the same thing. In a finance team they are not, and the difference matters.

A short history

When ChatGPT launched in November 2022 it was, for most of us, our first contact with a large language model, and for a while it simply was AI. It was the vanguard and it was rapidly followed by others: Claude, Gemini, Llama, Grok. The improvement in capability across all of them has been astonishing. We now face an array of models from all the large companies, and within each company’s offering there are models of varying capability and price.

Agentic AI came later. The term was popularised during 2024, largely by the AI researcher Andrew Ng, and the concept is straightforward. It can broadly be summarised under the mantra “give power to the machine”.

What an agent actually is

Agentic AI involves an LLM, some tools, and a program that organises the running of scripts and instructions. It is a bit like an orchestra, except the musical instruments have been replaced with a variety of digital tools, all aimed at an outcome. The key feature is that the thinking part of the agent, the LLM, is given some autonomy to decide how that outcome is reached. It chooses which instruments to play and in what order, every time the piece is performed.

This is all well and good for unstructured tasks. Customer service, exploratory data analysis, preparing a report from disparate research sources: these are jobs where the route to the answer is not known in advance, and letting the machine find it is the whole point.

But what about environments that are highly rule driven, where the quality of the outcome is measured precisely by the extent to which the rules have been followed? Enter the finance team.

I have spent my whole career working in and leading finance teams. There is certainly space for creative thinking, and the social skills that allow a finance team to engage properly across the business matter a great deal. But a considerable part of the workflow is rules driven. Payroll journals, bank reconciliations, intercompany, accruals, the month-end pack: the rules are known, the inputs are known, and a good outcome is one that follows the rules exactly. It is this area that software firms have been selling into for decades, and it is where the opportunity for the finance professional now lies.

My view is that in a rules-driven environment you do not want the agent. Three reasons:

• The outcome is deterministic. Given the same inputs the answer should be the same every time. An agent re-decides how to get there on every run. For a bank rec that is not a feature, it is a liability.
• Agents gobble tokens. Every decision the LLM makes costs money, and a process that runs daily or monthly across a business racks that cost up quickly. A script, once written, costs almost nothing to run.
• Auditability. A piece of software gives you a repeatable process that a reviewer can read and test. An agent gives you a transcript of what it happened to do this time. Anyone who has sat through an audit will know which of those they would rather hand over.

None of this makes the LLM irrelevant to rules-driven work. It just moves it. The LLM’s job is to help you write the software, not to be the software.

To be fair to the agent

I am not arguing that agents have no place in finance. They do, and it is in the parts of the job I described earlier: the unstructured bits. Drafting the commentary for the board pack, chasing down why a supplier’s statement doesn’t agree, pulling together a first cut of a market comparison. There is also a sensible role for an agent as a reviewer of what the deterministic tools produce, a second pair of eyes that reads the output and flags anything odd. That is a job that needs judgement, and it is a job where an occasional miss is tolerable because a human is still signing off.

So here is the challenge. The hype is pointing finance teams at the wrong end of their workload. The agent conversation is about the 20% of the job that needs judgement. The 80% that doesn’t, the repetitive, rules-driven, month-in month-out work, is sitting there waiting to be turned into small, boring, reliable software applications, and an LLM will now help you build them in an afternoon. That is the opportunity. It is less glamorous, and it is far more valuable.

Thinking like an engineer

What this requires of the finance professional is to start thinking a little more like an engineer. That means identifying the data sources, the processes and the hand-offs, and being able to draw them out on a piece of paper. When the picture on the paper is clear, a coding agent can be brought to bear, and it will do the typing. When it is not clear, no amount of AI will rescue it.

In practice the skill set looks like this:

• Process decomposition. Breaking a workflow into inputs, transformations and outputs. Accountants already do this when they document controls; it is the same muscle.
• Knowing your data. Where it lives (the Xero API, a Sage export, a CSV from the bank), what shape it arrives in, and which fields actually matter. Half of every tool I have built is wrangling the input.
• Writing a specification. Stating the rules and the edge cases precisely, in plain English, because that is what you hand to the coding agent. This is where double-entry people have an advantage over most. We are used to stating rules exactly.
• Test thinking. Knowing what “correct” looks like before you press go, and building the check into the tool. Control totals are tests. A reconciliation is a test.
• Enough technical fluency to review. Not writing Python from a blank page, but reading what the agent produced well enough to spot a wrong sign, a hard-coded date or a VAT rate that should have been a parameter.
• Ownership. Tools need a home, a version history and a named person who knows they exist when the chart of accounts changes. The spreadsheet on someone’s C drive was never a good idea; the Python script on someone’s C drive isn’t either.

Nothing new, pointed somewhere new

Look down that list again. Not one of those is a new skill for a finance professional. Documenting a process, knowing where the numbers come from, writing a rule down precisely, reconciling, reviewing someone else’s work, owning a control: that is the job. What has changed is the object those skills are pointed at. Instead of a spreadsheet, it is a small application, and instead of building it yourself over three weekends, you are describing it to a machine that writes the code.

The finance teams that get this will spend less time on the 80% and more on the 20%, which is where they always wanted to be. If you’re deploying the agent in this space you will have surprises, and not all good ones, and it could be expensive.