Systems Thinking
The agent and the estate
Most agentic AI programmes do not fail on the target state. They fail on the source state. The pilot works, the agent reasons well, and then it meets the estate. Four ways decades of working systems push back against autonomous agents, and why the messiest estates may hold the biggest advantage.
4 min
INSIGHT
FIELD NOTE
I
Systems Thinking
4 min
estimated reading
2026
published
The Agent and the Estate
A conversation repeats itself with enough regularity that I can now predict its shape.
An enterprise has run an agentic AI pilot. The pilot went well. The agent understood the request, reasoned its way through the steps, called the right systems and produced an answer that stood up to scrutiny. Everyone in the room saw it work.
Then the pilot was scheduled for production, and it stopped.
Not failed, exactly. Stalled. The timeline slipped, then slipped again. Somebody commissioned an integration study. The sponsor began describing it as a learning exercise.
The question I am then asked is almost never about the model.
It is: the pilot worked, so why can we not scale it?
The room nobody inspected
The answer, in most cases, is the estate.
A pilot needs a model and a prompt. A production agent needs to read from and write to the systems that actually run the business. The order management platform. The billing engine. The service desk. The scheduling system somebody wrote in 2004, which now has eleven integrations hanging off it and no surviving documentation.
Enterprises spent thirty years building those systems. They work. They carry load. And nobody who built them imagined they would one day be operated by something that decides for itself.
Four things tend to go wrong at that boundary.
Legacy systems assume a caller that behaves identically every time. Retry logic, transaction boundaries, idempotency, all of it rests on that assumption. An agent that reasons its way to a slightly different sequence on Tuesday than it used on Monday breaks a contract nobody ever wrote down, because nobody ever had to.
Agents need to understand state. In most estates, state is spread across a relational schema built for transactions, a document store added later, a message queue, and a few spreadsheets a regional team maintains by hand. The information exists, it is simply not in a form anything can reason over without an expensive middle layer that never appears in the business case.
Access control assumes a person. An agent acting on behalf of a user, calling a service that calls another service, breaks the audit trail quickly. Who authorised this becomes a genuinely difficult question. Under the EU AI Act, where autonomous systems in sensitive domains attract high-risk classification, it is a question that needs answering before deployment rather than after an incident.
And almost nobody can size the work. Estimates get built from documentation instead of from code. Documentation describes the system as designed. The code describes it as it became. The distance between the two is where programmes quietly lose their schedule.
The anthill, again
I have written before about an anthill in a storeroom, and the week I spent persuading a colony to relocate rather than drowning it. The lesson took me years to recognise.
We are taught to approach problems like this:
Problem → Solution
The anthill suggested a different sequence:
Problem → What are we trying to achieve? → What should be preserved? → What is the real issue? → Solve
I keep finding that the second question is the one that gets skipped.
In an agentic programme, the stated problem is usually a process that costs too much or takes too long. The desired outcome is autonomy over that process. The prescribed solution is to select the highest-value use case and point an agent at it.
What should be preserved rarely comes up at all.
Yet the estate is precisely what must be preserved. It is running the business today. Every workaround inside it is load-bearing. The undocumented integration is undocumented because the person who built it left, not because it does not matter.
Ask that question early and the sequence inverts. You stop asking which process deserves an agent, and start asking where the estate already offers a clean boundary. An existing API. A proper service contract. A workflow engine that manages its own state honestly.
That is a less exciting place to begin. It is also where programmes reach production.
What I would do differently
First change the mindset.
"Legacy is memory, not debt".
Read the source state before designing the target state. Not a capability survey. An actual reading of what the systems do, what they can safely expose, and what they cannot be made to do at all. It is unglamorous work and it is usually skipped in favour of the architecture diagram.
Build the accountability layer first. Logging, traceability, explainability, human checkpoints. These are normally treated as governance overhead to be retrofitted once value is proven. In regulated European operations that is backwards. Systems designed to be auditable from the start clear approval faster. Governance is not the tax you pay after the value. It is part of how you reach it.
Say plainly what should not be autonomous yet. Some processes are not ready. Saying so in month one is worth considerably more than discovering it in production. A roadmap that names its own exclusions is more credible than one that claims the whole landscape.
The part that stays human
There is a reading of all this that sounds discouraging, as though the old estate were simply an obstacle. I do not mean it that way.
The organisations best placed for agentic AI are often not the greenfield ones. They are the ones carrying deep, complicated, decades-old estates, provided they still have people who understand them. Thirty years of process logic encoded in working systems is not only technical debt. It is a description of how the business genuinely operates, and it is more accurate than any process map, because it has been executing every day for decades.
An agent that can read that context is worth a great deal more than one reasoning from a clean slate and a well-written prompt.
Which brings me back to where the anthill left me.
The tools have become extraordinary. They can analyse, generate options, and shorten the path to execution in ways that would have seemed implausible a few years ago. What they cannot do is decide what deserves to be preserved.
An agent can work out how to act. It cannot work out what we should leave alone.
And as with the storeroom, the thoughtful answer tends to take longer than the obvious one, and rarely delights anybody who was hoping to be finished by Friday.
This article builds on two whitepapers I co-authored at LTM: "Beyond Intelligence: Architecting the Agentic AI Enterprise" and "Unlocking Agentic AI: Transforming Processes and Operations at Scale." Both are published on the LTM site with references in the publications section.
“
Most agentic AI programmes do not fail on the target state. They fail on the source state. The pilot works, the agent reasons well, and then it meets the estate. Four ways decades of working systems push back against autonomous agents, and why the messiest estates may hold the biggest advantage.
Article summary
CONTINUE EXPLORING
More writing on technology, AI economics, systems thinking, leadership, and mentoring.