Supervising a running agent means watching its direction, permissions and evidence instead of waiting only for its final message. Review its plan, inspect important tool calls and answer real ambiguities. Stop the run when it repeats failures or goes beyond its scope.
Supervision does not require approving every harmless file read. Set safe defaults and reserve attention for writes, network access and new dependencies. Destructive commands and design choices need that attention too.
Ask for checkpoints on long tasks and keep git changes visible. Give the agent concrete evidence or a corrected constraint, never vague encouragement. The supervisor remains accountable for deciding whether the work is safe, complete and understandable enough to merge.
Rewriting in plainer words…
This answer doesn't lend itself to a diagram - it reads best . No credits were charged.
Which agent actions would you let run by default, and which would you want to approve first?Let reads and test runs go. Gate writes, network calls, new dependencies and destructive commands, based on how hard each is to undo.
Supervising an agent means watching its direction, its permissions and its evidence while it runs, not just reading the final message at the end.
I start by reviewing its plan. Then I check the tool calls that matter and answer the questions that are really ambiguous.
I don't approve every file read. I set safe defaults and save my attention for writes, network access, new dependencies, destructive commands and design choices.
On long tasks I ask for checkpoints and keep the git changes visible. If it repeats the same failure or goes outside its scope, I stop the run.
When I correct it, I give it something concrete, like the actual error output or a corrected constraint. Telling it to keep trying gives it nothing new.
The agent doesn't carry the responsibility. I still decide whether the work is safe, complete and understandable enough to merge.
Weak answers to avoid
Approves every action by handClicking yes on every file read is rubber-stamping. Set safe defaults and save attention for writes, network, new dependencies and destructive commands.
Only reads the final summaryThe final message is the agent's own claim about its work. Say you review the plan, watch the key tool calls and keep the git diff visible while it runs.
Steers with 'try again' or 'keep going'Vague encouragement gives the agent nothing new to act on. Give it the real error output or a corrected constraint.
Treats the agent as responsible for the resultBlaming the tool is a red flag. The supervisor decides whether the work is safe, complete and understandable enough to merge.
Interview lens
Likely follow-ups, what you can say, and the weak answers to avoid.
