Why Do AI Agents Fail Inside Legacy Stacks? The 4-Gate Test for AI Agents Legacy ERP Systems Can Support

Why Do AI Agents Fail Inside Legacy Stacks? The 4-Gate Test for AI Agents Legacy ERP Systems Can Support

AI agents legacy ERP systems reject fail at four gates: write back, segregation of duties, exception routing, and clean data demos. See which gate fails you.

Published

Last Modified

Topic

AI Use Cases

Author

Jill Davis, Content Writer

TLDR: Most AI agents legacy ERP systems reject fail for integration reasons, not model reasons: the agent cannot write back to the system of record, it breaks segregation of duties, it has nowhere to send an exception, and the demo that won the budget ran on clean data. The fix is a 4-gate sequence that earns write access one gate at a time, without replacing the ERP.

Best For: Heads of Transformation, Heads of AI, CAIOs, and COOs or finance leaders carrying the AI mandate at enterprises of 1,000 to 15,000 employees in manufacturing, distribution, healthcare services, hospitality, or insurance, especially multi-entity companies running one or more legacy ERPs and deciding what the second agent has to include.

Updated: September 2026

An AI agent inside a legacy operations stack is a piece of software that reads from and acts on systems that were never designed to be acted on by anything except a trained employee with a login. The ERP expects a person to post the journal entry, release the purchase order, or approve the credit memo, and it enforces its rules through screens, roles, and approval chains rather than through interfaces an agent can call. That mismatch, not the quality of the AI, is where most production deployments break at enterprises in traditional industries. The demo works because it reads a clean extract and shows a recommendation; production fails because the agent now has to write something back, under controls, and handle the 15% of cases that do not match the pattern. This post explains the four points where that happens and the order in which to clear them.

Why do AI agents fail inside legacy operations stacks?

AI agents fail inside legacy operations stacks because the stack, not the agent, decides what is allowed to happen. Four things go wrong in a predictable order: the agent has no safe write-back path into the ERP, its actions violate segregation of duties, it has no defined route for exceptions, and its pilot was judged on data that had already been cleaned by hand. Each one is an integration and control problem that a better model does not solve.

The failure numbers are integration numbers

The headline statistics on agent failure tend to get read as a verdict on the technology. Read closely, they describe integration. Gartner predicted in June 2025 that over 40% of agentic AI projects will be canceled by the end of 2027, and named "inadequate risk controls" alongside unclear business value as the reasons. In a separate February 2025 note, Gartner predicted that 60% of AI projects unsupported by AI-ready data will be abandoned through 2026. Neither finding says the agent reasoned badly. The environment around it was not built to receive it.

The environment at a 1,000 to 15,000 employee company is crowded. MuleSoft's 2025 Connectivity Benchmark put the average enterprise at 897 applications, with only 29% of them integrated, and 95% of IT leaders reporting difficulty integrating data across systems. In the same 2025 survey, organizations already using agents ran even more applications, 1,103 on average. An agent dropped into that estate does not find one ERP; it finds two or three, plus the spreadsheets that reconcile them.

What "legacy stack" means at a multi-entity company

For the audience of this post, a legacy stack is rarely one old system. It is the ERP the parent company chose, the different ERP the acquired distributor still runs, a warehouse system with its own item master, a bank portal, and the shared mailbox where invoices arrive. KPMG's 2025 SOX survey found the average number of in-scope systems nearly doubled to 40 in fiscal 2024 from 17 in fiscal 2022, and that automated controls fell to 17% of the control population from 21% over the same period. More systems, fewer automated controls. That is the surface an agent has to write into.

Half of the CEOs in IBM's 2025 study said rapid technology investment had left them with disconnected, piecemeal technology, and only 16% of AI initiatives in that study had scaled enterprise-wide. The disconnection is the legacy stack. The 16% is what happens when agents meet it.

How the thinking has moved since 2024

