Introduction
Orchestration for Your Product
Marcus sits down to decide the orchestration architecture for his podcast show-notes tool and runs the full chain this phase built, instead of guessing. First question: workflow or agent? Processing one transcript is mostly predictable — parse timestamps, detect chapter boundaries, generate notes — but chapter-boundary detection genuinely varies by how a given episode is structured, so it leans agent-shaped for that one step and workflow-shaped for the rest. Second question, now that part of it is agent-shaped: single agent or multi-agent? The subtasks (timestamp parsing, chapter detection, note generation) share a lot of context about the same transcript and don't obviously benefit from isolation — there's no clear case for a second agent catching something a well-harnessed single agent with the right tools wouldn't. He designs a single agent, augmented with the timestamp-parsing tool and the chapter-detection logic, wrapped in a workflow for the parts that are genuinely fixed-sequence. No multi-agent system, because nothing in the actual task needed one — exactly the discipline c12-05-3 was built to teach.
This walk-through isn't a new technique — it's this entire phase's reasoning, applied in sequence to one real decision instead of five separate examples. That sequencing matters: skipping straight to "should this be multi-agent" without first asking "should this be an agent at all" is how teams end up building elaborate orchestrator-worker systems for tasks that were workflow-shaped from the start. The order of the questions — workflow or agent, then single or multi-agent, then (if multi-agent) checking for the specific integration risks c12-05-4 and c12-05-5 named — is what keeps the final architecture matched to what the task actually needs, rather than to whichever pattern felt most sophisticated to reach for first.
Where this decision belongs
The orchestration architecture — workflow or agent, single or multi-agent, which specific patterns from c12-05-2 apply where — is an implementation decision, not a behavioral requirement. It belongs in the design doc from c12-03-6's "Proposed Architecture" and "Alternatives Considered" sections, following the same don't-mention-the-implementation discipline from c12-01-2: your product spec's acceptance criteria ("chapters must be correctly ordered by timestamp") shouldn't reference whether an agent or a workflow produces that ordering, and your orchestration choice, whichever it is, still has to satisfy that criterion. This is the harness-spec-versus-product-spec distinction from c12-04-2, one more time, applied to orchestration specifically: the what stays fixed in the product spec regardless of the how you document in the design doc.
Writing this into the design doc also means writing down what would change the decision — the specific condition under which Marcus would revisit "single agent" and consider splitting into specialists. For his product, that condition is concrete: if chapter-detection logic and timestamp-parsing logic start needing genuinely different context (different reference material, different failure modes worth isolating) rather than sharing the same transcript and the same task, that's the point where c12-05-3's "what would a second agent catch" question might start getting a real answer instead of "nothing specific." Recording that threshold now, while the reasoning is fresh, is far more useful to a future reader (including future Marcus) than a design doc that only states the current conclusion with no sense of what would ever revise it.
The orchestration decision doesn't change what "done" means
Whether Marcus's chapter detection ends up as one agent step or three coordinated specialist agents, the spec's acceptance criteria ("chapters must be correctly ordered by timestamp," "malformed input must raise a clear error") don't change and still have to be validated against, exactly as c12-03 covered. Orchestration is a design decision about how the work gets done — it is never a substitute for the validation step that checks whether the work is actually correct.
A learner documents their course-long product's orchestration choice ('single agent, augmented with a chapter-detection tool') directly inside their product spec's Acceptance Criteria section, alongside criteria like 'chapters must be correctly ordered.' Is this the right place for it?
This is the same violation c12-01-2 named for a different case (Redis cache details in acceptance criteria) applied to orchestration: naming a specific architecture choice inside acceptance criteria locks the spec to an implementation decision that could reasonably change (a single agent today, a multi-agent system later if the task grows) without the actual required behavior changing at all. The choice belongs in the design doc, where architecture decisions and their alternatives are supposed to live.
Walking the full decision chain for a new feature — 'given a batch of user-uploaded documents, extract structured data from each and flag any that fail a data-quality check' — a learner notes: the documents can be processed independently (no shared state between them), and there's no clear benefit to specialist roles versus one well-harnessed agent per document. What should the orchestration architecture look like, and which lesson's reasoning supports it?
The task's own shape answers the question: independent documents with no shared state is exactly parallelization's fit (c12-05-2), and the lack of a clear justification for specialist roles per document (nothing a second agent would specifically catch) means a single well-harnessed agent per document, per c12-05-3, is the right unit of work — run in parallel across documents, not coordinated as a multi-agent system within each one.