Why This Book Exists¶

There is already a lot of material about AI agents. There is much less material that treats an agent system as something that must be designed, constrained, rolled out, investigated, and supported in production.

This book exists to close exactly that gap.

What It Is Not¶

This is not:

• a manual for one framework;
• a guide to one vendor product;
• a prompt collection;
• a tour of benchmarks and AI news;
• a security checklist without an architectural model.

What It Is Trying To Do¶

The book treats agent systems as governed production systems that should have:

• trust boundaries;
• execution constrained by policy;
• approvals for risky actions;
• memory and context discipline;
• traces, SLO, and evals;
• rollout control, ownership, and lifecycle governance.

The main goal is not to help someone build "the most autonomous agent." The goal is to help them build a system that can be trusted in operation.

Compared with Framework Documentation¶

Framework documentation is useful when you already know what system you want to build. It explains orchestration patterns, state graphs, SDK usage, and integration details well.

But it rarely answers questions of this kind:

• what an agent should be allowed to do at all;
• which actions require approval;
• how memory should be bounded;
• how to roll changes out without losing control;
• how to conduct review after an incident.

This book tries to sit above frameworks, not argue with them.

Compared with Vendor Docs¶

Vendor docs usually give the shortest path to a demo. That is useful, but naturally limited by the surface of one vendor.

This book tries to keep the architecture above the product surface and to separate more stable engineering discipline from faster-moving platform tooling.

Compared with a Security Checklist Approach¶

A checklist approach is necessary, but it does not give you a working architecture by itself. It tells you where to look, but not how to connect runtime, approvals, telemetry, ownership, and lifecycle into one governed contour.

This book is trying to do exactly that.

The Intended Outcome¶

After the book, the reader should:

• see where trust and action boundaries really are;
• understand how to capture run behavior instead of guessing from symptoms;
• know how to define health and risk budgets;
• know how to produce reviewable judgments about quality and regression risk;
• distinguish rollout, response, lineage, and accountability as different operational functions.

If that sounds closer to your problems than another piece of agent theater, this book was written for you.