Give the agent a stop rule before you give it autonomy
Most teams give AI agents permissions before they give them stop rules.
That sounds backwards because it is. Claude Code can make useful progress when the task is scoped, the files are clear, the tests are available, and the reviewer knows what to look for. Enterprise agents can do even more when MCP tools connect them to tickets, logs, internal docs, workflows, RAG systems, and release automation.
But every extra capability creates a question the demo usually skips: when should the agent stop?
That is where Thomas De Vos’s two books connect. Claude Code: Building Production Agents That Actually Scale is about the engineering loop: task contracts, scoped edits, tests, review packets, evals, observability, cost control, and rollback. The book page points public readers to the Amazon Kindle edition as the main purchase path. Securing Enterprise AI Agents is about the authority model around agents: identity, permissions, MCP and RAG boundaries, audit evidence, policy gates, and incident response. If your team owns both delivery and risk, the Enterprise AI Agents in Production bundle puts those two problems in one operating model.
A permission is not a stop rule
A permission says what the agent can do.
A stop rule says when the agent must pause, collect evidence, and hand the decision back to a person.
That distinction matters. A Claude Code session may start as a harmless refactor and then discover that the fix crosses into authentication, billing, customer data, migrations, deployment configuration, or a shared library used by half the estate. The original permission may still technically allow the edit. The risk has changed anyway.
The same problem shows up with enterprise agents. An MCP server might be approved for read only use, but the agent’s path can still move from public documentation to incident notes, from a sanitized ticket to customer escalation detail, or from build logs to production like telemetry.
If the agent only has permissions, it will keep going until something external blocks it. If it has a stop rule, it can tell the team, “This crossed the boundary I was given. I need approval before continuing.”
That sentence is boring. It is also what makes autonomy usable.
Write the stop rule into the task contract
Do not hide the stop rule in a policy document nobody opens during the run. Put it where the agent and reviewer can see it.
A practical Claude Code task contract can look like this:
Task: reduce duplicate validation logic in the account settings package.
Allowed reads:
account settings package, related tests, local validation helpers.
Allowed edits:
account settings package and its tests only.
Allowed commands:
targeted package tests, lint for changed files.
Stop if:
the change touches auth, permissions, billing, customer data, migrations,
deploy config, shared validation used by other domains, or any MCP tool
that can change state.
Evidence required:
files inspected, files changed, commands run, tests passed and failed,
assumptions, reviewer questions, rollback note.
That is not elaborate governance. It is a guardrail written in normal engineering language.
The useful bit is the “stop if” section. It names the risk changes before the agent encounters them. The reviewer no longer has to infer whether the agent wandered. The run record should show either that the stop rule was not triggered, or that the agent paused when it should have.
Stop rules should be about risk changes, not vibes
Weak stop rules sound like this:
Stop if anything looks risky.
Ask a human when unsure.
Be careful with sensitive systems.
Those lines are better than nothing, but not by much. They depend on the agent having the same risk model as the organization. It does not.
A stronger rule names the boundary:
Stop before reading production customer data.
Stop before editing authentication, authorization, billing, or migration code.
Stop before using write capable MCP tools.
Stop before dispatching workflows, releases, or infrastructure changes.
Stop if the fix requires files outside the named package.
Stop if tests fail for a reason not explained by the task.
Stop if the agent needs secrets, credentials, or private incident context.
This is the sort of list I would want in a financial services rollout. Not because finance is special, although it often is, but because regulated teams are forced to say the quiet part out loud: authority has to be bounded, evidenced, and reviewable.
Agentic coding needs the same habit before the audit arrives.
The stop rule belongs in the review packet
A stop rule is only useful if the reviewer can verify what happened.
For routine Claude Code work, the review packet can stay short:
Task contract:
Stop rules given:
Files inspected:
Files changed:
Commands run:
Tests passed:
Tests failed or skipped:
Stop rule triggered: yes or no
If yes, who approved continuation:
Assumptions:
Rollback note:
For security sensitive agent work, add the enterprise evidence:
Agent identity:
Human delegator:
MCP servers available:
MCP capabilities used:
Data classes accessed:
Policy checks applied:
Approval owner:
Residual risk:
Incident or rollback path:
The reviewer should not have to reverse engineer the agent’s authority from a diff and a cheerful summary. If the agent stayed inside the boundary, show that. If it crossed the boundary with approval, show who accepted the risk and why.
This also helps platform teams. Once the team knows the stop rules it actually uses, the platform can enforce some of them with tool scopes, policy checks, CI gates, or workflow approvals. Start with the operating rule. Automate the stable parts later.
A stop rule is not a lack of ambition
Some people hear “stop rule” and think it means slowing the agent down. I think it is the opposite.
The teams that move fastest with agents are usually the teams that know which decisions the agent is allowed to make without debate. They can give Claude Code a tight task, let it work, and review the packet without turning every run into a meeting. They can let enterprise agents inspect safe context because the dangerous context has a named boundary.
The hesitation comes when nobody knows where the edge is.
If every agent run might secretly widen into auth, payments, customer records, deployment, or production tools, every run becomes suspicious. Reviewers slow down. Security asks for more process. Developers work around the process. The whole thing gets worse.
A good stop rule creates trust because it makes the handoff predictable.
A small template to use this week
Use this before the next serious agent run:
Agent stop rule
The agent may continue while:
- it stays inside the named files, packages, tools, and data sources
- it can explain the evidence for the change
- it can run the agreed checks
- the work remains in the original risk class
The agent must stop before:
- auth, permissions, billing, customer data, migrations, or deploy config
- write capable MCP tools or workflow dispatch
- production like telemetry or private incident context
- files outside the agreed scope
- unexplained test failures
- any action that changes shared state outside Git
When it stops, it must return:
- what changed
- what triggered the stop
- what evidence exists
- what approval is needed
- the safest rollback or abandon path
That is enough to start. It gives the agent a boundary, gives the reviewer a receipt, and gives security something concrete to inspect.
If you are trying to make Claude Code useful in real engineering work, start with Claude Code: Building Production Agents That Actually Scale. If you are responsible for the enterprise security model around AI agents, read Securing Enterprise AI Agents. If your team needs both the delivery loop and the control model, get the Enterprise AI Agents in Production bundle.