Runs and attempts
A run is one execution of a task. An attempt is one try inside that run. The distinction matters because agents are not expected to be right the first time, and the platform is built around that.
A run holds attempts
Section titled “A run holds attempts”When a task is ready to execute, the platform creates a run and dispatches it to an execution backend. The run is the durable record: it belongs to the task, carries a budget, and ends once, with an outcome.
Attempts alternate between two phases:
- Implement. Do the work, or revise it after feedback.
- Review. Score the work against the task’s acceptance criteria and record what is still wrong.
A failing review is handed to the next implement attempt in full, so the fixer reads the required fixes and open gaps, not a score. The agent keeps its working session when the score improved and starts a fresh one when it did not, so an agent told the same thing twice gets fresh eyes. The cycle repeats until the review passes or the run hits a limit.
The run’s budget caps the iterations, along with a time limit, a spend limit, and the score a review has to reach.
Which model reviews
Section titled “Which model reviews”The review does not run on the model that wrote the code. When the run’s own checks have all passed, it runs on the stronger of the two models your agent is configured with, the one the platform escalates to when an implementation stalls. When a check has failed there is nothing to gate yet, so the review runs on the implementation model and is advisory: it tells the next attempt what to fix and cannot finish the run on its own.
The review can also run on a different coding agent. That choice is a field on the run request, set at dispatch, and it defaults to the agent doing the work. See coding agents. A reviewer from another vendor uses that vendor’s stored credential and default model. Whichever model reviewed is recorded on the review itself.
Where a run can stop
Section titled “Where a run can stop”A run is pending while it waits for a backend, in progress while an attempt is working, review while it is being scored, and finalized when it is over. Two states are not failures, they are the platform waiting for you.
Paused for approval. Some tasks require a person to clear the work before an agent starts. Such a run is created already paused and goes nowhere until you approve or deny it, and the decision is recorded on it.
Paused for budget. When a run reaches its soft spend limit it stops rather than quietly continuing. Raising it is an approved, recorded action, not a setting an agent can change.
Cancellation is the third way out: a cancelled run is terminal and leaves its record behind.
Verification profiles
Section titled “Verification profiles”Every run bound to a repository carries a verification profile, chosen when the task is merged from the task’s own spec. Not every change deserves the same proof.
| Profile | Chosen for | What the run carries |
|---|---|---|
| Lite | Every changed file is documentation, and no new verify command | The repository’s own gates, the checks the spec names, and a review on the model that wrote the change |
| Standard | Everything else | Lite, plus a deciding review on a second model |
| Full | Anything sensitive: a migration, a workflow file, or code named for authentication or payment | Standard, at the fullest verification a run can carry |
You can raise a profile until the first run starts, and never lower one. For a managed run the projected cost is shown first, and your plan sets the highest profile it may use. See budgets.
What a run leaves behind
Section titled “What a run leaves behind”A finished run is not just a status. It leaves:
- A timeline. Attempt by attempt: what the agent did, read and changed, and what the review said.
- Artifacts. Decks, pages, diagrams, images and documents, each attached where it was created.
- Code, on a branch. Coding work is committed and pushed to a task branch by the runner, never by the agent. See workspaces and git.
- Cost and usage. What the run spent, which is what budgets are enforced against.
Outcome, and what happens next
Section titled “Outcome, and what happens next”A run finalizes as accepted, rejected, partial, or inconclusive, and reading a run walks through what each ending leaves you.
None of them ships anything on its own: what a run produces waits for your review, and for work in a repository the ship verification is what merges the branch.
Next steps
Section titled “Next steps”- Budgets: the limits a run executes inside.
- Execution backends: where an attempt actually runs.
- Your first task: a run watched end to end.