Back Matter

The Agent This Book Was Written With

This book is full of people in a room with an agent: the reviewer approving outputs faster than anyone can read them, the supervisor signing claims at a second and a half each, the adult who stepped out of the daycare. This is the room the writer was in.

The book was drafted into a chat window on a second screen, after the working day, for months. I argued with the model. I asked it for sentences and deleted most of them. I asked it for structure and kept some of it. I checked my reasoning against it on the chapters where I had been moving the argument for so long that I could no longer see it from outside. The book is mine. The work was not mine alone.

The discipline was not in the tool. I brought it. I had to know when the agent was producing prose worth keeping and when it was producing prose worth deleting, when to take its pushback seriously and when to override it, when the argument I needed was the one I would have reached without it. None of that is in the model’s documentation or its interface. It was what I brought. This book was written in the exact arrangement it describes, a person supervising an agent that drafts, and that does not weaken the argument. It is the argument, demonstrated.

What is sharper still is that the four runtime artifacts this book spends a chapter on were not theory in the writing; they were the writing. We had to settle the autonomy boundary, how much the agent decided on its own and where it had to stop and hand back, and we settled it the hard way, the same arguments repeating for weeks until the line held. We had to design the approval moment: how the agent presented its work so I could actually judge it, the research laid side by side, the draft I could take or reject, rather than a wall of output I would rubber-stamp. We had to keep an audit surface, a record of what was decided and why, so the next chapter built on the last hundred instead of relitigating them. And we needed a recovery workflow, a way to catch the agent drifting in real time and undo it before the drift set into the argument. Boundary, approval, audit, recovery. I did not design them because the book told me to. The book tells you to because I could not write it without them.

That is the why. The rest of this piece is the how, because the method is one you can use, and the reason it is worth handing over is larger than the workflow.


What the tool actually changed

One personal line, because it is the door into the general point. I have always worked in a way the standard delivery of knowledge was not built for, my own research, my own references, studying from the notebook I made rather than the notes I was given. The method worked and it was slow, bounded by how much I could read between everything else. I knew how I learned. I did not have the scale.

That constraint is what the tool removed, and this is the part that is not about me. The reason the loop below produces what it does is not that AI is powerful in the abstract. It is that AI accommodates the way a particular person actually works, which rigid systems never did. The classroom had one delivery format. The form had one set of fields. The enterprise tool had one workflow, and you bent yourself to fit it. An assistant you can talk to in your own words bends the other way. If your native language is not the one the documentation was written in, you work in yours and it meets you there. If you think out loud before you think clearly, it lets you. If you work in bursts, or need to see a thing before you can judge it, or reason by argument rather than by outline, it adapts to that. The accommodation is the point, and it is available to far more people than the ones the old tools were designed for. My version of the door is a learning style that did not fit a lecture hall. Yours will be something else. The instruction is not to copy my workflow. It is to find the one that fits how you actually work, because the burden of accommodation has moved: the tool adapts to the worker now, not the worker to the tool.

The loop

Here is the shape, and the specific stack does not matter; the roles do. I write a short spine document by hand: the thesis, the argument, the lived experience, the few claims that need evidence, the gaps I need filled. That part stays mine and never moves. Then research runs in parallel across more than one system, fed the same questions, and I read the results side by side. The agreement is usually the solid evidence. The disagreement is usually where the real argument lives. The omissions are what I learn to chase next. One model drafts. A different model checks the draft, every claim and citation, because the model that wrote it is the worst one to grade it. And the catalog of everything I have written sits underneath all of it as shared memory, so each new piece builds on the prior hundred instead of repeating them; a topic with no entry in the catalog is often the most useful thing it tells me, because it shows me a gap in my own work.

There is one role in the loop that is harder to describe and matters most. After a draft is correct, it still has to sound like me, and a model’s draft sounds like the model unless you actively pull it toward your own voice. I spent months building a voice profile, correcting it until one model had a working sense of how I write. Then the underlying model was upgraded, and I could not find my voice for weeks; the prose was clean, careful, well-argued, and not mine. The fix was to have the model that still carried my voice calibration coach the newer one, naming the tells and returning a list of corrections. One model coaching another on which costume to wear, and it only worked because I had spent the months building the calibration one of them carried. That is the whole book’s argument about agents as team members, lived in my own writing: the upgrade was a personnel change I did not approve, and the cost of it was real.

What this is, and is not

Run this way, the loop is not a productivity tool. It is an active-learning protocol. Every piece forces me to defend a thesis against several independent research traces, work the argument through many drafts, and check every claim against a separate validator. The cognitive work of a single piece is closer to a seminar than to using a tool, and the supervisor at the top of the loop, doing the thinking that decides what the volume is for, is the only role none of the systems can fill.

It is also not a solution to the problem the rest of this book describes. It solves the individual version of the supervision problem, one person staying truly in the loop, by deciding to be the supervisor rather than the user. It does not solve the enterprise version, where a hundred people cannot each run a personal orchestration and the supervisory role has to be built into the product instead. That is the work the rest of the book is about. This piece is only the proof, in the smallest possible system, that the discipline is what makes the difference, and that the discipline is something a person brings. The tool will bend to how you work. Whether the result is worth anything still depends on you being awake at the top of the loop.