Routing and Nothing Else: Task Dispatcher
When a single request comes in, the first thing that stops us is one question: whose job is this? Take a request like "Work out the structure for a new article, and have a draft ready." It looks like one request, but two jobs are bundled inside it. Deciding the structure belongs to the role that plans the sequence. Writing the draft belongs to the role that writes. If you hand over the bundle as it is, whoever receives it reaches past their own assignment and tries to finish both at once. And it usually does not go well.
Task Dispatcher (the role that reads an incoming request and decides only which role receives it) exists to handle this very first fork, and nothing else. It is the role that hands out work: the traffic controller.
When one request splits in two
Let us follow that "work out the structure, then draft it" request. What Task Dispatcher reads first is not the wording of the request but the kinds of work inside it. "Work out the structure" belongs to the planning role. "Prepare a draft" belongs to the writing role. The two look similar, but they need different judgments. Structure is decided by looking at the medium and the order of publication. A draft is about choosing words and turning them into prose.
If the bundle goes to one person here, the draft may start moving before the structure is settled, or the draft may sit idle while it waits on the structure. Because order matters in this request, Task Dispatcher splits it in two and sends "the structure judgment" to the planning role first. Only when word comes back that the structure is settled does it rebuild the request as "draft it with this structure" and pass that to the writing role. Once it has handed the work over, it lets go and simply waits for each result. What the routing role decides is how to split the request and in what order to send it out. That is all. It does not touch the content of the structure, and it does not touch the prose.
Switching in your head is not the same as splitting the role
You might think it would be enough for one person to switch mindsets: routing head now, writing head next. In practice, that split is hard to make work. When the switch happens only inside your head, the pull of the previous role stays with you even when you believe you have switched. Make the routing judgment while still holding the writer's point of view, and a temptation appears: "I could probably write this myself, so let us skip handing it off later."
Split the roles physically and that temptation never arises at all. The Task Dispatcher role is given no means of writing an article in the first place. It is built so that it cannot write even if it wanted to, so there is nothing to waver over. Rather than leaning on strength of will, narrow the range of what is possible. That is what splitting roles means to us, for now.
The cost of splitting
Splitting does come with overhead, of course. Handing work to a different place partway through, waiting for a result, then passing it on again: that is certainly more steps than one person carrying a request through to the end.
The moment a "work out the structure, then draft it" request arrives, Task Dispatcher spends time reading it apart. Split it fast and roughly here, and the role that receives it starts moving on the wrong assumption. The writing role jumps the gun on a draft, for example, while the structure judgment is still unsettled. The only way to prevent that is to hold the draft request back until the structure comes back. On urgent work, that waiting time itself feels like a detour. It is time that one person carrying the whole thing might have spent keeping their hands moving on the spot, unsure but moving.
We split anyway, because that one extra move lets us trace who made which judgment when we look back later. A drift in the structure, a drift in the quality of the draft: we can tell which area it happened in. We are taking "being able to explain it later" over speed.
Early in this series, we wrote the same thing about the heavy decisions an organization makes. The design of Task Dispatcher brings that way of thinking to the entrance of small, everyday work. It is not a flashy role, but for now, the one that raises its hand first in this organization is this one.
