Bounded autonomy

How it works

Bounded autonomy replaces per-step approval with a declared box. You define the box once, and the agent moves freely inside it. The box is not a vibe — it is a set of enforced limits:

• Tool and scope limits: which tools the agent may call, and against which resources (repos, tables, namespaces).
• Budgets: iteration, token, wall-clock, and cost ceilings that halt the loop when exceeded.
• Action class: which effects are permitted autonomously (usually reversible ones) versus which still route to a gate.
• Reversibility guarantees: checkpoints, worktrees, or transactions that make in-box actions undoable.

The control loop then looks like: the agent proposes and executes actions; the harness checks each against the boundary before it runs; anything outside the box is refused or escalated; everything inside runs without a prompt. Your oversight moves off the per-action path and onto two other surfaces — the boundary you designed up front, and the trajectory you review afterward. The human is still in the loop, but at the edges of the box, not at every keystroke. Done well, the agent's freedom and your control both go up, because the freedom is contained by construction rather than by trust.

Why it matters in an agent harness

A harness exists to make an agent controllable without making it useless. Per-action approval gives control but destroys throughput and pulls the operator into a babysitting loop. Full autonomy gives throughput but couples your safety to the model behaving well on inputs you never saw. Bounded autonomy is the harness's answer to that tradeoff: it lets the agent run long, unattended trajectories while capping what any single run can cost or break.

Concretely, the boundary is where your other controls attach. Blast radius is whatever the box permits, so sizing the box is sizing your worst case. Reversibility inside the box means a bad trajectory is recoverable by rollback rather than by incident response. Budgets convert runaway loops from an open-ended risk into a bounded, observable failure. And because the agent never asks about in-box actions, your observability and evals — not live approvals — become the primary way you learn what it did. The design work is front-loaded and legible instead of reactive and ad hoc.

Bounded autonomy vs human-in-the-loop

These are often posed as opposites; they are complements that place the human at different points.

The practical design is not to pick one. You grant bounded autonomy over the reversible interior and keep a human-in-the-loop gate on the small set of irreversible or out-of-box actions. The skill is drawing the line in the right place.

The Rifty take

We optimize for the largest box an agent can be trusted to run inside without a human on the action path — and we make the box's edge, not the operator's attention, the thing that holds. We accept that this front-loads real design work: naming permitted tools, budgets, and reversible action classes is harder than clicking approve. We accept it because a boundary is legible, testable, and reusable, while live approval is none of those. The line we enforce is reversibility: autonomy is granted over actions we can undo, and irreversible effects stay on a gate.

Implementation checks

• Make the boundary enforced, not advisory. A limit the agent can talk its way past is documentation, not a control. Check it in the harness before the action runs.
• Size the box by blast radius. Ask what the worst in-box trajectory can cost or destroy, and shrink scopes and budgets until that answer is acceptable.
• Guarantee reversibility inside the box. Checkpoint or sandbox in-box actions so a bad run is undone, not cleaned up.
• Keep irreversible actions on a gate. Deletes, payments, external sends, and production migrations should escalate, not auto-run.
• Define behavior on breach. Decide explicitly whether an out-of-box request halts, escalates, or degrades — and log every breach.
• Instrument the trajectory. Since you removed per-action prompts, your after-the-fact record has to be good enough to reconstruct what the agent did and why.
• Review the boundary, not just the model. When something goes wrong, the first question is whether the box was drawn wrong, not whether the model was clever enough.

Frequently asked questions

How is bounded autonomy different from human-in-the-loop?

Bounded autonomy puts the human at the box's edge — designing limits and reviewing trajectories — while human-in-the-loop puts them on the action path, approving each risky step live. They combine well: grant autonomy over the reversible interior and keep a live gate on rare, irreversible actions.

How do I decide how large the box should be?

Size it by blast radius. Ask what the worst permitted trajectory could cost or destroy, then shrink tool scopes, budgets, and action classes until that worst case is acceptable. The box is right when an in-box failure is recoverable by rollback, not by incident response.

Is bounded autonomy safe for irreversible actions?

Not by default. Bounded autonomy is safest over reversible actions you can checkpoint or undo. Irreversible effects — deletes, payments, external sends, production migrations — should sit outside the box and escalate to a gate, so autonomy is granted precisely where recovery is cheap.

What should happen when an agent hits the boundary?

Define it explicitly: halt, escalate to a human, or degrade to a safer path. An undefined breach is where bounded autonomy fails silently. Every out-of-box request should be refused before it runs and logged, so the boundary stays enforced rather than advisory.

Does bounded autonomy reduce oversight?

It relocates oversight rather than reducing it. You move control off per-action approvals and onto two surfaces: the boundary you design up front and the trajectory you review afterward. That trades reactive, live judgment for legible, testable, reusable limits and stronger after-the-fact observability.