Modernising legacy systems for AI agent access

Last updated: July 2026

Most enterprises trying to deploy AI agents in 2026 hit the same wall. The agents work. The models are ready. The vendor pitches are compelling. And then the target system — the ERP that runs on a database from 2007, the ticketing platform with no API, the underwriting engine written in a language the current team does not speak — cannot be called by anything modern. Legacy system integration is now named as the first of three core obstacles to agentic AI because older systems lack the APIs, real-time execution, and modularity that agents need. The engineering response is not a rewrite. Rewrites take years, the enterprise cannot wait, and the operational risk is unacceptable. The response is a shim layer — a modern, agent-accessible surface that sits between the agent and the legacy system, translating in both directions, protecting each side from the other. This post is the pattern for building that shim layer. It is a cluster child of our pillar on agentic AI workflow services.

Key takeaways

• The shim layer is the default modernisation pattern for agent access. Not a rewrite. Not a lift-and-shift. A translation layer that makes the legacy system agent-accessible without changing it.
• The anti-corruption layer (ACL) is the shim's job. It converts legacy formats and contracts into modern standards and stops legacy technical debt from bleeding into the agent's world. The ACL is the structural guarantee.
• The interface choice — REST, GraphQL, MCP — depends on the fleet. One agent, one tool: REST. Many agents, one tool: MCP. Many agents, many tools, need for query composition: GraphQL.
• Agent-readable is more than API-readable. The shim also has to expose schema, entity resolution, and provenance the agent can reason over. An endpoint that returns raw legacy field names is a technically valid API and an operationally useless one.
• The strangler-fig pattern retires the shim over time. The shim is designed to eventually replace the legacy system, not stay forever. Every service the shim owns is a candidate for a proper rewrite once the agent workload proves the shape.

The five failure modes when you skip the shim

Every enterprise that tries to point an agent directly at a legacy system encounters some subset of the same failures:

The legacy schema leaks into the agent's world. The agent's prompts contain field names like CUST_ADR_LN1_TXT because the legacy database schema flows straight through. The prompt becomes a cryptography exercise. The ACL exists specifically to prevent this bleed.

Rate limiting on the legacy system breaks the agent. The legacy system was sized for a handful of concurrent human users. The agent runs a hundred queries in a burst and takes production down.

Legacy authentication is incompatible with modern identity. The legacy system uses a static service account and cannot represent per-user identity. The agent has no way to preserve the identity of the human on whose behalf it acts. Audit becomes impossible.

Response shapes are unstable. A field that returns a number in most cases returns a string sometimes, or is missing under some legacy code path. The agent's downstream reasoning breaks on the edge case.

No sandbox environment. The legacy system has one environment: production. The agent development team is testing against live customer records.

The shim layer's job is to solve all five. It is not just an API on top of an API. It is a governance, identity, and reliability surface that the legacy system did not have.

The shim layer's five responsibilities

Every shim layer that ships successfully in 2026 does the same five things:

Translation. The shim converts between the legacy system's data shape and a modern, agent-readable shape. Legacy field names get normalised. Legacy status codes become semantic strings. Legacy timestamps get standardised to UTC ISO-8601. This is the classical ACL work.

Identity propagation. The shim accepts modern identity — OAuth 2.1 bearer tokens, session-scoped credentials — and translates that into whatever the legacy system understands (service-account impersonation, per-user credential mapping, whatever the legacy stack supports). The audit trail on the shim side records who initiated each call.

Rate limiting and back-pressure. The shim protects the legacy system from agent traffic. A hundred-query burst becomes a queued, paced sequence. Circuit breakers stop cascading failures when the legacy system starts responding slowly.

Response shape stabilisation. The shim normalises response variability. Missing fields get defaulted or explicitly nulled. Type coercion happens on the shim side. Response schemas are versioned and validated. Agents reason over a stable contract, not the legacy system's edge cases.

Sandbox and replay. The shim exposes a sandbox surface that returns realistic responses without touching the legacy system. This lets the agent's development, evaluation, and CI pipelines run without needing production access to the legacy stack.

Skip any of the five and the shim becomes another leaky abstraction. All five make the shim a real integration layer.

The interface choice — REST, GraphQL, MCP

Every shim layer exposes an interface. In 2026 there are three defensible choices, and the choice depends on the shape of the fleet.

REST. Sensible when the fleet is small and the queries are predictable. One agent, one tool, one endpoint. The shim exposes a small number of hand-crafted endpoints tuned for the specific queries the agent runs. Fast to ship, easy to debug, familiar to every backend engineer. This is still the winning choice for a large share of workloads.

