Agentic AI in Banking: What It Is and How It Works

Roughly 59% of banks have lifecycle risk monitoring in place for generative AI. Only 44% have it for agentic AI, according to Deloitte's 2026 banking trust analysis. That gap between watching a model answer and watching a system act is the most expensive blind spot in bank technology right now.

An agent that drafts a reply is a productivity tool. An agent that writes to the CRM, prices an exception, or initiates a payment is an operating risk with a customer attached. Banks have approved the second kind faster than they've built the ability to explain what it did.

The pages that follow are a direct read of where agentic AI in banking stands, what the deployment numbers reveal, and what a board should demand before granting an agent anything beyond read access. The finding is uncomfortable. Capability isn't the constraint. Post-deployment assurance is.

What Agentic AI Means in Banking

The Bank of England and Financial Conduct Authority's 2024 survey of AI in UK financial services recorded 75% of nearly 120 firms already using some form of AI, another 10% planning adoption within three years, 55% of reported use cases involving some form of autonomous decision-making, and just 2% classified as fully autonomous. Two years earlier, 58% had reported current use and 14% planned adoption. Adoption is settled. The depth of it is not.

Agentic AI is the part of that adoption where software pursues a stated goal by calling tools, learning from feedback and adapting to changing conditions. A credit scoring model scores an application and stops. An agent reads the application, pulls peer benchmarks, tests the request against credit policy, drafts the memo and holds it for signature. What separates the two is how many steps the system completes before a person touches the work.

The spectrum from assisted to autonomous

Those last two survey figures describe the spectrum more clearly than most vendor taxonomies. A majority of reported use cases already let software take part of a decision, yet almost nothing ran end to end on its own. Broad deployment, partial autonomy, minimal independent action.

That middle band is where agentic AI in banking will live for several years, and it is the hardest band to govern. A fully manual process has clear owners. A fully autonomous one can be tested as a unit. A partially autonomous workflow splits each task between software and staff, and every split is a point where the record of who decided what can go thin. The survey can count how many firms deployed agents. It cannot show what a given agent did on a Tuesday afternoon, which rule it applied, or who approved the outcome. That evidence has to be built into the deployment itself.

Practical rule: If an agent can finish a task without a person, the board needs to know what the agent can reach, why it acted and who signed off.

For commercial and relationship teams, the near-term value sits in the middle of the spectrum: agents that reconcile filings, peer benchmarks and relationship history, then surface an alert or a prepared action for a banker to approve. The banker keeps the decision. The agent absorbs the research time.

An agent the bank can explain is infrastructure. One it cannot explain is an unaudited liability with write access.

How an Agent Moves From Trigger to Action

The closest analogy is the best assistant a commercial relationship manager ever had. They read the entire file before a call, know the pricing authority without asking, draft the follow-up note, and leave it on the desk for signature. They never send anything on their own.

An agent does that same work against live systems, which changes the stakes. Reading a file is harmless. Writing to the core system is not. That's why the sequence matters more than the model.

The loop below is what separates a controlled workflow from a demo that impressed the steering committee.

The six-step loop

1. Perceive a trigger. A balance crosses a threshold, a covenant line moves, a peer ratio shifts beyond tolerance. The trigger should be a defined event, not a sentence someone types into a box.
2. Gather evidence. Approved sources only: call report data, UBPR ratios, CRM history, prior correspondence. An agent allowed to browse freely is an agent that can be manipulated.
3. Plan the sequence. The agent selects which tools to call and in what order. Conventional model validation misses this step entirely, because the plan is generated at runtime.
4. Call tools inside permissions. Read access by default. Write access is a separate grant tied to a named approver and a named action.
5. Check and escalate. When two sources conflict, or confidence falls below the floor, the agent stops and hands the conflict to a person instead of guessing.
6. Act or hand off, and log. Every prompt, retrieved document, tool call, output and override lands in an append-only record a reviewer can replay.

A worked example

Say a commercial client's deposits fall 18% over six weeks. The agent confirms the drop against account history, separating a single treasury sweep from a broad outflow. It checks the banker's pricing authority, drafts a retention offer inside that authority, and routes it for approval. It doesn't email the client. It doesn't move funds.

