A team decides to deploy an AI agent and discovers that the system holding the key data is fifteen years old, has no interface and is understood by one person. The usual reaction is to postpone the agent until the system is modernised. That can mean years of waiting for a project that was never the goal.
This article is about the narrower question: what in an old system actually blocks an agent, and what can you do cheaply to unblock it. If you are planning the full replacement of a legacy system, read how to modernize legacy systems without stopping business instead.
Old does not mean blocked
Age is a poor test. A stable old system with a clean export can serve an agent well, while a new tool with messy data and open permissions can not. Ask what the agent needs from the system, and check only that.
Four checks for every system
Run these for each system the agent would touch. A short written answer per check is enough.
1. Can the agent reach the data?
Look for the existing ways in: an API, a database view, a scheduled export, a report that can be saved as a file. A system with none of these is a real blocker for live use. Systems with even a nightly file export are usually fine for a first, read-only agent.
2. Is the data good enough for this task?
Do not judge the whole database. Pick the 5 to 10 fields the agent would use and look at a sample of real records: empty values, duplicates, the same customer spelled three ways, dates in different formats. Our article on data readiness explains why this is where many AI projects stall.
3. Can the agent write back safely?
Reading and writing are different risks. Ask whether a change can be logged, who made it, and whether it can be undone. If the system cannot tell the agent's changes from a person's, keep the agent read-only, or let it write to a separate place such as a draft list that a person approves.
4. Does anyone understand the system?
If the only person who knows how it works is leaving, that is a risk for the agent and for the business. Ask them to write down where the data lives, what the odd rules are and who to call. This is often the cheapest and most valuable fix on the list.
Cheap first fixes
| Problem | Cheap first step |
|---|---|
| No interface | Scheduled export to a file or a read-only database view |
| Messy fields | Clean and standardise only the fields the agent uses |
| Cannot tell who changed what | Give the agent its own account, or keep it read-only |
| One person knows everything | A short written description of the data and the rules |
| Data spread over spreadsheets | Name one source of truth for the agent's task |
If a thin layer is needed in front of the old system, the options in API integration patterns for growing companies will help you choose a simple one. Keep the layer small: it exists to give the agent a narrow, controlled way in.
When to leave the system alone
If a system fails the checks and the fix is large, do not make it a condition for the whole agent. Pick a neighbouring process whose data is already usable and start there. Put the old system on the modernisation plan with a clear reason: the agent use case it would unlock. Connect it later, one system at a time, as described in connecting an AI agent to CRM, email and documents. Before that step, run the written tests from evaluating AI agent reliability before production.
Worked example (invented numbers, for illustration only). A team has three candidate processes for an agent. System A has a nightly export and 40 of 200 sampled records with a missing customer number, 20%. System B has no export or interface. System C has an API and clean data. The team starts with C. For A it fixes only the customer number field, and for B it asks the one expert to write down the data layout, a task of about two days. Nothing is rewritten, and the agent is working on C while the cheap fixes for A and B are still under way. If the team had waited for a full replacement of B, the agent would not have started at all.
Common mistakes
- Making full modernisation a precondition. The agent waits for a project that has its own schedule.
- Cleaning the whole database. Only the fields used by the agent matter first.
- Giving write access because the system allows it. Technical possibility is not a safety check.
- Ignoring the person who knows the system. Their knowledge is the real dependency.
- Building a large wrapper first. A small read-only layer is enough to learn from.
Where to start this week
List the systems your first agent would use. For each, write a short answer to the four checks, sample 20 to 30 real records for the fields involved and name the owner. Choose the system with the most passes as the starting point, and add one cheap fix for each system that failed a check. For the wider picture, an AI readiness assessment can help you place this step.
Sources
- Your own system documentation, exports and sampled records, collected as described; all figures in the worked example are invented for illustration.
- Our related articles linked above.