Enterprise AI Integration Patterns for Legacy Applications

Ask an enterprise AI team where a project is stuck and the answer is almost never the model. It is the policy administration system that only exposes a green screen. The core banking platform whose vendor charges per integration. The ERP where the supported read path is a nightly extract to a fixed-width file on an SFTP server. The claims system that authenticates by service account, so every query looks identical in the log regardless of who asked.

These systems hold the data that makes an agent useful — and they were designed before anything like an agent existed. Getting an enterprise AI agent platform to work against them is an integration engineering problem wearing an AI costume, and treating it as anything else is why pilots that demo beautifully never reach a production queue.

What legacy systems don’t give you

Agent platforms make four assumptions that older systems of record routinely violate:

• A documented, callable API. Many systems expose only a terminal interface, a vendor-controlled integration module, or a batch file contract. Where an API does exist, it may be a SOAP endpoint modelled on screens rather than on business operations.
• Per-user identity. Legacy integrations commonly authenticate with a single shared service account. Any agent connected that way inherits the union of everyone’s permissions and produces an audit trail that cannot distinguish one requester from another.
• Real-time reads at arbitrary volume. Capacity was sized for a known number of human users and a known batch schedule. An agent that fans out ten retrieval calls per question is a load profile nobody planned for.
• A safe write path. Writes often run through code that assumes a human at a screen, with validation in the UI layer rather than the data layer, and no straightforward rollback.

Each of those has a pattern that addresses it. None of them is solved by a better prompt.

Pattern 1 — Read from a projection, not from the system

The single highest-leverage decision is to stop having agents read the system of record directly. Instead, maintain a projection: a read-optimised copy of the subset the agents actually need, populated by change data capture, by the existing nightly extract, or by an event stream if one exists.

This buys three things at once. Query load never touches the production system, so an agent cannot degrade a service that a thousand people depend on. The projection can carry the metadata that retrieval needs — record status, effective dates, ownership, classification — which the source system often stores implicitly. And you get a natural place to enforce filtering, because metadata filters in private RAG work far better against a schema you control than against one you inherited.

The cost is freshness. That is a design input, not a defect: state the tolerable staleness per workflow. A knowledge assistant answering policy questions can live with an overnight refresh. A workflow checking whether a payment cleared this morning cannot, and needs a narrow real-time path for that one field rather than a real-time path for everything.

Pattern 2 — Put an anti-corruption layer in front

Every legacy system eventually leaks its quirks into whatever calls it: undocumented status codes, fields that mean different things depending on record type, errors returned as HTTP 200 with a message body. If agents call the system directly, those quirks end up encoded across every agent that touches it.

The alternative is a thin service that exposes a small, stable contract — a handful of named operations with typed inputs and predictable errors — and absorbs the mess behind it. The pattern is old and well understood in domain-driven design as an anti-corruption layer, and it applies here almost unchanged.

What makes it worth the effort in an AI context is that it becomes the single enforcement point. Permissions, rate limits, field-level redaction, and logging all live in one service instead of being reimplemented per agent. And when the underlying system is finally replaced — which is usually already on a roadmap somewhere — the contract survives the migration.

Pattern 3 — Treat screen and file interfaces as real interfaces

Sometimes there is genuinely no programmatic path: the only access is a terminal emulator or a scheduled file drop. This is not a reason to abandon the use case, but it does change the design.

File-based integration is more workable than teams expect, because it is explicit, auditable, and easy to test — you know exactly what left the system and when. Build the contract around the file: a defined schema, a checksum, a deterministic parser, and a rejection path for records that do not conform.

Screen-scraping and robotic automation should be the last resort, and should be scoped to reads or to narrow, reversible writes. It is brittle by nature, and a screen layout change becomes a silent data-quality incident. If it is unavoidable, make failure loud: assert on the structure you expect and stop rather than proceeding with whatever was parsed.

Pattern 4 — Separate reads from writes, and gate the writes

Reads and writes are different risks and deserve different controls. A read from a projection has essentially no blast radius. A write into a system of record changes financial, customer, or regulatory state.

For most legacy write paths, the defensible default is that the agent prepares rather than commits. It assembles the proposed change, shows the evidence behind it, and hands it to a named person who commits it through the normal interface — the same human-approval step pattern that governs any consequential agentic workflow, applied here because the target system cannot enforce it itself.

Direct writes are reasonable where the operation is narrow, idempotent, reversible, and covered by tests: appending a case note, setting a status field with a defined set of values, attaching a document. They are not reasonable for anything that moves money, changes a customer’s contractual position, or alters a record a regulator may later examine.

Identity is the control that gets skipped

The shared service account is the most common and most consequential shortcut. It collapses every distinction that governance depends on: which department asked, whether the requester was entitled to that record, and who is accountable for what the agent did.

Fixing it fully often means changes the legacy system cannot support. The practical middle path is to enforce identity in the layer you control — the integration façade — by carrying the requesting user or agent identity into every call, checking entitlement against your own access model before the call reaches the legacy system, and logging the resolved identity alongside the request. The downstream system still sees one account, but your audit trail does not, and scoping agent access at the data layer rather than in a prompt is what makes the arrangement reviewable.

Why this argues for staying inside the boundary

Legacy systems of record hold the material an organisation is least willing to expose: policy and claims history, core banking positions, patient administration, citizen records. An integration layer that serves agents is, by construction, a concentration of exactly that data — projections, caches, extracted fields, and logs of what was retrieved.

Building that concentration inside the organisation’s own environment keeps it under the controls the source systems already sit behind. Building it so that an external model provider is on the path means the most sensitive integration surface in the estate now has an outbound dependency. This is the practical version of the argument for on-premises AI: the model is only part of what needs to stay inside, and the integration layer is often the part that matters more.

How VDF AI fits this shape

VDF AI is designed to sit on top of estates like this rather than assume them away. VDF AI Agents call enterprise systems through governed tool definitions, so every operation an agent can perform is declared, permissioned, and logged — which is the enforcement point the anti-corruption layer pattern needs. VDF AI Data handles the projection side, connecting to enterprise databases and document repositories to build the retrieval layer agents read from, with metadata filtering and scoped access applied there rather than left to the source system. Human-approval steps cover the write path where a legacy system cannot enforce control itself. And because the whole platform runs inside your own environment, the projections, the tool logs, and the audit trail stay where the systems of record already are.