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 capabilities, 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 actions without asking after every step. State the scope, success criteria, and prohibited changes in the objective.

​
Goal commands

  • /goal shows the objective, whether it is running, paused, blocked, or complete, elapsed time, and token use. If you set a budget, it shows that too.
  • /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.

​
What a goal can show

A goal continues automatically while it is active and the session is idle. You can pause, resume, change the budget, and clear it. Embedder can mark it complete or blocked.
  • Active: automatic turns continue when the session is idle.
  • Paused: you stopped it, pressed Stop, the continuation cap was reached, or Embedder parked it.
  • Blocked: progress needs your input or an external change.
  • Complete: the objective was achieved and no required work remains.
A goal also stops if the model provider hits an account usage limit, or if a token budget you set is exhausted. If the same blocker stops progress for several turns, Embedder marks the goal blocked.

​
Goal limits

  • Objectives can contain up to 4,000 characters.
  • Automatic continuation stops after 50 turns in a row. Sending a message resets that counter.
  • An optional token budget stops the goal when usage reaches the budget.
  • Plan mode suspends continuation. Returning to Act mode allows the next continuation.
  • Pressing Stop during an automatic continuation pauses the goal. A message you send during 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. If the goal stopped because it hit the budget, raise the budget in /goal edit before resuming.

​
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

Each profile is a reviewed capability set:
  • Research and report reads the project, documents, or the web. You can keep work in the current conversation or reuse one child session that searches code, hardware documents, or the web.
  • Update a plan can edit plan documents in Plan mode.
  • Edit software can read and edit source files in Act mode. It cannot run shell commands.
  • Observe hardware can read hardware status and buffered or saved telemetry in Debug mode. It cannot change live hardware.
No loop profile can run shell commands, call MCP servers, load skills, flash a target, send device commands, use GDB, capture live traces, or spawn extra agents. A selected research child session 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 26, 2026