Agentic Engineering in Financial AI

When work gets handed to an agent, what is left for us to design.

Talk about agents in financial AI and the first question is usually how far automation can go. Writing reports, generating SQL, analysing portfolios, flagging suspicious transactions, answering customer questions.

From inside the work, the question shifts.

More important than “can the AI do it?” is “when the AI is wrong, how does the system respond?”

Finance is not ordinary software. One bad recommendation becomes a customer’s loss. One bad query becomes a distorted decision. One bad piece of automation reaches straight into trading, payments, risk management and regulatory reporting.

So an agent here is not a productivity tool. It is an actor wired to money, risk, regulation and reputation.

Which is where agentic engineering comes in.

Agentic engineering is not about handing the agent more freedom. If anything it is the opposite. The more an agent does, the more structure has to be built around it: restricting tool access, recording execution, verifying intermediate results, designing so that invalid states cannot be created, and leaving output in a form a person can actually read.

Say a financial agent writes SQL. Whether it produced SQL is not the interesting part. These are:

Did it query only permitted tables?
Did it stay away from sensitive columns?
Did it use the correct metric definition?
Is the result consistent with the existing dashboard?
Did it run up an unreasonable bill?
Is there an execution log and a record of what it decided and why?
Can a person understand and sign off on the final result?

Without that scaffolding an agent is impressive in a demo and dangerous in production.

A good agent system in finance is not one smart model. It is several layers of protection.

Domain invariants

Some states must never exist. An approved payment with no authorisation code. A risk decision with no recorded basis. A settled transaction with no settlement date. A credit score with no record of which model version produced it.

Good engineering does not detect these after the fact. It makes them unrepresentable in the first place.

Fast feedback loops

Agents work better when something answers them. Type errors, failing tests, simulation output, historical replay and dry-run results are all signal.

Historical replay matters especially here. A new fraud rule, a new credit scoring strategy, a new trading signal, a new portfolio constraint should not go straight to production. Run it over the past first.

How did this strategy behave during the last stress period? Did it fall disproportionately on one customer segment? It raised approval rates, but did it raise fraud losses with them? Returns look good, but was turnover and transaction cost quietly ignored?

Without that check, financial AI is not automation. It is automated risk.

Traces a person can follow

Checking whether an AI result is right takes more than the final answer. What data did it look at, what did it assume, what intermediate calls did it make, and where was it uncertain.

In finance, explainability is not really a model-interpretation problem. It is a question of operational accountability. Someone will ask, and you need an answer.

Why was this transaction blocked? Why was this customer’s limit cut? Why was this rebalance recommended? Why does this number differ from the dashboard?

The agent produced the result, but the responsibility stays with the organisation running the system. Which makes traces, audit logs, reason codes and evidence references core design elements rather than nice extras.

Code review, and people who understand the system

An agent writing code does not remove code review. It raises the stakes.

An agent can write code that passes the tests. Passing tests is not the same as being good. What matters in a financial system is not merely working code but code that is simple, readable, verifiable, extensible, and hard to misuse.

Agents often take strange shortcuts toward the stated goal. Told to make the tests pass, one may weaken the test instead of fixing the cause. Told to add a feature, it may leave duplication, hard-coded values, thin exception handling and vague permission logic behind.

So code review here is not primarily bug-hunting. It is keeping the system in a state that a person can understand and answer for.

Where the difference will actually come from

I do not think model performance alone will decide competitiveness in financial AI. The gap is more likely to open around the model.

Who has the better agent harness? Who designed the safer tool registry? Who built the faster verification loop? Who leaves the clearer audit trail? Who makes the agent’s output legible to a human?

That is where the real difference lands.

Which reduces to a single stance:

Not automating because you trust the AI, but automating on the assumption that it can be wrong.

A good financial AI system does not assume the model is right. It assumes the model can be wrong, can miss context, can answer with far too much confidence, and can use a tool in a way nobody anticipated. It is built to hold anyway.

Agents can make financial work faster. But speed alone was never the point here. That is why agentic engineering matters in this domain: it puts speed inside a controllable structure, automation inside a verifiable system, and the model’s capability within human understanding and accountability.