Agent autonomy needs a stop button and a receipt
The mistake is not giving an agent power. The mistake is giving it power without a clean way to stop the run and inspect what happened.
That is true for Claude Code in a repository. It is also true for enterprise agents that call MCP tools, read customer data, open tickets, update records, or trigger workflows. The useful version of agent work needs more than a good prompt. It needs an operating loop a human can trust under pressure.
My rule is simple: if the agent can act, it needs a stop button and a receipt.
The stop button has to be real
A stop button is not a paragraph in a policy document. It is the thing an engineer, owner, reviewer, or security person can use when the run starts moving outside the shape of the task.
For Claude Code, that might mean closing the current permission, ending the session, reverting the patch, blocking a command, or forcing the agent to restate the contract before it continues.
For an enterprise agent, it might mean disabling a workflow, revoking a token, removing an MCP method, narrowing a retrieval scope, turning off a service account, or sending the next action to human approval.
The question I would ask before approving more autonomy is blunt:
Who can stop this agent today?
How fast can they do it?
What exactly stops?
What keeps running?
How do we know the stop worked?
If the answer is fuzzy, the autonomy is probably too wide.
The receipt is where trust becomes inspectable
The receipt is the record the agent leaves after meaningful work. It should be boring, specific, and easy to review.
For Claude Code, I want to see:
Task contract:
Files changed:
Files inspected but not changed:
Tools and commands used:
Tests or checks run:
What those checks prove:
What was not tested:
Risk left behind:
Rollback path:
First lines for human review:
For an enterprise agent, I want the same habit with a wider surface:
Business process:
Agent identity:
Owner:
Data sources read:
Systems touched:
MCP methods called:
Actions taken:
Approval gates hit:
Approval gates skipped:
Logs and evidence location:
Revocation path:
This is not paperwork for its own sake. It is how a reviewer avoids guessing. If the receipt cannot tell you what the agent touched, which tools it used, what evidence came back, and how to undo the result, the team is trusting a story rather than a system.
Claude Code makes the problem visible
Claude Code is a good training ground for this discipline because the feedback loop is close to the code.
A small task can turn into a bigger one quietly. The agent reads another file. Then it asks to run a command. Then it changes a helper. Then it updates a config file because the test failed. Each step may make sense in isolation, but the reviewer still needs one coherent answer at the end: did the agent stay inside the approved task?
The receipt should make that visible. It should also make missing evidence visible.
If no test ran, say that. If the rollback is manual, say that. If the agent touched a file outside the original scope, say that. The worst outcome is a smooth summary that hides the part a human needed to inspect.
That is why Claude Code: Building Production Agents That Actually Scale spends so much time on task contracts, scoped edits, review packets, rollback-first prompting, observability, and human approval. The book is not about making agents look clever. It is about making their work safe enough to use in a real engineering loop.
Kindle readers can get it here: Claude Code on Amazon Kindle.
Enterprise agents need the same control loop
Enterprise agents raise the stakes because the action may not look like a code diff.
An agent might summarize a customer case, update a CRM field, query a knowledge base, open a support ticket, call a payment-adjacent workflow, or pull from regulated data. The output can look harmless while the authority behind it is not.
That is why the receipt matters. It gives the business owner, security reviewer, and engineering team the same view of the run. What did the agent know? What could it do? What did it actually do? What evidence exists? How do we stop it next time?
Securing Enterprise AI Agents goes deeper on that side: identity, MCP boundaries, RAG governance, data scope, audit evidence, policy gates, incident response, and revocation. If your agent can act across enterprise systems, the security model is not optional decoration. It is the product boundary.
LeanPub readers can get it here: Securing Enterprise AI Agents on LeanPub.
Use the pair when one team owns both problems
Many teams now own both problems at once. They are rolling out Claude Code or similar coding agents while also testing internal enterprise agents with MCP servers, workflow tools, and retrieval systems.
That is where the two books fit together.
The coding-agent problem asks: can we ship useful changes without losing review quality? The enterprise-agent problem asks: can we give agents useful authority without losing control of data, tools, and audit evidence?
The answer is the same operating habit in two places: narrow the task, narrow the authority, record the run, inspect the evidence, and keep the stop path close.
If your team owns both the delivery loop and the control loop, start with the Enterprise AI Agents in Production bundle. One book helps you make agent work reviewable in the repository. The other helps you keep enterprise agent authority bounded, logged, and revocable.
Useful autonomy is not the absence of control. It is control that does not get in the way until it needs to.