Everyone is suddenly talking about AI agents. Gartner expects task-specific agents inside 40% of enterprise applications by the end of 2026. Defense teams are building them, developers are sending AI-assisted pull requests into open source, and vendors are already describing assistants that anticipate what you need before you ask.
- Autonomy is three dimensions, not one dial: what an agent may read, what it may change, how long it runs unattended.
- Trust is a property of the record an agent leaves behind, not a feeling about the model.
- Widen the remit until the record stops being legible — then stop. That line is your answer.
Talking about agents
So the next question sounds obvious: how much autonomy should we give them? I think that is the wrong first question.
The sharper question is this: when an AI agent acts, who can still explain what happened? Everything else — model choice, framework, permission scheme — is downstream of that answer.
How much autonomy
Autonomy is usually discussed as a dial, from suggestion on the left to full delegation on the right. That framing flatters vendors and confuses everyone else, because it implies a single dimension where there are at least three: what the agent may read, what it may change, and how long it may run unattended.
A model that drafts a reply for me has almost unlimited reading autonomy and no writing autonomy. A model that files the reply has both, and the failure modes are not comparable. Treating them as neighbours on one slider is how teams end up surprised.
The people declining agentic helpers are not behind. They are refusing a trade whose terms they have not been shown.
Defining risk and trust
Risk here is not the chance that the agent is wrong. Models are wrong constantly and we cope. Risk is the cost of being wrong quietly — an action taken inside a system where nobody was watching, in a format nobody reviews, at a time nobody remembers.
Trust, then, is not a feeling about the model. It is a property of the record the model leaves behind. If I can reconstruct what an agent did, in what order, on whose behalf, I can extend it a surprising amount of latitude. If I cannot, no benchmark score buys my confidence.
Good behaviour, rooted in transparency
Good agent behaviour is boring and legible. It announces intent before acting. It works in reversible increments. It reports what it touched in the same place a colleague would have reported it, not in a log file three systems away.
The best agentic tools I have used share one habit: they make the plan the artefact. You review a short list of intended steps, you edit it, and only then does anything move. Nothing about that is a capability limitation — it is a courtesy, and it is the reason people keep the tool switched on.
Transparency is also a compounding asset. An agent that explains itself teaches its operator where its judgment is thin, and that operator writes better instructions next week.
Bad behaviour: blatant, stealthy, and in between
Blatant failure is the easy case. The agent deletes the wrong branch, the alarm goes off, someone restores it and writes a postmortem. Painful, survivable, instructive.
Stealthy failure is the one worth designing against. The agent completes the task in a way that looks correct, drifts slightly from what was asked, and nobody notices for a quarter. Small silent edits to shared documents. Confident summaries of data it could not actually see. Tickets closed with plausible resolutions that were never verified.
Between those poles sits most real behaviour: mostly right, occasionally creative, rarely annotated. That middle is where governance either exists or doesn't.
Adaptive intelligence is coming
The next generation of these systems will not hold still. They will adjust to the operator, remember preferences, and shorten their own loops. Helpful, and quietly destabilising for anyone whose safety model assumed a fixed function.
Once an agent adapts, an approval granted in March describes a different system in September. Permissions need expiry dates for the same reason passwords do.
Beyond determinism: influencing behaviour
We cannot specify our way out of this. Rules enumerate cases; agents encounter situations. The practical alternative is influence: shape the incentives, the defaults, and the friction, and accept a distribution of outcomes rather than a guarantee.
In practice that means defaults biased toward reversibility, friction that scales with blast radius, and an escalation path the agent is rewarded for using. Not a cage — a gradient.
This is closer to managing a capable new hire than configuring a build server, and it asks for the same skill: clear expectations, visible work, short feedback loops.
Build the trust ecosystem that fits you
There is no universal setting. A two-person studio and a regulated bank need different answers, and both are allowed to be conservative while they learn where their own silent failures live.
So: start with the record, not the autonomy. Decide what you must be able to reconstruct, instrument that, and then widen the agent's remit until the record stops being legible. Stop there. That line is your answer, and it will move.
And when a colleague says they would rather not hand this off yet, take the objection seriously. They are usually not describing a fear of the model. They are describing an absence of evidence.