Bounded background tasks keep coding-agent work recoverable by giving each phase one objective, one output path, one validation condition, and one clean commit boundary.
Quick answer
- Create the run folder and status file first.
- Spawn one bounded child task per phase.
- Commit and push only authored files after success.
- Have the parent validate artifacts and git state.
- Start retries in a fresh attempt path.
One phase should fit in one sentence
If a child task owns research, implementation, deployment, and reporting, it is too broad. A good phase can fail without making the whole system ambiguous.
The parent owns closeout
A child final message is helpful, but it is not the source of truth. The parent should check the task state, status file, expected artifacts, git diff, commits, and external side effects before calling the phase done.
Retries need isolation
A timed-out task may still write late. Resuming into the same path can mix old and new attempts. Use attempt-specific output paths and reconcile deliberately.
Frequently asked questions
Should every coding task run in the background?
No. Quick local edits are better inline. Use bounded background work for long, multi-phase, deploy-related, or easy-to-lose tasks.
Why commit after each phase?
A pushed commit makes successful work remotely recoverable and gives the parent a concrete artifact to validate.
Can one child run several phases?
Only when the work is small and failure is easy to inspect. For long work, one child per phase is safer.