Legacy Integration: The Unglamorous Reason AI Agents Stall Before Production

Enterprise agent programmes rarely fail on reasoning. They fail on write access. Legacy integration is the constraint that decides the outcome, and 35% of large enterprises now name data readiness and integration as the top barrier to scaling agentic AI, ahead of talent, budget and use cases. The systems of record an agent must change predate REST.

What "legacy integration" actually blocks

Here, a legacy system is any system whose interface was designed for a person or a nightly batch file rather than for a program acting on its own behalf. That definition catches far more than mainframes. It catches the 2011 procurement suite with a SOAP endpoint nobody maintains, the warehouse system that accepts a fixed-width file at 2am, and the finance module whose only supported write path is a screen.

The direct answer, for anyone scanning: agents stall because the systems of record they must change expose no safe transactional interface. Reading is cheap. Writing requires an interface that can be retried, reversed and audited, and most old systems provide none of the three. That gap is engineering work, not model work.

Read access is a solved problem, which is why pilots look good

Almost every enterprise agent pilot is a read pilot. The agent retrieves a record, summarises a thread, drafts a reply, or answers a question about inventory. One service account and one query gets you there, and the demo is genuinely useful.

Pilot success rates therefore tell you very little. A read pilot exercises none of the machinery that production requires. The reasons a pilot passes and a rollout does not are catalogued separately in the breakdown of how agent pilots fail on the way to production.

Write access is where the project stops

The moment an agent has to create a purchase order, adjust a ledger entry or cancel a shipment, four new requirements appear at once. The call must be idempotent. The action must be reversible. The actor must be identifiable. The whole sequence must be visible to an auditor months later.

Those requirements are properties of the interface between the agent and the system of record, and in a legacy estate that interface usually does not exist yet. Building it is a normal integration project with a normal integration timeline, which is measured in quarters.

The evidence that integration is the gap, not intelligence

Three independent surveys published in the first half of 2026 point the same way, and it is worth being precise about what each one actually measured.

CrewAI surveyed 500 C-level and senior leaders at organisations above $100 million in revenue and 5,000 employees, across seven regions. Asked what blocks scaling, respondents ranked data readiness and integration first at 35%, talent second at 33%, and budget fourth at 25%. In the same survey, ease of integration with existing systems was the second most important criterion when choosing an agent platform, at 30%, well ahead of time to value at 2%.

Google's 2026 State of AI Infrastructure report surveyed more than 1,400 senior IT leaders. 83% said their infrastructure needs upgrades before it can support agentic systems, and only 17% expressed full confidence in their current stack for mission-critical agents. Nirav Mehta of Google Cloud told CIO Dive that traditional architectures are cracking under the pressure.

Gartner's contribution is the most quoted and the most often misused. The firm predicted in June 2025 that over 40% of agentic AI projects will be cancelled by the end of 2027. The stated reasons are escalating costs, unclear business value and inadequate risk controls. Legacy systems are not named in that prediction, and secondary write-ups that attribute the 40% figure to legacy architecture are adding a cause the source does not contain.

Integration cost is one input into escalating cost and unclear value, not the whole explanation. My position is that integration is the largest single controllable input, which is a narrower claim than the one circulating.

MuleSoft's 2026 Connectivity Benchmark, covering 1,050 IT leaders, adds a useful detail on scale. The average enterprise in that sample runs 12 agents today. Twelve agents against a system of record with no transactional API is twelve integration projects, not one.

The ERP case, where the deadline is already on the calendar

ERP is the clearest illustration because the timeline is public and the numbers are countable. Most agent use cases worth money touch the ERP eventually, since that is where orders, invoices, inventory and ledgers live.

SAP has roughly 35,000 ECC customers. By the end of 2024, about 14,000 of them, or 39%, had migrated to S/4HANA, according to figures reported by CIO. Mainstream maintenance for ECC ends at the close of 2027, with paid extension available to 2030. Gartner projects roughly 17,000 customers will still be on ECC at that deadline. IDC puts the figure at 40% to 45%, and Forrester at above 40%. Three independent analyst houses landed within a few points of each other, which is stronger corroboration than any single number.

Then there is the commercial layer, which is the part enterprise architects underestimate. At Sapphire 2026, SAP said on-premises ECC and S/4 customers can access Joule assistants only if they commit 50% of their maintenance spending to cloud. Cloud ERP Private customers get up to three assistants at no extra cost. SAP chief strategy officer Sebastian Steinhaeuser put it plainly: Joule assistants and agents are designed for cloud, and that is unchanged.

Read that as a pricing decision rather than a technical constraint. The agent capability is being used to accelerate a migration that fifteen years of product marketing did not achieve. If your agent roadmap assumes the ERP vendor will meet you where you are, check the licence terms before the architecture.

Four patterns for systems that predate REST

You will not modernise the whole estate before the agent programme starts. So the practical question is which integration pattern to use per system, and what each one costs you later.

The fçade is the pattern most teams should default to

A fçade is a small service that exposes a deliberately narrow contract. Not the whole ERP, just the six operations your agents actually need, each one validated, logged and versioned. It is unglamorous, it takes a quarter, and it is the only pattern that gets cheaper as you add agents.

The discipline is in the narrowness. Teams fail here by trying to generate a complete API surface from the legacy schema, which reproduces every ambiguity of the original system and secures none of it.

Event capture buys you a record of intent

Writing the agent's intended change to a durable queue, then applying it with a controlled worker, separates two things that should never be coupled. What the agent decided is now a fact you can inspect. Whether the write succeeded is a separate fact. When something goes wrong at 3am, that separation is what makes the incident diagnosable.

Driving the interface is a tactical answer, not an architecture

