Phases of a run

A ticket crosses the board by running through the same phases every time. This page says what each phase does and what has to happen before the next one starts.

What a run is

A run is one pass of one agent over one ticket: a plan, an execute attempt, a review. Each run has its own timeline, and a ticket collects several of them. The Activity tab lists every run newest first, one line per event, with the agent’s own commands and their exit codes underneath.

A run is bounded by turns and by time, never by money. Herdloom does not track cost, because the agents are running on the subscriptions you already pay for. A run stops at a turn cap of 120, and it stops when the agent has produced nothing for five minutes. What a run took is reported as turns and elapsed time.

Triage

One read-only pass over the backlog. It gives every untriaged ticket a rank, a size, the tickets it depends on, the tickets it must not run beside, the areas of the codebase it touches, a one-line rationale, and flags for duplicates, oversized tickets and unclear ones.

It ends with a ranked backlog. Ranked tickets keep their place, pinned ones are never moved, and running tickets are never touched.

Plan

Read-only. The agent reads the repository and writes a structured plan: a goal, numbered steps, the files it expects to touch, the risks, any questions, and the spans of code it relied on.

The phase ends when you accept the plan, edit it, or reject it. If the plan asks a question, the ticket waits in Needs you until you answer. A project can be set to approve a plan that asks nothing on the spot, in which case a clean plan goes straight into execution.

Execute

The agent gets the approved plan as text, along with the code the planner relied on, read fresh from the checkout. When the planner and the executor are the same tool, it also resumes the planning session.

The phase ends with a structured result, and there are only three: done, blocked with a question, or needs review. A blocked result is not a failure. It becomes a question in Needs you with an answer box, and answering sends the run on rather than starting it over.

Verify

Verification happens outside the model, after every execute attempt, and an agent cannot skip it. Commits must exist on the ticket branch, and the project’s test command must pass.

If verification fails, the next attempt starts a fresh session with the ticket, the approved plan and a short history of what earlier attempts tried and how they failed. The project sets how many attempts are allowed. Failures are named in plain words: ran out of turns, tests failed, finished without changes.

Note

A circuit breaker stops the loop early when two attempts change nothing, when the same failure repeats, or when the agent makes no tool calls at all. A sign-in failure is marked not retryable, so attempts are not spent on something only you can fix.

Review

With review on for the project, a second agent reads the branch against the ticket. It turns the ticket into a checklist of requirements, judges each one from the code rather than from the worker’s summary, and lists findings with a severity and a file.

The phase ends in a verdict. If the reviewer asks for changes, the findings go back to the worker’s own session for a fix round and the reviewer looks again; how many rounds are allowed is a project setting. A review that produces no verdict is marked inconclusive, and the ticket still reaches you.

Next

See what waits for a person in Needs you, or decide how many of these phases stop for you in How much you approve.