How multi-agent AI works in financial services

How multi-agent AI works in financial services

Thomas Wing Evans, blog author, smiling at the camera against a white background.

Thomas Wing-Evans

|

|

0 Mins

A cardholder disputes a $340 transfer they say they never made. Answering them properly means checking who they are, pulling the transaction, screening the receiving account, and asking the merchant whether the goods ever shipped.

Three of those four live in your systems. The fourth lives in someone else's, and that's where most AI support stops and hands the ticket to a human.

Where single agents stall

A single-agent AI system routes every task through one model with one context window, one set of tools, and one decision pathway. For an account balance question or a loan offer summary, that's enough.

The dispute above is a chain: identity verification, transaction history lookup, fraud scoring, regulatory hold assessment, possible reversal, and a compliance record. A single agent can carry all of that, but only while the work stays inside your own systems.

The model drifts instead of failing outright, losing precision on the compliance step because it's still holding context from the identity step, and returning answers that are coherent but operationally incomplete. In financial services, that's a compliance risk and a customer experience failure at the same time.

The harder limit is reach. When the answer depends on a merchant confirming a shipment or an acquirer confirming a chargeback window, the agent has nowhere to send the question. It writes a summary, opens a ticket, and a person picks up the phone.

What multi-agent means

Multi-agent means the concierge holding the customer conversation can dispatch other agents to do work it can't do itself. In financial services the work that matters most happens outside your systems.

Lorikeet's Team of Agents dispatches agents to contact third parties by phone, SMS, email or Slack: the merchant, the acquirer, the delivery partner, the vendor. The concierge keeps the customer's conversation live and updates them as answers come back.

A dispatched agent places the call and asks the question. Each one runs to clear parameters: what information to gather, what outcome to achieve, and how long to try before escalating.

The concierge can spawn multiple agents in parallel while keeping the customer on the line. Context carries across channels, so the customer doesn't repeat their case or switch channel to find out where it got to. For how that plays out across a fintech support queue, see AI Agents for Fintech Customer Service.

A disputed transfer

The concierge confirms the customer's identity and pulls the transaction in the same conversation. The receiving account has been flagged in a prior dispute, so the concierge dispatches one agent to email the merchant for shipment confirmation and a second to call the acquirer for the chargeback window.

Both run while the concierge stays with the customer, tells them the claim is open, and gives them a real timeline. When the merchant replies four hours later, the concierge picks the thread back up, with context carried across voice, SMS, chat and email.

Without the dispatch, that sequence is a ticket. Someone emails the merchant, someone else calls the acquirer, and the customer waits without an owner until both replies land.

Compliance by construction

Lorikeet keeps audit trails that log all interactions, decisions, and actions. Every customer interaction, model choice and action is tracked and visible through transparent reasoning tooling. For regulatory reporting, Lorikeet supports audit trail exports, compliance dashboards, exception reporting and data access logs.

An audit needs the record itself: the agent contacted the merchant at 09:14, asked for shipment confirmation, and logged the reply. (For more on managing AI accuracy in production, see Defense in Depth.)

The same record answers the customer. When they ask where their dispute has got to, the concierge can say the merchant was emailed on Tuesday and hasn't replied yet, instead of saying the case is under review.

Runtime guardrails evaluate every message and response as conversations happen, checking outgoing responses before they're sent. Because the check runs outside the concierge's reasoning loop, the concierge can't talk itself out of a violation.

Architecture tradeoffs

Dispatch needs a dependency graph. Identity has to be confirmed before anything goes outbound, and the merchant email and the acquirer call can run at the same time because neither depends on the other.

Any dispatch design needs a defined output for each agent, so the concierge isn't parsing free text out of a phone call. Those outputs are what make a case inspectable and its failures manageable. A timeout, an unreachable number, and a merchant who declines to answer each need their own next step.

Failure handling is where multi-agent implementations break down in production. Partial failures, where the merchant replies and the acquirer doesn't, are far more common than total failures.

A system that treats a compliance timeout as a soft pass is worse than one that blocks until compliance can be confirmed. Insurance carriers face this acutely (see For Insurers, the Problem Isn't Hallucination - It's Liability).

The dispatch is the AI. The rule that a compliance timeout blocks instead of passing is deterministic, and it should stay that way.

I think the line between judgment and rule is worth drawing precisely. Deciding how to ask a merchant for a shipment confirmation, and what to do with a half-answer, is judgment, and it's what the agent is for. Whether a case can proceed with an unconfirmed sanctions screen is a rule, and it should be written as one.

The common mistake is to answer that with staffing, routing anything legally load-bearing to a human queue. That puts a person in the path of every dispute and still leaves the decision undocumented. A rule that blocks, logs the reason code, and tells the concierge what to say to the customer produces the same outcome every time.

Latency changes shape once the dispatch goes outbound. A merchant email comes back in hours, an acquirer call in minutes, and neither fits inside a single chat session. The concierge has to hold the case open across that gap, update the customer without being asked, and resume in whatever channel they come back on.

Lorikeet's approach

Lorikeet builds this for financial services and insurance workflows. The concierge holds the customer conversation and dispatches agents to third parties by phone, SMS, email or Slack when the answer lives outside your systems.

The inbound conversation is where fintech deployments start. Flex doubled CSAT against its previous support tool and halved median conversation duration to resolution, in a queue where chat volume runs 4x higher during rent week than the rest of the month. That is an inbound result, not a Team of Agents deployment.

Cases sitting in a financial services queue are often stalled on a reply from someone outside the business. An agent that can place the call, log what came back, and tell the customer is what closes them.

Book a call

See what Lorikeet is capable of

Share this article

Related posts