Same models, different moat: why your legacy is the AI advantage competitors can't copy

TL;DR

Chief AI Officers and CIOs at banks and insurers now run the same LLMs as every competitor, so the model itself can't set them apart. The advantage sits in what the model calls: decades of business data and the business logic that acts on it, two assets no rival can download. Both still live on the mainframe, and agents stall there, which helps explain why Deloitte finds only 11% of organizations run agentic AI in production. Teams that let agents read, run and update that data and logic under governance, one high-value process at a time, turn legacy into the moat.
Banks and insurers now have access to the same LLMs and the same agent frameworks as their rivals. So the AI advantage leadership keeps asking about has to come from somewhere else.
Below, we look at where a lasting advantage lives (your business data and your business logic), why agents stall before they reach it, and how to put both to work, one process at a time.

What is an enterprise AI moat?

Your board wants to know what makes your AI different from a competitor's. For most banks and insurers, the answer can't be the model, because any competitor can license the same LLMs you do.

McKinsey named the problem in its May 2026 article, From AI table stakes to AI advantage: Building competitive moats: "When everyone has access to the same AI models, the winners are those who use them to build advantages that competitors can't copy." Entrepreneur reached a similar view in July, noting that "the underlying models are rapidly compressing into commodities." So model choice still affects cost and quality, but it no longer sets one enterprise apart from the next.

A moat fills that gap. In plain terms:

An enterprise AI moat is a lasting AI advantage that competitors can't buy or copy. It comes from assets only your company holds, mainly decades of business data and the business logic that acts on it, available for AI agents to read, run and update under governance.

Rivals can match your model and your cloud provider in a matter of months. Yet they can't recreate thirty years of customer history, or the rules your teams refined through decades of rate changes and audits.

Those two assets explain why two companies running the same LLM can see very different results.

Why the same models produce different results

Give two insurers the same LLM and the same agent framework, and they can still get very different outcomes. The difference shows up in what each agent can see and do once it leaves the chat window.

Dennis Sevilla, CMO of ZoomInfo, made the point in his Entrepreneur piece with a simple test: "If two competing AI agents write equally clean copy to the same executive, the model cannot break the tie." The tie-breaker, he argues, sits in "the integrity of the data layer the agent calls." McKinsey lands in the same place, writing that "privileged data becomes a moat when AI models use it to deliver products and services that competitors can't."

For Chief AI Officers in banking and insurance, the takeaway is practical. Take two agents running on the same model. One quotes a renewal from last night's batch export, while the other reads the live policy, applies your current rating rules and writes the result back. Only the second one creates value a rival can't match.

So the strategic question moves from which model to pick toward what your agents can reach and act on. In most regulated enterprises, the answer involves two separate assets, and both matter.

Your moat has two halves: business data and business logic

Much of the AI moat conversation stops at data. For a bank or insurer, data covers only half of what makes your AI hard to copy.

The first half is your business data: decades of accounts, policies, claims and transactions. McKinsey describes the most valuable data sets as "cumulative and protected," and a large book of business fits that description. Each year adds history a new entrant can't buy, and regulation limits who can see it.

The second half is your business logic, the rules that decide what happens to that data. It covers how you price a renewal, when an underwriting exception applies, which claims go to a human reviewer and how your team resolves a payment dispute. Jon Knisley of ABBYY made a similar point in InformationWeek in September, writing that legacy systems hold "years of transaction history, edge-case handling and regulatory logic that no startup can synthesize."

The two halves create value together. Data without logic gives an agent facts with no rules for acting on them, and logic without data gives it rules with nothing to act on. An agent that reads both, runs your rules and writes the outcome back behaves like your company. A rival's agent on the same LLM, without either, behaves like everyone else's.

Sreenivas Vemulapalli of Bridgenext drew the conclusion in InformationWeek's 2026 enterprise AI predictions: "The true competitive advantage will belong to the enterprises that have meticulously documented, secured and exposed their proprietary business logic and systems as high-quality, agent-callable APIs." A competitor can buy similar data sets. Nobody can buy your data paired with thirty years of your own decisions.

For most banks and insurers, both halves sit in the same place: the mainframe.

Why your most valuable data and logic still run on the mainframe

Banks and insurers kept the mainframe for a practical reason: it handles very high transaction volumes under tight control. According to IBM, "more than two-thirds of the Fortune 100 continue to use the IBM zSystems family." In financial services the share runs even higher: nearly all of the world's top 50 banks rely on the platform, and so do the top 10 insurers.

Both halves of the moat live there. The records sit in VSAM files and in IMS or DB2 databases, often decades deep. The rules run in COBOL programs and CICS transactions on z/OS, and in RPG and COBOL applications on IBM i. Teams have tuned that logic through rate changes, regulatory updates, audits and peak seasons.

Age works in your favor here. An exception buried in the code usually traces back to a real event, such as a regulator's ruling or a product from 1998 that still has active policyholders. Many teams file that code under technical debt, yet it also works as institutional memory that runs in production every day.

The difficulty lies in access. Teams designed those systems for people at green screens and for nightly batch jobs, so an AI agent can't reach them the way it reaches a cloud app.

The asset is in place. The access is what's missing, and that gap explains why so many agent pilots stall.

