Agent workflow
AI Coding Agent Workflow: From Task to Reviewed Merge
A practical agent-first workflow covering task briefs, context, worktrees, permissions, tests, handoff, and human review.
Treat a coding agent like an execution system, not a chat box. Give it a bounded task, repository instructions, an isolated workspace, explicit permissions, and machine-checkable acceptance criteria. A person still owns prioritization, review, and release.
Solo developers and engineering teams moving from chat-assisted coding to longer, parallel agent tasks.
What is changing now
Leading coding platforms now emphasize parallel agents, longer tasks, worktrees, tool use, and human approvals. The durable advantage comes from the harness around the model: context, feedback loops, tests, and observability.
Problems this guide solves
- Agents start coding before the problem and finish line are understood.
- Parallel runs share files, ports, or credentials and interfere with each other.
- A polished summary hides untested assumptions or incomplete work.
Step 1
Turn an issue into an executable brief
The task should be narrow enough to review and concrete enough to test.
- Describe the user-visible problem and why it matters.
- Point to relevant modules, constraints, and examples without prescribing every edit.
- List acceptance checks that can be observed or run.
- State what is out of scope and which decisions require a human.
Step 2
Create a controlled run
Isolation and permissions keep a failed attempt cheap.
- Use a branch or worktree and a separate port or test resource when needed.
- Load current repository instructions and only the context relevant to the task.
- Approve commands by risk: read and test broadly, restrict secrets, deploys, and destructive actions.
- Require checkpoints for architecture changes, new dependencies, and public API changes.
Step 3
Demand evidence at handoff
Completion means the result is reviewable, not that the agent stopped.
- Review the diff, generated files, migrations, and lockfile changes.
- Check the commands and tests actually run, including failures or skipped checks.
- Reproduce the target behavior and at least one important failure case.
- Record unresolved risks, then merge or send the task back with specific evidence.
Final checklist
- The task has a user problem, scope, and acceptance checks.
- The run is isolated from unrelated work.
- Repository instructions are current and short.
- Permissions match the task risk.
- New dependencies and public interfaces receive explicit review.
- The handoff includes diffs, commands, results, and unresolved risks.
Common questions
What should humans still own?
Humans should own priority, product intent, risk decisions, architecture boundaries, review, and release. Agents can perform more execution, but they do not absorb accountability.
How many agents should run in parallel?
Start with one. Add parallel runs only when tasks are independent, workspaces and resources are isolated, and you have enough review capacity for the resulting changes.
What makes an acceptance check useful?
It should be observable and tied to the task, such as a test passing, an error no longer reproducing, a page meeting a measured condition, or an API returning the expected result.
Sources and further reading
These primary sources support the current direction described in this guide. Product features can change, so verify controls in the tool before adopting them.
Continue reading