The demo goes well. An agent triages tickets, drafts responses, updates records, all in a sandbox stocked with clean sample data. Then it gets pointed at the real estate: an application from 2011, a database where the same customer exists four different ways, an integration that only works because a nightly job papers over the mismatch. The agent does not fail loudly. It does something worse. It runs, and it amplifies the mess.
Our AI work regularly starts inside a client's legacy estate rather than beside it, decommissioning dead subsystems and remediating data ahead of any AI layer, and that vantage point produces a consistent observation. When an agent initiative stalls, the blocker is rarely the agent. It is the foundation the agent was bolted onto.
Agents amplify whatever they sit on
A reporting tool sitting on messy data produces a wrong dashboard, and a human notices before anything happens. An agent sitting on messy data takes actions, at volume, with the confidence of software. Every inconsistency in the estate underneath becomes a behavior: duplicated customers become duplicated outreach, an ambiguous status field becomes a wrong decision applied a hundred times before lunch, an undocumented side effect becomes an action loop nobody designed and nobody is watching for.
This is why "which agent framework" is the wrong first question. Frameworks are interchangeable and improving monthly. The estate is neither. The right first question is what the agent will be standing on, and whether that surface rewards automation or punishes it.
The four layers to fix first
Sequencing is the whole game here. The remediation below is not a detour that delays the AI work. It is the first phase of the AI work, and skipping it does not skip the cost. It moves the cost into production, where it compounds.
The data model. An agent cannot resolve what the organization never resolved. If customer, order, and status mean different things in different tables, the agent inherits the ambiguity and acts on it. The fix is unification work: canonical entities, deduplication, and an explicit decision about which system is authoritative for each fact. Not glamorous, but every downstream agent behavior depends on it.
The boundaries. Agents act through interfaces. If the only way to update a record is a stored procedure with nine side effects, that is what the agent will trigger. Estates that expose clean, bounded operations, even just a thin service layer in front of the legacy core, give the agent a safe vocabulary of actions with limits built in. Estates that let it write to tables directly are handing it the master key and hoping the prompt holds.
The verification layer. Tests, validation rules, reconciliation reports: whatever confirms the system did the right thing after the fact. Human operators compensate for missing verification with experience and suspicion. Agents do not. Whatever checking has always lived in someone's head has to become executable before the agent takes over the keyboard, because the agent will not pause at the record that "looks off."
The dead weight. Every abandoned module, stale integration, and zombie scheduled task is surface area the agent can wander into, and context the model has to carry without knowing it is garbage. Decommissioning is the cheapest AI-readiness work there is, and it pays twice: less risk surface for the agent, less noise for the humans supervising it.
How to tell you are ready
A short honest checklist beats a maturity model.
Can you name the authoritative source for each entity the agent will touch? Can the agent's intended actions be expressed through bounded interfaces rather than raw table writes? Does a verification signal exist that would catch a wrong action within hours rather than at month-end? Has someone deliberately decided what the agent must never do, and is that enforced somewhere besides the prompt?
Four yes answers, and agent work on this estate is likely to compound: each automation makes the next one easier. Two or fewer, and the agent will spend its first six months discovering the estate's problems for you, expensively, in front of customers.
There is a diagnostic shortcut buried in this. If you cannot write the checklist answers down in an afternoon, that is itself the finding. The estate's actual behavior is undocumented, which means the agent will be operating on folklore. That is not a reason to abandon the initiative. It is the initiative's real starting point.
Spend the pilot budget in the right order
The uncomfortable implication is budgetary. A remediation sprint has no demo at the end, and an agent pilot does, so the pilot gets funded and the remediation gets deferred. Eighteen months later the pilot has been rebuilt twice, the estate is unchanged, and the organization has concluded that agents are overhyped when what it actually tested was its own data quality.
The teams that get this right run the sequence in the other direction. They treat readiness as the first deliverable (we wrote about what an honest modernization triage looks like), fix the two or three foundation gaps that gate the specific agent they want, and then ship the agent onto a surface that rewards it. The agent that arrives second ships faster than the agent that arrived first, and it keeps shipping, because the same clean foundation serves every automation that follows.
If you are weighing an agent initiative against a legacy estate and want the foundation assessed before the framework debate starts, that is what our readiness work covers. AI that ships, not AI that demos.