Skip to main content
Goals and bounded loops both continue work across turns:
  • A goal keeps pursuing one objective in the current conversation until it completes, pauses, blocks, or reaches a limit.
  • A bounded loop runs at a reviewed cadence with fixed tool permissions, an iteration cap, and a three-day expiry.
Use a goal for continuous autonomous execution. Use a bounded loop for scheduled research, plan maintenance, software edits, or read-only hardware observation.

​
Pursue a goal

Set a goal with a concrete objective:
Embedder stores one goal per conversation. Setting an active goal switches the session to Act mode and enables auto-confirm for that goal run. When a turn ends and the session is idle, Embedder starts another turn with the same objective and current usage.
An active goal can edit files and run approved Act mode tools without asking after every step. State the scope, success criteria, and prohibited changes in the objective.

​
Goal commands

  • /goal shows the objective, status, elapsed time, token use, and budget when one is set.
  • /goal edit opens the editor for the objective and optional token budget.
  • /goal pause stops automatic continuation but keeps the record.
  • /goal resume returns an unfinished goal to active execution.
  • /goal clear removes the goal from the conversation.
Setting a different objective while a goal is unfinished requires replacement confirmation because replacement resets its accumulated usage.

​
Goal statuses

A goal can be:
  • active: automatic turns continue when the session is idle.
  • paused: you stopped it, the continuation cap was reached, or the runtime parked it.
  • blocked: progress needs input or an external change.
  • usageLimited: the model provider stopped a continuation for account usage.
  • budgetLimited: the configured token budget was exhausted.
  • complete: the objective was achieved and no required work remains.
The agent can mark a goal complete or blocked. It should use blocked only after the same condition prevents progress for at least three consecutive goal turns. You control pause, resume, budget changes, and clearing.

​
Goal limits and accounting

  • Objectives can contain up to 4,000 characters.
  • The default safety cap is 50 consecutive automatic continuations. A user message resets that counter.
  • An explicit token budget stops the goal when cumulative use reaches the budget. Cached input tokens are excluded; uncached input and output tokens count.
  • Plan-like modes suspend continuation without changing the stored active status. Returning to Act mode allows the next continuation.
  • Pressing Stop during an automatic continuation pauses the goal. A user message that preempts a continuation becomes the next step instead.
  • A pending question or confirmation prevents another automatic turn from starting.
When a budgeted goal completes, Embedder reports the final token use. A budget-limited goal cannot resume until you raise its budget in /goal edit.

​
Schedule a bounded loop

Run /loop without arguments to open the interactive designer:
The command asks you to choose the goal, workload, cadence, iteration limit, completion rule, and any required mode transition. You review the generated loop plan before it starts.

​
Workload profiles

  • Research and report uses read-only tools. You can keep work in the current conversation or reuse one foreground codebase-explorer, document-explorer, or web-searcher child session.
  • Update a plan can edit plan documents under Plan mode restrictions.
  • Edit software can read and edit source files in Act mode. Shell execution is unavailable.
  • Observe hardware can read status and buffered or saved telemetry in Debug mode. It cannot mutate live hardware.
Every profile excludes shell commands, MCP tools, skills, background agents, general subagents, live captures, command sends, flashing, and GDB. A selected research specialist is read-only and is reused across iterations.

​
Cadence and bounds

The designer offers these fixed choices:
  • Cadence: every 5 minutes, 15 minutes, or 1 hour
  • Maximum iterations: 3, 10, or 24
  • Early completion: stop when the goal is demonstrated, stop when the answer is complete, or disable early completion so only you or a safety bound can stop it
Every plan also expires three days after creation. The loop stops at the iteration limit or expiry, whichever comes first.

​
Mode transitions

Each profile has a target mode:
  • Research uses Plan mode.
  • Plan maintenance uses Plan mode.
  • Software edits use Act mode.
  • Hardware observation uses Debug mode when Debug is available.
If the current mode differs, you can approve that exact transition with the final plan, require another confirmation before the first iteration, or keep the current mode. Declining a Plan transition downgrades plan editing to read-only research. After a transition has occurred, unexpected mode drift pauses the loop. A change to the active project, workspace, or conversation also pauses it for review.

​
Manage a loop

Run /loop again while a loop exists. The control view shows its plan, state, completed iterations, failure count, and next run time. From there you can pause, resume, or stop it. Embedder applies these runtime guards:
  • Runs never overlap. A busy session or pending interaction delays the next iteration.
  • Background task results land before the next iteration so it evaluates current evidence.
  • Three consecutive failed iterations pause the loop.
  • An iteration that reports a need for user input, new authority, or an unobservable external change pauses the loop.
  • A completion marker stops the loop only when early completion was enabled in the reviewed plan.
  • Pausing a running iteration aborts it without counting that aborted run.
An unchanged monitored condition is not a failure. The loop should report the current evidence and wait for the next cadence unless it needs a decision that scheduled observation cannot supply.
Last modified on August 24, 2026