Parallelization workflows

You're building a material-designer feature: a user uploads a photo of a part and your app recommends which material to make it from — metal, polymer, ceramic, composite, elastomer, or wood. The tempting shape for this is one Claude call: "here's the image, pick the best material from this list." It works, barely. The better shape is six parallel calls, each one evaluating the part for exactly one material, with a final aggregation step that compares the six analyses. This is the parallelisation workflow pattern.

The problem with cramming everything into one prompt

A single-prompt approach for multi-criteria decisions looks sensible and performs badly. The reasons:

1. Claude has to juggle too many criteria at once. Evaluating "is this part a good candidate for metal" is a different analysis from "is this a good candidate for polymer" — they care about different properties, different failure modes, different cost profiles. Asking Claude to hold all six criteria sets in its head while also picking a winner makes each individual evaluation shallower.

2. Adding more detail makes it worse. Your first instinct when a one-shot prompt underperforms is to add more detail — explicit criteria for each material, weighting rules, edge cases. The prompt grows to 3,000 tokens and the output gets worse, not better, because the model is spending its capacity on coordination instead of analysis.

3. Optimisation becomes impossible. If the metal analysis is bad, you can't fix it without touching the prompt that also handles polymer, ceramic, and everything else. Every tweak risks breaking the others. There's no way to test one material's logic in isolation.

4. Extensibility is awful. Adding a new material to the list means rewriting the whole prompt and re-testing the other five.

Parallelisation: split, run concurrently, aggregate

The parallelisation workflow splits a single complex task into multiple focused sub-tasks, runs them concurrently, and aggregates the results into a final decision.

For the material designer:

1. Split. Define six separate prompts, one per material. Each prompt has:

   • The same input image.
   • Specialised evaluation criteria tailored to that one material (for metal: strength, corrosion resistance, machinability, cost; for polymer: chemical resistance, thermal limits, mouldability; and so on).
   • A single focused question: "is this part a good fit for this specific material?"

2. Run in parallel. Fire all six Claude calls concurrently. Use asyncio.gather, a ThreadPoolExecutor, or whatever concurrency primitive your language gives you. The six calls don't depend on each other, so parallel execution is both faster and the point of the pattern.

3. Aggregate. When all six analyses come back, send them to Claude in a seventh call with a request to compare them and make the final recommendation:

   "Below are six material analyses for the same part. Each evaluates the part for one specific material against specialised criteria. Pick the best overall material and explain why."

   The aggregation step now has focused, high-quality analyses as its input and only has to handle the comparison — not the analyses themselves.

Each sub-task is independent and specialised; the aggregation step is the single place where comparison happens.

Why this works

Focused attention. Claude does better analysis when the prompt is focused on one thing. Six focused prompts produce six strong analyses; one prompt covering all six topics produces one mediocre multi-topic response. This is the same principle as specificity in prompt engineering (Module 5) applied at the architecture level.

Independent optimisation. Each material's prompt lives in its own file or function. If the metal analysis is weak, you iterate on the metal prompt alone. You can run evals specifically for the metal evaluator, grade it, improve it, and ship the change without touching the other five prompts. Modules 4 and 5 taught you how to iterate on prompts; parallelisation lets you iterate on each part of a system independently.

Better scalability. Adding a seventh material — say, concrete — is a local change: write a new concrete prompt, add it to the parallel call list, make sure the aggregation step knows about it. The existing five prompts don't move. Contrast this with the giant-single-prompt approach where adding a material means rewriting everything.

Improved reliability. Smaller, focused prompts produce more consistent results because the model has less context to balance. You reduce the cognitive load on Claude and get more predictable outputs across different inputs.

Latency. Because the sub-tasks run concurrently, the wall-clock time is dominated by the slowest individual call, not the sum. Six parallel 2-second calls take roughly 2 seconds, not 12. For user-facing features this matters enormously.

The parallelisation structure

In code, the pattern looks something like:

async def evaluate_part(image_bytes):
    analyses = await asyncio.gather(
        evaluate_metal(image_bytes),
        evaluate_polymer(image_bytes),
        evaluate_ceramic(image_bytes),
        evaluate_composite(image_bytes),
        evaluate_elastomer(image_bytes),
        evaluate_wood(image_bytes),
    )

    return await recommend_material(image_bytes, analyses)

Six sub-tasks, each its own async function with its own specialised prompt, followed by a single aggregation call. The code is structurally simple; the power comes from what each sub-task is doing individually.

Sub-tasks don't have to be identical. The pattern doesn't require all parallel calls to use the same prompt or the same model. Different sub-tasks can use different models (Haiku for simple criteria, Sonnet for complex ones), different tools, or different temperature settings. What they share is the shape of the overall flow — split, run concurrently, aggregate.

When to reach for parallelisation

The pattern applies whenever you have:

• A complex decision that breaks down into independent evaluations. If the sub-decisions can be made without depending on each other, they can run in parallel.
• Multiple criteria or domains of expertise. When different aspects of a problem call for different specialised analysis.
• Comparison tasks with many candidates. Evaluating N options against fixed criteria is always a parallelisation candidate.
• Latency-sensitive features. If you need the answer in 2 seconds instead of 12, parallel is the only way to get there.

Some tasks look like parallelisation candidates but aren't. If the sub-tasks depend on each other's outputs, parallelisation doesn't work — you need chaining instead, which is the next lesson. And if the right sub-task to run depends on the input (different inputs need different prompts), you need routing, which is the lesson after.

Parallelisation is the pattern for independent, simultaneous evaluations across known criteria. That's its sweet spot, and it's a sweet spot you'll hit often.