# Autonomy is a runtime decision, not a model decision

An agent run once produced a perfectly reasonable plan, executed it cleanly, and wrote the output into the wrong workspace. No exception. No alert. The model behaved exactly as intended. The runtime had simply never been told where the run ended.

That is the shape of most early agent incidents. Nothing crashes. Something correct happens somewhere it should not.

## Two planes, and only one of them should be able to act

The control plane decides what a run is permitted to do: which tools are enabled, which environment it targets, what budget it has, whether it is switched on at all. The runtime does the work inside those limits.

Teams collapse the two because it is faster. The agent process reads its own configuration, resolves its own credentials, picks its own target environment. Now the only record of what the agent was authorised to do is the code path it happened to take, and you can reconstruct it only by reading logs afterwards.

Keep them separate and permission becomes something you can query before a run rather than infer after one.

## Split the run into read, plan, act, commit

Most agent work is harmless. The dangerous part is small and easy to name: the moment a side effect leaves the process.

Marking those phases explicitly gives you somewhere to put a gate. Reads and planning run free. Actions execute in a sandbox with a scoped credential. Commits are the only phase that touches shared state, which makes them the phase you can require approval for, rate limit, or refuse outright in a given environment.

The alternative is one undifferentiated `run()` where a retry might resend an email.

## The isolation questions an operator should answer cold

- Which tenant, user, workspace and environment is this run bound to, and is that binding enforced or merely conventional?
- Who owns the artifacts it produced, and are they scoped to the same workspace as its inputs?
- Can this run be paused or killed right now, by somebody who is not an engineer?
- If the feature flag goes off, does an in-flight run stop, or does it finish?

The last one catches people. A kill switch that only prevents new runs is a launch control, not a stop control. Both are worth having. They are not the same thing, and during an incident you will badly want the second.

## Closing thought

Every runtime permission your agent holds should be visible somewhere other than the source code. If the only way to answer "what was it allowed to do" is to read the implementation, you do not have a boundary. You have a habit that has held up so far.

*Part 1 of 5 Days of Agent Infrastructure.*