Bounded autonomy: limits every unattended agent run needs

This page covers bounded autonomy: limits every unattended agent run needs, and why each limit has to be checked before the agent acts rather than after. The short answer is six limits: an explicit list of tasks the run may work on, a maximum number of agent launches, a maximum number of retries per task, an elapsed-time limit, a stop after a set number of consecutive failures and a spending limit. Without them, an unattended run is bounded only by whatever breaks first: your usage quota, your test environment or your patience the next morning. Limits do not make an agent smarter. They make its worst night predictable, and they turn 'it kept going' into a recorded stop with a reason. The ideas apply whether you drive Claude Code or Codex CLI from a shell loop, a CI job or a project tool. For the money limit specifically, see whether you can put a hard spending cap on an agent.

The six limits, with an example

Task allowlist: the run may only work on named tasks, for example ENG-12, ENG-13 and ENG-15. Not 'whatever is next on the board', which changes while the run is going.

Launch count: the total number of agent processes the run may start, for example six. This catches loops where a supervisor keeps restarting a failing agent.

Retries per task: how many times one task may be attempted again after a failed check, for example one. A task that fails twice usually needs a person, not a third attempt.

Elapsed time: a wall-clock limit for the whole run and for each process, for example 90 minutes and 45 minutes. Agents can stall in a long test run or a tool that waits for input.

Consecutive failures: stop after, say, two failures in a row on different tasks. That pattern usually means the environment is broken (a missing service, an expired credential), not the tasks.

Spend: the maximum the run may cost. This is the hardest limit to enforce, for reasons explained on the spending page. Write all six down in the run's record before it starts.

Why limits must be enforced before effects

A limit checked after the fact is a report, not a limit. If the launch counter is only incremented after a process starts, a crash between the start and the increment leaves the counter wrong. If the time limit is only checked when the agent next reports in, an agent that never reports in has no time limit.

The safe order is: check the limit, record the intent, act, then record the outcome. Before a launch, the runner checks that launches remain, writes 'launch 4 of 6 for ENG-13' to durable storage and only then starts the process. A supervisor that can stop the process enforces the time limit, rather than trusting the agent to stop itself. Counters live on disk, not only in memory, so a restarted runner does not believe it has a fresh budget.

The same reasoning explains why spend is hard. Most of a request's cost is only known after the response comes back, so a limit checked afterwards will always overshoot by at least the last request. Enforcement before effects is the property to look for in any tool that claims to bound an unattended run.

What the task allowlist protects against

The allowlist is the limit people skip, because 'just do the next ready task' sounds efficient. It removes the most important boundary: the owner's decision about which work is in play tonight.

Consider what happens when an agent discovers a follow-up mid-task, such as 'the export module uses a different rounding helper and should be unified'. An unbounded runner sees a new ready task and may start it. Now the run is doing work nobody scoped, approved or prioritized, often in shared code. With an allowlist, the discovery is recorded as a new task and waits; the run continues only with the tasks you named. The page on tasks an agent discovers mid-work covers how to record them.

The allowlist also makes order explicit. If ENG-13 depends on ENG-12, the run should take ENG-13 only after ENG-12 has a verified completion, which is the subject of running dependent tasks in sequence. A list plus dependency order gives you a plan you can read before you go to bed.

When a limit trips

A tripped limit should stop the run cleanly, not degrade it. Do not let the runner raise its own limits, switch to a cheaper model on its own or skip the failing task and carry on with others unless you wrote that policy down in advance.

A good stop leaves three things behind. First, which limit tripped and its value: 'stopped: 2 consecutive failures (ENG-13, ENG-15)'. Second, the state of every task touched: completed and verified, failed with check output, or in flight. Third, anything uncertain, such as a process that may still be running or a write that may be half done. Uncertain items need reconciliation before anyone resumes; see recovering interrupted agent work.

Distinguish Pause from Stop. Pause holds the run with its counters intact, so resuming continues within the same limits. Stop ends it, and a new run needs a new authorization. Both are normal outcomes, and the wider list of conditions where a run should stop and ask goes beyond the six limits here.

QUESTIONS

How many retries should an unattended AI agent get per task?

Usually one. A first failure can come from a flaky test or a misunderstanding the check output clears up. A second failure on the same task almost always means the task is underspecified, the check is wrong or the agent is stuck, and a third attempt mostly adds cost and noise. Record the failures and leave the task for a person.

What is a consecutive failure limit for agent runs?

It stops a run after a set number of failures in a row, typically on different tasks. One failure is about a task. Several in a row usually mean something shared is broken, such as a missing database, an expired login or a full disk. Stopping early saves you from a night of identical failures and a confusing log.

Should an unattended agent run pick its own next task?

Not from the whole backlog. Give the run an explicit list of tasks and let it choose only among those, in dependency order, after the previous task has a verified completion. Tasks discovered during the run should be recorded and wait for you, so the night's work stays inside what you actually decided to do.

RELATED GUIDES

• Cards vs scheduled tasks: what starts an agent?
• What is a project management harness?

RELATED HARNESS PAGES

• Can you put a hard spending cap on an AI coding agent? Client-side budget flags in agent CLIs are estimates that can overshoot. A hard cap needs a reservation before each request. Here are practical limits instead.
• Running dependent AI tasks in sequence Running dependent AI tasks in sequence: start the next task only after a verified completion, one assignment at a time, with an explicit policy for blocks.
• When an autonomous agent run should stop and ask When an autonomous agent run should stop and ask: failed checks, missing approval, open blockers, impact obligations, out-of-scope writes or uncertain state.
• scheduled agent tasks Scheduled agent tasks done carefully: explicit prompts, readiness and authority checks, and why a started run is not a finished one.
• Interactive vs unattended AI coding sessions Interactive vs unattended AI coding sessions: terminal pairing, single unattended tasks and authorized multi-task runs compared on authority and failures.
• AI assistance vs autonomous project management AI assistance vs autonomous project management: five levels from assisted edits to autonomous coordination, and what each level must prove.