The clever model is the easy part.
A customer opens a ticket. She upgraded yesterday and now sees two charges on her card. She wants one reversed. Read the account, check the billing history, apply the refund policy, answer clearly. A capable model can do all four beautifully in a demonstration.
A company cannot operate on a beautiful demonstration. It needs the unglamorous answers. Did the agent open the right account? Was the policy current? Was the refund permitted at that amount? What happens if the payment service accepts the refund but the response never comes back, so nobody knows whether the money moved? Can the agent safely try again? What should the customer be told while the outcome is unknown? Who can stop the system when yesterday's update changed its behaviour?
The model does not answer those questions by being more intelligent. The surrounding system does. That system is the harness: the runtime that decides what the model sees, what it may attempt, what actually happened, and whether the result deserves to be trusted.
The model proposes. The harness governs. Evidence and ownership determine how much autonomy the organization should grant.
This is why the prompt is rarely the final bottleneck. And it is why a stronger model raises the stakes rather than lowering them: a weak model fails visibly, while a capable one can move quickly through the wrong account with the wrong policy while sounding entirely reasonable.
The equation the field is missing
The fashionable version is Agent = Model + Harness. It is a useful correction to the habit of blaming the model for everything. It is also not enough to put a system into an enterprise. The playbook develops the harder equation:
Trustable agentic system = model + harness + independent evidence + accountable owner
The harness controls behaviour. Evidence qualifies the claims you are allowed to make about that behaviour. An owner accepts the residual risk and holds the authority to stop the system. Without independent evidence, "trust" is confidence. Without an owner, "governance" is a dashboard nobody is obliged to act on.
That reframes the deployment question. Not "is this agent trustworthy," which is too vague to test, but something an organization can examine, approve, monitor and revoke: version 3.4 may issue refunds below a set amount for verified duplicate charges under this policy, while the reconciliation service and the human fallback remain available.
Three problems, one architecture
Once a team can build and deploy an agent, the work changes shape. The book is organised around the three questions that follow, plus the one that governs all of them.
- Optimization. How do you improve the whole outcome rather than one convenient score? An agent gets faster by skipping a check, cheaper by using stale information, and more accurate by refusing hard cases. None of those is necessarily an improvement.
- Coordination. When does another agent add useful difference rather than cost and noise? Three agents can agree because they copied the same source. Coordination value comes from independent evidence, not headcount.
- Adaptation. How can a system change tactics as conditions change without rewriting the rules that make it safe? It may choose a different route. It may not quietly redraw the map.
- Warranted trust. Which claim has the evidence earned, for which task class, under which conditions, owned by whom, and when does that claim expire?
What is inside
Eight parts, twenty-one chapters, a recurring worked case, and twenty-two field artifacts you can copy into a design review. Every chapter names a mechanism, ranks its evidence, exposes the trade-off it buys and taxes, defines a test you can run on your own system, and ships an artifact.
Part I
Foundations
What a harness is and is not, where operational truth lives when the conversation disappears, and how a tool call becomes a safe action.
Part II
Runtime
Building the right briefing rather than the biggest one, knowing when to continue, wait or stop, testing that earns trust, and turning procedures into versioned agent skills.
Part III
Optimization
What you are really optimizing, learning from what the system actually did, and knowing where an improvement still holds.
Part IV
Coordination
When more agents actually help, how work changes hands without losing evidence, and the hidden cost of agent teams.
Part V
Adaptation
Changing tactics without changing the rules, and how a system improves without grading its own homework.
Part VI
Warranted trust
Who is allowed to do what, how good components become a dependable system, security beyond prompt injection, and turning trust into an operating decision with an owner and an expiry date.
Part VII
Practice
A ninety-day campaign that earns one bounded production claim, what to learn from leading AI teams without copying their conditions, and the full customer resolution case.
Part VIII
Field artifacts
Twenty-two appendices: glossary, reference architectures, and the copyable contracts for interfaces, context, control loops, evaluation, skills, topology, delegation, adaptation, permissions, reliability, threat modelling, assurance, and the ninety-day campaign.
One case runs through the whole book. A disputed duplicate charge, several imperfect systems, limited authority, and a result that has to be true in the world. It carries twelve failure injections: malicious input, ambiguous identity, stale policy, conflicting systems, human concurrency, an ambiguous payment timeout, delivery ambiguity, a worker crash, duplicate delivery, model substitution, an unavailable verifier, and an optimizer that tries to authorize itself. Abstract systems are easy to admire and hard to challenge; consequences make the missing machinery visible.
Who should read it
- AI and platform leads: the whole book. Parts I, II and VI are the architecture; Part VII is the campaign.
- Engineers building agents: the runtime and optimization parts, plus the field artifacts you can paste into a design review this week.
- Security, risk and compliance: Part VI. Permitted influence, permission lattices, reliability claims, and assurance cases with defeaters and owners.
- Executives and product leaders: the introduction, the opening of each part, and Chapter 18. Enough to challenge a design without writing the code.
No prior proficiency in agent engineering is assumed. The introduction builds the mental model in ordinary language, and each chapter moves from a concrete problem to the precise mechanism. The book runs at two speeds: a main narrative you can read end to end, and an engineering layer of state machines, schemas, experiments and failure fixtures for when you are building or reviewing.
What it will not do
It will not offer a universal architecture, because task, consequence, evidence and operating capacity decide the right design. It will not treat a frontier company's implementation as proof that the same pattern belongs in your organization. It will not promise that governance removes risk; governance decides which risks may be accepted, by whom, on what evidence, and when the decision has to change.
The templates are proposed engineering instruments, not production-validated tools. Field pilots come with the vertical work that follows. Where the evidence is a recent preprint or a single company's report, the book says so and keeps the negative results visible, including our own: an elaborate context architecture that lost to a trivial permission-filtered baseline, and a verifier study whose headline did not survive its own audit.
The digital edition is a tagged PDF with document structure, alternative text on every meaningful illustration, and tagged tables and links. It has passed structural checks. It has not been through assistive-technology user testing or independent conformance validation, and we will not claim otherwise until it has.
Free, under a Creative Commons BY-NC-ND 4.0 licence. If you want the templates for commercial or internal company operations, or you find something wrong in here, write to [email protected].
