You defined the system on your first day and you have been feeding it ever since: rules, a spec, decisions, gates, tests. Every bit of it you have driven by hand. That was the point, because you cannot hand over work you have never done. You have now done it, and this part is where you start handing it over.
9.1.1Automation is what trust buys
Automation is one component of the system, not the system itself, and it is deliberately the last one to arrive.
Anyone can put an agent on a schedule on day one. What they get is a machine producing work they have no way to judge, faster than they can check it. You spent the last stages learning what good output looks like on your own project, which is the only thing that makes handing it over safe.
So nothing about the loop changes here. What changes is who runs each step, how much of it survives between sessions, and how many agents can work at once without colliding.
9.1.2Machinery earns its place
Add each piece of machinery only when a task actually hurts without it. The people who run real operations this way never carry a part they have not needed, and neither should you.
The proof is never glamorous. In one long-running setup, a single plain file describing how the deploy really works ended a mistake the agent had repeated in every session. That one page paid for the whole system inside a week.
9.1.3The whole system, and where each piece came from
Once the machinery exists, your agents have a home: they know where things go, what matters right now, and how you want the work done. You stop re-explaining yourself and start giving commands.
Everything below belongs to the software department of your operating system, the one this book builds end to end. The growth department attaches to the same tree later, and the last part of the book points at where.
Here is every piece of it on one page:
| Piece | What it gives you | Where it gets built |
|---|---|---|
| One entry file every session reads | The agent walks in knowing your project | Already done, in Set Up |
| A spec, an architecture, decisions on record | Something to build against, not vibes | Already done, in Plan and Architect |
| Gates that block bad work mechanically | Rules that hold when nobody is watching | Already done, in Build and Test |
| The tree, departments, and a control center | One home for everything that is not app code | This part |
| Agents with roles, tools, memory, and limits | A crew instead of a chat window | This part |
| A shared board, a ledger, and one task path | Work that survives the session it started in | This part |
| Version stamps, verdicts, and a freshness sweep | Knowing whether any of it actually worked | Later, once you are live |
Only the last two blocks are new. Everything above them you already own, which is exactly why you can be trusted with what comes next.
9.1.4Build your own, and grow it with you
Everywhere else this book tells you to reuse before you build. Your operating system is the one deliberate exception, and building it yourself is the point. You learn exactly how it works, it fits how you build, and it keeps growing with you.
That means your own way to test your work, your own inbox for the tasks you and your agents create, your own way to run your content. Each piece is shaped to what matters to you, not to a generic template.
If you would rather start from a ready-made one, a system like the one this part describes already runs a real company in production. A version you can install and adapt is what could come next. You can follow it and vote for it here.
This prompt sets the base up and, more importantly, teaches your agent that it now has one:
Do this now: paste the prompt so the folder exists and your agent knows it is the home for everything that is not app code.
