The Integration Burden: Why Connecting Agents to Legacy Systems Is the Real Cost of GaaS

Table of Contents

• The part nobody quotes you on
• What "legacy" actually means to an agent
• The four integration patterns, ranked by pain
• Why GaaS pricing models break against integration cost
• The read/write asymmetry that catches everyone
• Who actually does the integration work
• A pragmatic sequencing approach
• Insights Most People Overlook
• References

The part nobody quotes you on

When a vendor demos an agentic AI service, the agent does something impressive against a clean sandbox: it reads a ticket, checks an order, issues a refund, writes back a note. Everything connects. The demo environment has tidy REST APIs and well-labeled fields because someone built it that way on purpose.

Then you try it against your stack, and the order system is a 2009-era Oracle instance that a retired contractor configured, the "refund" action requires three approvals routed through a workflow tool nobody fully understands, and the field the agent needs to read is stored as a free-text comment because the real field was deprecated in 2017.

This is the integration burden, and it is consistently the most underestimated line item in any agent deployment. McKinsey's research on enterprise technology has long noted that integration and data-readiness work routinely consumes the majority of an AI project's effort and budget, and agents have not repealed that law, if anything they've intensified it, because an agent doesn't just read your data, it acts on your systems. You can find the broader pattern in McKinsey's analysis of why most enterprise AI value stalls before scale. The model is rarely the bottleneck. The connection to reality is.

What makes this a GaaS-specific problem, rather than a generic IT problem, is the economics. When you buy an agent priced per task or per outcome, you're implicitly buying a promise that the agent can reliably complete a unit of work end to end. End to end means touching every system in the loop. If one of those systems is a brittle legacy app, the agent's reliability, and therefore the vendor's ability to charge for outcomes, is hostage to a forty-year-old database that times out under load.

What "legacy" actually means to an agent

"Legacy" is doing a lot of work in this conversation, so it's worth being specific. From an agent's point of view, a system is legacy if it fails one or more of these tests:

• No programmatic interface. No API, or an API that only covers 20% of what the human UI can do. The rest is locked behind screens.
• No stable contract. Field names, response shapes, or business rules change without versioning, so an integration that worked last quarter silently breaks.
• Hidden state and side effects. Clicking "submit" triggers downstream consequences, a notification, a ledger entry, an inventory decrement, that aren't visible in any documentation.
• Authentication built for humans. SSO with MFA, session cookies, IP allowlists, and no concept of a non-human principal with scoped permissions.
• No idempotency. Retry the same call twice and you create two orders. The system assumes a careful human who won't double-click.

A modern SaaS product with a clean API fails none of these. A homegrown logistics tool from 2011 fails all five. Most enterprises are a messy middle: a few good APIs, a lot of half-documented ones, and a long tail of systems that can only be reached the way a human reaches them, by looking at a screen and typing.

That long tail is where teams reach for computer-use agents, agents that operate the GUI directly, the way a person would. Anthropic's own documentation on computer use as a capability is candid that it's slower and more error-prone than calling an API, which is exactly the tradeoff: GUI automation lets you reach a system with no API, but you pay for it in reliability, the very thing outcome-based pricing depends on.

The four integration patterns, ranked by pain

Every agent-to-legacy connection falls into one of four buckets. They're worth understanding because the choice determines your cost, your reliability ceiling, and frankly whether the project ships.

1. Clean API (the happy path)

The system exposes a documented, versioned, rate-limited API with proper auth scopes. The agent calls it through a tool definition. This is the dream, and for modern systems it's increasingly real. If your whole stack looked like this, the integration burden would mostly evaporate. It doesn't.

2. Wrapped legacy (the pragmatic path)

The legacy system has some interface, a SOAP endpoint, a database connection, a flat-file export, and you build a thin middleware layer that translates between the agent's clean tool calls and the system's awkward reality. This is where most serious integration work happens. The middleware handles auth, retries, idempotency, field mapping, and the inevitable "if status is null, treat it as pending" business logic that lives in nobody's head. It's unglamorous and it's most of the job.

3. GUI automation (the desperate path)

