The agent diff and the agent boundary belong in the same conversation
A Claude Code diff can look neat while the work behind it is still hard to trust.
An enterprise agent answer can look harmless while the authority behind it is much larger than the sentence on screen.
Those two problems often get split into different meetings. Engineering talks about review packets, tests, and rollback. Security talks about identity, data scope, MCP permissions, audit logs, and revocation. That split is convenient on an org chart, but it is a bad way to run agents.
The agent diff and the agent boundary belong in the same conversation.
The diff is only one part of the run
A diff tells you what changed. It does not tell you what the agent believed the task was. It does not tell you which files it inspected, which commands it ran, which checks it skipped, which tool calls widened the blast radius, or how painful rollback will be if the change behaves badly.
That matters because reviewers are already busy. If the reviewer has to reconstruct the whole run from a patch, the agent has not saved as much time as it thinks it has.
For serious Claude Code work, I want the review packet to be part of the delivery, not an optional summary after the interesting part is done.
A useful packet answers boring questions:
What task was approved?
Which files could the agent change?
Which files did it read for context?
Which tools and commands did it use?
Which tests ran?
Which checks were skipped?
What risk remains?
How do we roll back?
What should the human reviewer inspect first?
That is not bureaucracy. It is the receipt for the run.
If the agent touched a shared helper, say so. If it skipped the slow integration suite, say so. If it changed configuration, permissions, auth, CI, data migration code, or anything with a wider blast radius, do not hide that behind “tests pass”.
The boundary is part of the delivery story
The same habit applies outside the repository.
An enterprise agent may produce a clean answer, a ticket update, a policy summary, or a workflow decision. The risky part is often not the text. It is the authority behind the text.
Which identity did the agent use? Which data did it read? Which MCP server did it call? Which action did it take? Which approval gate did it skip or request? Where is the log? Who can revoke access before the next run?
If those questions are missing, the team is asking people to trust the visible output while ignoring the hidden authority.
That is how safe demos become uncomfortable production systems. The first version reads a page and summarizes it. The next version reads internal data. Then it updates a record. Then it calls an MCP tool. Then someone adds another tool because the first tool worked. Nobody feels like they made a major security decision, but the agent has quietly become part of the control surface.
The boundary needs to move with the delivery process. When the agent can do more, the evidence needs to get better.
One operating stack, two surfaces
I think about this as one operating stack with two surfaces.
The coding surface asks:
Can the agent change code in a way a human can review, test, and undo?
The enterprise surface asks:
Can the agent act across systems in a way the business can bound, audit, and stop?
Those are not separate disciplines. They are the same operating question with different failure modes.
On the Claude Code side, the failure mode is usually a confident patch that hides intent, skipped checks, or rollback cost.
On the enterprise agent side, the failure mode is usually a confident action that hides identity, data access, tool authority, or audit gaps.
Both need task contracts. Both need scoped authority. Both need logs that a human can use. Both need approval points. Both need a way back when the work is wrong.
What I would require before widening access
Before giving a coding agent more room in the repository, I would ask for a review packet from the previous run and inspect it like an artifact, not a courtesy note.
Did the agent stay inside the task contract? Did it explain what it changed? Did it name the checks it skipped? Did the risk section match the actual diff? Did the rollback note say something more useful than “revert the PR”?
Before giving an enterprise agent more authority, I would ask a similar set of questions.
What identity does it use? What data can it read? Which MCP methods can it call? Which actions are allowed without approval? Which actions require approval? Where are the audit records? Who owns revocation? How quickly can we shut it down if the next run is wrong?
If the team cannot answer those questions, the answer is not to write a longer prompt. Keep the authority narrow until the review path catches up.
The buyer problem hiding inside the technical problem
This is the reason I wrote the two books as a pair.
Claude Code: Building Production Agents That Actually Scale is about the engineering operating loop around Claude Code: task contracts, scoped edits, review packets, evals, observability, rollback-first prompts, cost control, and human approval. If your team wants Claude Code to be useful in real repositories, the patch is not enough. The work needs to be inspectable.
Kindle readers can get it here: Claude Code on Amazon Kindle.
Securing Enterprise AI Agents is about the security operating model around agents that act across enterprise systems: identity, MCP boundaries, RAG governance, policy gates, audit evidence, incident response, and revocation. If an agent can touch business systems, security is not a final review. It is part of the product shape.
LeanPub readers can get it here: Securing Enterprise AI Agents on LeanPub.
If your team owns both sides, the Enterprise AI Agents in Production bundle puts the two problems together. One book helps you ship agent work without weakening engineering review. The other helps you keep enterprise agent authority bounded, logged, and revocable.
The practical rule is simple: do not scale the agent faster than you scale the evidence around it.
A useful agent should leave a diff, a boundary, and a way back.