Routing workflows

A user types "Python functions" into your video-script generator. A different user types "surfing." A third types "my startup's funding round." These are different kinds of content that deserve very different treatments — a Python explainer is educational, a surfing script is entertainment, a funding-round announcement is a news story. No single prompt handles all three well. Routing is the workflow pattern for exactly this situation: categorise the input, then dispatch to a specialised pipeline tuned for that category.

The generic-prompt trap

Imagine the video-script generator with one prompt:

Generate a short-form video script about: {topic}

It works. Sort of. The Python one comes out okay. The surfing one is dry and educational when it should be punchy and visual. The funding-round one sounds like a generic explainer when it should open with a hook.

The underlying problem is that a "good" script depends heavily on the genre. Educational content cares about clarity and progression. Entertainment content cares about hook and pacing. Comedy cares about timing and surprise. There is no prompt generic enough to handle all of them well — what a great educational script needs is actively wrong for a great comedy script.

You could cram the "write in the appropriate style for the topic" instruction into a giant prompt with six genre subsections. Claude then has to balance "figure out the genre" with "apply that genre's rules" with "actually write the script" all in one pass. The results are fine, just never great.

The better design is to separate the genre decision from the content generation. Route first, then write.

The routing pattern

A routing workflow has two steps:

1. Categorisation. A router Claude call takes the input and classifies it into one of a predefined list of categories.
2. Specialised processing. Based on the category, the input is forwarded to one specific pipeline — a prompt, a workflow, a set of tools — optimised for that category.

The input only goes to one pipeline. This is the key distinction from parallelisation (where the input goes to all sub-tasks). Routing picks one lane and the rest never run.

Defining the categories

For the video-script generator, a reasonable category set looks like:

• Entertainment — high-energy, trendy language, visual appeal
• Educational — clear explanations, relatable examples, progression
• Comedy — sharp, unexpected, observational
• Personal vlog — intimate, authentic, conversational storytelling
• Reviews — decisive, experience-based, strengths-and-weaknesses
• Storytelling — vivid details, emotional arc, narrative structure

Each category gets its own specialised prompt template. The educational template might say "Develop a clear, engaging script that transforms complex information into digestible insights using relatable examples and thought-provoking questions." The comedy template might say "Write a short script with a strong opening hook, a surprising observation at the 30-second mark, and a clean punchline at the end."

These templates can be very different from each other — different structures, different instructions, different examples. They don't have to share anything except the input topic. That's the payoff of routing: each pipeline is completely free to optimise for its own use case.

Step 1 — Categorisation call

The router step is a dedicated Claude call with one specific job:

Categorise the topic of a video into one of the listed categories.

<topic>
Python functions
</topic>

<categories>
- Entertainment
- Educational
- Comedy
- Personal vlog
- Reviews
- Storytelling
</categories>

Respond with only the category name.

Notice the structure: a clear instruction, the input wrapped in XML tags, the allowed categories wrapped in XML tags, and an explicit instruction to respond with only the category name. The output is a single string you can use as a dict key.

Use a cheap fast model for this — it's a classification task, and Haiku will do it perfectly well for a fraction of the cost of Sonnet. Pair the routing call with a low temperature to keep it deterministic.

Step 2 — Dispatch

In code, the dispatch is trivial once the category is known:

pipelines = {
    "Educational": educational_pipeline,
    "Entertainment": entertainment_pipeline,
    "Comedy": comedy_pipeline,
    "Personal vlog": personal_vlog_pipeline,
    "Reviews": reviews_pipeline,
    "Storytelling": storytelling_pipeline,
}

category = await categorise(topic)
pipeline = pipelines.get(category, default_pipeline)
result = await pipeline(topic)

Each pipeline is its own function. Each one can be a single prompt, a chain, a parallelisation workflow, or even an agent — routing doesn't constrain what happens inside the pipeline, only that a specific pipeline gets chosen.

Including a default_pipeline fallback is a good habit. When the router returns something unexpected (a hallucinated category, a blank string, a typo), the default catches it and the request still gets handled instead of crashing.

Why routing wins here

Specialised pipelines can be genuinely specialised. The educational pipeline can include one-shot examples of great educational scripts. The comedy pipeline can include a 300-token system prompt about comedic timing. These things would blow up a single generic prompt but they're perfectly reasonable in a dedicated one.

Independent optimisation again. When the comedy output is weak, you iterate on the comedy pipeline alone. Eval the comedy pipeline against comedy test cases; ignore the others. Same principle as parallelisation, applied across request types instead of criteria.

Predictable cost. A single request only runs one pipeline, not six. The routing step is cheap (Haiku classification), and the full-cost pipeline is only one of the branches.

Extensibility. Want to add a "Tutorial" category? Add it to the router's category list and write a new tutorial pipeline. Nothing else changes. No existing category gets re-tested, no existing prompt gets re-tuned.

When to use routing

Reach for routing when:

• Your application handles diverse types of requests that need different approaches to produce good output.
• You can clearly define the categories. If the boundaries between categories are fuzzy or contested, routing will produce inconsistent classifications and downstream problems.
• The categorisation step is reliable. Test the router in isolation before trusting it. If Haiku can't reliably sort your test cases into the right categories, the whole workflow is built on sand.
• The specialisation benefit outweighs the overhead of the extra routing call. For simple tasks where one prompt is almost as good as six specialised ones, routing adds complexity without buying much.

Routing shines in customer-service bots (sort incoming tickets to the right handler), content tools (sort topics to the right style), and any application where "the right response depends heavily on what kind of request this is."

The four workflow patterns, together

With routing covered, you now know the four named workflow patterns:

• Evaluator-Optimizer — producer, grader, loop. For iterative quality improvement.
• Parallelisation — independent sub-tasks, concurrent execution, aggregated result. For multi-criteria decisions.
• Chaining — sequential subtasks with dependencies, focused per-step prompts. For long, dependent flows and the long-prompt problem.
• Routing — categorise the input, dispatch to specialised pipeline. For diverse request types.

Most real applications mix two or more of these. The routing pipeline for each category might itself be a chain, which contains a parallelisation step, which feeds into a producer-grader loop. Learning the patterns as vocabulary lets you describe and combine them cleanly instead of inventing bespoke designs every time. The next lessons shift to the agent half of the module — what principles make agents work, and when you should choose an agent over any of these workflow patterns.