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.
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.