The agent runbook needs a buyer’s question

A good AI agent demo asks, “Did it work?”

A production buyer asks something less exciting: “What would I need to see before I let this run near real work?”

That question changes the shape of the whole system. It turns a Claude Code session from a clever patch into a delivery record. It turns an enterprise assistant from a polished answer into a governed actor with identity, permissions, logs, and a way back.

That is the gap most teams feel after the first impressive demo. The tool can do more than the process can safely absorb.

the buyer is buying the run, not the output alone

The obvious product is the output: code, a ticket update, a policy summary, a deployment change, a customer response, a data lookup, a workflow decision.

The real product is the run.

Who approved it? What scope did the agent receive? Which files, records, systems, and tools could it touch? Which checks ran? Which checks were skipped? What did the agent change? What did it only read? Where is the audit evidence? What happens if the run was wrong?

Those questions sound like security paperwork until something breaks. Then they become the only questions that matter.

A buyer does not need a grand theory of agents. They need enough evidence to say yes without pretending the risk disappeared.

Claude Code needs a runbook before it needs more freedom

With Claude Code, the temptation is to widen access as soon as the patches look good.

That is backwards.

Before widening access, ask for a runbook that makes the work reviewable:

1. Start with a task contract.
2. Name the allowed paths and blocked paths.
3. Require the agent to stop if it needs broader scope.
4. Capture commands run and checks skipped.
5. Ask for a review packet before merge.
6. Require a rollback note that a tired human can follow.

This does not slow the agent down much. It slows down the bad kind of speed, where the patch is neat and the reasoning has vanished.

The useful version of Claude Code is not “let the model roam the repository and hope the diff is clean.” The useful version is narrower and stronger: give it a bounded job, make it bring evidence, then review the evidence before trusting the patch.

That is how you keep speed from turning into hidden operational debt.

enterprise agents need the same habit around authority

Enterprise agents have a different surface area, but the same buyer problem.

A coding agent might touch tests, config, CI, migrations, or auth code. An enterprise agent might touch customer records, internal documents, support tickets, finance systems, HR workflows, vendor tools, or MCP servers.

The output may look harmless. The authority behind it may not be.

A serious enterprise agent runbook should answer:

Which identity did the agent use?
Which data sources were available?
Which MCP tools or actions were allowed?
Which actions required human approval?
Where are the logs?
Who owns revocation?
How do we contain a bad run?

If those answers are missing, a better prompt will not fix the system. The agent may sound more careful, but the business still cannot see the boundary.

This is where security work becomes practical product work. The runbook is not a compliance appendix. It is part of the user experience for every engineer, operator, manager, auditor, and customer who has to trust the agent after the demo.

one test before you scale the agent

Before giving an agent more authority, run one small exercise.

Pick a recent agent run. Do not use the cleanest demo. Use a run that was useful but a little uncomfortable. Maybe Claude Code changed more files than expected. Maybe an assistant called an MCP tool you had forgotten about. Maybe a reviewer had to ask, “What did it actually do?”

Now write the buyer’s question at the top of the run:

What would a buyer, auditor, or production owner need to see before trusting this run near real work?

Then look for the missing evidence.

If you cannot reconstruct the task contract, scope, tool use, skipped checks, data access, approval path, and rollback path, the next move is not more autonomy. The next move is a better runbook.

That is an uncomfortable answer for teams that want acceleration. It is also the answer that keeps acceleration from becoming a mess someone else has to clean up.

the two books are a practical pair

This is the reason I keep writing about Claude Code delivery and enterprise agent security together. They are not separate topics once agents start doing real work.

Claude Code: Building Production Agents That Actually Scale is for the engineering side: task contracts, scoped edits, review packets, evals, observability, rollback, cost control, and human approval. If you want Claude Code to help in shared repositories, the book gives you the operating loop around the patch.

Kindle readers can get it here: Claude Code on Amazon Kindle.

Securing Enterprise AI Agents is for the risk and governance side: identity, MCP boundaries, RAG governance, policy gates, audit evidence, incident response, and revocation. If an agent can act across business systems, the security model needs to be designed before the rollout becomes normal.

Teams that need both can start with the Enterprise AI Agents in Production bundle. One book helps the agent ship work a human can review. The other helps the organization keep the agent’s authority bounded, logged, and stoppable.

The buyer’s question is blunt, but useful: would you pay for this agent if the run record was missing?

If the answer is no, fix the runbook before you scale the autonomy.