Work one workflow at a time rather than one system at a time. Expose a narrow interface to that workflow, let the agent read and draft proposals against it before it can change anything, then open one named write action behind a human approval. Widen only after that action has proven itself.
Choose the workflow before choosing the technology
The unit of retrofitting is a workflow, not an application. A workflow has a beginning, an owner, a decision in the middle, and a record at the end, which is exactly the shape an agent can be governed against.
Choose one where the decision is currently a bottleneck and the inputs are already digital. Something like preparing a credit review, triaging an incident, or assembling a supplier record works well because a person already reviews the output. That reviewer becomes the approval gate, so governance does not have to be invented alongside the agent.
Avoid starting with a workflow that has no human reviewer today. Adding both an agent and a new review step at once means two changes to the business process, and a failure cannot be attributed to either.
Read first, and let the proposals be the evidence
A read-only agent is not a rehearsal. It is the phase where the interface, the identity model, and the evidence trail all get exercised without any ability to cause harm.
Let it draft proposals for a period and have the existing reviewer read them. Three things come out of that. You learn whether the agent's evidence is good enough to trust, which is the real question. You learn where the interface is missing information the agent needs. And you get a body of accepted and rejected proposals that tells you which action to open first.
If the proposals are consistently poor, you have discovered that cheaply, and nothing in production changed. That is the outcome the sequence is designed to make survivable, and it is the reason AI prototypes fail in production less often when the read phase is real rather than skipped.
Open one action, then widen
When the write path opens, it opens as a single named operation with an approval in front of it. Not a general write capability, and not several actions at once.
- One operation. The agent can do exactly one thing to the outside world, and that thing has a name in the interface.
- A named approver. A person records approval or rejection with a reason, and the reason is stored.
- A separate executor. The component that performs the approved action is not the agent. The agent never holds the write tool.
- A recorded artifact. What was done is stored alongside who approved it and the evidence attached.
Widening then means adding a second named operation, with the same shape, once the first has been running long enough for its refusals and mistakes to be visible. Where the estate resists exposing even one operation, the earlier question of whether a rewrite is really needed is the one to answer first.
What tends to go wrong
Three patterns account for most trouble. Starting with a workflow nobody reviews, so there is no approval gate and no baseline. Giving the agent a broad service account because narrowing it looked like extra work, which turns every agent mistake into a data incident. And treating the read phase as a formality, which means the interface gaps are discovered after the write path is open.
Frequently asked questions
How long should the read-only phase last?
Long enough that the reviewer has seen the agent handle the awkward cases, not a fixed period. The signal to move on is that proposals are being accepted without material correction and the rejections are for reasons the agent could not have known. If corrections are still substantive, the interface or the evidence is incomplete.
Can we retrofit several workflows in parallel?
You can, once the first one has been through the full sequence, because by then the interface pattern, the approval mechanism, and the audit record are settled and reusable. Running the first two in parallel is what causes difficulty: a problem in the shared foundations shows up in both, and neither gives you a clean signal.
Does the legacy system have to change at all?
Often not, beyond adding an interface in front of it. Where it does have to change, the usual reasons are that permissions are decided by the caller rather than enforced by the system, or that a repeated write creates a duplicate. Both are narrow fixes rather than a rewrite.