Compare that with a chatbot that answers "what's our deposit pricing?" The chatbot produces text and stops. The agent completes a workflow across three systems and leaves a decision record behind. Only one of those two things needs a control framework, and it isn't the chatbot.

The one-page test

Can you draw every step of that workflow, the tool it uses, the log entry it writes and the person who approves it on a single page? If not, you have a prototype rather than a controlled process. Teams that map it for the first time usually find the weak point sits at step four, where permissions were granted for a pilot and never revisited.

Sketching it as a workflow diagram forces those handoffs into view before anything gets automated.

Where Agents Already Work in Banking

Agents aren't arriving as general-purpose bankers. They're arriving as narrow workflow engines, and the approval gate determines how much risk each one carries.

Workflow	What the agent does	Human approval gate
Financial-crime monitoring	Flags unusual activity and assembles the case file	Investigator approves any account action or report
Customer-support assistance	Retrieves account context and drafts replies	Staff approve every external message
Internal process optimization	Routes tasks and reconciles workflow steps	Process owner approves changed routing rules
Commercial deposit retention	Spots an outflow, checks history and pricing authority, drafts an offer	Banker approves the offer before outreach
Credit package preparation	Gathers borrower financials and compares them with peers	Authorized officer approves pricing and commitment
Relationship outreach	Identifies decision-makers and drafts outreach	Relationship manager approves before any CRM write or contact

Read the table by proximity to money

The pattern is simple and it should drive sequencing. Rows near the top touch records, drafts and routing, where a mistake produces a bad file or an awkward reply and the cost is measured in minutes. Rows near the bottom touch credit and customer relationships, where a mistake produces a commitment the bank has to honor.

The Bank of England's 2025 Financial Stability in Focus report on AI in the financial system names internal-process optimization, customer support and financial-crime prevention as the leading near-term applications in UK financial services. Those are precisely the workflows where an agent coordinates several steps rather than generating a paragraph, which is also why they're the ones where the action log matters most.

Take the credit row. An agent can gather borrower financials, compare a prospect against peer benchmarks, calculate policy-based exceptions and assemble the package. Pricing and commitment stay with an authorized officer, because those are the two decisions a bank can't easily reverse.

Start with the rows where the agent only reads and recommends. A bad draft is a coaching moment. A bad transaction is an incident.

The input problem comes first

An agent is only as reliable as what it reads. If a peer benchmark is stale, a ratio is built from mismatched entities, or a filing version is wrong, the recommendation inherits every one of those errors and presents them with more confidence than a human analyst would.

Visbanking unifies public and proprietary sources into a consistent model with entity resolution, quality checks and version control, so an agent pulling a peer ratio is reading a resolved institution with a version behind it. That's the difference between a defensible recommendation and a plausible one.

Benefits and Risks Executives Should Weigh

Every agent proposal arrives with two documents stapled together, a benefit estimate and a permission request. They're rarely priced against each other.

Where the benefit sits

Set the gains plainly. Faster decisions, because evidence gathering stops consuming the first two days of every review. More capacity from the relationship team, because research time goes back into client conversations. Fewer missed exceptions, because the agent checks the whole book nightly rather than the accounts a banker happens to remember. More consistent policy application, because the same threshold triggers the same escalation whoever is on duty.

Those gains are real and measurable. They're also lopsided, which is why the permission conversation usually runs ahead of the benefit conversation.

The four axes below are the ones worth arguing about in committee, and they don't carry equal weight.

Where the exposure sits

An erroneous recommendation doesn't stay a recommendation. It becomes a sequence of consequential actions, each internally consistent with the last, which makes the error harder to catch on review. A prompt injection buried in an external document can redirect an agent that reads it. A hallucinated instruction or a compromised tool can trigger an action the bank never approved. A session that began legitimately can keep permissions after the task has changed.

Exposure scales with permission, not with model quality. A mediocre model with read access is an annoyance. An excellent model with payment initiation is a liability.

