Production AI agents need two loops

Most agent rollouts split the problem in the wrong place.

Engineering asks whether the agent produced a useful patch, plan, ticket, or workflow. Security asks whether the agent had the right authority, used the right tools, and left enough evidence. Those questions often happen in separate rooms, with separate language, after the work is already moving.

That split is where the risk hides.

A Claude Code run can be technically good and still be hard to approve. An enterprise agent can stay inside policy and still be useless to the team trying to ship. Production needs both loops at the same time: the delivery loop that proves the work, and the control loop that proves the authority.

That is the reason I keep pairing these two books in the campaign. Claude Code: Building Production Agents That Actually Scale is about the delivery loop: scoped work, review packets, evals, observability, cost control, rollback, and human approval. Securing Enterprise AI Agents is about the control loop: identity, permissions, MCP and RAG boundaries, audit evidence, policy gates, and incident response. If your team owns both sides, the Enterprise AI Agents in Production bundle is the cleaner starting point.

The delivery loop is not enough

The delivery loop is familiar to software teams.

A person writes a task. Claude Code or another agent inspects the repo, produces a patch, runs tests, summarizes the change, and hands the work to a reviewer. If the diff is small, the tests pass, and the rollback note is clear, the work can move.

That loop matters. Without it, agentic coding becomes theatre. You get confident summaries, scattered edits, and a reviewer who has to guess what happened.

But the delivery loop only answers part of the question. It says what changed. It may say which tests ran. It may say what failed. It does not automatically explain whether the agent was allowed to read the files it inspected, call the tool it used, touch the data it saw, or widen the task without approval.

A clean patch can still carry a messy authority story.

The control loop is not a paperwork layer

Security teams often get pulled in after the agent is already useful. That is understandable. Nobody wants to design controls around a demo that may be dead next month.

The problem is that authority patterns become habits quickly. A team gives the agent read access to a ticket system because it saves time. Then it adds an MCP server for docs. Then it allows a workflow tool. Then the same setup gets reused for a more sensitive task because it is already there.

Nothing in that story requires bad intent. It is ordinary delivery pressure.

The control loop makes the authority explicit before the release decision:

Agent identity:
Human owner:
Allowed files and repos:
Allowed MCP servers and actions:
Data classes the agent may access:
Commands and workflows allowed:
Forbidden zones:
Stop rules:
Approval owner for escalation:
Evidence required before release:

That is not a separate bureaucracy. It is the other half of the review.

If an agent can call tools, read internal knowledge, query logs, update tickets, trigger workflows, or change code, the reviewer needs more than a diff. They need to know which authority was used and whether it matched the task.

Where the two loops meet

The two loops should meet at one release decision.

For a low risk Claude Code run, that meeting can be light. The review packet says the agent stayed inside the named files, ran the expected tests, used no external tools, and has a rollback path. Good. The release decision is mostly an engineering review.

For a higher risk run, the same packet should carry the control evidence. Did the agent touch auth, billing, deployment config, customer data, regulated records, write capable MCP tools, or policy files? Did it ask for more scope? Did a human approve that wider scope? Is there a named person who accepts the residual risk?

This is where many teams get vague. They say “security reviewed it” or “the platform team approved it” without naming the actual decision. That will not survive a real incident review.

Use a plain release line instead:

Release decision: ship / hold / escalate
Decision owner:
Reason:
Evidence reviewed:
Residual risk:
Rollback or containment path:

That line is small, but it changes the conversation. The agent is no longer treated as magic productivity dust. It becomes a delegated system with a human owner and a reviewable trail.

A practical rollout pattern

If I were rolling this out inside a team, I would not start with a large governance program. I would start with one agent workflow and make the two loops visible.

Pick a useful but bounded workflow. A bug fix in one service. A documentation update with tests. A ticket triage agent that can read issues but cannot close them. A Claude Code run that can inspect a package, edit named files, run targeted tests, and produce a review packet.

Then add the control loop before the agent starts:

This run may read:
This run may edit:
This run may call:
This run must not touch:
This run must stop if:
The review packet must include:
The human owner is:

After a few runs, look at the evidence. Where did the agent keep asking for wider access? Which MCP tool was useful enough to keep? Which permission was convenient but not necessary? Which review questions kept coming back? Which failures would have been hard to explain without the record?

That evidence is better than arguing in the abstract about whether agents are safe.

The buyer problem is operational, not motivational

Most teams do not need another speech about how AI agents will change work. They need a working operating model.

The engineering side needs to make the agent useful without producing unreviewable work. The security side needs to control identity, tool use, data access, audit evidence, approvals, and incident response without smothering the team in process.

Those are connected problems. Treating them separately is how you end up with fast agent work that risk cannot trust, or safe agent policy that engineers route around because it does not help them ship.

The better question is simple: can the team explain both what the agent did and what authority it used?

If the answer is yes, you can widen autonomy with evidence. If the answer is no, keep the agent in a smaller box until the loop is clearer.

Start with the loop you are missing

If your team is using Claude Code and the weak spot is the engineering loop, start with Claude Code: Building Production Agents That Actually Scale. The landing page routes Kindle readers to the Amazon edition: Claude Code on Amazon Kindle.

If your weak spot is the authority model around enterprise agents, read Securing Enterprise AI Agents. It is built for teams dealing with MCP security, RAG governance, bounded autonomy, audit trails, policy gates, and incident ready evidence.

If you own both delivery and control, get the Enterprise AI Agents in Production bundle. One book helps the agent ship useful work. The other helps the organization trust the authority behind it.