So you're about to build AI agents in-house. Price the second year first.

The pitch lands in every community bank inbox now: build your own AI agent in an afternoon, point it at your loan files, and stop paying a vendor to do it. The demo is real. A product manager wires a language model to a few documents and it answers questions on stage. What the demo skips is the second year, when the model provider ships a breaking change, an examiner asks how the thing makes decisions, and the person who built it has moved to another job.

The gap between the demo and the second year is where most of this work dies. S&P Global Market Intelligence found that 42 percent of businesses scrapped most of their AI initiatives in 2025, up from 17 percent a year earlier, and that companies killed close to half of their AI proof-of-concepts before anything reached production. That is a maintenance and ownership failure more than a technical one, and a bank with a generalist IT team is more exposed to it than a company with a machine-learning group.

Price your second year with someone who has no stake in which way you decide

Build vs buy AI agents: what the decision actually turns on

Two variables decide it, and neither is the sticker price. The first is whether the workflow is yours. A process shaped by your own credit policy, your own exception rules, and your own core setup is a candidate to build, because no vendor will model it exactly. A process that looks the same at every bank, fraud alerts, address changes, statement questions, is a candidate to buy, because a vendor spreads the upkeep across hundreds of clients and you cannot. The second variable is who owns the agent in year two. An AI agent is a system that drifts: the model provider ships changes, your policies move, and someone has to test and correct it every quarter. Build only where the workflow is genuinely yours and you have named that owner. Buy or wait everywhere else. For a small bank, the default leans toward buy.

Scale does not rescue the math. Community banks earned $6.4 billion in net income in the second quarter of 2024 as a group, on a net interest margin of 3.30 percent, according to the FDIC. That is a healthy sector, but the profit sits across thousands of institutions, each running lean. A single community bank does not have a machine-learning team, and it does not have the transaction volume to spread the cost of maintaining one over enough activity. That is the structural reason the build case is narrow, not a knock on any bank's ambition.

Read the table by row, not by column. No bank should pick one path for everything. The common mistake is treating build vs buy as a philosophy, where a board decides the bank is a builder or a buyer and applies it across the board. The processes do not care about the philosophy. A single bank will rationally build one agent, buy three, and wait on two, and the ledger that says which is which is worth more than any platform decision.

The buy option is mostly your core provider

For a community bank, buy has a specific meaning the AI vendors gloss over. Three companies, Fiserv, Jack Henry, and FIS, run the core systems at more than 70 percent of banks, with Fiserv alone at 42 percent, Jack Henry at 21 percent, and FIS at 9 percent, according to the Federal Reserve Bank of Kansas City. Your fraud scoring, your statement questions, your address changes: the agent that touches those already lives inside the core, or it is on the core provider's roadmap. Buying a bolt-on that duplicates what your core will ship next year is how a bank ends up paying twice. Before you sign a point solution, ask your core provider what is shipping and when. Sometimes the right move is to wait one release cycle.

The trap: the demo that no one can maintain

The AI win that turns into a liability looks like this. A bright analyst builds an agent that drafts adverse-action notices or summarizes a loan file. It works. It saves real hours for two quarters. Then the model provider deprecates the version it was built on, the analyst leaves, and the notice it drafts is now subtly wrong in a way no one catches until an examiner does. The build was never the hard part. The quarter-after-quarter ownership was, and that cost does not show up in the demo. Community bankers already feel this: in the 2024 CSBS Annual Survey of Community Banks, they ranked technology implementation and costs among their top three internal risks, alongside cybersecurity and liquidity. A tool you cannot maintain only looks cheaper than a subscription. The bill arrives later, and larger.

How we would run the decision

We do not start from a tool. We start by mapping one operating week and marking every task where a person moves information from one screen to another with no judgment added. That map almost always shows three or four rooms where the same task repeats: the exception queue, the document rekeying, the status-update phone tag, the report that gets rebuilt by hand every Monday. Then we run the build, buy, or wait test on each room, not on the bank as a whole. The output is a one-page ledger: which workflow is yours to build, which to buy now, which to leave on the core provider's roadmap, and who owns each one in year two. An operator walks away knowing exactly where an agent pays for itself and where it becomes a second job. For where the money actually hides in a small bank's back office, we went room by room through the cost stack, and the same sequencing logic drives which part of a process to automate first. If you want the shape of that first working session, it is on the how it works page.

The honest answer to build vs buy AI agents is not a rule, it is a short list: the one or two workflows in your bank that are yours to build, and the dozen that are not. Which of your workflows is actually unique to your bank, and which just feels that way because you have always run it by hand?