The autonomy gap
Why connecting a model to enterprise systems is not the same as creating an autonomous operation.
Two different questions
Connecting a model to a CRM, a ticketing system and a data warehouse answers one question: what can this system reach? It is a real engineering problem and it is largely solved. Credentials, schemas, rate limits, retries — the work is well understood and the tooling is mature.
Running an operation autonomously answers a different question: what is this system permitted to decide, on whose authority, with what recourse when it is wrong? Nothing about solving the first question makes progress on the second. They are separate problems that happen to share a codebase.
The gap between them is where most enterprise AI work currently sits. A system has been connected. It has not been authorised. And because the connection was the visible, difficult, demo-able part, the absence of the second is easy to miss until something consequential happens.
What the gap looks like from inside
The symptom is not usually a dramatic failure. It is that nobody can answer straightforward questions about the system afterwards. Which rule produced this decision? Who approved the change to that rule, and when? If we disagree with what it did last Tuesday, what exactly do we change so that it does something different next Tuesday?
An integrated system can often answer none of these. Not because the information was destroyed, but because it was never structured as a record in the first place. Logs are a byproduct of execution; they are written for whoever is debugging, in whatever shape was convenient. Reconstructing a decision from them is an act of interpretation, and an interpretation is an argument rather than a record.
This is the practical difference between a system that is monitored and a system that is accountable. Monitoring tells you what happened. Accountability tells you who is answerable for it and what they can change.
Why the gap does not close on its own
There is a persistent assumption that governance is a later-stage concern — that the sensible order is to get it working, then add controls. In practice the order runs the other way, because the controls determine what working means.
A system built without a stated boundary will acquire one anyway, informally, through the accumulated habits of the people who use it: a step someone always checks, a case everyone knows to route manually, an output that a particular person quietly corrects before it goes out. These are real controls. They are simply undocumented, unowned, and resident in individuals rather than in the architecture.
Retrofitting explicit controls onto that means first discovering what the informal ones were — which is considerably harder than stating them at the outset, because the people performing them often do not describe them as controls. They describe them as their job.
Closing it deliberately
The closing move is unglamorous: state the boundary before execution begins. What the system is for, what it may reach, what it may decide alone, what requires a person, what happens when something falls outside all of that, and what evidence the run must leave behind.
This is what an Agentification Contract is. It is not a policy document and it is not a compliance artefact. It is the operational definition of the system, written before the system exists, in a form both the people and the machine can be held to.
The useful test is whether a permission can be revoked. A permission that was never written down cannot be withdrawn, because there is nothing to withdraw — only behaviour to discover and negotiate with. That is the autonomy gap, stated as precisely as it can be.