A working agent loop needs four things: a repeat (something that re-invokes the agent), shared state (so runs compound instead of starting cold), isolation (so parallel runs do not collide), and a done-signal you can verify. Every tool class in the loop engineering space gives you some of those and makes you build the rest. This page is an honest map of who gives you what.
At a glance
| Dimension | Hand-rolled scripts | Agent SDKs | Cloud background agents | Lanes |
|---|---|---|---|---|
| The repeat | cron, tmux, while-loops | Your code owns the loop | Vendor's runner | You bring it: a /loop, a cron, or a small driver |
| Shared state | JSON files and logs | Whatever store you wire up | Vendor's dashboard | The issue board |
| Isolation | Manual worktrees, if you remember | Yours to build | Vendor sandboxes | A git worktree per issue, managed |
| Done-signal | Exit codes, grep | Callbacks and return values | PR shows up | Session status: busy, waiting, exited |
| Oversight | Tail the logs | Build a UI | Web dashboard, diffs at the end | Live terminals on a board |
| Billing | Your CLI subscription | API metering | Vendor seats or metering | Your CLI subscription |
Where the alternatives fit
- Hand-rolled scripts. A cron entry and a shell loop around the CLI is the fastest start and the fullest control. It is also where loops go to become archaeology: state in JSON files, progress in logs, and nothing to look at when a run goes sideways. Fine for one repo and one nightly job; see Lanes vs tmux for the longer version of this trade.
- Agent SDKs. Frameworks like the OpenAI Agents SDK or LangGraph put the loop in your code, with real control flow, retries, and structured outputs. That is the right call when the loop is the product you are shipping. For your own development workflow it means building state, isolation, and oversight yourself, and paying per token on API metering instead of the subscription you already have.
- Cloud background agents. Codex cloud tasks, Cursor background agents, and their cousins run the loop on vendor infrastructure and hand you a pull request. Zero local footprint, easy to start from a phone. The loop itself is opaque: their sandbox, their cadence, their models, and your code on their machines.
Where Lanes fits
Lanes takes the position that the loop should run where you can see it. The board is the loop's shared state, every run is a card with a live terminal, each issue gets its own managed worktree, and the Lanes Desktop MCP server gives any agent the tools to read the board, start sessions, and check results. Sessions run the official CLIs interactively, so the work draws on the subscription you already pay for.
What Lanes deliberately does not ship is the repeat itself. You bring it, and pair it with
what your CLI already has: a /loop on a cadence, a scheduled run, a stop-hook, or the small
driver in Building Loops. Lanes supplies everything the repeat acts
on: state, isolation, status, and the diff to verify against.
Choose what, when
- Choose a script if it is one repo, one job, and you will read the log tomorrow anyway.
- Choose an SDK if you are building an agent product and the loop must ship as code.
- Choose a cloud agent if you want zero local setup and are comfortable with the loop, and your code, living on someone else's machine.
- Choose Lanes if the loop is part of your own development week: fleets of local sessions, verifiable diffs, a human checkpoint in the review column, and no second bill.
These compose more than they compete. A scheduled cloud task can file issues that a local Lanes loop drains into PRs, and an SDK-built service can drive the same board over MCP.
Further reading
- Building Loops: the status rule, loop patterns, and a runnable driver.
- Loop engineering: the use case this page compares tools for.
- Loop Engineering: Stop Prompting, Start Looping: why the practice took off.
- Lanes Desktop MCP: the tool surface a loop drives.
- Lanes with Claude Code: pairing the board with the CLI that runs your sessions.
See Lanes Desktop or start with the quick start.