Understand the Workbench Before You Scale the Work
A curated map of the few concepts that explain how Agent Studio turns coding-agent sessions into reviewable software tasks.
Read this in order once, then return by concept. It distills the product model instead of mirroring an internal concepts folder file by file.
The Task Is the Unit of Work
A task binds intent, repository boundary, agent run, changed files, evidence and the final decision. The prompt is only one part of that record.
Next read
Continue to Lifecycle to see how that contract moves through the system.
- Use a task when the outcome can be reviewed and accepted independently.
- Keep constraints and proof beside the requested change.
- Split work when one decision would hide several unrelated outcomes.
State Shows Who Must Act Next
Ready, running, automated review and human review are attention states—not decoration. The board stays acute while the task detail preserves history.
- Ready means the task contract can be picked up.
- Running means an agent or process currently owns the next action.
- Review means evidence exists and a machine or person must judge it.
- Done means a decision was made; it does not mean the agent was infallible.
Agent Studio Wraps the CLI Run
Codex, Claude Code and Gemini remain execution engines. Agent Studio prepares the task, starts a configured tool in an isolated worktree and collects the result around it.
- Accounts, subscriptions and CLI authentication remain provider-owned.
- The repository and worktree define where a run may write.
- The task protocol makes commands, failures and completion inspectable.
Evidence Turns “Done” into a Reviewable Claim
A completion message is not proof. Evidence connects the requested outcome to a diff, test, build, screenshot or other observable result.
The evidence record of one task: its task branch, the single commit, the two changed files, and the develop and main promotions still pending.
- Ask for proof proportional to risk and user impact.
- Use screenshots for visual behavior, not as substitutes for tests.
- Record review findings as concrete reasons to accept, reissue, split or reject.
Give the Run Acute Context; Keep the Rest as History
Repository rules, acceptance criteria and relevant decisions belong in the current task. Older protocols and outcomes remain searchable history instead of flooding every prompt.
A real workspace wiki: 384 knowledge pages under categories, a generated Pulse entry view, the recent-change feed and an unfiled inbox.
- Load only context that can change the current decision or implementation.
- Keep durable repository rules close to the code.
- Use prior task records to avoid repeating failed approaches and settled debates.
The Whole Model in One Loop
Shape a bounded task, route it to a configured CLI, observe the isolated run, collect evidence, review the result and preserve the decision. Scale only after this loop is trustworthy.
- New here: complete the 30-minute onboarding once.
- Running real work: use Patterns and Best Practices for repeatable task shapes.
- Evaluating the product: inspect Product, Software Quality and Security next.