That's the argument for splitting the approval. Signing off on an agent's accuracy and signing off on its action scope are separate votes, and they belong to different people.

A useful discipline is to tier the use case before the demo runs. Read-only retrieval needs logging. Recommendation needs provenance and a confidence score. Bounded execution needs thresholds, dual approval and rollback. Anything above that needs a business justification most banks can't write yet.

The executive question is narrow and answerable. Which benefit justifies which level of permission, and who owns the outcome if the agent is wrong? A team that can't answer both halves isn't ready for write access, however well the demo performed.

Measuring Value and Keeping Someone Accountable

An agent's business case is subtraction. Cycle time removed, minus the cost of running the agent, minus the cost of the errors it introduces. Banks that measure only the first term approve projects that never pay for themselves.

Take a credit exception queue. If an agent cuts review from three days to four hours across a normal week's volume, a credit analyst gets back roughly 20 hours a week for structuring and client work. That's the figure that belongs in the approval memo, tracked monthly against the agent's operating cost and its exception rate.

Three numbers for the approval memo

Boards should approve each agent against three figures rather than a pilot narrative.

• Recovered capacity. Hours or dollars the workflow is expected to return, measured before and after, not estimated once at the kickoff.
• Tolerable error rate. The rate the business can absorb, set in advance and specific to the workflow. A missed outreach draft tolerates far more error than a pricing exception.
• Named owner. The executive who absorbs the loss if the agent is wrong, and who answers the examiner's first question.

Accountability comes before deployment, not after the first incident. Each agent needs an explanation the bank can give a customer or a supervisor, plus a decision record showing who approved each action and on what evidence.

The readiness numbers explain why that's harder than it sounds. In a 2026 survey of 148 financial institutions, Wolters Kluwer reports that only 31.8% had AI or machine learning in production and just 12.2% described their strategy as well defined and resourced. 28.4% named explainability and transparency as a leading regulatory concern, ahead of bias or discrimination, data privacy and fair lending, and regulatory guidance was the most requested enabler at 58.8%.

Those figures describe an industry waiting for supervisors to specify the rules before it scales. The practical substitute is an internal decision record strong enough to serve as the record, which is what an audit trail for agent actions has to deliver.

Controls That Keep Agents Within Bounds

Autonomy is a dial with four settings, and each setting carries its own control requirement and its own share of what banks run.

Autonomy level	Typical action	Control required	Share of reported AI use cases
Assisted, read-only	Retrieves and summarizes evidence	Read-only default and action logging	Part of the 45% of use cases with no autonomous decision-making
Recommendation	Proposes an action for a human to decide	Source provenance and confidence score	Part of the same 45%
Bounded autonomy	Executes low-stakes steps within set limits	Approval thresholds, dual approval and rollback	55% include some autonomous decision-making
Full autonomy	Acts without human approval	Rarely justified, requires independent validation	2%

Benchmarking of the largest banks now makes the permission gap visible. Most global and domestic systemically important banks permit agentic AI in production for selected use cases, yet only a minority operate a standardized monitoring and control framework that explicitly covers agents. Agents remain a small share of the AI portfolio at nearly all of them, and many still lack a centralized, tool-based inventory of what they have deployed.

Most of the largest banks let agents act. Far fewer can produce a standard record of what the agent did, which tool it called and who authorized the step.

The control checklist

Conventional model-risk governance covers accuracy. Agents add failure modes accuracy testing never touches: tool selection, delegated permissions, multi-step planning, escalation and termination. Each control below exists to answer one question after the fact: can the bank reconstruct this action, end to end, for a customer or an examiner?

1. A declared action scope. Read-only by default, with every write permission named, justified and time-bound. The scope document is the first artifact an auditor should be able to pull.
2. Approved tools and data domains. An allow list enforced at the tool layer, so permissions live in code and configuration, beyond the reach of a prompt the agent could be talked around.
3. Materiality and confidence thresholds. The agent escalates below a confidence floor or above a dollar limit, and the business sets those limits, never the model.
4. Human approval for external communications and credit recommendations. Nothing leaves the building and nothing prices risk without a named person attached.
5. Immutable records. Prompts, retrieved evidence, tool calls, outputs and overrides, append-only and replayable, so any single action can be reconstructed in full.
6. Trajectory testing in production. Beyond answer quality: did the agent use the right sources, attempt an unauthorized action, exceed its data scope, or fail to escalate an ambiguous signal?

