Orchestration & Workflows

The earlier chapters covered the primitives one at a time — memory, commands, subagents, skills, hooks, settings, MCP servers. This chapter is about composing them, because real engineering work is rarely a single prompt. It’s a sequence: understand the problem, plan an approach, make the change, verify it holds, review it with fresh eyes. Orchestration is the practice of structuring that sequence so each step gets the context it needs and nothing it doesn’t.

The reason this matters more than wording is worth stating plainly. For an atomic task in a vacuum, output quality is roughly prompt quality — and a chatbot would do. But real work isn’t atomic, and there the quality of the result is a function of three things: the effective context the model sees at inference, the capability of the model, and the iteration loop it runs in. You control a sliver of the first by what you type. The harness — and the workflow you build on it — controls the rest: what context gets assembled, what runs in isolation, what gets verified, what persists across sessions. Orchestration is how you take command of the parts that actually move quality.

So the Items here are about structure, not syntax. Plan before implementing. Manage the context window as the finite budget it is. Delegate side-quests to subagents so the main thread stays focused. Close every workflow with a verification loop Claude runs itself, then a second opinion from fresh eyes. Drive multi-step work through a durable task list rather than the conversation’s memory. And compose all of it from the primitive that fits each step — because the harness is a composition system, and the leverage is in using it as one.