Decomposition

Why prompts fail named a category you can only reach after ruling out the other two: the task really is too hard as posed. Splitting is the oldest answer to that, and it is no longer the first one to try. As of October 2026, Anthropic's guidance is that a current model with thinking on does most multi-step work inside one call. So this lesson is half how to cut, and half when to leave the prompt whole.

1.One prompt, five jobs, one number

A prompt doing five things fails at the hardest one and hands you a single output. That output is your only signal, and it is the wrong shape for debugging. With five jobs fused into one call, you cannot:

• tell which step was wrong when the answer is wrong,
• change one step without risking the other four,
• test a step against its own examples,
• put the easy steps on a cheaper model, or in plain code,
• log an intermediate that anyone could review.

There is an arithmetic version of the same problem. Five steps at 95% each is about 77% end to end, if the errors are independent. Real errors are correlated, so it is a direction, not a measurement. What is reliable is the shape: accuracy multiplies down, and a fused prompt hides which factor is dragging.

Notice what this argues for. It does not say "more steps is worse". It says that when a result is wrong, a fused prompt gives you one number and no way to find the cause.

2.The chain: extract, decide, write

The shape that works most often is boring: pull out facts, decide something, produce prose. Each step has a narrower job and an output you can check.

Look at step 2 once it stands alone, with a typed input and a three-value output. Does it need a model? Refund policy is usually a handful of rules about dates and amounts, and rules are cheaper, faster and exactly repeatable in code. You could not see that while it was buried in the middle of a paragraph. Splitting shows you which parts were never model work.

The sample below is that chain. The parameter spellings are copied from vendor docs as of October 2026, not run here, so try them on your SDK version first.

from datetime import date, timedelta

from anthropic import Anthropic
from pydantic import BaseModel

client = Anthropic()
MODEL = "claude-sonnet-5-5"   # as of October 2026

def text_of(resp) -> str:
    return "".join(b.text for b in resp.content if b.type == "text")

class Facts(BaseModel):
    order_id: str | None
    purchase_date: str | None   # YYYY-MM-DD, or null when the email does not say
    product: str | None
    problem: str | None
    repeat_contact: bool        # added after a reply missed 'third time this month'

def extract(email: str) -> Facts:
    resp = client.messages.parse(
        model=MODEL,
        max_tokens=2000,   # thinking is on by default and counts against this
        system="Extract the facts. Use null for anything not stated. Never guess.",
        messages=[{"role": "user", "content": email}],
        output_format=Facts,
    )
    # The schema holds only for a finished answer: a refusal or a cut-off may not match it.
    if resp.stop_reason != "end_turn":
        raise RuntimeError(f"no usable answer: {resp.stop_reason}")
    return resp.parsed_output

def decide(f: Facts, today: date) -> str:
    # Step 2 began as a model call. It turned out to be three rules.
    if f.order_id is None or f.purchase_date is None or f.repeat_contact:
        return "needs_human"
    if today - date.fromisoformat(f.purchase_date) > timedelta(days=30):
        return "decline"
    return "refund"

def write(decision: str, f: Facts, email: str) -> str:
    resp = client.messages.create(
        model=MODEL,
        max_tokens=2000,
        system="Write a short, kind reply that carries out the decision. State no facts beyond those given.",
        messages=[{"role": "user", "content":
            f"Decision: {decision}\nFacts: {f.model_dump_json()}\n<email>\n{email}\n</email>"}],
    )
    if resp.stop_reason != "end_turn":
        raise RuntimeError(f"no usable answer: {resp.stop_reason}")
    return text_of(resp)

email = "Hi - the lamp I bought in March arrived cracked. Order 8812. Third time this month I've written."
facts = extract(email)
print(facts)   # the whole point of splitting: a typed middle you can look at
reply = write(decide(facts, date.today()), facts, email)

parse with output_format sends Facts as an enforced schema; Output contracts, later in this part, explains how.

That print(facts) is not debugging clutter. It is the thing you bought. You can log it, assert on it, alert when order_id is null more than usual, and hand it to someone who does not read Python. Here purchase_date would come back as None, because "in March" is not a date, and decide sends the case to a person instead of guessing.

Put the seams where you would want to look at the intermediate result.

The failure case is the seam itself. Suppose the first version of Facts had no repeat_contact field. The customer wrote "third time this month", the extractor had nowhere to put it, and the reply was polite and clueless. Every seam is a lossy handoff, and your intermediate shape decides what the rest of the pipeline may know. Two habits help: add the field when a failure shows you what was dropped, and pass the original email to the last step, as write does, so tone survives.

A second shape is the one Anthropic's guide calls the commonest chain: draft, review against written criteria, refine. Each is its own call, so you can log the draft, skip the refine when the review finds nothing, and see whether the reviewer ever changes an outcome. If it never does, delete it.

One more rule of thumb. Steps that depend on each other run in sequence. Steps that do not, such as summarising ten documents, can run at once, which finish in about the time of the slowest one. Only a real dependency forces a queue.

3.What it costs, and when one prompt wins

The vendor's current advice is blunter than the table. With adaptive thinking and subagents, most multi-step work happens inside one call; chain explicitly to inspect intermediate outputs or to enforce a fixed pipeline (as of October 2026). Anthropic's Sonnet 5.5 guide also reports that splitting a structured task into an answer call and then a JSON call kept accuracy high but at very high cost and latency (vendor-run, no numbers given). Treat both as reasons to start with one prompt and earn each split.

The last cell is not a joke. Decomposition is a debugging tool, not a virtue. A single prompt that passes its tests does not need splitting because it looks monolithic.

Routing is decomposition's cousin, and often the better first cut. Instead of one prompt with five conditional branches inside it, make one cheap classification call, then dispatch to whichever specialised prompt matches. Every downstream prompt stays short, focused and independently testable. A sixth category means writing a sixth prompt, not editing the one that five other categories depend on.

Two things to get right: give the classifier an explicit fallback such as other, going to a generic handler or a human, so it never has to force a bad fit; and log the routing decision, because "which branch did this take" is the first question you will ask when something goes wrong.

A split can also be a security seam. If one call reads untrusted text and a different one acts, the boundary between them is a place to enforce rules in code. A router that picks only from a fixed menu, and never sees tool output again, is what a 2025 design-patterns paper calls an action-selector. Prompt injection explains the threat and Containing prompt injection builds on it.

Next: the technique that makes a single hard step work better, and the many tasks where it is pure waste — Thinking out loud.