Screen driving is the pattern everyone reaches for first, because it works in a demo within hours. It is also the pattern with an open-ended maintenance liability, since the contract is a rendered page that nobody promised to keep stable. Use it for a bounded, low-volume workflow with a named owner. Do not build a programme on it.

The human approver is a control, until it is not

Putting a person between the agent and the commit is the right starting posture for consequential writes. It stops being a control when volume rises and approval becomes reflexive, which is a well-documented pattern in the case for designing the approval loop by reversibility rather than importance. Design the exit from this pattern at the same time you design the entry.

Why write access is a different engineering problem

The four requirements below are what separate a read connector from a write connector. Each one is ordinary engineering, and together they explain why the second integration takes ten times as long as the first.

Idempotency comes first. An agent will retry. Networks time out, orchestrators restart, and a retried create request against a legacy endpoint produces a second purchase order. The fix is a caller-supplied idempotency key that the fçade stores and honours. Legacy systems almost never provide this, so the fçade has to own the deduplication table itself.

The reversal path must exist before the write does. Most legacy transactions cannot be rolled back after commit, so the practical answer is a compensating action: a credit note against an invoice, a cancellation against an order. Write down the compensating action for every verb you expose. If a verb has no compensating action, it does not get agent access this quarter.

Identity has to survive the audit. A shared service account tells an auditor nothing about which agent, acting for which person, under which policy, made the change. Non-human identity in legacy directories is its own project, covered in the analysis of how agent identity and non-human access are actually governed. Solve it before the write path goes live, because retrofitting attribution to historical transactions is not possible.

Observability is not optional at this layer. You need to answer, months later, what the agent proposed, what the fçade accepted, what the legacy system recorded, and where those three disagree. Most incidents in agent systems are reconciliation problems, not reasoning problems.

The elapsed time row is a general pattern from published deployment accounts rather than a measured benchmark. Treat it as an ordering claim rather than a duration you can plan against.

Sequencing, and what it plausibly costs

The cost question has no clean public answer for agent integration specifically. What is documented is the adjacent number. Gartner vice president Fabio Di Capua told CIO that S/4HANA migrations range from $2 million to $1 billion depending on enterprise size. Agent integration is a narrower job than a full ERP migration, and it competes for exactly the same scarce people.

An ASUG survey cited in the same reporting found 48% of respondents struggling with integration during S/4HANA migration, against 61% citing budget. The sample size is not disclosed in the reporting, which is a real weakness in that figure.

Here is the sequence I would defend. Pick one workflow with measurable money attached. Build the fçade for that workflow alone, with two or three verbs and their compensating actions. Run it behind human approval for a quarter while you record the agent's error rate by verb. Then relax approval only on the verbs whose failures are cheaply reversible.

That sequence deliberately refuses both popular answers. It is not a modernisation programme that delays value for two years, and it is not a demo promoted to production because it impressed a steering committee. It is a vertical slice that tests the integration design and the business case together. That is the same logic behind the readiness tests a proof of concept has to pass before it earns production traffic.

Where this argument is weakest

Three objections deserve a proper hearing, and one of them is partly right.

The integration layer may genuinely be commoditising

The strongest counter-argument is that connector work is being standardised out of existence. MuleSoft's 2026 benchmark found 39% of its 1,050 IT leaders using the Model Context Protocol and 40% using agent-to-agent protocols. Protocol adoption at that level is not noise.

My answer is that a protocol standardises the call, not the capability. If the ERP has no transactional API, MCP gives you a consistent way to invoke an interface that still has to be built. What the standard does and does not settle is examined in the assessment of MCP as an interoperability standard. I hold this position with moderate confidence, and a genuinely good managed connector market would weaken it.

Much of the evidence here is vendor-sponsored

Two of the three headline figures in this post come from research commissioned by companies that sell into the problem. CrewAI sells an agent platform. Google sells infrastructure. Neither survey publishes its full instrument, and both have an interest in the answer being "your stack needs work".

That is a real limitation and I am not going to argue it away. What raises my confidence is convergence from parties with different incentives: an agent vendor, an infrastructure vendor and three analyst houses on the ERP question all describe the same shape. Convergence across incentives is weaker than an independent study and stronger than any one of them alone.

The honest version of the claim is therefore narrower than the headline. Integration is consistently named as a leading barrier by people with reason to name it. Whether it is the single largest cause of failure is not established by anything published.

What an enterprise architect changes on Monday

These decisions sit with the person accountable for the estate, not with the agent programme. Three changes are worth making immediately.

First, publish a write-capability register. For every system of record, record whether a transactional API exists, whether it supports idempotency, and what the compensating action is for each critical verb. Most estates have never had this written down, and the exercise usually reveals that the constraint is concentrated in two or three systems.

Second, move integration cost into the agent business case rather than into a separate platform budget. Programmes that hide the fçade work in a shared line item produce return figures that cannot be checked. That is one route to the outcomes described in the review of AI deployments that returned less than they cost.

Third, refuse verbs rather than refusing systems. "No agents in the ERP" is a policy that gets routed around within a month. "These four verbs, with these compensating actions, behind this fçade" is a policy people can build against, and it is enforceable.

Frequently asked questions

Where to start this week

Take your three highest-value candidate workflows and write down the exact verb the agent would need to call in the system of record. Not the outcome, the verb. Then find out whether that verb is reachable through a supported interface today.

In most estates, one of the three turns out to be reachable and the other two are not. That result is the roadmap. It tells you which workflow to build this quarter and which two systems need a fçade before anyone promises a date.

If your ERP is on a maintenance clock, add one more line to the same page: the date support ends, and whether your agent licence terms depend on migration progress. Those two facts have moved from procurement's problem to architecture's problem, and most roadmaps have not caught up.

Related reading