Usually yes. Agents reach existing systems through interfaces those systems already expose: an API, a queue, a database view, or a thin adapter written for the purpose. What decides the answer is whether a governable interface exists and can be constrained, rather than how old the code behind it happens to be.
The rewrite question is really an interface question
A system does not need to be modern to be reachable. It needs a boundary where a request can be described, permitted, refused, and recorded. Where that boundary already exists, an agent can work against it without the code behind it changing at all.
The difficulty appears when no such boundary exists. A batch job that writes directly to a shared schema, or a screen that is the only way to trigger a business action, gives an agent nothing to hold onto. In that case the work is to add an interface, which is smaller and safer than rewriting the system that sits behind it.
That framing changes the cost conversation. Adding an adapter in front of a stable system is bounded work with a testable surface. Replacing the system is open-ended work whose risk lands on the business process, not on the adapter.
What an adapter has to do beyond passing the call through
A pass-through wrapper is not enough for agentic work, because an agent will attempt things a human caller would not. The adapter is where those attempts get shaped.
- Name the actions. Expose a small set of explicit operations rather than a general-purpose escape hatch. An agent that can only call
raise_credit_reviewcannot invent a different write. - Carry identity. The call should say who it acts for, so the system behind it applies its own permissions rather than trusting a service account with broad rights.
- Make writes idempotent. A retried proposal must not create a duplicate record, and an agent will retry.
- Return refusals as data. A refused action should come back as a structured reason the agent can reason about, not as an opaque error.
- Record the attempt. Every call, permitted or refused, belongs in a log that can be read later.
Sequence the work so the risky part comes last
Reading before writing is the sequence that keeps this recoverable. An agent that can read a legacy estate and draft proposals is useful on its own, and it exercises the adapter, the identity model, and the evidence trail without being able to change anything.
Only once those proposals are being reviewed and found sound does the write path need to open, and it can open one named action at a time. This is the shape described in how you retrofit agents into a legacy estate, and it is why what has to be true about a codebase is worth checking before any of it starts.
Some systems genuinely resist this. Where a business rule exists only inside a user interface, or where the data model cannot express who did what, the honest answer is that an interface has to be built first. That is a modernisation project with an agentic goal, not an agentic project.
Frequently asked questions
Does this mean we never have to modernise the underlying system?
No. It means modernisation stops being a precondition. An adapter lets agentic work start against a system as it is, and it often reveals which parts of that system genuinely need replacing, because those are the parts where a governable interface cannot be described honestly. The evidence for a rewrite becomes concrete rather than assumed.
Is an adapter layer just technical debt by another name?
It can be, if it grows into a second business layer with rules of its own. Kept narrow, it is the opposite: a small, testable surface that documents exactly which operations are permitted against a system. The discipline is to expose named actions rather than a general gateway, and to resist putting logic behind it.
What if the existing system has no API at all?
Then the first piece of work is an interface, not an agent. That might be a service in front of a database, a queued command, or a scheduled export. It is bounded work with a clear acceptance test, and it is considerably smaller than replacing the system. Talk to us through contact us if that is where you are.
