A bank running fraud detection, credit decisioning, and dispute resolution today is probably running three AI models. It is also probably running three models that have never exchanged a single piece of context. The fraud model does not know that the credit model flagged the same account last week. The dispute agent rebuilds a case file that the fraud system has already assembled. Each model is accurate on its own. But when the decisions depend on context from other systems, accuracy in isolation does not always produce an accurate outcome.
That gap comes from how the models work together or fail to do so. Banking decisions rarely remain within a single system, so intelligence cannot remain within a single model. This is why the conversation inside banking is moving from model capability to system design. Intelligence is moving from the model to the system that connects the models.
EY-Parthenon's 2025 Generative AI in Banking survey, covering 100 retail and commercial banking institutions, found that 77% had launched or soft-launched generative AI applications, up from 61% in 2023. Sixty-one percent already reported a substantial impact from those deployments. Banks are clearly moving from experimentation to use.
Yet adoption has not solved the larger problem. Only 16% of generative AI use cases that banks develop reach full deployment, and 40% of those that do reach production fail to meet expectations. The issue is increasingly about the gap between AI capabilities and the decisions banks need to make. Models that perform well in isolation do not always produce decisions that hold up across a sequence of connected steps.
The reason becomes clearer when we look at how banking decisions actually work. A model answers one question within a single context window. Banking decisions rarely arrive as one question.
Onboarding a corporate client touches identity verification, sanctions screening, beneficial ownership tracing, credit assessment, pricing, and product fit. Each sits in a different system, with its own data shape and its own owner. A model dropped into any single step can improve that step, but it inherits every broken handoff around it. The context assembled at screening is discarded before credit assessment begins. The judgment applied at pricing has no visibility into what the risk assessment weighed.
The numbers reflect this fragmented reality. EY found that only 28% of the automation use cases that banks are currently developing or have in production use generative or agentic AI at all. The rest remains traditional machine learning and robotic process automation (RPA). That means most banking automation still operates within individual tasks and systems, even when the decision itself crosses several of them.
The problem, then, is not simply getting more AI into each step. It is about connecting the steps so that the intelligence created in one informs the next.
Multi-agent design addresses that gap by moving the unit of intelligence from the model to the system around it. Specialized agents each own a defined task. An orchestration layer holds context across the lifecycle and coordinates handoffs between them.
That changes three things.
These changes have one thing in common. They depend on the surrounding architecture, not on the models themselves. A more capable model, placed within the same fragmented process, still produces a decision assembled from disconnected inferences.
This becomes clearer in a real banking workflow. In an orchestrated design, an application arriving at a commercial lending desk is worked by a coordinated set of agents rather than a queue of systems.
An intake agent extracts and structures the submitted financials and legal documents. An enrichment agent verifies entity details against registries and bureau data resolving discrepancies. A risk agent evaluates exposure against the institution's own historical performance for comparable borrowers. A policy agent checks the emerging recommendation against the credit policy and applicable regulations before it reaches a human. A monitoring agent watches the relationship after drawdown and surfaces deterioration against the assumptions on which the original decision was built.
The difference from a model-per-step design is that these agents share state. The policy agent does not re-read the file. It tests a recommendation whose reasoning is already visible in the case. Each step builds on the one before it, so the system carries the decision forward instead of rebuilding it at every handoff.
That distinction also explains why many agentic AI projects will struggle. The technology can connect tasks, but simply calling something an agent does not create a working system.
Gartner, polling more than 3,400 institutions actively investing in the technology, predicts that over 40% of agentic AI projects will be canceled by the end of 2027. The reasons it names are escalating costs, unclear business value, and inadequate risk controls. None of those three describes a limitation of the models. Gartner also flags widespread agent washing, where existing assistants and chatbots are rebranded as agents without meaningful autonomy.
For banks, the system has to meet an even higher bar because the decisions carry regulatory and financial consequences. Among larger institutions, EY found that 71% cited regulatory compliance as a barrier to agentic adoption, and 67% cited data privacy as a barrier. 79% said that if they were restarting their generative AI program, improving governance would be the first thing they would change, ranking it above all other factors.
An autonomous decision in banking must be explainable to a regulator, attributable to a policy, and reversible. Those requirements must be designed into the orchestration layer from the start. This is where generic automation applied without domain knowledge tends to break.
Opus Technologies builds agentic orchestration around the specifics of the lifecycle it operates in rather than around a general automation pattern.
Intelligent Dispute Management is one worked example. Rather than adding another layer of automation to dispute handling, it coordinates a pool of specialized agents across the lifecycle: intake and classification, evidence aggregation, decisioning and prioritization, representment and documentation, SLA and compliance monitoring, and a learning agent that improves decisioning based on realized outcomes. The orchestration holds context that would otherwise be lost between intake and representment, and it keeps every submission aligned to network rules and timelines.
The distinction that matters is domain-native engineering. Knowing what the data means, where the edge cases lie, and which decisions can safely run unattended determines whether an agentic design survives contact with production.
The measure of banking intelligence is therefore changing. For most of the past decade, the question was how many models an institution had in production and how accurate they were. That question is becoming less useful as more models become capable.
The more important question is how many decisions are made end-to-end without human assembly, and whether the institution can provide evidence for why each one was made. Answering that requires more than capable models. It requires a system that carries context, coordinates decisions, records provenance, and knows when to involve a human.
The fraud model, the credit model, and the dispute agent were each doing their job all along. The system connecting them was the missing piece.