Home Book Blog Contact

Preface

The mandate from enterprise leadership is absolute: build autonomy. Automate the workflows. Deploy the agents.

The mandate has an economic basis. For the first time, software can take on open-ended, judgment-laden work that resisted automation precisely because it could not be reduced to fixed rules. Triaging a messy ticket, drafting a considered reply, navigating an unfamiliar API: these tasks now fall within software’s reach. Done well, this reduces the cost of work that used to require a human in the loop. The resulting pressure to deploy these systems is operationally justified, even when the proposed architecture is not.

But under the weight of this urgency, the software industry is sleepwalking into a structural mess.

Sound software engineering has always rested on a simple triad: build the right thing, build the thing right, and assume all things fail. In the rush to accelerate business impact, we are routinely failing on all three fronts. We are building the wrong things. We prescribe highly complex, unmanageable multi-agent swarms for problems that require a simple router. The point-and-click agent builders only sharpen the temptation: when standing up an autonomous agent takes a few clicks, every problem starts to look like one. We are building them wrong. We treat conversational logs as databases and system prompts as security boundaries. And we are operating with reckless optimism, deploying open-ended reasoning loops into production with the hope that the model will behave like a careful junior engineer. It will not.

The danger is not that foundation models do not work. The danger is that they work just well enough in a stage-managed demo to be trusted with things they cannot structurally guarantee once that demo meets production. That demo is sometimes called AI theater, which is slightly rude and unfortunately accurate.

I wrote this book because I watched technical leaders struggle without a treatment that integrated bounded autonomy, governance, memory, the trace, the harness, and the skills boundary as one subject rather than scattered across pattern catalogs and position papers. Where Gulli, Anthropic, CSIRO, and Andrew Ng catalog patterns and demonstrate frameworks, this book integrates the architectural discipline end to end, covering bounded autonomy as substrate, governance as load-bearing structure, failure-mode taxonomies, trace discipline, the harness, and the skills boundary. Governance-as-architecture is now consensus the book documents; the integration is the contribution. Judge the work on whether that integration holds, not on whether every position is novel.

Unless a case is named and sourced, incidents described in this book are composites of documented public cases, altered to remove identifying detail. Claims about the state of the field are as of mid-2026, whether adoption figures, dominant transports, or model capabilities; the architectural arguments are written to survive their revision (Chapter 1 makes the same shelf-life bet).

Many seasoned engineers lack vocabulary for probabilistic components; architects who see the risk struggle to hold the line without a formal framework to defend against hype and deadline pressure. This book is an attempt to provide that blueprint. It is for the engineer turning prototypes into production software, and for the architect who will carry the pager when these systems meet production.

An agentic system is not an AI project; it is a distributed systems engineering problem. The foundation models at the center of these systems are highly useful, highly volatile probabilistic components. They cannot be trusted to police their own behavior, adhere to corporate policy, or respect cost constraints. They are valuable exactly insofar as their behavior can be bounded, governed, observed, and recovered from by the deterministic infrastructure built around them.

If you are looking for a book on how to write the perfect prompt or how to fine-tune a model, this is not it. The frameworks will be obsolete in six months; the prompt-engineering hacks will be patched out in the next model weights update. This book assumes you already know how to build standard software. It does not teach you how to write a web server; it teaches you how to safely embed a non-deterministic agent into one. The harness that embeds the agent is the deterministic loop the model runs inside. That loop is designed directly in Chapter 19.

The book is divided into four parts:

Autonomy is not a feature you turn on. It is an operational state that has to be bounded by infrastructure. The economic case only holds if we engineer these systems for failure: when the model is wrong, the deterministic shell catches it.

For the engineers, architects, and technical leaders tasked with shipping these systems without giving up the reliability of the ones already in production, I hope this book provides the vocabulary and the structure to do both.