No usable interface exists, so the agent drives the screen. Sometimes this is a computer-use model; sometimes it's RPA-style scripted automation that an agent orchestrates. It works, but it's fragile, a UI redesign breaks it, a slow page load confuses it, a surprise modal stops it cold. Teams treating this as a permanent solution rather than a bridge tend to regret it. This is, incidentally, the same brittleness that doomed many legacy RPA programs and is a major reason organizations are now replacing RPA with agents, only to discover the agent inherits the same screen-scraping fragility unless they also fix the underlying interface.

4. Human-in-the-middle (the honest path)

For the highest-risk or least-accessible actions, the agent does everything it can and then hands off to a person for the final step inside the legacy system. The agent drafts; the human commits. This is often dismissed as a failure of automation, but for regulated actions or systems where a mistake is expensive, it's the correct design, at least until trust is established. It also quietly shifts where the cost lands, which matters for ROI math.

Most real deployments are a blend. A single "process this return" outcome might use a clean API to look up the customer, wrapped middleware to check inventory, GUI automation to update the legacy warehouse system, and a human approval for the refund itself.

Why GaaS pricing models break against integration cost

Here's the tension at the center of agentic-AI-as-a-service. The pricing innovation everyone is excited about, pay per outcome, pay per resolved ticket, pay per completed task, assumes the agent can complete the outcome autonomously and reliably. Integration burden is precisely what undermines that assumption.

Think about what per-outcome pricing implies. The vendor takes on delivery risk: they only get paid when the work gets done. That's attractive to buyers and it's a genuine shift from seat-based SaaS, as a16z and others have argued in their writing on how AI is reshaping software business models. But it only pencils out for the vendor if the failure rate is low and predictable. A legacy system that returns garbage 8% of the time, or rate-limits the agent during business hours, or requires a manual re-auth every four hours, turns the vendor's pricing model into a money loser, or pushes them to quietly cap which outcomes they'll guarantee.

So one of two things happens. Either the vendor charges a large upfront integration fee (which kills the "pay only for results" pitch and makes the deal look like traditional enterprise software), or they scope the outcome narrowly enough that it only touches systems they trust (which limits the value). The integration burden is the reason a lot of headline per-outcome pricing comes with asterisks once you read the contract. It's also why measuring agent ROI in terms a CFO will believe has to account for integration as a real capital cost, not a one-time nuisance.

There's a second-order effect worth naming. Because integration is expensive and sticky, it becomes a moat. Once an agent is wired into your legacy stack, with all the middleware, auth handling, and edge-case logic that entailed, ripping it out and connecting a competitor means redoing that work. The integration burden cuts both ways: it's a barrier to adoption and, once crossed, a barrier to switching.

The read/write asymmetry that catches everyone

If you remember one technical point from this article, make it this: reading from a legacy system is an order of magnitude easier and safer than writing to one.

Read-only integration is forgiving. If the agent misreads a field, the worst case is usually a wrong answer that a human can catch. You can deploy a read-heavy agent against a messy legacy system relatively quickly because mistakes are recoverable.

Write integration is where the danger lives. The moment an agent can create an order, issue a refund, update a record, or trigger a downstream process, every weakness of the legacy system becomes a liability. The lack of idempotency means a retry creates a duplicate. The hidden side effects mean an innocent-looking update fires off a customer email or decrements real inventory. The absence of a transaction boundary means a multi-step action can fail halfway and leave the system in a corrupt state the agent can't reason about.

This is why mature deployments stage their integration: read-only first to build confidence and prove value, then narrowly scoped writes with heavy guardrails, then broader autonomy only once the failure modes are understood. The teams that get burned are the ones who let the agent write broadly before they've mapped the legacy system's side effects, and legacy systems are defined by undocumented side effects.

Practically, the write path demands things the legacy system usually doesn't provide: idempotency keys (often faked in middleware via a dedup table), a way to verify the write actually landed (re-reading after writing, because you can't trust the response), and a rollback or compensating action for when something goes wrong mid-sequence. Building those compensations is a real chunk of the integration burden, and it's invisible in any demo.

Who actually does the integration work

A recurring source of failed projects is ambiguity about who owns the integration. Three parties think it's someone else's job:

• The agent vendor assumes the customer has APIs, or will build the connectors, because the vendor sells intelligence, not plumbing.
• The customer's business team assumes the vendor handles integration, because that's what "as a service" implied to them.
• The customer's IT team gets handed the work late, with no budget, and discovers the legacy system they're now responsible for exposing is one they've been trying to decommission for years.

