Loop engineering is the practice of replacing yourself as the person who prompts the agent: you design a system that finds work, runs it, checks it, and repeats, only pulling you in when judgement is needed. A loop needs durable state, isolated execution, and a reliable done-signal. Lanes provides all three out of the box.
How Lanes does it
A designed loop has five parts: a skill that defines the work, a verifier it cannot fake, state it carries between runs, guardrails on what it can touch, and hard stops so it cannot run away. Lanes gives you all five out of the box, and the diagram above is the loop they make.
- The board is the loop's memory. Issues and columns are shared state that survives any single conversation, so a loop compounds progress instead of starting cold each run. The issue board is what the loop reads and advances.
- Sessions are the workers. Over the Lanes Desktop MCP server, an agent can start, stop, and resume a coding session on any issue, in plan mode or with a custom prompt.
- Status is the signal. Lanes classifies every session as busy, waiting for input, or
finished. The loop's rule is one line: a run is done, or needs you, when it is
awaiting_input,exited, orstopped. Poll that cheap status, not the raw terminal. - Worktrees keep runs isolated. Each issue gets its own git worktree, so ten looped sessions never collide on files or context.
- Verification is first-class. The loop can read the git diff per issue, run the tests, or start a second session whose only job is to review the first one's work before anything moves to review.
The patterns follow from those pieces: wait until done, babysit a fleet on a cadence, fix until the tests are green, or drain the whole backlog with one session per issue, each in its own worktree, each opening a pull request when it finishes. All of them are one prompt away; Building Loops walks through each with copy-pasteable prompts and a runnable driver.
Why it matters
Prompting an agent gets you a good first turn. A designed loop gets you the tenth turn without drift, because every iteration is checked against something objective before the next one starts. And the brakes are built in: a timeout, an iteration cap, and a terminal status stop the loop, while the review column keeps a human sign-off between the loop and anything that ships.
Set it up
- Enable the server. In Lanes, open Settings, then Local MCP, and toggle it on.
- Connect your agent. One-click buttons write the
lanes-desktopentry for Claude Code or Codex; any MCP client can point at the SSE endpoint on port 5353. - Paste a loop. Start small: "Check my running Lanes sessions every few minutes and tell me in one line what each one needs. Stop when nothing is left running."
- Scale it up. Point the loop at a column: one session per backlog issue, each in its own worktree, a PR per issue, results waiting in review.
Where this breaks without Lanes
Loops without a shared workspace end up as scripts: state in JSON files, progress in logs, and no way to see what is running or why. When an iteration goes wrong you reconstruct it from stdout. On the board, every run the loop starts is a card with a live terminal, a status, a diff, and a history you can click.
Further reading
- Building Loops: the status rule, the loop patterns, and a runnable driver.
- Loop Engineering: Stop Prompting, Start Looping: the thinking behind the practice.
- Lanes Desktop MCP: the tool surface the loop drives.
- Multi-agent coding orchestration: agents dispatching agents on the same board.
- Git worktrees for AI agents: the isolation layer under every looped session.