Autonomous Runs

Two commands run UGENT without you at the keyboard. /loop repeats a prompt. /goal pursues an objective until it is done.

Both are bounded: by iterations, by wall-clock time, by tokens, and — for /goal — optionally by your project's own checks.

/loop: repeat a prompt

/loop 5m check the build status

Fixed interval. The prompt runs every five minutes until you stop it.

/loop watch for new issues and triage them

Self-paced. UGENT decides when to run next based on how the last iteration went, rather than on a clock.

Command	Does
/loop status	Show running loops
/loop list	List all loops
/loop stop <id> or /loop stop all	Stop one loop or all of them

/goal: pursue an objective

/goal migrate the auth module off the deprecated client

UGENT works toward it across turns, reporting progress as it goes, and stops when it judges the objective met.

Command	Does
/goal status	Show current progress
/goal pause	Pause pursuit
/goal resume	Resume a paused goal
/goal clear	Clear the current goal

Verification gates

A goal ends when the agent decides it is done. That is a self-assessment, and a confident agent can be wrong.

Configure goal_gate and your project's own checks must agree before the verdict is accepted:

[autorun]
goal_gate = [
  "cargo fmt --all -- --check",
  "cargo clippy --all-targets -- -D warnings",
  "cargo test",
]
goal_gate_max_retries = 3
goal_gate_timeout_secs = 600

Every command must exit zero. If one fails, the completion verdict is downgraded to in-progress and the failing output — bounded, tail-retained, so you get the errors rather than the build banner — is fed back into the next iteration. The agent gets the real error, not a bare rejection.

Commands run in order and stop at the first failure. After goal_gate_max_retries consecutive failures of the same command, the goal stops as blocked rather than grinding against a check it cannot satisfy.

Gate commands are trusted

They come from your ugent.toml, not from the model, which cannot set, append to, or influence them. That is why they run without the confirmation prompt the bash tool applies to model-authored commands.

Put nothing there you would not run yourself unattended.

Reruns are skipped when nothing changed

If a gate fails and the agent then changes no files, rerunning costs a full build to reach the identical failure. UGENT fingerprints the worktree and skips that, telling the agent plainly that nothing changed.

One limitation is worth knowing. The fingerprint is built from git, so it cannot see gitignored files. If your gate depends on a generated config, a .env, or a downloaded fixture, a fix to one of those can look like no change at all.

Including ignored files would not fix this — it would break the feature. A gate is usually a build or test command, so it writes to the build directory itself; the fingerprint would then differ on every run and the skip would never fire. On this project's own repository that measures as 20,000 extra entries and a digest that changes across a plain cargo check.

The harm is bounded instead: the final attempt always runs the command for real. A wrong skip can waste an iteration, but it can never be the reason a goal is declared blocked.

Bounding the run

[autorun]
# /loop
loop_max_iterations = 100
loop_max_duration_hours = 168
loop_min_interval_secs = 30

# /goal
goal_max_iterations = 50
goal_token_budget = 2000000   # omit for unlimited
goal_compress_every = 5       # compress the session every N iterations; 0 disables

# both
max_concurrent_runs = 3
max_consecutive_failures = 3

goal_token_budget counts input, output, and cache-write tokens, and excludes cache reads — you are billed for what was written, not for what a cache hit saved you.

goal_compress_every matters on long runs: without periodic compression a goal that runs for fifty iterations will spend its later turns mostly re-reading its own history.

Watching a run

/goal status and /loop status report from the TUI. The Sub-Agents panel (Ctrl+F, or /subagents) shows anything the run delegated, and /btw gives a read-only summary that never enters the agent's own context.

To stop a run that is going wrong, /goal pause or /loop stop — both take effect at the next iteration boundary rather than killing work mid-tool-call.