Autonomous agent

How it works

An autonomous agent runs a loop instead of answering a single prompt. You hand it a goal, and it decides the next step itself, repeating until it judges the goal met or gives up.

A typical turn:

1. Read state — the goal, prior steps, tool results, and whatever context survived compaction.
2. Decide — the model chooses an action: call a tool, write a file, or stop.
3. Act — the harness executes that action against the real world.
4. Observe — the result feeds back into context for the next turn.

The defining trait is that step 2 belongs to the model, not to a human. Nobody approves each action. The agent selects tools, sequences them, recovers from errors, and terminates on its own. What makes it autonomous is not intelligence but this transfer of per-step control from the operator to the loop.

That transfer is the whole design problem. An assist tool fails safely — the worst case is a bad suggestion a human ignores. An autonomous agent fails forward: it acts on its own wrong decision, then acts again on the consequences. Autonomy is therefore a property of the harness, not of the model. The same model is an assistant behind an approval gate and an autonomous agent behind a tool that runs unattended.

Why it matters in an agent harness

Autonomy moves the failure surface from output to action. When a person drove every step, the harness only had to render suggestions. When the loop drives, the harness becomes the last thing standing between a stochastic decision and a production side effect.

That reframes what you build. You stop tuning prompts for better answers and start engineering the boundary the agent acts inside:

• Permissions — what tools exist, and what each can touch. An autonomous agent will use every capability you expose, so the tool surface is the risk surface.
• Reversibility — can you undo an action after the agent commits it? Checkpoints, dry-runs, and rollback turn an irreversible mistake into a recoverable one.
• Blast radius — how much can one bad decision damage before something stops it? Sandboxing and least-privilege bound the cost of being wrong.
• Observability — because no human watched each step, you need the trajectory recorded well enough to reconstruct why it did what it did.
• Termination — an iteration or tool budget so a confused loop stops burning instead of looping forever.

None of these make the model correct. They make its inevitable errors cheap, visible, and undoable. That is the actual job: not preventing autonomous action, but containing it.

Autonomous agent vs bounded autonomy

"Autonomous" is often treated as a binary — human-driven or not. In practice the useful axis is how much autonomy, granted where. Bounded autonomy is the same loop with explicit limits on scope, permissions, and reversibility.

The distinction changes a real decision: whether to add an approval gate on a given tool. You don't make an agent "more" or "less" autonomous globally — you decide, per capability, whether this action can be taken unattended.

The Rifty take

We treat full autonomy as a cost, not a goal. The interesting variable is never "can it act on its own" — it's how narrow we can make the boundary while still letting the loop do useful work end to end. We optimize for reversibility and a small blast radius over speed, and we accept slower, gated action on anything we can't cleanly undo. Autonomy you can't retract isn't a feature; it's a liability wearing a feature's clothes.

Common failure modes

• Autonomy without reversibility — the agent acts unattended on actions you can't roll back. Add checkpoints or a dry-run before you remove the human.
• Over-broad tool surface — every wired capability becomes something a wrong decision can reach. Scope tools to the task.
• No termination bound — a confused loop retries forever. Cap iterations and tool calls.
• Silent trajectories — an autonomous run nobody can reconstruct is an outage waiting to be un-debuggable. Record the loop.
• Autonomy theater — a human still approves every step, so you carry the cost of an agent with none of the leverage. Either bound it and let it run, or admit it's an assist tool.

Frequently asked questions

What makes an agent autonomous rather than an assist tool?

The transfer of per-step control. An assist tool responds while a human decides each move, so failures stay as ignorable suggestions. An autonomous agent chooses and executes its own next action in a loop, acting on its own decisions. The difference lives in the harness, not the model.

Is more autonomy always better?

No. Autonomy moves the failure surface from output to action, so an autonomous agent acts on its own wrong decisions. More autonomy is worth it only where actions are reversible and blast radius is bounded. On irreversible operations, unbounded autonomy is a liability, not a capability upgrade.

How do I make an autonomous agent safe to run unattended?

Engineer the boundary, not the model. Scope tools to least privilege, gate irreversible actions behind approval or dry-run, add checkpoints so mistakes roll back, cap iterations and tool budget so confused loops stop, and record the trajectory so any run can be reconstructed after the fact.

Does the same model become more autonomous with a better prompt?

No. Autonomy is a property of the harness around the model, not the model itself. The identical model is an assistant behind an approval gate and an autonomous agent behind a tool that runs unattended. What you expose and what you gate determines autonomy — the prompt only shapes decision quality.

What's the difference between autonomy and bounded autonomy?

Autonomy is a spectrum, not a switch. Bounded autonomy is the same loop with explicit limits on scope, permissions, and reversibility, decided per capability. You rarely choose global autonomy; you decide, tool by tool, whether a given action can be taken unattended or must pass an approval gate.