In 2024 the assumption was that agents would sit on top of existing systems and simply do what a person does through the same screens. By 2025 the vendor market had split between tools that could act and tools that could only draft, and Gartner's June 2025 note estimated that of thousands of vendors claiming agentic capability, only about 130 were real. In 2026 the question has narrowed to something an operations leader can actually test: can this agent write to my system of record, under my controls, and what does it do when it is unsure? The rest of this post is that test.

Why AI agents legacy ERP systems demos mislead: clean data versus production data

AI agents legacy ERP systems demos mislead because the demo runs on data that a person already cleaned, against a workflow that has already been narrowed to its happy path. Production data carries duplicate vendors, unit-of-measure mismatches, entities with different chart-of-accounts structures, and the 15% of transactions that need a judgment call. An agent judged on the first will look wrong on the second, and the pilot will be blamed for a data problem it inherited.

What the demo left out

A typical demo extracts three months of invoices, strips the ones with missing purchase orders, and shows the agent matching the rest. The match rate looks like 96%. In production the missing-PO invoices are back, the three entities post to different account structures, and the acquired company's vendor master has the same supplier under four names. None of that is the agent's fault, and all of it lands on the agent's scorecard.

Carnegie Mellon's 2025 benchmark of agents on realistic office tasks found the best-performing agent completed roughly 30% of tasks end to end, with failures concentrated in multi-step work that required handling an unexpected state. Production looks like that: the invoice, plus whatever is wrong with the invoice.

The workflow was never redesigned around the agent

The second thing the demo left out is the workflow. PwC's April 2025 agent survey found 79% of companies adopting agents, but only 42% redesigning processes around them. McKinsey's 2026 State of AI found that nearly three quarters of high performers had fundamentally redesigned workflows because of AI, up from 55% a year earlier, and that 40% of large organizations now report scaling agents, up from 27%. The redesign is what separates the two groups. An agent placed into an unchanged workflow inherits every handoff and every spreadsheet reconciliation that workflow already had; the earlier post on where to start with AI agents in a traditional industry makes the case for picking high-volume intake work for exactly this reason.

MIT's 2025 GenAI Divide report put the share of enterprise AI pilots that deliver no measurable profit impact at 95%, and attributed most of the gap to tools that do not retain context or fit into existing workflows rather than to model quality. Same conclusion from a different direction.

What AI agents legacy ERP systems need: the 4-Gate Write-Back Test

AI agents legacy ERP systems can support are the ones that pass four gates in sequence: a safe write-back path, a segregation-of-duties design, a defined exception route, and a reversible, logged action trail. The 4-Gate Write-Back Test is a diagnostic to run on any agent proposal before it touches a system of record. An agent that fails a gate is not rejected; it is held at the previous gate until the missing piece is built.

The test exists because the same four gaps appear in nearly every stalled agent we see at multi-entity companies, and because the order matters. Teams that start with direct write access and try to add controls later are the ones Finance shuts down. Teams that start read-only and earn each gate are the ones that reach production.

Gate

Question the gate asks

What "pass" looks like

What fails it

1. Write-back path

Where does the agent's output land?

A staging queue or draft transaction in the ERP that a person releases, or a documented interface the ERP owner has approved

Screen scraping, unofficial database writes, or "the agent emails Finance"

2. Segregation of duties

Does the agent both prepare and approve?

The agent holds one role in the ERP with the same restrictions as a clerk; approval stays with a different role

The agent runs under an admin or integration account with create, approve, and post rights

3. Exception route

What happens when the agent is not sure?

A named exception class, a threshold that triggers it, and a person and queue that receive it

"It will flag it"; no queue, no owner, no SLA

4. Reversibility and trail

Can every action be found and undone?

Every agent action carries an ID, a reason, the inputs used, and a reversal path in the ERP

Actions visible only in the vendor's dashboard, or reversals that require a manual journal entry

Gate 1: the write-back path

