article feature

Autonomous mode: bounded unattended continuation

Autonomous mode injects follow-up turns until quality gates pass or configured continuation, turn, token, or wall-clock limits stop further work. Goals, heartbeats, and schedules provide durable objectives and recurring prompts. A budget limit stopping the loop is not proof of task success.

v v0.7.1reviewed 2026-08-09evidence officialsources S010, S006, S090cutoff 2026-08-09
Daemon recovery

First-party announcement, documentation, release, or installer.

Persistent goals

A persistent goal gives unattended work an explicit objective that can survive beyond one conversational turn. Goals are created by a user or host action; the runtime does not infer a durable goal from every ordinary prompt.

The goal supplies direction, not proof of completion. Verification still needs a relevant quality gate or a human review of the resulting artifacts.

Heartbeats

Heartbeats provide recurring prompts that let a session check state and continue work over time. They are a continuation mechanism for a durable objective rather than evidence that useful progress occurred on every interval.

A heartbeat should be paired with bounded work and an observable outcome. Otherwise it can consume provider and runtime resources while repeatedly revisiting the same state.

Schedules

Schedules trigger prompts at configured times, allowing work to recur without keeping the terminal interaction in the foreground. They complement persistent goals and daemon-backed sessions.

A scheduled trigger only starts or steers work. It does not ensure that the provider, daemon, dependencies, or task-specific preconditions will be available when the schedule fires.

Quality gates

Quality gates run defined checks before autonomous work is considered acceptable. A gate can turn a concrete test, build, or other command into a stopping condition for the continuation loop.

The guarantee is no broader than the command. A passing narrow test does not validate unrelated behavior, and a poorly selected gate can stop work while important requirements remain unchecked.

Budgets and limits

Continuation count, turns, tokens, and wall-clock time place independent bounds on unattended operation. These limits contain resource use and give the runtime explicit reasons to stop.

  • Continuation and turn limits bound how many additional interactions occur.
  • Token limits bound model usage.
  • Wall-clock limits bound elapsed runtime even when other budgets remain.

Limits are not success

Reaching a budget is a stop condition, not a success condition. The agent may have completed the task, partially completed it, or exhausted its allowance without producing a valid result.

Judge the final state through the configured quality gates and the requested artifacts. Report a budget stop explicitly instead of presenting bounded termination as completion.