Self-Improving Systems

What this book is

A governance problem, not just a detection problem

An earlier book in this series covered how a multi-agent system watches its own session history, notices a recurring task type, and proposes creating a dedicated specialist for it — how a system knows when it has a gap. This book picks up where that one stopped. Once a system can create new specialists on its own signal, a second question opens up that isn't a detection question at all: what stops it from creating too many, or the wrong ones? A system that gets pattern-watching and threshold-setting exactly right can still over-create, because getting the trigger right says something different from getting what happens after the trigger fires right.

At one point, three things that exist in the real deployment this book draws from were all true at once, and none of them are true anymore: there was no deny-list of names or roles that should never be auto-created regardless of signal strength; there was no requirement that more than one independent source agree before a certain class of creation signal could queue a proposal; and a supervision control meant to authorize every new specialist before it went live existed on paper, in the pipeline's design, without ever being checked by the code that actually ran. Three missing pieces, present at once, is the condition this book's central incident grew out of.

What you’ll learn

Six chapters, from the weakest link to the admission bar

• the-single-sender-problem — A creation signal that only needed to hear from a single source before queuing, and why that's the weakest link.
• the-blocklist — A cheaper, blunter guardrail: an explicit list of names that must never be created, regardless of how strong a triggering signal gets.
• the-over-generation-incident — A real batch of specialists created before either of the first two guardrails existed, and the audit that caught what they had in common.
• the-paper-control — A supervision control that was designed, admitted on the record to have never actually run, and set aside in favor of something narrower.
• setting-the-admission-bar — Turning the four guardrails into an approach a reader can apply to their own system.
• conclusion — What carries over to any self-improving system, this one included.

From the book

A preview

A system that gets pattern-watching and threshold-setting exactly right can still over-create, because getting the trigger right says something different from getting what happens after the trigger fires right.

Who it’s for

Anyone building a system that expands itself

This book assumes a reader who already has, or is building, a system capable of proposing its own expansions — new specialists, additional capabilities, broader coverage — without a human initiating each one. It doesn't re-teach the detection side of that problem; Stewards That Build Stewards (Book 56) does that already, and this one references it rather than repeating it. What follows is specifically the governance layer: what to check before a proposal is allowed to queue, what to check before something gets created, and what it costs to discover that a control you designed sat unchecked in the path that actually runs.

A longer excerpt is available to newsletter subscribers.

Buy Ebook on Amazon