Most proposals skip this gate entirely. The agent reads the invoice, matches it, and then has to create a transaction somewhere. In a legacy ERP that "somewhere" is often a screen with no interface behind it. The practical answer is a staging layer: the agent writes a draft document that the ERP already knows how to hold (a parked invoice, an unreleased PO, a proposed journal), and a person releases it. The write-back is real. Nothing touches the ledger without the release step, and the release step is the one the auditors already understand. The earlier piece on integrating AI with legacy ERP systems describes the layered architecture this sits in.

Gate 2: segregation of duties

Integration accounts cause the trouble here. An agent running under a technical account that can create and approve is, for control purposes, one person doing two jobs. The fix is boring and effective: give the agent a named role with the same restrictions the preparer role has, and leave approval where it already lives. Protiviti's 2023 SOX survey found 58% of organizations reporting an increase in SOX compliance hours over the prior year; an agent that collapses two roles into one adds to that number rather than reducing it.

Gate 3: the exception route

Gate 3 decides whether the agent survives its first month. Every high-volume workflow has an exception rate, usually between 10% and 20% for invoice and order intake in our experience, and those cases need a place to go. "The agent flags it" is not a route. A route is an exception class (missing PO, tolerance breach, new vendor, entity mismatch), a threshold that triggers it, a queue that receives it, and a person whose job includes clearing that queue. Without this, exceptions either get forced through the happy path or pile up in a place nobody checks.

For an agent that posts to a system of record under SOX at a multi-entity company, a generic approach is not enough; the answer is a dedicated build that 1. writes only to a staged queue that a separately authorized person releases, 2. carries an explicit exception taxonomy with a threshold and an owner for each class, and 3. logs every action with its inputs and a reversal path inside the ERP itself, so the audit trail lives where the auditors already look.

Gate 4: reversibility and the action trail

Gate 4 is how you turn the agent's autonomy up later without a fight. If every action carries an ID, its inputs, its reasoning, and a reversal path, the review threshold can move from "every item" to "items above tolerance" to "sampled items" with evidence at each step. Deloitte's April 2026 survey of 3,235 leaders found only 21% of enterprises had mature governance for agentic AI; the action trail is the smallest unit of that governance and the one that has to exist first. The post on how to govern AI agents in enterprise operations covers the decision-level governance that sits above it.

AI agents vs. RPA vs. ERP-native automation on a legacy stack

AI agents, RPA, and ERP-native automation are three different answers to the same legacy stack, and confusing them is why many "agent" projects are RPA projects with a new label. RPA replays clicks on a fixed path and breaks when the screen or the data changes. ERP-native automation lives inside the vendor's workflow engine and stays inside its limits. An agent reads unstructured input, decides, and acts, so it needs the four gates and the other two do not.

Dimension

RPA

ERP-native automation

AI agent

Input it can handle

Structured, fixed screens

Structured, inside the ERP

Unstructured (emails, PDFs, portals) plus structured

Behavior on an unexpected case

Breaks or loops

Routes by rule

Decides, which is the risk and the value

Write-back

Through the same screens a person uses

Native

Needs Gate 1 designed

Segregation of duties

Inherits the bot account's rights

Inherits ERP roles

Needs Gate 2 designed

Exception handling

Stops

Rule-based

Needs Gate 3 designed

Where it fits on a legacy stack

Stable, repetitive, low-variance steps

Steps the ERP already models

Intake and judgment steps with variance

The honest reading of this table is that a legacy stack usually needs all three, and that the agent should be reserved for the steps with variance. Capgemini's July 2025 report found only 2% of organizations had fully scaled agent deployment, that fewer than one in five reported high data readiness, and that trust in fully autonomous agents fell from 43% to 27% in a year. The drop in trust is rational when agents are used where RPA would have done.

What skeptics get wrong, and what they get right

Skeptics of AI agents on legacy stacks are right about the risk and usually wrong about the remedy. The three objections that come up most often come from IT and Finance: replace the ERP first, the agent will post something wrong, and this is RPA with a bigger budget. Each has a direct answer, and two of the three point back to a gate that was skipped.

"We need to replace the ERP first"

