Yes, and legacy systems are often where agents help most, because staff spend hours there copying, checking and translating. The deciding factor is rarely technology. It is whether anyone has written down what the old system's fields and codes mean, because an agent reading a status code nobody documented will guess, and a guess is not a basis for action.
What makes legacy systems hard for an agent?
The connection is usually the smaller problem. Older systems can be read through exports, database copies or screens, as covered in whether an AI agent can work without an API. The harder problems are about meaning and timing.
| Legacy trait | Risk for an agent | What to do |
|---|---|---|
| Codes whose meaning lives in staff heads | Agent misreads a status and acts on it | Write a data dictionary; make it a registered source |
| Fields reused for other purposes over the years | A "notes" field holding account flags | Document each reuse; test on real records |
| Overnight batch processing | Data mid-update; changes rejected in windows | Schedule around batches; check freshness |
| No test environment with realistic data | Cannot test writes safely | Run in shadow mode on live reads first |
| Duplicated data across old and new systems | Two versions of the truth | Name which system is the record for each field |
| Change freezes and slow release cycles | Integration changes wait months | Prefer reading and drafting, which need no change to the system |
The first row is the one that catches teams out. In many older systems, a code like "07" on an account means something specific that every experienced clerk knows and no document records. Writing those meanings down is unglamorous work, and it is the work that makes the agent safe.
What can the agent do, and what stays with people?
| The agent does | Stays with people |
|---|---|
| Reads records and translates codes using the data dictionary | Defining what each code means |
| Compares records between the legacy system and newer ones | Deciding which system is right when they disagree |
| Drafts changes for staff to enter, in a work queue | Entering changes the system cannot take safely from the agent |
| Enters narrow, well-tested changes, once certified | Owning the integrity of the legacy system |
Comparing records is a particularly good first job. Legacy and newer systems drift apart over time, and finding the differences is slow work for people; see how to reconcile records between two systems with an AI agent. A work queue is the usual hand-over point when the agent drafts and a person enters.
Who answers for the result?
The process owner answers for the agent's decisions. The legacy system's owner, often in technology, answers for the system's integrity and must agree any route by which the agent writes to it. Both should sign off the data dictionary, because a wrong definition is a shared failure.
What does this look like in practice?
Take a life insurer running policy administration on a system several decades old. Staff answering customer queries look up policies, translate codes and work out surrender values by hand.
The insurer starts the agent at depth 1. Before it goes live, two long-serving administrators spend a few weeks documenting every status and product code the agent will meet, including three codes that had changed meaning over the years. The dictionary becomes a registered source. The agent reads policies overnight from an export, translates them, and prepares a plain summary for each policy with a query that day.
Shadow running shows one gap: policies converted from an acquired book use a different code set. The dictionary is extended before the agent goes live. Writes stay with people; the agent never changes the legacy system directly.
What controls make it safe?
- A data dictionary as a registered source, owned and versioned.
- A named system of record for every field the agent uses.
- Freshness checks against batch timings.
- Shadow running on live data before any action, since realistic test environments are rare.
- Narrow write access, agreed with the system owner, or none at all.
- Monitoring for format changes in exports and screens.
Connecting the agent in general is covered in how to connect an AI agent to your systems.
Older systems do not change the stages of deploying an AI agent: train, shadow, certify, widen; they make the shadow stage matter more.
Questions people ask
Should we replace the legacy system first?
Not for the agent's sake. Agents can work with old systems now, and the data dictionary you build will help any later migration.
Can the agent help write the data dictionary?
It can propose meanings from patterns in the data, at depth 1. People who know the system confirm each one before it becomes a source.
What if the vendor of the legacy system no longer supports it?
Then prefer reading and drafting over writing. Changes to an unsupported system are riskier whoever makes them.