How work happens in Agent Studio
Follow a task through preparation, execution and review. Inspect evidence, handle incomplete runs and distinguish integration from acceptance.
Board lanes show the workflow stage. Live run state shows whether a CLI is executing. Review the changes and checks before deciding what to accept or send back.
The task pipeline
The platform owns task transitions and starts or stops runs. Every coding run uses an isolated Git worktree, including single-slot execution, resume and reissue. A card in progress can remain after a process has stopped.
- 0-backlog: new work waiting to be shaped.
- 1-preparation: define scope, constraints and the execution contract.
- 2-ready: queued work; dependencies can still prevent pickup.
- 3-progress: execution stage; check the live run state for actual activity.
- 4-auto-review: automatic review and post-processing.
- 5-human-review: human decision, including escalated work.
- 6-completed: work accepted by a person.
- 7-archive: retained history.
Run protocol
Claim. Run. Deliver.
One ordered attempt, from fenced pickup to reviewable evidence.- 01
run/claimedClaim
The Runner asks for ready work. The Task Server grants a time-bound lease with a fencing token.
- from
- agent-runner
- owns
- task server
- 02
run/startedRun
The selected coding-agent CLI works inside its task branch and isolated worktree.
- scope
- task/<id>
- proof
- checks + diff
- 03
run/deliveredDeliver
The Runner returns the verdict and durable evidence. The Task Server routes the result to review.
- payload
- status + evidence
- next
- review decision
task WEB-12 lease f_18 verdict → evidence → review Follow the Git revision
Task work becomes delivery evidence, passes automatic gates and integrates into the configured branch before human review. Promotion and a versioned Stable release follow separate checks.
Automatic review and rework
After a successful CLI run, automatic review examines the result and selected review aspects. It can request a bounded reissue, forward the task to human review or escalate with a reason. It does not complete the task on a person’s behalf.
- Missing required checks or screenshots can trigger rework.
- An inconclusive run with preserved partial results needs inspection; it must not disappear into repeated automatic retries.
Make the acceptance decision
Read the diff, run record and evidence. Accept the work, request a concrete revision or split out a follow-up. Integration and acceptance are recorded separately: the change may already be on develop while the task awaits your decision.
Exception example: DEMO-9 has exhausted its reissue budget. Open findings and pending integration remain visible beside the decision controls.
Check the release scope
The promotion dialog recalculates the exact Git range and identifies accepted tasks, open reviews, escalations and unattributed commits. Check that manifest before advancing main. Stable requires an immutable v<semver> tag on a qualified main revision and recorded build evidence.
Integrate checked work. Tag a verified release.
The release step promotes the integration branch with its recorded review state. An immutable version tag identifies a checked revision.
- 01Task cards
task/*Bounded work carries its diff, checks and review evidence.
- 02Integration branch
developRevisions join develop after configured gates pass. Human acceptance may still be pending.
- 03Release merge
develop → mainThe dialog shows accepted, unreviewed, escalated and unattributed work before confirmation.
- 04Release branch
mainA main revision records released code. A separate version tag identifies an immutable release.
- 05Version tag
v<semver>A checked main SHA is recorded with a version tag and release manifest. A Stable reference checkout can later move to another revision.
Inspect the result record
The platform commits task changes and recorded deliverables. Diffs, source-labelled screenshots, command output, summaries and the timeline let a reviewer inspect what happened. Preserving uncommitted agent output is the platform’s responsibility.
Record work done outside the runner
Use POST /api/tasks/{id}/external-completion to record external work with a summary, source and deliverables. It reconciles evidence and run status before the lane transition; the default target is human review. The external-completion badge identifies its origin.
Activity across projects: a queryable ledger of signals, decisions, and actions with per-project and event-class filters.
Run on a configured host
A remote host runs the CLI and task worktree while the Task Server keeps task state and review records. Each host needs configured repository access and accounts. Recorded Ubuntu 24.04 validation is evidence for that environment, not every deployment.
Discuss work in its project context
Project and task conversations can reference the board, context and evidence. Choose a configured CLI, model and thinking level, and check the recorded session usage and links before acting on an answer.