Chapter 5 of The Orchestrator is now available: “The Orchestrator’s Toolkit.”

This is the chapter where the book has to stop talking about orchestration as an emerging job and look at the equipment. Not the equipment as a shopping list. The equipment as a set of layers that somebody has to assemble, constrain, observe, and keep from doing something stupid at scale.

The main argument is simple: a model is not the system. A model is a component. The harness decides what the component can do.

That distinction matters because the market is currently in what Carlota Perez calls an irruption: the first phase of a technological revolution, when money and attention pour into invention, new categories appear faster than anyone can name them, and entire industries form before the survivors have consolidated around common standards. That is where we are with generative AI tooling. New runtimes, memory systems, agent frameworks, policy engines, identity products, and evaluation tools arrive every week, often before the previous week's announcement has made it into anybody's architecture diagram.

The chapter uses the bicycle boom of the 1890s as a comparison. In 1890, manufacturers built roughly 40,000 bicycles in the United States. By 1896, they were building more than a million. There were more than 300 manufacturers, competing frame geometries, incompatible standards, and enough patent activity to make the whole thing look like the future of transportation. The Wright brothers were in the business too, assembling bicycles from catalog parts and putting their own name on the result.

Then the boom peaked and collapsed. By 1900, the bicycle industry had overproduced, prices were falling, and the automobile was beginning to absorb the roads, manufacturing talent, and public attention that the bicycle movement had helped create.

The point isn't that AI is going to become a bicycle. The point is that a market can be full of real invention and still be temporary in its categories. A survey written during an irruption is a snapshot of a moving system, not a map of settled territory.

That is the honest position for this chapter. There is no finished set to buy.

What the chapter covers

The technology under discussion. “AI” is not one thing, and it is not the model by itself. It is the model plus context, memory, tools, permissions, workflows, records, and the controls around them. A better model does not repair a missing permission boundary or create a governance record that was never designed.

The survey and the coordination ladder. The chapter connects the taxonomy from the earlier chapters to the products and projects appearing in the market, then lays out a ladder from direct model calls to durable, event-driven execution. More agents do not automatically mean a better system. The lowest complexity that reliably does the job is the right amount.

Inference engines and models. This section looks at proprietary and open-weight models, the economics of inference, workload types, benchmarks, and the danger of treating launch cadence as a technical roadmap. Exact prices and scores move quickly. The order-of-magnitude differences, and the architectural choices they force, last longer.

Retrieval and memory. Retrieval answers what a run can see. Memory answers what survives the run. Both become permission questions as soon as the information matters. For every important memory, somebody should be able to answer when it was written, who wrote it, and whether that can be proved later.

Tool interfaces and actuation. MCP and function calling make it possible for a system to reach beyond text, into browsers, code execution, repositories, tickets, and messaging. That reach is useful. It is also where approval fatigue turns into a security problem, especially when people start approving nearly everything because stopping to read each request is inconvenient.

Identity, access control, policy, and permissions. Agents are beginning to receive identities and on-behalf-of credentials, but identity is not decision authority. Policy systems can return deterministic allow or deny decisions outside the model's reach. None of that answers the harder question: who, in combination with whom, had authority when the decision was made?

Durable orchestration and task agents. Durable execution can preserve state and replay work. A task agent can be described with an objective, context, tools, permissions, output format, and stop conditions. These are useful pieces. The full durable orchestration system that snapshots the entire arrangement and restores it on demand does not exist yet.

Everything is called an agent. The word has stopped carrying much information. A coding assistant, a persistent runtime, a bounded task worker, and a multi-agent team may all be called an agent. The label doesn't tell you what the thing can see, what it can do, or who can stop it. Read the contract instead.

Multi-agent coding and the architecture of participation. Gas Town, Gas City, Symphony, Claude Code Agent Teams, OpenHands, CrewAI, and LangGraph each solve part of the problem. None is an orchestrator in the full sense the book describes. The useful architecture keeps the model and the harness separate, because a model's capability is not the same thing as a system's authority.

The final section puts the whole chapter in one picture: agents surrounded by workflow runtimes, execution and authority controls, evaluation and observability, and deterministic infrastructure. The question is never which agent is best. It is which layer exists, what it can see, what it can do, what evidence it produces, and who is allowed to stop it.

The tools will come. They have not arrived.

Read Chapter 5, “The Orchestrator’s Toolkit,” now. And read it with the right expectation: not as a buying guide, and not as a permanent taxonomy, but as a practical survey of the machinery being invented while we are already trying to use it.

---

HQ 6 — Assembled. This chapter combines human-created and AI-created sections. The complete result was assembled and reviewed as a whole. HQ describes how the chapter was produced, not its quality or merit.

This chapter is part of the larger argument about the transition from programmer to orchestrator in The Orchestrator.