The first control is knowing the agents exist. With many institutions running no centralized inventory, the starting point is a register that records, for every agent, its owner, its permitted tools, its data domains and its action limits. A program that skips that step is governing a fleet it cannot count.

Test to run this quarter: Ask for the full log of one agent action from last week and time how long it takes to produce. If nobody can assemble it, the control framework is theoretical.

What supervisors have and haven't said

Supervisors drew a careful line. A U.S. Government Accountability Office review reports that FDIC, Federal Reserve and OCC model-risk guidance rests on sound development, attention to complexity and transparency, performance testing and independent validation (GAO review of AI use at the financial regulators). The same review records the Federal Reserve's position that generative and agentic models are novel and rapidly evolving and fall outside its existing supervisory guidance, which leaves each institution's own governance and risk management to set the controls.

That arrangement transfers responsibility to the institution, and directors should document their position before an examiner asks for it. The binding constraint on agentic AI in banking is assurance capacity. Model quality keeps improving on its own; the ability to evidence a single agent decision does not. That is the case for treating explainable AI in banking as an operating requirement, the kind an examiner or a customer can test, rather than a compliance checkbox.

Roll Out One Governed Agent and Confirm the Use Case

Choose the pilot by risk, not by enthusiasm. The first agent should be the one whose failure costs the least and teaches the most about your controls.

The sequence below keeps a single workflow in scope until its controls hold, then widens access on evidence.

1. Name one workflow and one owner. A pilot without an accountable executive can't be judged and can't be stopped, which is the worst combination available.
2. Set the action scope to read-only, with a named data list and no payment initiation or customer-record writes.
3. Give the agent its own identity and a tool-level allow list, so every action traces to a permission rather than to a shared service account.
4. Connect only evidence with provenance. Visbanking pulls its data directly from regulatory filings, including FDIC, NCUA and FFIEC filings, so a peer comparison inside an agent's output traces to a filing rather than to an aggregation step nobody can audit.
5. Test adversarially. Prompt injection, hallucination checks, replay tests for correct tool ordering, and a verified ability to interrupt or contain the agent mid-task.
6. Run shadow mode for 30 days, comparing agent recommendations with the team's decisions. The disagreements are the most useful output of the pilot.
7. Authorize sensitive actions at runtime. Evaluate identity, delegated authority, policy and risk threshold immediately before an action executes, then record the decision in a tamper-evident log.
8. Widen permissions on evidence, and only when error rates and exception handling meet thresholds the committee set before the pilot began.

Steps seven and eight carry the weight. Agentic systems need runtime authorization rather than one-time access approval, because their risk profile changes across a multi-step workflow. The control set that makes it workable isn't exotic: a unique identity per agent, tool-level allow lists, read-only default permissions, just-in-time elevation for sensitive operations, and an append-only audit trail across systems, as McKinsey's analysis of agentic controls in financial services sets out. Continuous authorization is what stops a legitimately opened session from retaining access after the task has moved on.

Three tests for the first use case

Apply all three before you write a project charter.

• Does it touch customer money or credit? If yes, it isn't a first pilot. It's a second-year program with a control history behind it.
• Can the exception be measured? If you can't count what a wrong recommendation would cost, you can't set a tolerable error rate, and you can't judge the pilot.
• Can an accountable human reverse the action? An action that can't be unwound needs more approval than one that can.

The best opening move is a read-and-recommend agent on peer benchmarking or commercial deposit retention, where a wrong output costs a draft rather than a dollar.

---

Visbanking's Bank Performance app lets you benchmark your institution against more than 4,600 peers before you scope a single agent, and Bank Intelligence, now in beta, surfaces the stress markers and early warnings an agent would need to read first. The team runs guided demos and pilots, and most customers are fully operational in a single afternoon. Visit Visbanking to see which of these workflows your own data can support today.