Preface · Before you start

What this asks of you

Nothing technical. This book is written for the people who decide what gets built and who answer for it afterward, and it assumes you have shipped software, sat through a demonstration that impressed a room, and watched something reasonable turn into something nobody meant.

It does assume you will not skip Part One. Part Two is the useful half, the one with the documents in it, and it will not do what it is supposed to do if you arrive there without the first half, because every artifact in it exists to answer a question Part One raises.

Six words, used precisely

The vocabulary in this field is loose and the looseness is expensive, because two people can agree to build an agent while meaning different things by the word. Six terms, defined here only as far as you need them to start. Chapters 4 and 6 take them apart properly.

A model is the thing that produces text. On its own it knows a great deal about the world in general and nothing at all about your company.

Context is what you hand it about your company, per request: the account history, the policy, the tone, the thresholds. Assembling it is a real engineering job and it is the part nobody scopes.

A tool is something the model can call to look something up or to make something happen. The second kind is the one that matters, because it is where the software stops describing the world and starts changing it.

A loop is the model calling tools, reading what comes back, and deciding what to do next, several times, without a person between the steps.

An agent is all of that together, pointed at a task, with a boundary around what it may do and somebody whose job it is to watch. Chapter 4 gives the full test. The short version is that a model and a prompt is a demonstration, and this is not that.

A rung is how much the thing is allowed to do without a person. There are five and they run from suggesting to acting alone. The whole book turns on which one you are on, and the gap that matters is the one between drafting something a person releases and doing something a person merely approves. Below that gap a mistake costs a deleted draft rather than a sent letter, because a hand sits between the output and the world. Above it, the system touches state.

Three things that are different in kind

Everything else in this book follows from three properties. None of them is a defect being worked on, and none of them will be fixed by a better release.

It answers differently on Tuesday. Ask the same question twice and you can get two different answers, both reasonable. This is how the technology works rather than a fault in it, and it breaks something you have relied on for your whole career without noticing: that a passing test tells you a property of the system. It does not, any more. A test that passes tells you what happened on one run. Ten runs of the same test is a different kind of statement, and the difference between those two numbers is where the trouble lives. Chapter 7 opens this up and Part Two's third phase is mostly about it.

The decisions happen after you ship. Ordinary software makes its decisions at design time; you argue about them in a document, and then the thing does what it was built to do, the same way, until somebody changes it. An agent decides at run time, case by case, on inputs nobody saw during the argument. Which means a rule that lives in a specification is a preference expressed forcefully, and the only rules that are rules are the ones enforced in the path the system actually takes. It also means the model underneath you can change without your code changing at all, and your product will behave differently on a Monday because a vendor shipped on a Sunday.

Nobody's job covers the after. Every role that shapes what a product does acts on it up to the moment it ships: product management, design, engineering, architecture, the domain expert who briefs them. That was always sufficient, because the shipped thing held still. It does not hold still now, and the job of watching what it decides afterward has no name in your organization, no lineage, no career path and nobody in it. The case in this book ends on a job posting, and that is not a flourish.

How the two halves work

Part One is the argument, ten chapters of continuous prose, each carrying one sentence worth keeping.

Part Two is one company, Ostermill Industrial Supply, building one agent across five phases, with the paperwork reproduced. It adds three things: cards, which are procedures you can run; exhibits, which are the documents themselves; and glosses, which define a term where it first does work.

Ostermill does not exist. The rule this book holds itself to is that the fiction carries the shape of the work and never carries the evidence. Where a claim rests on something outside these pages, it is sourced and identified, and where a figure is teaching material it says so.