No. Panorama's 2026 ERP report found more than a quarter of ERP projects over budget and almost a quarter over schedule, with organizational issues the main driver of delays. A replacement is a two to three year program that freezes the operations team while it runs. The staging-queue pattern in Gate 1 works on ERPs from any decade, because every ERP already has a concept of a parked or unreleased document. Replace the ERP when the ERP needs replacing, not because an agent wants an interface. The earlier post on implementing AI without replacing legacy systems covers the three patterns in more depth.

"The agent will post something wrong and we will find it at quarter close"

That is a Gate 3 and Gate 4 failure, and it is a fair objection to any agent proposal that has not designed them. The answer is to hold the agent at read-only and recommend-only until the exception route and the action trail exist, rather than keeping it away from the ERP for good. An agent that cannot post cannot post something wrong.

"This is just RPA with a bigger budget"

Sometimes it is, and the comparison table above is the test. If the step has no variance, use RPA. If the vendor cannot explain what the agent does on a case it has not seen, it is not an agent yet. The gap analysis in how to go from one AI use case to a program applies here too: the missing piece is usually an owner and an intake process, not a different tool.

How to sequence an AI agent from read-only to write-back on a legacy stack

An AI agent on a legacy stack should earn write access in four stages that map to the four gates: read-only, recommend-only, staged write, and thresholded write. Each stage produces the evidence the next one needs, and each can run in production, so the program never stalls at the demo. The rule is simple: the agent moves up one stage only when the exception rate at the current stage is measured and owned.

Stage one is read-only. The agent reads the ERP and the intake channel and produces a match rate, an exception rate, and a list of the exception classes it found. This stage alone often reveals the data problems the demo hid, and it costs nothing in control terms. Stage two is recommend-only. The agent proposes the transaction and a person posts it; the measure is how often the person overrides the recommendation, by exception class. Stage three is the staged write from Gate 1: the agent creates the draft document and a separately authorized person releases it. Stage four is thresholded write, where items under tolerance post on release without review and items over tolerance still stop, with Gate 4's trail making the threshold defensible.

Written down, the sequence converts the CEO's "why is this not in production yet" into a stage and a date, and converts IT's "not on my ERP" into a gate and a design. Gartner named escalating costs and unclear value as the other reasons agent projects get canceled; a staged sequence keeps both visible because each stage has a measured exception rate and a measured override rate before the next one is funded. The post on why AI automations break lists the production failure modes that stage one is designed to surface early.

This analysis was developed using methodologies and operating experience from Assembly.

Frequently Asked Questions

Why do AI agents fail inside legacy operations stacks?

AI agents fail inside legacy operations stacks because the stack decides what is allowed, not the agent. The four recurring causes are no safe write-back path into the ERP, actions that break segregation of duties, no route for exceptions, and a pilot judged on cleaned data. Each is a control gap that a better model does not fix.

Can AI agents work with legacy ERP systems without replacing them?

AI agents can work with legacy ERP systems without a replacement when the write-back uses a staging pattern. Every ERP already holds parked invoices or unreleased orders. The agent creates that draft and a separately authorized person releases it. Panorama's 2026 ERP report found over a quarter of ERP projects run over budget, so replacement is rarely the faster path.

What is the 4-Gate Write-Back Test?

The 4-Gate Write-Back Test is a diagnostic that checks an agent proposal for a write-back path, a segregation-of-duties design, an exception route, and a reversible action trail before it touches a system of record. An agent that fails a gate is held at the previous stage until the missing piece is built, rather than rejected or given direct write access.

Why do AI agent demos on clean data mislead?

AI agent demos on clean data mislead because someone already removed the cases that fail in production. Missing purchase orders, duplicate vendors, entity mismatches, and tolerance breaches are stripped from the demo extract and return the moment the agent runs live. Carnegie Mellon's 2025 benchmark found the best agent completed roughly 30% of realistic multi-step office tasks.

How does segregation of duties apply to an AI agent?

Segregation of duties applies to an AI agent exactly as it applies to a clerk: the agent must not both prepare and approve a transaction. The failure pattern is an integration account with create, approve, and post rights. The fix is a named ERP role for the agent with preparer-level restrictions, and approval left where it already lives.

