Banks can use AI agents to resolve service cases and coordinate operations across fragmented systems. The opportunity also carries an unusual level of risk: an agent can expose account data, make an unauthorized change, or give a customer an incorrect explanation in seconds. The useful question is therefore where an agent should act, with what authority, and under whose control. Here is a practical model for choosing workflows and taking them safely into production.
What is an AI agent in banking?
An AI agent is software that receives a goal, gathers context, chooses a next step, uses approved tools, and continues until it completes the task or hands it to a person. In banking, its tools might retrieve a transaction, create a dispute case, send a document request, schedule a payment, or update a customer relationship management system. In practice, agentic AI in banking combines goal-directed reasoning with controlled action.
That ability to act separates an agent from adjacent systems:
| System | What it does | Typical banking role |
|---|---|---|
| Predictive model | Estimates a score or class from data | Fraud score, default probability, churn risk |
| Rules engine or robotic process automation (RPA) | Executes predefined logic | Reconciliation, field validation, scheduled reports |
| AI assistant | Retrieves, summarizes, or drafts for a person | Policy search, case summary, response draft |
| AI agent | Chooses and executes steps through approved tools | Dispute intake, KYC follow-up, service resolution |
An agent does not make every component generative. A sound banking workflow can use a specialized fraud model for anomaly detection, a deterministic policy engine for action limits, and a language model for interpreting a customer's explanation. The agent coordinates those parts.
The difference matters because most banking work needs bounded autonomy. In a 2024 survey of 118 UK financial-services firms, the Bank of England and Financial Conduct Authority found that 75% already used AI. Fifty-five percent of reported use cases had some automated decision-making, while only 2% were fully autonomous. Data privacy, data quality, security, bias, model complexity, and third-party dependence featured among the leading risks in the UK financial-services survey.
For customer-facing voice workflows, Dasha's managed voice AI runtime gives technical teams the telephony, REST APIs, integrations, testing, monitoring, and call execution layer needed to run production conversations. The bank still owns identity verification, system-of-record data, policy rules, permissions, and compliance approval. Dasha should sit inside that controlled architecture rather than become the decision system for credit, fraud, or account eligibility.
Eight banking workflows that fit AI agents
The best first use case has a high volume, a stable operating procedure, a clear completion state, and an action boundary the bank can enforce in code. It should also have a useful human fallback.
| Workflow | What the agent can do | Recommended action boundary | Human checkpoint |
|---|---|---|---|
| Customer servicing | Authenticate, retrieve approved account facts, answer questions, create cases, and complete low-risk updates | Read access plus a short allowlist of reversible writes | Identity failure, vulnerable customer, complaint, advice request, or policy exception |
| Fraud outreach | Contact a customer, verify recent activity, gather evidence, and update an investigation | Collect and route evidence; allow a temporary protective action only under explicit policy | Permanent restriction, account closure, loss allocation, or suspicious activity filing |
| Dispute intake | Capture the customer's account, classify the dispute, collect documents, and open the right case | Case creation and status updates; provisional credit only through a separate rules service | Ambiguous facts, high value, repeated claims, or final liability decision |
| KYC refresh | Request missing documents, extract fields, compare records, and assemble a review package | Data collection and discrepancy flagging | Risk-rating change, rejection, or enhanced due diligence decision |
| Loan application support | Check completeness, extract document data, calculate policy inputs, and prepare an underwriting summary | Preparation and routing; keep the language model outside final credit decisioning | Approval, denial, pricing exception, or adverse-action reason |
| Collections and servicing outreach | Explain the current balance, capture a promise to pay, and schedule an approved arrangement | Offers must come from an eligibility and terms service | Hardship, dispute, custom terms, or any indication of vulnerability |
| Payment exception handling | Diagnose formatting or routing failures, collect corrected data, and retry within limits | Idempotent retries under value, count, and destination caps | Changed beneficiary, unusual destination, repeated failure, or limit breach |
| Employee operations | Retrieve policy, summarize cases, draft reports, and recommend next actions | Read-only by default; approved case-management writes | Policy interpretation, regulated filing, customer-impacting decision, or unresolved source conflict |
These boundaries are more important than the model choice. A highly capable model connected to unrestricted payment and account APIs creates a larger failure surface. A narrower agent with typed tools and enforced limits can still finish valuable work.
Why customer conversations are a strong starting point
Service, fraud verification, dispute intake, collections, and KYC follow-up all contain conversation plus coordination. The agent needs to understand free-form language, retrieve current data, call one or more tools, explain the outcome, and transfer the exception with context.
Voice adds production constraints that text pilots can hide. The agent has to handle interruptions, silence, background noise, ambiguous confirmations, telephony failures, and live handoffs. Latency changes whether the caller interrupts or abandons the call. A production contact center AI workflow therefore needs turn-level traces and call outcome evaluation in addition to ordinary API monitoring.
Where agents are the wrong tool
Use a simpler or more specialized system when it fits the job:
- Stable deterministic process: Use a workflow engine or RPA for a fixed sequence with well-defined inputs.
- Structured prediction: Use a validated statistical or machine-learning model for fraud probability, credit risk, or forecasting.
- Irreversible regulated decision: Keep a person or approved decision service accountable for credit denial, account closure, regulatory filing, and comparable actions.
- Broken upstream process: Fix missing ownership, contradictory policy, poor data quality, and absent APIs before adding an agent.
- One-step lookup: Retrieval or a conventional application endpoint is easier to test and operate.
The first design decision should be whether the workflow needs reasoning and tool orchestration at all.
Set authority before prompts
Give every agent and tool an authority tier. This prevents a broad instruction such as "resolve the customer's problem" from silently becoming permission to change a balance or account status.
| Tier | Agent authority | Banking example |
|---|---|---|
| 0: Observe | Read approved data and explain it | Transaction status or policy lookup |
| 1: Prepare | Draft a response, case, or recommendation | Underwriting summary for review |
| 2: Reversible action | Make a low-impact change that can be undone | Schedule an appointment or create a dispute case |
| 3: Bounded transaction | Execute through deterministic limits and preconditions | Retry a failed payment to the same verified destination under a cap |
| 4: High-consequence decision | Require human or approved decision-service authorization | Deny credit, close an account, or file a regulatory report |
Authority belongs in the tool gateway and policy engine, outside the prompt. Each operation should have a typed schema, a named owner, least-privilege credentials, value and rate limits, identity preconditions, and an idempotency key. The language model can request an action. The control layer decides whether it is allowed.
This model also protects the explanation path. The US Consumer Financial Protection Bureau states that creditors using complex algorithms still need to give applicants specific and accurate reasons for adverse action. Model opacity does not remove the obligation under the Equal Credit Opportunity Act and Regulation B, according to CFPB guidance. In the EU, systems used to evaluate a natural person's creditworthiness or establish a credit score are listed as high-risk, subject to the exceptions in the EU AI Act. A fluent generated explanation cannot substitute for the actual validated decision reason.
A production architecture for banking AI agents
A banking agent needs more than a model and a collection of tools. A durable stack separates conversation, reasoning, policy, execution, and evidence.
- Channel layer: Receives voice, chat, email, documents, or internal events. It handles session state, customer disclosures, recording controls, and channel-specific failure modes.
- Identity and context gateway: Authenticates the person or service, resolves the account and role, and returns only the data required for the current task.
- Agent runtime: Manages the goal, state, model calls, retrieval, retries, timeouts, and handoffs. The runtime must support durable execution so a network failure does not lose or repeat work. See the deeper AI agent runtime design guide for execution patterns.
- Policy and authorization service: Evaluates each requested tool call against identity, jurisdiction, workflow state, authority tier, amount, destination, and approval requirements.
- Tool gateway: Exposes narrow operations such as get_transaction, create_dispute, or schedule_payment. It validates schemas, enforces idempotency, redacts logs, and blocks unapproved endpoints.
- Human review queue: Presents the source evidence, proposed action, decision reason, conversation history, and exact point of uncertainty. Reviewers need controls to approve, edit, reject, or take over.
- Evidence and operations layer: Stores versioned prompts, policy decisions, retrieved sources, tool inputs and outputs, model versions, approvals, and final outcomes. It supports replay, incident review, evaluation, and rollback.
Treat vendor controls as part of the same system. US bank regulators' interagency guidance frames third-party risk management across planning, due diligence and selection, contracting, ongoing monitoring, and termination. For an agent platform, that means understanding data flows, subcontractors, access controls, incident handling, operational resilience, model changes, export paths, and exit plans before production traffic arrives.
Voice deployments need one additional legal control. The Federal Communications Commission has ruled that AI-generated voices count as artificial voices under the Telephone Consumer Protection Act. US outbound programs should apply the relevant consent and calling restrictions to AI-generated calls, as set out in the FCC ruling.
How to take one banking agent into production
1. Write the operating contract
Define the eligible customer and case, required identity level, allowed data, permitted actions, transaction limits, escalation triggers, completion state, and accountable owner. If any of those are ambiguous, the workflow is not ready for autonomous execution.
2. Start in read-only and shadow modes
Let the agent assemble context and propose actions while the current process remains authoritative. Compare its recommendations, evidence, and escalation choices with actual outcomes. Read-only operation exposes retrieval and reasoning gaps without creating customer harm.
3. Build an evaluation set from real workflow history
Cover routine cases and the failures that production will produce:
- identity mismatch or attempted social engineering
- contradictory records and stale policy documents
- prompt injection inside a document, email, or customer message
- unavailable tools, partial writes, timeouts, and delayed callbacks
- duplicate requests and retries
- amount, destination, or jurisdiction limit breaches
- vulnerable customers and required human handoff
- model refusal, unsupported claim, and fabricated tool result
- accent, noise, interruption, and silence for voice calls
Score the final outcome and every material action. A plausible conversation with the wrong account change is a failed run.
4. Add one write action at a time
Move from observation to case creation, then to reversible updates, then to bounded transactions. Keep each new permission behind a feature flag and a policy check. Use a small traffic canary, automatic rollback, and a manual kill switch.
5. Measure control quality and business value together
Track:
- correct completion rate across eligible cases
- incorrect or unauthorized action rate
- human escalation rate and whether escalation was timely
- duplicate write, retry, timeout, and tool failure rates
- identity and policy-control failures
- voice latency, interruption recovery, transfer success, and abandonment
- customer repeat contact and complaint rate
- human minutes and cost per correctly resolved case
- outcome differences across relevant customer groups
Containment or deflection alone can reward an agent for keeping a customer away from a person even when the case is going badly. Pair efficiency metrics with correctness, safety, and customer outcome measures.
The practical deployment rule
Banking agents should be autonomous inside a small, explicit envelope. Give them enough context and tools to finish routine work, then enforce identity, policy, and transaction boundaries outside the model. Keep final authority for high-consequence decisions in validated services and accountable human roles.
If your first workflow runs over the phone, start with Dasha. Build one end-to-end call that authenticates the customer, uses a bank-owned tool, records the result, and transfers the exception with full context.