GraphQL. Sensible when the agent needs to compose queries across multiple legacy entities. Order + customer + line items + shipment status, in one round-trip, without inventing a new REST endpoint for each combination. GraphQL's schema also gives the agent an introspectable surface — the agent can discover what queries are possible. This is the shape that pays back when the shim is fronting a system with many related entities.

MCP. Sensible when many agents will call the shim, and governance sits on the tool-call layer. The MCP decision framework from our protocol post applies unchanged — MCP pays off when the fleet benefits from one governance layer over many tool calls. For a shim in front of a widely-consumed legacy system, this is often the right choice.

Nothing prevents combining these — a shim can expose a GraphQL surface for exploratory work and an MCP surface for governed tool calls over the same underlying data. But the choice sets the expectations for how the fleet consumes the shim, and that choice deserves the Phase 1 conversation.

Agent-readable is more than API-readable

An API that returns valid JSON is not automatically usable by an agent. Agent-readable requires three properties on top of a working endpoint:

Schema the agent can reason over. Every field has a name that means something outside the legacy context, a type, and a docstring that describes what it represents in business terms. customer_lifetime_value_eur beats CLV_AMT. An agent reading a tool description with a well-annotated schema will use it correctly the first time.

Entity resolution. The shim gives every entity a stable identifier the agent can use across tool calls. A customer returned by the "get customer" call carries an identifier that the "get orders" call accepts. Without entity resolution, the agent has to reason about which representation of a customer it is holding — a task humans get wrong and models get more wrong.

Provenance. The shim's responses include where the data came from, when it was last updated, and how confident the shim is in the value. This lets the agent reason about staleness and reliability — critical when the legacy system is a batch-updated data warehouse rather than a live transactional system.

These three properties turn a technically valid API into a surface an agent can operate on without hand-holding. They are the concrete meaning of the agent-readable data governance definition from our pillar on data readiness — the pattern applied to a legacy system.

The strangler-fig endgame

The shim is not a permanent architecture. It is a bridge, and the bridge has a planned decommissioning.

The strangler-fig pattern describes what happens next. As the shim proves the agent-facing shape of each legacy capability, the corresponding legacy system component becomes a candidate for a proper modernisation. Not a lift-and-shift — a re-implementation of the capability, with the shim's agent-readable surface as the specification. The new implementation lands behind the shim; the shim continues to expose the same contract; the legacy system component gets retired. From the agent's perspective, nothing changes.

This is what makes the shim investment pay back over multiple years. In year one, the shim makes agents possible against the legacy system. In years two and three, the shim's contract becomes the target architecture for the modernisation. In year five, the legacy system is gone and the shim is the system.

The alternative — pointing agents directly at the legacy system and betting on a future rewrite — leaves the enterprise stuck. The rewrite gets postponed indefinitely, the agent workload accumulates on brittle direct integrations, and the eventual modernisation project has to re-instrument every agent. The shim pattern avoids that trap.

The five-phase build

The sequence we run when we ship a shim layer into an enterprise:

Phase 1 — Contract design. Sit with the agent team and the legacy system owners. Define the agent-readable contract: what entities exist, what queries are needed, what response shapes look like. This is the highest-impact phase and the one enterprises are most tempted to skip.

Phase 2 — Interface choice and skeleton. Pick REST vs GraphQL vs MCP. Stand up the shim skeleton with a small number of full paths — enough to prove the pattern, not enough to lock in the design.

Phase 3 — ACL and legacy integration. Wire the shim to the legacy system. Translation, identity, rate limiting, response stabilisation. Ship one path from the agent all the way to the legacy system and back.

Phase 4 — Sandbox and CI. Ship the sandbox surface. Get the agent's CI pipeline running against the sandbox. This is what unblocks the agent team from waiting on production legacy access.

Phase 5 — Fleet the pattern. Add more paths. Add more agents. Retire direct legacy access. This is the phase where the shim starts paying back the investment.

Phase 1 is where projects succeed or fail. A shim built without a rigorous contract design ends up mirroring the legacy system's shape, which is exactly the failure mode the shim was supposed to prevent. Every hour spent on the contract pays back tenfold when the agents actually start calling it.

The one question that decides the whole architecture

Every legacy modernisation-for-agents project turns on one question: is the shim the future, or a bridge?

If the shim is a bridge, it is designed to be strangled out. The contract is what matters; the implementation is temporary. Investment goes into the contract quality and the sandbox. The legacy system's replacement is planned from day one.

If the shim is the future, it is designed to become the system. The contract is what matters; the implementation gets industrial-grade over time. The legacy system may never fully retire — parts of it might live behind the shim for years — but the shim is where the enterprise's forward architecture lives.

Both answers are legitimate. The wrong answer is not deciding. A shim built without a stance on this question ends up with neither the disciplined bridge economics nor the industrial-grade future architecture. Naming the answer in Phase 1 is what makes the rest of the work coherent.