Between July and October 2026 we recorded 19 discovery and scoping conversations about putting AI agents to work, 15 of them with banks and credit unions, from community banks to large ones. We went back through the transcripts looking for what actually decided whether a project moved. It was almost never the technology. It was where the rules live, who owns them, whether anyone could show an examiner what an agent did, and whether the bank had room on its calendar. Here are the five patterns that came up most, in the words people used, and what we're changing because of them.
Who we talked to, and how to read this
The people on these calls were heads of IT and data, operations and lending leaders, a chief credit officer who used to be a regulator, CISOs, risk and compliance executives, enterprise architects and AI program leads. Four of the 19 conversations were outside banking: a wealth platform, a securities finance firm, a healthcare billing company and a manufacturer.
We don't name institutions or people, and every quote here is anonymized. The counts are approximate: we counted a theme once per conversation when the prospect raised it. Nineteen conversations is not a market survey. It is enough to see where the same sentence keeps coming back.
Pattern 1: the rules are scattered before any agent reads them
The first thing almost every bank described, usually before we asked, was the state of its own rules. Not missing, exactly. Spread out, duplicated and out of date in places nobody had looked at for a while.
A head of IT and data at a community bank put it simply: "It's not just one giant document, it's like multiple giant documents." A risk executive at another bank told us their roughly 300 policies and procedures had mostly sat in people's folders, not in a central place, and that they were partway through moving them into a template. An executive at a credit union described the maintenance problem: when one document changes, nobody checks the others, because the comparison is done by hand in a word processor.
None of this is unusual, and none of it stopped these banks from operating. Experienced people know which document wins. The problem shows up when an agent arrives, because an agent reads what it is given. Two documents with two different thresholds become two possible decisions, and the agent picks one on each run. We wrote about that failure in the thesis post for this series.
What it means for an agent project: before you can automate a process, someone has to decide which version of each rule is the real one. That work belongs at the start of the project, and the person who decides should be the one accountable for the process.
Pattern 2: the same job, done differently by every person
The second pattern is the human version of the first. Where the documents disagree, the people fill the gap, and each one fills it a little differently.
The credit union executive who described the document problem also described the result: ten people in one department doing the same job, each a different way, and "everybody thinks they're right. So who's wrong?" A chief credit officer told us his bank had never had formal guidance for the people in the branches making first-line decisions. An operations leader at a bank gave us a number for it: at least half of the requests their team received had to be kicked back, because the request was missing something or followed the wrong steps.
This is the pattern that makes banks both keen on agents and wary of them. Keen, because an agent would apply one way of working to every case. Wary, because nobody is sure which of the ten ways it should be.
What it means for an agent project: the variation across people is not noise to average out. It is a set of decisions the bank hasn't made yet. Surface them, have the owner choose, and the agent gets one way of working that someone actually approved.
Pattern 3: everyone has an assistant, nobody governs the decisions
By late 2026, most of the banks we spoke to had rolled out a general-purpose AI assistant to staff, and several had internal search tools over their policies. Nobody described a problem getting access to models. What they described was a gap between what those tools do and what an agent making decisions would need.
The head of IT and data quoted above said it in one line: there's nothing on the governing side, so how do you know if this agent is making the right decision? "You know, you don't." A technology lead at another bank worried about the agent that does exactly what it was asked, but not the way anyone meant. An operations executive at a bank told us they didn't think they had anybody internally who could make sure an agent would return the same information every time.
Security came up in about 8 of the 19 conversations, usually early: where the data sits, who can see it, which certifications the vendor holds, and whether the regulator had seen anything like this. A CISO at a community bank told us that regulators ask about every fintech the bank signs with, and the bank needs to be able to give its blessing.
What it means for an agent project: access to a capable model is solved. The open questions are consistency, control and evidence, and they need answers before the pilot, not after it.
Pattern 4: what really stalls a project
The most common reason a promising conversation stalled had nothing to do with the product. In about 11 of the 19 conversations, the prospect raised timing, bandwidth or competing priorities.
Core conversions came up again and again. A credit union executive told us their CEO wouldn't pay for any integration into the core during a conversion, so anything new had to lay over what they were already doing. An IT leader at a bank said they had no KPIs set yet and would revisit strategy in January. An enterprise architect worried about the opposite failure: building a proof of concept that the process owner then refuses. Others told us, kindly, that they would rather not be first.
None of that is resistance to agents. It is what a bank's calendar looks like. A small IT team, a core conversion, an examination cycle and a board that wants to see someone else do it first leave very little room for a new project that needs integration work.
What it means for an agent project: the projects that moved needed no core integration to start, asked very little of IT, and had a business owner who wanted them.
Pattern 5: the first agents that moved were internal, low on customer data, and owned
The use cases that made progress in these conversations had three things in common. They were internal processes with little or no customer data. They had a named owner with a number they wanted to improve. And they could be tested without touching the core.
Vendor due diligence was the clearest example. A technology lead at one bank described documents that take weeks, months, sometimes years to come back, and said frankly that nobody likes to read through SOC reports. Account-maintenance intake was another: the bank with the "at least half kicked back" number chose it precisely because the rework was measurable. A chief credit officer pushed for annual credit review, which his team was behind on, and described the gap between his current process and what he wanted with a memorable image: horse and buggy, and he wanted SpaceX.
Then there was the idea we liked most, because it came from the customer. A CISO at a community bank proposed running the agent in parallel with the existing process on every loan, and comparing the results before anyone relied on it. That is a better pilot design than most vendors propose, and it answers the trust question with evidence instead of a promise.
What it means for an agent project: start where the data risk is low, the owner is motivated and the result can be measured, then expand into the processes that carry more risk.
The five patterns at a glance
| Pattern | In their words | What it means for an agent |
|---|---|---|
| Rules are scattered | "Multiple giant documents" | Decide which version of each rule is real, before the build |
| Same job, different ways | "Everybody thinks they're right. So who's wrong?" | The variation is a set of unmade decisions; the owner makes them |
| Nobody governs the decisions | "How do you know if this agent is making the right decision? You don't." | Consistency, control and evidence come before the pilot |
| What stalls is the calendar | "It has to just lay over what we're currently doing" | Start with no core integration and little IT time |
| What moves is internal and owned | "Nobody likes to read through SOC reports" | Low customer data, a named owner, a measurable number |
What we got wrong, and what we're changing
Field notes are more useful if they include our own mistakes, so here are three.
We led with the hardest process. Our early demos were commercial lending, because it is where the money is. An AI program lead at a bank told us flatly that rigid, deterministic code won't let you succeed in mid-market commercial banking, where the edge is making a deal work that wouldn't on a grid. He was right about the risk, and we hadn't framed our answer well. Determinism belongs where the bank chooses, with judgment points owned by named people, and every exception recorded as a decision. We now start with the internal processes in pattern 5 and talk about commercial lending later.
We under-answered the technical buyers. Business owners understood the idea quickly. Architects and AI leads wanted specifics: how the rules sit beside the agent platforms they already run, whether rule sets can be reused across workflows as building blocks, and how much faster this is than the interviews a business analyst would run. One AI lead told us three vendors had claimed to do this before, and none had been faster than eight to ten weeks of interviews. Those are fair questions, and they deserve written answers, not a promise to follow up.
We didn't make it easy to share. More than one person asked for something they could send to colleagues: a short demo link, a page for their use case, a security summary. One told us our website didn't do justice to what we do. We have been rebuilding the website, and this blog is part of the answer.
What we're changing in how we work: we now start with one internal process that needs no core integration, design the pilot as a parallel run against the current process, and bring compliance and information security into the second conversation instead of the last one.
What to do on Monday
If you run operations or lead AI at a bank, you can test these patterns against your own institution in an afternoon.
- Pick one internal process with a backlog. Vendor due diligence, account-maintenance intake and annual credit review are good candidates. Write down its owner and the one number they would like to change.
- Count the documents that define it. Then ask two people who do the work how they handle the same tricky case. If the answers differ, you have found a pattern-2 decision nobody has made.
- Check what's on the calendar. If a core conversion or an exam is coming, choose a process that can run beside your systems without integration.
- Ask the governance question now. If an agent did this work for a month, how would you show your examiner which rule it applied to a given case?
- Design the pilot as a parallel run. Run the agent alongside the current process on real cases and compare the results before anything depends on it.
Where Factify fits
The patterns above are the reason Factify works the way it does.
Rulebook Studio pulls the rules for a process out of your policy, procedures, regulation and tribal knowledge, and flags every conflict and contradiction: the scattered rules of pattern 1 and the unmade decisions of pattern 2. The domain owner reconciles them and seals one versioned truth.
The Sealed Truth becomes an Executable Factified Rulebook that agents use as tools, through MCP or API, alongside the systems you already run. Nothing leaves a step unless it matches, and judges step in at owner-defined points or when a case isn't covered.
Every case is recorded in the Ledger with the Rulebook version it ran on, which is what a parallel run compares and what an examiner asks to see.
Have a process with a backlog? Bring one process and we'll map its rules with you.
Book a sessionFrequently asked questions
How are banks using AI agents in 2026?
In the conversations we recorded, most banks had general-purpose AI assistants in use and were piloting agents on internal processes such as vendor due diligence, request intake and credit review. Few had agents making customer-facing decisions in production.
What stops banks from putting AI agents into production?
Mostly not the technology. The common blockers were scattered and conflicting rules, no clear way to show which rule an agent applied, security and vendor reviews, and limited IT capacity during core conversions.
What is a good first use case for an AI agent at a bank?
An internal process with little customer data, a named owner with a measurable backlog, and no need for core integration. Vendor due diligence and account-maintenance intake are common examples.
How should a bank pilot an AI agent?
Run it in parallel with the current process on real cases, compare the results, and bring compliance and information security in early. Rely on the agent only after the comparison holds.
Do AI agents work for judgment-heavy banking work like commercial lending?
They can help, but the bank should decide where rules are applied strictly and where a named person decides. Starting with internal, rules-heavy processes builds the evidence before moving into judgment-heavy work.