The agent demo is not the risk. The handoff is.

The demo is usually fine.

Claude Code edits the right files. The internal agent answers from the right documents. The MCP tool call works. The team sees enough value to keep going.

That is the moment I worry about.

The risky part is not the first demo. It is the handoff from a careful experiment to a workflow that other people start depending on. Once that handoff happens, the agent is no longer a clever helper on the side. It has a job, a boundary, a human owner, and a failure mode. If those are not written down, the team is trusting vibes.

This is the bridge between my two books. Claude Code: Building Production Agents That Actually Scale is about the engineering loop around coding agents: task contracts, scoped files, commands, review packets, tests, cost control, and rollback notes. Securing Enterprise AI Agents is about the authority loop around enterprise agents: identity, MCP permissions, RAG boundaries, policy gates, audit evidence, and revocation.

If you own both problems, the Enterprise AI Agents in Production bundle puts the two loops in one place.

A demo proves capability, not ownership

A good demo answers one question: can the agent do something useful?

Production asks colder questions:

Who owns this agent workflow?
What exact job is it allowed to do?
What data, files, tools, and commands can it touch?
Which actions need approval?
What evidence comes back after a run?
How do we undo the work?
When does the permission expire?

Those questions sound heavy until something goes wrong. Then they are the first things everyone wants.

I have seen this pattern in ordinary software delivery for years. The uncomfortable part is not the clever technology. It is the support question at 2am: who changed what, why was it allowed, and how do we get back to a safe state? Agents make that question sharper because one successful pilot can widen fast.

The handoff needs a control record

Do not wait for a platform program to define the perfect agent governance framework. Start with a small control record for every workflow you want other people to rely on.

For Claude Code, that record can be plain:

Task:
Repo and directory scope:
Files the agent may edit:
Commands the agent may run:
Tools or MCP servers allowed:
Approval triggers:
Evidence required:
Rollback note:
Human owner:
Expiry or review date:

For an enterprise agent, the shape changes but the habit is the same:

Business process:
Agent identity:
Data sources:
Tools and MCP methods:
Denied actions:
Human approval points:
Audit trail:
Retention rule:
Revocation owner:

The record does not make the agent safe by itself. It makes the safety claim reviewable. That matters.

Without it, the team ends up reviewing the output while ignoring the authority behind the output. A polished answer can hide a bad data boundary. A passing test can hide a permission change. A clean ticket comment can hide a tool call nobody meant to allow.

Review the run, not only the result

The cheapest habit is to review the run as well as the artifact.

For a Claude Code task, the reviewer should not only ask whether the diff looks good. Ask whether the run stayed inside the contract. Which files changed? Which commands ran? Did the agent request more scope? Did a human approve it? Which test result actually covers the risk?

For an enterprise agent, ask the same style of question. Which identity did the agent use? Which source answered the question? Which MCP method executed? Was the denied path logged? Was a human gate hit or bypassed? Could an auditor reconstruct the decision without reading a Slack thread?

This is where the two books meet. The Claude Code book teaches the smaller operating loop inside engineering. The security book stretches that loop across identity, data, tools, audit, and governance. The vocabulary changes. The discipline does not.

The buyer test for agent work

Before you roll an agent workflow out to another team, use this test:

Could someone who did not build the demo explain why the agent was allowed to do what it just did?

If the answer is yes, you have the start of a production system.

If the answer is no, you still have an experiment. That is fine. Experiments are useful. Just do not sell the experiment internally as production readiness.

The move from demo to production is not about adding theatre. It is about making the agent boring enough to trust. Narrow job. Named authority. Run evidence. Review packet. Rollback. Human owner. Repeat.

Start with the book that matches your pain

If your immediate pain is Claude Code in real repositories, start with Claude Code: Building Production Agents That Actually Scale. Kindle readers can buy it here: Claude Code on Amazon Kindle.

If your problem is agent authority, MCP security, RAG governance, audit, policy gates, and regulatory pressure, read Securing Enterprise AI Agents or get it on Leanpub.

If your team owns both the delivery loop and the security model, get the Enterprise AI Agents in Production bundle. One book helps you make agent work reviewable. The other helps you prove the agent had bounded authority while doing it.