What should happen when an AI agent hits an exception it cannot resolve?

An AI agent that hits an unresolvable exception should route it to a named exception class with a threshold, a queue, and an owner. "The agent flags it" is not a route. Invoice and order intake workflows typically carry exception rates between 10% and 20%, so a queue that nobody clears fills within weeks and the agent gets switched off.

What is the difference between an AI agent and RPA on a legacy stack?

An AI agent decides on unstructured input and acts, while RPA replays fixed clicks on structured screens and breaks when anything changes. RPA suits stable, low-variance steps; agents suit intake and judgment steps with variance. Gartner's June 2025 note estimated only about 130 of thousands of vendors claiming agentic capability were real.

How should an enterprise sequence an AI agent from read-only to write-back?

An enterprise should sequence an AI agent through read-only, recommend-only, staged write, and thresholded write, moving up only when the current stage's exception rate is measured and owned. Read-only surfaces data problems at no control cost. Recommend-only measures override rates. Staged write keeps release with a person. Thresholded write posts low-risk items and stops the rest.

Why do AI agents in production need an action trail?

AI agents in production need an action trail because the trail is what lets review thresholds move from every item to sampled items with evidence. Each action should carry an ID, its inputs, its reasoning, and a reversal path inside the ERP. Deloitte's April 2026 survey found only 21% of enterprises had mature governance for agentic AI.

How many systems does an AI agent typically have to work across at an enterprise?

An AI agent at an enterprise typically works across dozens of systems, not one ERP. KPMG's 2025 SOX survey found in-scope systems nearly doubled to an average of 40 in fiscal 2024, while MuleSoft's 2025 benchmark put the average enterprise at 897 applications with 29% integrated.

Does workflow redesign matter more than the AI model for agents on legacy systems?

Workflow redesign matters more than the AI model for agents on legacy systems, because an unchanged workflow hands the agent every handoff it already had. McKinsey's 2026 State of AI found nearly three quarters of high performers fundamentally redesigned workflows, while PwC's 2025 survey found only 42% of adopters redesigning processes.

Who should own AI agent deployment on a legacy ERP: IT, Finance, or Operations?

AI agent deployment on a legacy ERP should be owned by the operations or transformation leader, with IT owning the write-back interface and Finance owning the approval role and thresholds. Gate 1 belongs to IT, Gates 2 and 4 to Finance and audit, and Gate 3 to the operations team that clears the exception queue.

How long does it take to move an AI agent from pilot to write-back on a legacy stack?

Moving an AI agent from pilot to staged write-back on a legacy stack usually takes one to two quarters when the four gates are designed up front and each stage runs in production. Read-only and recommend-only stages can run within weeks. Staged write depends on the ERP owner approving the interface, and thresholded write follows once override rates are stable.

What data problems do AI agents expose on legacy ERP systems?

AI agents expose duplicate vendor masters, inconsistent units of measure, entity-specific chart-of-accounts structures, and missing purchase orders on legacy ERP systems. These problems predate the agent and were absorbed by clerks who knew the workarounds. Gartner predicted 60% of AI projects unsupported by AI-ready data would be abandoned through 2026.

Should an AI agent ever have direct write access to the ERP?

An AI agent should have direct write access to the ERP only at the thresholded-write stage, only for items under a defined tolerance, and only with a full action trail. Everything above tolerance still stops for release. Starting with direct write access and adding controls later is what gets agents shut down by Finance at quarter close.

When should an enterprise bring in an external partner for agents on legacy systems?

An enterprise should bring in an external partner for agents on legacy systems when nobody in-house has designed a staged write-back and an exception taxonomy before, or when IT and Finance cannot agree on the gates. The partner's job is the gate design and the sequence, not the model. If they cannot describe Gate 1 for your ERP, keep looking.

Your AI Transformation Partner.

Your AI Transformation Partner.

© 2026 Assembly, Inc.