Most conversations about AI agents in finance are really conversations about autonomy: can a model be handed a decision a person currently signs off. That framing hides where the engineering work actually sits. In the finance workflows we have looked at, the agent’s reasoning loop is rarely the hard part — data access, the audit trail, and the compute the agent triggers on every step are.
Split the workflow before you split hairs about model quality. Steps that are retrieval, aggregation, or orchestration are delegable, testable, and reversible. Steps that are judgement exercised under regulatory accountability are not delegable, regardless of how good the model gets. That line — the sign-off boundary — is where an engineering problem becomes a governance problem, and no benchmark settles it.
What do AI agents actually do in finance workflows?
Strip away the framing and the useful work looks mundane. An agent pulls positions from three systems that do not share a schema. It reconciles a counterparty list against yesterday’s. It assembles the inputs for a risk or pricing run, kicks off the run, waits, and drafts the commentary around the output. Each of those steps has a measurable duration, a definable success condition, and a rollback path.
The step it does not take is issuing the decision. An agent that assembles the inputs for a capital, credit, or pricing decision is an engineering problem with throughput and latency you can report. An agent that issues that decision moves accountability, and accountability in a regulated process attaches to a person, not to a tool chain. This is why “the model got better” is not an argument for moving the boundary.
That distinction also separates agents from what a bank already runs. A fraud score, a probability-of-default model, or a nightly batch job is a fixed pipeline: fixed inputs, fixed sequence, fixed output. An agent chooses its next call at runtime. The capability gained is orchestration across systems that were never integrated; the cost incurred is that the call graph is no longer known in advance. Our wider view of what banking teams actually build — and what each workload costs to run on a nightly schedule — sits in bank machine learning and analytics.
Decomposing the workflow: what delegates and what does not
Use this as the first pass over any candidate workflow. Anything in the right column stays with a named person.
| Workflow step | Class | Delegable to an agent? | What makes it safe or unsafe |
|---|---|---|---|
| Pull ledger, position, and market data from multiple systems | Retrieval | Yes | Deterministic, replayable, output diffable against the manual pull |
| Reconcile records against a prior period or a golden source | Aggregation | Yes, with exception routing | Break items must escalate, not get resolved silently |
| Assemble and validate inputs for a risk or pricing run | Aggregation | Yes | Input set is checkable before the run consumes it |
| Trigger and monitor a calculation batch | Orchestration | Yes | Reversible; failed runs re-run without side effects |
| Draft a report or commentary from a completed run | Generation | Yes, as draft only | Draft carries no authority until reviewed |
| Choose model assumptions or override a risk parameter | Judgement | No | Assumption changes propagate into a regulated figure |
| Approve a limit, price, or capital number | Judgement | No | Sign-off is an accountability act, not a computation |
| Communicate a decision to a customer or regulator | Judgement | No | Attribution must be to an accountable person |
The pattern holds across the finance workflows we see: the delegable share is concentrated in preparation, and preparation is usually where the hours go. That is the honest ROI anchor. Measure the share of manual preparation time — data pull, reconciliation, input assembly, report drafting — that can be delegated with a verifiable audit trail, plus the end-to-end latency of that preparation step. Both are reportable before anyone touches who signs off (observed across TechnoLynx engagements; not a published benchmark).
The audit trail is a design input, not a logging feature
An agent’s output cannot enter a regulated process unless you can reconstruct how it got there. In practice that means recording, per step: the tool or system called, the query or parameters used, the data version returned, the model and prompt version in play, the timestamp, and the human who reviewed the result. If any of those are missing, the output is unusable for a controlled process even when it is correct.
Teams that treat this as instrumentation to add later usually rebuild the agent. Retrofitting provenance into a loop that already fans out across five internal systems means changing every call site. Design the trace schema before the first tool integration, and treat an untraceable step as a broken step.
Agentic fan-out is a compute problem
Here is the part that gets discovered late. An agent that orchestrates calculation requests does not run one job — it runs many, often speculatively, often re-running with adjusted inputs because that is what an agent is for. Where a nightly risk or pricing batch previously ran once, agentic orchestration can multiply GPU-hours several-fold against the same workload. That multiple is not a model-quality property; it is a property of the call pattern layered on top of an unchanged pipeline.
Which means the agent inherits every inefficiency underneath it and multiplies it. A kernel that wastes a third of its cycles on avoidable memory traffic wastes that third on every one of the agent’s fan-out calls. Scheduling gaps between dependent stages compound the same way. This is exactly why the profile-first discipline — algorithmic and pipeline gains before hardware purchases — governs whether agentic orchestration is affordable on the hardware you already own; we set out that argument in our work on GPU performance engineering.
The measurement to take before committing:
- Baseline the current batch. Wall-clock time, GPU-hours consumed, and per-stage utilisation for one representative nightly run.
- Count the agent’s calls, not its tokens. Instrument the prototype to log every calculation job it triggers, including retries and abandoned branches.
- Compute the fan-out ratio. Agent-triggered jobs divided by the manual baseline’s job count. This number, not the token bill, drives the compute cost.
- Profile before you scale. If per-stage utilisation shows headroom being wasted, fix the pipeline first — the saving multiplies by the fan-out ratio.
- Re-measure under concurrency. Several agents against one cluster behave differently from one agent in isolation.
Where agent pilots fail
Model quality is rarely the cause. The failures we encounter cluster in two places. The first is data access: the agent needs read paths into systems whose access model was designed around named human users, and the entitlement work turns out to be the project. The second is governance: the pilot quietly produces an output that someone starts relying on, without a reviewer in the loop, and the control framework has no answer for it.
Pilot design follows from that. Keep the decision boundary exactly where it is, put the agent only on preparation steps, and run it in shadow mode against the manual process for long enough to diff the outputs. Report two numbers: preparation time saved with a complete trace, and the fan-out ratio against the existing batch. If the second number is large and the pipeline underneath has never been profiled, the agent is not the next piece of work.
Frequently Asked Questions
What do AI agents actually do in finance workflows, and where do human-in-the-loop limits still apply?
They retrieve data across disconnected systems, reconcile records, assemble and validate inputs for calculation runs, trigger and monitor those runs, and draft reporting from the results. Human-in-the-loop limits apply wherever judgement is exercised under regulatory accountability: choosing model assumptions, overriding risk parameters, approving a limit or price, and communicating a decision outward. Those limits are set by who is accountable, not by how capable the model is.
How do you decompose a finance workflow into steps an agent can take and steps that require a human sign-off?
Classify every step as retrieval, aggregation, orchestration, generation, or judgement. The first four are delegable when they are deterministic enough to replay and reversible enough to re-run without side effects; judgement steps stay with a named person. The decision table above is the working version of that pass, and it is worth doing on paper before any tooling is chosen.
What is the difference between an AI agent and the automation or ML scoring a bank already runs?
Existing automation and scoring pipelines have a fixed sequence: known inputs, known steps, known output. An agent selects its next call at runtime, which buys orchestration across systems that were never integrated and costs you a call graph that is not known in advance. That runtime choice is the source of both the value and the audit and compute problems.
What audit trail does an agent need to produce before its output can be used in a regulated finance process?
Per step: the system or tool called, the parameters used, the version of the data returned, the model and prompt version, the timestamp, and the reviewer who accepted the result. Missing any of those makes the output unusable in a controlled process even when it is factually right. Design that trace schema before the first integration rather than retrofitting it.
How much extra compute does agentic orchestration add to a nightly risk or pricing batch, and how do you measure it before committing?
Agent-triggered fan-out can multiply GPU-hours several-fold against the same batch, because agents re-run and branch by design. Measure it as a fan-out ratio: instrument the prototype to log every calculation job it triggers, including retries and abandoned branches, and divide by the manual baseline’s job count. Baseline wall-clock time and per-stage utilisation on a representative run first, so the ratio has something to multiply against.
Which agent use cases in finance fail in practice, and what is the usual cause — model quality, data access, or governance?
In our experience the failures concentrate in data access and governance, not model quality. Entitlements designed around named human users do not extend cleanly to an agent, and that integration work often becomes the whole project. Governance failures look different: a pilot output starts being relied on without a reviewer in the loop, and no control covers it.
How do you pilot an agent in a finance workflow without moving the decision boundary?
Confine the agent to preparation steps, keep every sign-off exactly where it is today, and run it in shadow mode alongside the manual process so outputs can be diffed. Report preparation time saved with a complete trace, plus the fan-out ratio against the existing batch. If the fan-out ratio is high and the calculation pipeline has never been profiled, profiling is the next piece of work — not wider agent scope.
The honest read on AI Agents Finance
None of this is theoretical. AI Agents Finance rewards teams that measure first and argue later — start with the smallest instrumented slice and let the numbers settle the design.
