The Orchestrator

Chapter 2 opened on a Monday at 9:12, with Maya running three private agent workflows on her laptop, none through architecture review, none with a second operator — a senior engineer carrying the whole arrangement in her head, which the Introduction called making your own nervous system the only control plane. By the end of the book her Monday looks different, and the difference is not the tooling. The workflows are the same kind of thing; what changed is that they exist on the company’s books. Chapter 2’s register says what each system may change and where a person intervenes; Chapter 10’s approval map says which actions need no one, one person, or several; Chapter 16’s record is joined on a trace_id, so when the return workflow told a customer a refund was complete before it was, the record showed which agent said it and under what authority. None of that made her less technical. It made her legible.

That is also where Chapter 1’s most quotable sentence needs qualifying. It said Maya’s report at 8:18 on a Monday was more output than a team of forty could produce in a month, which is true as written and easy to hear wrong. The forty were not replaced by the report; they were relieved of the handoffs, where the month went, and Chapters 10 and 11 said what the company owed in exchange: a staffed review queue, an approval owner, a goal owner, memory and recovery in the budget. The claim was about output, never a headcount plan. Maya’s title at the end of this book is still senior engineer. What has a name is the work: objective, authority, evidence, and stop are hers on paper, and the person who takes over her Monday can find all four.