When agents do part of your delivery, the question is not whether people stay involved. It is where. Too many approvals and you lose the speed. Too few and mistakes reach your customers. This guide gives a simple way to choose.
Ask two questions about each step
- How costly is a mistake here? A typo in a comment is cheap. A change to billing logic is not.
- How easy is it to undo? A draft pull request can be closed. A released change is harder to take back.
Steps that are cheap and easy to undo can run without approval. Steps that are costly or hard to undo need a person.
A starting point most teams use
- Plan: a person approves it for new kinds of work, and skips it for work the agent has done well before.
- Build: no approval needed, the agent works on a branch.
- Review: automated, with a person reading the pull request.
- Merge: a person approves, always, for the areas that matter most.
- Release: follows your existing process.
Name the approver
An approval without a name attached waits forever. For each step that needs one, pick a person or a small group, and say how long they have. If nobody answers in that time, decide in advance whether the work waits or escalates.
Loosen approvals over time
Start strict. After a few weeks, look at which approvals were always granted without changes. Those are candidates to remove. Look also at the ones that were often rejected: they show where the agent or the ticket needs help.
Keep a record
Whatever you choose, the backlog item should show who approved what and when. That record is useful for your team, and it answers the questions customers and auditors ask.