2026-07-18 · Updated 2026-08-27 · 4 min read
Start a bounded AI-agent development loop
Run your first coding-agent loop with one task, one iteration cap, reviewable per-cycle evidence, and explicit stop conditions.
By Juno AI INC · yylo · bounded-loops
A bounded agent loop is one coding agent working one task under an explicit iteration cap, with your review between cycles. The cap is the boundary: the agent gets a fixed number of passes, execution stops, and you inspect what actually changed before anything continues. Bounds are what make a first agent session safe to look away from and cheap to correct.
Install and initialize once
yy and yylo are equivalent launchers; use one consistently. Initialization creates the project's .juno_task/ directory: the installed scripts, the kanban task store, and the project prompt that yy start runs when you do not pass -p. The versioned install command for the current release lives in the YYLO documentation, and this page's install action always carries the generated package version.
Put one verifiable outcome in the task
A loop is only as bounded as its task. Write the outcome as something a command can verify, and record dependencies as blockers instead of burying them in prose.
"Fix the flaky login test" is bounded because a test run decides it. "Improve the auth area" is not, because no gate can tell the agent it is finished.
Run exactly one cycle first
-i 1 is the whole idea: one iteration inside this invocation, then a stop. Without -p, yy start runs the installed project prompt, which points the agent at ready kanban work behind guardrails; pass -p 'Fix the login bug' to steer one cycle yourself. -v keeps progress human-readable instead of raw JSON.
Start with a single cycle even when you plan more. You learn what the agent does to your repository on a budget of one before you spend three or five.
Check the evidence each cycle produced
A cycle is not finished when the process exits; it is finished when its evidence holds up:
- The kanban response — what the agent says it did, in its own words.
- The commit — what actually changed in the repository diff.
- The run log —
yy view-log .juno_task/logs/claude_shell_*.log --output json-only --limit 50replays the run without terminal scrollback. - The session id — printed in the run summary, and the handle for continuing this exact conversation later.
If the response claims a passing gate but the diff shows unrelated edits, the cycle failed your review even with a zero exit.
Continue deliberately, or stop
yy cc continues the most recent session in this shell with its saved runtime settings, so the next cycle starts from the agent's own context instead of a cold prompt. Raise the cap only after single cycles have earned it: -i 3 once three clean cycles passed review, never before.
Stop conditions belong to the loop; they are not an admission of failure. Stop and mark the task done when its gate passes. Stop and narrow the task when two cycles produce no forward progress. Stop and take the work back when the agent repeatedly edits files outside the outcome you wrote.
What separates this from an unbounded loop
An unbounded loop re-prompts the same agent until a quota, a crash, or a human interrupts it; every extra cycle compounds changes nobody reviewed. A bounded loop makes your review the unit of progress, because the loop cannot continue past evidence you have not checked. When a whole queue is genuinely safe to advance, Run Until Completion repeats bounded iterations until no open work remains and stops on stale, unchanged cycles. When the work outgrows one task at a time — ordered steps that exchange results, or independent tasks worth fanning out — choosing between the runners is the next decision to make.