Why AI agents stall at the core system

Most enterprises have moved past the question of whether agents work. The harder question is whether agents can work on the systems that matter. Deloitte's Tech Trends 2026 found that 38% of organizations are piloting agentic AI, while only 11% run it in production.

For banks and insurers, the gap usually opens at the core system, for four reasons:

• The systems expect a person. CICS transactions and IBM i applications assume someone at a green screen, stepping through fields in a fixed order. An agent needs a callable service with clear inputs and outputs.
• The data arrives late. Many teams feed AI from nightly batch exports. An agent that quotes from yesterday's file gives yesterday's answer, and in claims or payments that answer can cost money.
• Connecting differs from governing. MCP, the Model Context Protocol, gives agents a standard way to reach tools. It doesn't decide which agent may update which record, or log what the agent changed.
• Raw responses cost too much. When a system returns a full legacy record, the response can run to thousands of tokens, most of them irrelevant to the task. The agent pays for every one, and accuracy drops as the noise grows.

Each issue on its own can stall a pilot. Together, they explain why many Chief AI Officers have working agents that never touch the policy admin system or the core ledger.

Each of those four problems has a fix, and none of them involves replacing the mainframe.

How to make legacy data and logic agent-ready, one process at a time

Making legacy agent-ready means giving agents governed access to read, run and update what already works, without rewriting it. Teams that make progress tend to follow the same pattern.

Pick a high-value process

Choose one process where better decisions show up in the numbers, such as renewal pricing or the claim lifecycle. Volume matters too, because each improvement repeats thousands of times a day. Proving value on a process the business cares about earns the budget for the next one.

Let agents read data and logic where they live

OpenLegacy exposes existing mainframe and IBM i data and transactions as governed services, so the data stays in place and no one rewrites the code. Teams deliver those services up to 10x faster than hand-built integrations, and agents receive only the fields a task needs, which cuts context by up to 99%. A top-3 US bank used this approach to make hundreds of thousands of VSAM and IMS files readable, cutting customer data requests from weeks to minutes.

Let agents act on it, under governance

Reading builds trust, but acting is where the value shows up. Agents can run existing business transactions and update records, with a confirmation step for sensitive changes and a log of every call. Teams can also change the logic itself more safely. A leading card issuer is mapping tens of millions of lines of COBOL into governed specifications, so AI-assisted changes link back to business rules and pass regression tests before release. And because teams reuse logic instead of rewriting it, costs can drop by up to 60%.

Each step adds one more process your agents can trust, and each one widens the gap between your AI and a competitor's.

Make decades of data and logic the advantage your agents run on

Your competitors can license the same LLMs next quarter. They can't license your book of business or the rules your teams have refined for thirty years. The advantage goes to the company whose agents can reach and act on that data and logic, with a record of every step.

OL Gene, OpenLegacy's agentic AI platform, gives those agents one governed place to work. Teams connect the services OpenLegacy exposes from mainframe and IBM i systems, along with other APIs and MCP servers, then build agents from skills and business context. Agents run through a single Co-pilot control plane or through any MCP client. Actions Monitoring records every API and tool call, and audit logs track every configuration change. You can run the platform as managed SaaS or self-host it.

Pick the process that matters most to your business, and give your agents the advantage only you hold. See how OL Gene works.

FAQ

What is an AI moat in enterprise AI?

An enterprise AI moat is a lasting advantage competitors can't buy or copy. Since rivals can license the same LLMs, the moat comes from assets only your company holds: decades of business data and the business logic that acts on it, available for AI agents to read, run and update under governance.

Are AI models becoming a commodity?

Largely, yes. Entrepreneur reported in July 2026 that "the underlying models are rapidly compressing into commodities," and McKinsey makes a similar point about shared access to the same models. Model choice still affects cost and quality, but it rarely separates one bank or insurer from another for long.

Why do AI agents need both business data and business logic?

Data tells an agent what happened, such as a policy's history or an account balance. Logic tells it what to do next, such as how to price a renewal or route a claim. An agent with only one half either knows the facts without your rules, or follows rules with nothing to act on.

Can AI agents use mainframe data and business logic without rewriting COBOL?

Yes. OpenLegacy exposes existing mainframe and IBM i data and transactions as governed services, so the code and data stay where they are. Agents call those services to read records, run business transactions and update data, and the platform logs every call. Teams typically deliver the services up to 10x faster than hand-built integrations.

Is MCP enough to connect AI agents to core banking systems?

MCP gives agents a standard way to reach tools, which solves part of the problem. It doesn't decide which agent may update which record, and it passes legacy responses through at full size. Banks and insurers usually add a governed layer on top, such as OL Gene, to control access and send agents only the fields they need.

Should we replace the mainframe before we scale AI?

Usually not. A rewrite or migration can take years, and it can drop the business rules and history that make your AI hard to copy. Most banks and insurers get faster results by keeping the mainframe running and giving agents governed access to its data and logic, one business process at a time.

Which business process should we open to AI agents first?

Pick a process with clear business value and high volume, such as renewal pricing or the claim lifecycle. Value earns the budget for the next process, and volume means each improvement repeats thousands of times a day. Run old and new side by side, so you can prove results before you expand.