This is the same fault line that runs through the broader debate over who owns agents inside a company and the recurring fights between IT and the business over agent ownership. Integration is where that ownership question gets expensive and concrete. The successful pattern is to name an integration owner early, frequently this is where a system integrator's role in agent adoption becomes load-bearing, and to treat the legacy connection as a first-class deliverable with its own budget, timeline, and acceptance criteria, not as glue work that'll sort itself out.

One more under-discussed actor: the agent operations function. As organizations move from one agent to many, the integrations themselves become assets that need monitoring, versioning, and on-call ownership. When a legacy system changes a field name and silently breaks an agent's write path, someone has to notice before the failure compounds across thousands of outcomes. That's an AgentOps responsibility, and it's continuous, not a one-time setup cost.

A pragmatic sequencing approach

If you're staring at a legacy estate and an agent you want to deploy, here's an order of operations that consistently works better than trying to boil the ocean.

First, inventory the systems the target outcome actually touches, and classify each by the four patterns above. You'll often find that 80% of an outcome runs through good interfaces and 20% runs through one nasty legacy system. That 20% is your real project.

Second, push the worst legacy system to the edge of the workflow. If the genuinely brittle integration can be the last step, and ideally a human-confirmed one, you de-risk the whole flow. Redesigning the workflow around the agent's capabilities, rather than bolting the agent onto the old process, often makes a previously impossible integration trivial.

Third, start read-only, prove the outcome, then earn write access incrementally. Resist the pressure to demonstrate full autonomy before you've earned it against the messiest part of the stack.

Fourth, build the middleware as a reusable asset, not a one-off. The auth handling, retry logic, and idempotency layer you build for one legacy system will be needed for the next agent too. Teams that treat integration as throwaway glue pay for it repeatedly; teams that treat it as platform investment compound their returns as they scale from one agent to a fleet.

The blunt truth is that the integration burden is not a phase you get through, it's a permanent operating cost of running agents against systems that weren't built for them. The organizations winning with GaaS aren't the ones with the smartest agents. They're the ones who took the plumbing seriously.

Insights Most People Overlook

The integration burden is a feature for incumbents, not just a cost. Vendors with deep, pre-built connectors into specific legacy systems, think the dominant ERP or core banking platforms, have a structural advantage that has nothing to do with model quality. The hardest integration work is also the most defensible. Expect agent vendors to compete on connector libraries the way they once competed on model benchmarks, because that's where the real switching cost lives.

Good APIs can be worse than no API if they lie. A documented, well-shaped API that silently returns stale or incomplete data is more dangerous than a screen a human reads, because the cleanliness creates false confidence. At least with GUI automation you know you're on thin ice. The most expensive integration failures come from APIs that look trustworthy and aren't, and legacy systems are full of APIs bolted on years after the fact that don't reflect the true state of the underlying data.

The agent will expose data quality problems your humans were quietly working around. Humans tolerate a legacy system's mess by applying undocumented judgment, they know that "status: closed" actually means "open" for orders before a certain date. An agent doesn't know that unless you tell it, and the act of integrating forces every one of those tribal workarounds into the open. Integration projects routinely become data-cleanup and tribal-knowledge-extraction projects, and the budget rarely accounts for it.

Per-outcome pricing pushes risk onto the messiest part of your stack, which is exactly backwards. When a vendor guarantees an outcome, they're guaranteeing the reliability of your worst legacy system, because that's the weakest link in the chain. This creates a perverse dynamic where the buyer's technical debt becomes the vendor's financial liability, and savvy vendors respond by excluding the messy systems from their guarantees, leaving the buyer to integrate exactly the part they most wanted help with.

Middleware is becoming the actual product. As models commoditize, the durable value in many agent deployments is shifting to the integration layer, the translation, auth, idempotency, and side-effect handling that lets a smart agent act safely on a dumb system. The team that owns that layer owns the relationship. Watch for "agent integration platform" to become a category in its own right, separate from the agents themselves.

References

• McKinsey QuantumBlack, Insights on enterprise AI value and scale
• Anthropic, Computer use documentation
• Andreessen Horowitz (a16z), Writing on AI and software business models