The difference between a chatbot and an agent is one thing: tools.
A chatbot can discuss your policy. An agent can look up your policy, check the claim against it, request the missing document, and put the file in front of an adjuster with a recommendation. The language capability is identical. The difference is that one has access to systems and the other doesn't.
This is why the value is concentrated in operations rather than customer-facing chat, and why the interesting deployments in banking and insurance don't look like assistants at all.
What's actually running
Two disclosed examples from large European financial institutions.
Trading surveillance. A major bank is building agents that monitor trading activity — orders, trades, market movements — flag anomalies, and escalate to a human compliance officer for investigation. Extension planned to monitoring communications from client-facing staff, looking for unusual behaviour such as forwarding confidential information to personal addresses.
Claims processing. A major insurer deployed an agentic system for a specific claims category that reduced processing from days to hours, explicitly with a human in the loop. The same group has a partnership focused on agents handling multi-step workflows including intake documentation in motor and health insurance.
Two things stand out. Both are narrow — a defined process, not a general assistant. Both keep a human at the decision point. That isn't regulatory theatre; it's what makes them deployable, because the failure mode of these systems is confident wrongness, and a human checkpoint is the control that catches it.
The tools that matter in financial services
An agent is defined by what it can reach. Roughly in order of value-to-difficulty:
Read-only lookups across systems. Policy details, account status, claim history, transaction records. Low risk, high volume, and it removes an enormous amount of internal request traffic. This is where almost everyone should start.
Document extraction. Reading submitted documents — claim forms, statements, invoices, identity documents — and pulling structured fields. Mature technology, immediate measurable saving, and the before-state is easy to quantify because someone is doing it manually today.
Policy and rule checking. Comparing a case against written policy or a regulatory rulebook and flagging where it doesn't fit. Valuable precisely because the rules are voluminous and change often.
Cross-system reconciliation. Finding where two systems disagree about the same customer. Tedious, high-value, and something nobody enjoys doing.
Case file assembly. Gathering everything relevant to a decision into one place with a summary. Doesn't make the decision — makes the human faster at it. Frequently the highest return per unit of risk.
Writing to systems. Updating a record, creating a case, issuing a communication. Here the risk profile changes completely. This should come last, be scoped narrowly, and be reversible.
Notice the pattern: the first five are all about getting the right information in front of a person. That's where the reliable return is. Writing to systems is where the demos are.
Where it doesn't work
Worth being direct, because these get proposed constantly.
Autonomous decisions with customer impact. Declining a claim, refusing credit, closing an account. Beyond the regulatory exposure, you cannot currently guarantee the reasoning. Keep the human.
Anything requiring calibrated uncertainty. These systems don't reliably know when they don't know. If the process depends on someone recognising an unfamiliar situation and escalating, that's a poor fit.
Processes nobody has documented. If the current process lives in the heads of three experienced people and varies by case, an agent will automate an inconsistent process consistently. Document first.
Anything where the data is wrong. An agent surfaces bad data faster and more persuasively than a human would. Fixing the data is not optional preparatory work; it's the project.
The model choice matters less than you'd think
A common concern in procurement: which model provider to commit to.
For most of these use cases, the answer is that it matters less than the surrounding architecture. If the system is built properly — tools exposed through a standard interface, evaluation set in place, permissions enforced at the data layer — the model is a swappable component. You can move between providers, and you should build assuming you will, because pricing and capability are both moving fast.
What you're really choosing is your integration layer, not your model. Get that right and the model becomes a procurement decision you can revisit annually. Get it wrong and you've built a system welded to one supplier's roadmap.
For regulated industries there's a second dimension: where inference runs, what's retained, and whether the provider can meet your data residency obligations. That's a compliance question and it may narrow the field more than capability does.
What it costs, honestly
The pilot is cheap. A narrow agent against a well-understood process, six to ten weeks, small team. This is why so many exist.
Production is where the cost sits. Permissions, audit logging, evaluation, monitoring, human review workflow, and an owner. Typically several times the pilot.
Inference is a running cost that scales with volume. Model it at production volume, not pilot volume. Some use cases are fine at both; some are only fine at one.
Data preparation is usually the largest line. Accenture disclosed that half its AI projects bundle data modernisation. Plan accordingly.
On the return side, the mechanisms that hold up: reduced handling time per case (measurable, defensible), reduced rework from errors caught earlier, faster response to regulatory requests, and capacity released rather than headcount removed. That last distinction matters for how you sell it internally — the projects that succeed are almost always framed as capacity release, not job reduction, because the second framing guarantees you won't get the cooperation of the people whose knowledge you need to build it.
Six controls to insist on
Non-negotiable in a regulated environment.
- The agent acts as the user, with the user's permissions. Never a service account with broad access.
- Every action is logged and attributable to a person, with a timestamp and a record of what was accessed.
- A human checkpoint before anything with external consequence.
- An evaluation set that runs automatically — so a model change is caught by you, not by a customer.
- A defined escalation path for when the agent can't complete a task. It must fail loudly.
- A named owner with a budget line, not a project team that disperses at go-live.
How to start
Pick one process. It should be high-volume, currently manual, already has a human reviewing the output, and touches at most two systems.
Build the read-only version first — the agent assembles the case and recommends, the human decides. Measure handling time before and after with a real baseline.
Then, and only then, discuss whether anything should be written back automatically.
The organisations getting value from this aren't the ones that deployed the most ambitious agent. They're the ones whose second and third deployments took six weeks instead of six months, because the permissions model, the logging and the evaluation harness were already built.
The first project is infrastructure with a use case attached. Price it that way and the rest gets much easier.
Sources: public disclosures from Deutsche Bank and Google Cloud on trading surveillance agents; Allianz public communications and partnership announcements on claims processing; Accenture Q1 FY2026 earnings commentary. All accessed 2026-07-26.
Fares runs QartMina Labs, an independent backend and AI engineering practice.