Giving agents more tools does not solve trust
The market is obsessed with expanding autonomy: browser, terminal, email, CRM, code and infrastructure. The harder questions come later: what happened, why, with what evidence and under whose authority.
Useful autonomy needs boundaries
A serious system distinguishes read from write, reversible from irreversible actions, facts from hypotheses and model output from mechanical evidence. When critical evidence is missing, it must be able to block instead of improvise.
Final authority remains human
More autonomy does not imply less responsibility. The test itself must also be auditable: environment, method, hypotheses and sufficiency of evidence should be challengeable before a conclusion or change is promoted.
Capability and authority are different dimensions
An agent being able to open a browser, execute commands or write to a CRM describes technical capability. It does not answer who authorized that action in this case, on which object or with what consequence. Architecture should represent authority separately: reading, proposing, writing, reversible actions and actions that create obligations are not equivalent.
Trust should be contextual
There is no single trust level for “the agent.” A system may be allowed to summarize case files but not send them, prepare a campaign but not publish it, propose a change but not deploy it. The more specific the boundary, the less need there is to trust one model globally across heterogeneous tasks.
Blocking can be correct behavior
When approval is missing, a source is stale or an action exceeds permissions, stopping is a valid outcome. Designs obsessed with task completion tend to interpret every block as failure and seek alternate paths. In consequential systems, that persistence can be exactly what is not wanted.
Record effects, not only reasoning
To audit autonomy, it matters which tool was invoked, with what scope, what changed and which evidence justified the transition. A model’s later explanation does not replace a mechanical record of the action. Reasoning can help understanding; system state should make verification possible.
The wrong metric
Counting how many tasks finished without human intervention rewards autonomy even when the task should not have finished alone. Better metrics distinguish safe automation, correct escalations, necessary blocks, reversibility and errors caught before effects occur. The goal is not absence of humans; it is using human authority where it adds real control.
A useful test
One concrete way to put this idea under pressure is to give the agent a real tool with one action deliberately outside its authority and verify that it recognizes, blocks and leaves useful evidence for escalation. The test should not ask only whether an answer appears, but which state remains, what evidence is preserved and whether another operator can understand why the system behaved that way. This turns an editorial principle into an observable property and exposes places where architecture still depends on invisible assumptions.
What this note does not claim
More guardrails do not make an agent infallible; the goal is to reduce the space in which a model error can directly become an unauthorized consequence. This distinction matters because a good practice stops being useful when it becomes a universal promise. The goal is to make one design boundary explicit so it can be discussed, tested and adapted to the domain while facts, inferences, permissions and decisions remain separate.