Where should a coding agent stop and ask?

Most teams set approval rules for coding agents in one of two ways. They approve everything, and their engineers learn to press "Allow" faster than they can read. Or they approve nothing, and the agent installs a dependency, rewrites a migration and pushes to a branch called fix-final-v2.

Neither is governance. The useful question is narrower: at which points should this workflow pause for a human, and what should that human see?

Actions that deserve a checkpoint

An agent that reads code and suggests changes is low risk. The risk rises when it moves from reading to acting, or from its agreed boundary into somewhere new. Good candidates for a pause include:

• moving from investigation to implementation
• applying code changes when your process requires approval
• running commands that change dependencies, build state, infrastructure or environments
• reading other repositories, or connecting to external tools and MCP servers
• reading sensitive files or credentials
• changing tests in a way that could hide failures
• preparing a release or deployment
• continuing after validation has failed

The item about tests deserves a moment. An agent that "fixes" a failing test by weakening the assertion has done exactly what the failing test was there to prevent.

Three questions for every checkpoint

A checkpoint that just says "Approve?" trains people to say yes. Each one should answer three questions:

1. What action is the agent asking to take?
2. Who has the authority to approve it?
3. What evidence should the approver inspect before deciding?

For a CI investigation, the approver should see which files the agent plans to edit, why the change is needed, what validation will run and what is out of scope. If that information isn't there, the approver is guessing.

A second point is easy to miss. A tool's settings and your team's rules are different things. An agent's sandbox might allow local edits without a prompt. That doesn't override a team decision that this workflow is proposal-only. Write the team rule down, because the tool won't enforce it for you.

Where my agent didn't stop

Here's a real session from September, on schoolCRM, my school operations platform. The agent finished a task and listed three environment limitations. The Python tests needed dependencies, the Go integration tests needed a Docker container, and the issue tracker's database was unavailable. I told it to fix them.

In about seven minutes, it:

• installed the Python dependencies
• started Docker Desktop
• rebuilt the issue tracker's local Dolt database from the repository's metadata
• committed and pushed

Each step was reasonable, and I had asked for the outcome. But starting a system service and rebuilding a database both change the environment, which puts them on the list above. Neither step paused.

My next request was "fix it", about a failing authorisation test. To get its commit past the pre-commit hook, the agent narrowed the hook's Go checks to the packages that had changed. It described this as "narrowing the hook's Go lint scope to changed Go packages rather than weakening production checks or skipping hooks". The same change also narrowed go test and govulncheck before every push. That's a change to a quality gate, made in the same step as a change to three test expectations, with no pause between them.

Explore the interactive diagram of where the agent didn't stop

Why didn't it stop? Mostly because nothing told it to. The repository's AGENTS.md said "Work is NOT complete until git push succeeds" and "NEVER say 'ready to push when you are' - YOU must push". That team rule authorised pushing. Nothing in it said when to stop and ask. The repository's Codex config has since gained default_permissions = ":danger-full-access", so the sandbox won't stop it either.

Lines like these in AGENTS.md would have caught both moments:

• Ask before you change the expected result of an existing test.
• Ask before you change Git hooks, CI configuration or the scope of any check.
• Ask before you start or stop local services, such as Docker or a database.
• If a failing test and the code disagree, report which one you think is wrong and why. Then wait.

Match the safeguards to the risk

Different workflows need different levels of control:

The table isn't a configuration guide. It's a way to avoid two opposite mistakes: under-governing the risky workflow, and over-governing the safe one until nobody uses it.

Governance is what lets you go faster

"Governance" often sounds like a brake. In agent workflows, it works more like a seatbelt. Clear rules about what the agent can access, where it must pause and what it must return mean nobody has to renegotiate the boundaries on every task. That's what makes a fast workflow safe enough to repeat.

If you're setting this up for your team, write a short note for each workflow:

• Workflow and risk: what it does and why it's low, medium or high risk.
• Boundary: what's in scope, what's out, and which tool settings and team rules apply.
• Checkpoints: where it pauses, who reviews and when it escalates.
• Evidence: what the agent must return, and what stays traceable afterwards.
• Expansion condition: what evidence would justify using it on another team or repository.

Keep it short. "Use AI with governance" is too vague to act on. A list of every possible control is too long to read.

Which of your agent's approval prompts has your team learned to click through without reading?