Should Community Banks Build AI Agents or Buy Them?

A community bank should compare four options for each workflow: configure existing software, buy a service, build a narrow extension or wait. Start with the work and the access it requires. Select the option that meets the requirements with support the bank can sustain; neither bank size nor a claim that the process is unique settles the decision.

Buying does not remove internal work. Building does not necessarily mean training a model or replacing a core. A bank can license infrastructure and retain its own workflow configuration, while a purchased product can still require considerable integration and review.

Sei AI’s build-or-license analysis usefully separates platform ownership from workflow design. Treat its commercial assumptions as a supplier perspective. Your comparison needs your scope, existing contracts, staff capacity and test results.

Compare proposals with the open AI vendor evaluation scorecard.

Describe what the agent may actually do

This is a proposed bank buying method, not a vendor ranking or a guaranteed cost model.

Write down the trigger, inputs, systems read, outputs and permitted changes. “Summarize a loan file for an analyst” is materially different from “update the loan record and notify the applicant.” Name each dependency: document store, loan-origination system, core, identity service, messaging and reporting. Identify which interfaces are supported in the bank’s exact version and contract.

Then ask whether the task needs an agent at all. A fixed checklist, scheduled report or deterministic rule may fit existing configuration. If documents need interpretation, extraction or summarization may be enough. Autonomous selection of tools and actions should earn its additional complexity through a demonstrated need.

Compare the work left with the bank

A distinctive credit policy is not proof that the entire platform must be custom. Ask a supplier to demonstrate the policy gap before treating it as unconfigurable. Equally, a familiar core-provider logo is not proof that a feature is available, included or adequate.

Use the same cost boundary for every proposal

Compare a chosen planning horizon using implementation plus recurring external charges, retained bank labor, change work and exit costs. State transaction volume, document size, usage and support assumptions. Include licensing, integration access, hosting or model usage, security review, testing, training and operating support where applicable.

Separate costs paid regardless of the decision from costs the option actually changes. Existing employees still have limited capacity, but their time is not automatically a new cash expense or a cash saving. If a proposal relies on moving people to other work, name that work and the manager who can make the change.

Request a low, expected and high usage case. Identify the fees triggered by extra documents, retries, long calls or additional environments. Compare change orders and renewal terms, not just the initial subscription. A purchased system with extensive custom connectors can have many of the same maintenance obligations as a build.

Rehearse a year-two change before signing

Ask the internal team and each supplier to walk through the same scenario: the bank changes a document requirement and an upstream interface changes its field format. Who identifies the impact, updates the workflow, revises the test set, approves release and supports a failure?

Require names or accountable roles on both sides. Request an example change record, the evidence retained before and after release, and the way the prior process can be restored. Have someone other than the original builder explain the recovery steps. If the explanation depends on one person’s memory, handover is incomplete.

The federal agencies’ community-bank third-party release describes risk management across the relationship. A vendor contract is therefore the beginning of an operating arrangement, not the end of bank oversight. The bank’s risk and compliance owners should determine the applicable review requirements for the actual use.

Model risk guidance will not settle the question for an agent. In April 2026 the OCC, the Federal Reserve and the FDIC replaced SR 11-7 with revised model risk management guidance that applies to community banks subject to its limitations, is expected to be most relevant to banking organizations with over $30 billion in total assets, and states that generative AI and agentic AI models are not within its scope. Do not assume a model validation program covers the agent; decide explicitly how the bank's third-party, information security and compliance reviews will test and monitor it.

Waiting needs evidence too

Ask the core provider for the proposed feature, supported version, release status, dependencies, pricing and a way to evaluate it. Distinguish a roadmap discussion from a generally available capability. Set a decision date and record what would make the bank stop waiting.

Include interim processing effort and any service or control problem in that decision. Waiting can be reasonable when the existing process is acceptable. It is less compelling when an unresolved bottleneck keeps growing and the roadmap has no reliable commitment.

End the comparison with the selected workflow, chosen delivery model, unresolved evidence, budget assumptions and named operational owner. Use the open supplier scorecard for proposal evidence and the finance operations overview to place the project in the bank’s priorities.