# Day 44: Why dynamic dispatch needs ownership rules

Some workloads refuse to be planned in advance. You cannot know whether a request needs three subtasks or thirty until you are inside it.

That is what the orchestrator-worker pattern is for. The orchestrator reads the request, invents the subtasks at runtime, and dispatches each to whichever qualified worker is free. Ten documents today, three hundred tomorrow, same architecture.

## Dispatching is the easy half

The engineering lives in the bookkeeping, and this is where implementations quietly fail:

- **Orphaned tasks.** A worker dies mid-task and nothing notices. Every dispatched task needs a timeout and an owner of record, or work simply evaporates and the orchestrator waits forever for a result that is never coming.
- **Duplicate execution.** Retries plus non-idempotent tasks equals the email sent twice, the refund issued twice. Design tasks to be safely re-runnable *before* you scale the fan-out, not after the first incident.
- **Reconciliation.** Results arrive out of order, partially failed, occasionally contradicting each other. Integrating that into one coherent outcome is the orchestrator's actual job, and it is where the real engineering time goes.
- **Spec drift.** Dynamically generated task descriptions degrade under unusual inputs in ways static pipelines never do. Sample them and read them periodically, a task spec that made sense for the last thousand requests can be nonsense for the next one.

## Make routing explainable

The failure that hurts most in production is the unexplainable dispatch: nobody can say why worker C was chosen, so nobody can fix it when C was the wrong choice.

Log the routing decision and the signal behind it, not just the outcome. "Routed to the SQL worker because the query mentioned an order ID" is debuggable. "Routed to the SQL worker" is a black box that will cost you an afternoon every time it misroutes.

## Choose it deliberately

Rule of thumb: **if you can enumerate the stages on a whiteboard, build a pipeline.** Static structure is easier to trace, cheaper to run, and far easier to reason about.

Reach for dynamic dispatch when the work genuinely refuses enumeration — variable-size batches, unpredictable subtask types, load that fluctuates enough that fixed workers are either idle or overwhelmed.

## Closing thought

Orchestrators create and dispatch work. That flexibility is real, and it arrives bundled with distributed-systems problems that a fixed pipeline simply does not have.

*Day 44 of 60 Days of Production AI Systems.*

If a task went missing in your system tomorrow, how long before anything noticed?

---

**Previous:** [Day 43: When hierarchy helps multi-agent work scale](https://blog.vamsiannamreddy.com/day-43-when-hierarchy-helps-multi-agent-work-scale)  
**Next:** [Day 45: Why pipelines make AI handoffs inspectable](https://blog.vamsiannamreddy.com/day-45-why-pipelines-make-ai-handoffs-inspectable)  

*Day 44 of 60 · Multi-Agent Design Patterns (chapter 8 of 10)*