FredrinWhat a run spawns
- A branch, named from the ticket.
- A worktree - a real, isolated git checkout of your repository on that branch.
- A Worker - an agent session running inside that worktree.
The isolation is the point. Ten running tickets are ten checkouts and ten agent sessions that cannot overwrite one another's files.
Plan or Build
Every ticket can be run two ways.
Build does the work: the Worker writes code, commits, and opens a pull request.
Plan writes no code. The Worker researches the ticket, asks up to three questions only a human can answer, and ends with a plan saved onto the ticket. Then it stops and asks whether to build it.
Plan mode earns its place when the request has a real fork in it. If different answers would produce a materially different implementation, plan first. If the ticket is unambiguous, plan mode will correctly ask nothing, and you have spent a couple of minutes buying certainty.
The questions are not a formality. A Worker is told to surface only decisions it genuinely cannot settle from the code, and to refuse to ask about naming, wording, visual style, priority or effort. Zero questions is a correct outcome.
When a plan is ready, one click flips the same ticket to Build, and the plan rides into the build as context.
Watching a run
Open the ticket and you get two views of the same session.
Chat is the readable one: the agent's turns, the questions it asks, the decisions it makes. This is where you answer when it needs you.
Terminal is the raw session, the same one you would see if you had run the CLI yourself. Useful when something has gone strange, unnecessary the rest of the time.
You do not have to watch either. Leave, come back tomorrow, and the transcript is still there.
Interrupting
You can talk to a running Worker. Anything you send lands in its session and it adapts. This is the fastest way to correct a run that is heading somewhere you did not intend, and it is much cheaper than letting it finish and sending it back.
The concurrency cap
There is a limit on how many Workers run at once on a machine, and you set it yourself in settings. Tickets beyond the cap queue and start as slots free up.
The cap exists because Workers are real processes on real hardware. If you want more of them at once, raise the limit or add a remote agent to run some of them on another machine.
When it finishes
The run ends when the agent's own session lifecycle says it ended, not when a model claims success. The ticket moves to Review and you get a diff to read.
If the Worker got stuck instead of finishing, see when a Worker stops.
Next steps
- Review and merge - the other half of the loop.
- Branches and worktrees - the git model underneath.
- When a Worker stops - blocked, waiting, or stale.