Chaining workflows

You gave Claude a crisp prompt with four constraints — "no emoji, no 'as an AI,' no clichés, professional tone" — and the output ignores at least one of them. Again. You rewrite the prompt harder. Claude obeys the new emphasis and breaks a different constraint. You add more emphasis. Now the prompt is 600 tokens and outputs are still leaking emojis. The problem isn't your prompt — it's that you're asking Claude to do two incompatible things at once. Chaining fixes this by splitting the work into focused sequential steps.

What chaining is

A chaining workflow breaks a large task into smaller sequential subtasks where each step's output feeds into the next. Instead of asking Claude to do everything at once, you split the work into focused steps and run them in order.

Chaining is different from parallelisation in a simple way: parallel sub-tasks are independent; chained sub-tasks have dependencies. If Step B needs Step A's output, they can't run in parallel — they have to run in order. That's a chain.

Chaining is different from ordinary multi-step prompts in a subtler way: you're not asking one Claude call to do multiple things sequentially inside its own reasoning. You're making separate API calls, each with its own focused prompt, orchestrating the sequence from your code.

A natural chaining example

Imagine a social media marketing tool that takes a topic and produces a posted video. The process has inherent sequential dependencies:

1. Find trending topics on Twitter (API call, not Claude)
2. Pick the most interesting topic (Claude)
3. Research the topic (Claude, possibly with web search)
4. Write a script based on the research (Claude)
5. Generate a video using an AI avatar and text-to-speech (external service)
6. Post to social media (API call)

Steps 2, 3, and 4 are Claude calls that happen in strict order because each depends on the previous one. You couldn't run them in parallel even if you wanted to — step 4 needs the research from step 3, which needs the topic from step 2. That's a chain by necessity, not by choice.

Notice also that non-Claude processing can happen between steps. Step 5 is a video-generation service; step 6 hits social media APIs. Chaining workflows often interleave Claude calls with traditional code, services, or other tooling. The "chain" is the overall sequence, not just the Claude parts.

Why break things up instead of one big prompt

The natural question is: "Why not just put steps 2, 3, and 4 into one massive prompt and let Claude handle it all in one shot?" You could. It would work sometimes. The reasons to chain instead:

Focus. Each step has one job. Step 2 just picks a topic. Step 3 just researches. Step 4 just writes. Claude does each of these well when it's the only thing on the table. Combined into one prompt, the model has to context-switch between discovery, research, and creative writing within a single response — and each sub-task gets shallower attention.

Intermediate processing. Between steps, you can do non-LLM work: log the picked topic, cache the research, spellcheck the script, run a fact-checker, apply a house-style regex. None of that is possible if Claude is producing the final script as one atomic output.

Debuggability. When the final script is bad, you can tell exactly which step failed — was the topic a poor choice, was the research thin, or did the script-writing step drop a constraint? Each step is independently inspectable and testable. One giant prompt gives you one output with no internal visibility.

Independent iteration. You can improve step 4's prompt without touching steps 2 or 3. Each link in the chain is an independently-versioned piece of prompt engineering.

The long-prompt problem: chaining as a practical fix

There's a second, subtler use case for chaining that catches people off guard. It's the pattern you reach for when Claude keeps ignoring constraints in a long prompt no matter how hard you push.

You want a technical article that:

• Does not mention being AI-written
• Avoids emojis
• Skips clichéd or overly casual language
• Uses a professional, technical tone

You put all four constraints in the prompt. Claude writes the article. It has emojis. You add stronger emphasis. Claude obeys the emoji rule and now includes "As an AI language model..." You push harder and the tone gets weirdly stiff. Round and round.

The fix is a two-step chain:

Step 1 — Generate. Ask Claude to write the article normally, without worrying about getting every constraint right on the first shot. Accept that the initial output will violate some rules.

Step 2 — Revise. Make a second Claude call with the article from step 1 and very targeted revision instructions:

Revise the article below. Follow these steps:

1. Find and remove any sentences that identify the author as an AI.
2. Find and remove all emojis.
3. Find any clichéd or casual language and replace it with something a technical writer would actually say.
4. Do not alter any other content.

Claude in step 2 is only doing the revision. It doesn't have to balance content creation against constraint compliance — it just has to find and fix specific problems. This works much better than one prompt fighting to do both at once.

Why revision beats negative constraints

There's a general principle buried in the long-prompt problem: Claude is better at fixing specific problems in existing content than at avoiding those problems during generation. Negative instructions like "don't use emojis" are weaker than positive instructions like "remove all emojis from the following text." In a generation prompt, the model has to simultaneously attend to creating the content and monitoring for rule violations. In a revision prompt, it only has to do the monitoring.

The two-step chain lets you exploit this. Generate first. Revise second. Accept that the first pass is imperfect and use the second pass to make it conform.

This pattern shows up everywhere once you start looking for it:

• Generate content, then apply brand voice
• Write code, then apply style rules
• Draft a response, then strip confidential information
• Create an outline, then expand it, then trim it to a word count

Any time you find yourself adding more and more "avoid X" clauses to a prompt without success, stop fighting and turn the rule into a revision step.

When chaining is the right tool

Reach for chaining when:

• Subtasks have dependencies. B needs A's output. (The naturally sequential case.)
• You need non-LLM work between steps. Validation, processing, external API calls.
• A single prompt has too many competing requirements and Claude keeps ignoring some of them.
• You want each step testable in isolation for debugging and iteration.
• Different steps might benefit from different models. Use Haiku for step 2's cheap categorisation, Sonnet for step 4's creative work.

Chaining looks like more work than a single prompt because it is — you're making multiple API calls, managing intermediate state, and wiring the sequence yourself. It's also usually worth it, because the reliability and quality gains are large. And as a bonus, the resulting pipeline is easier to monitor, cache, and evolve than a single fragile mega-prompt.