Lrnon

Lesson 3 of 8 · 8 min read · last verified 2026-08-26

One prompt, one job

In this lesson you will:

  • Split a multi-part request into single-purpose prompts
  • Explain why decomposition improves reliability and debuggability

Here is a prompt that looks efficient:

Read this support email. Work out what the customer is asking for, categorise it, judge how urgent it is, draft a reply, and flag anything needing a manager.

Five jobs. It will do all five, and it will do each of them worse than it would have done alone.

Why one prompt does five things badly

Attention is finite. A single pass has to satisfy five objectives at once, and they compete — effort spent getting the category right is effort not spent on the draft.

Worse, they interact. Having decided the issue is urgent, the draft becomes apologetic. Having written an apologetic draft, the urgency judgement looks confirmed. The steps contaminate each other, and you cannot see it happening because you only see the finished output.

And when something is wrong, you have no idea which part failed. You rewrite the whole prompt and hope.

Split it

Prompt 1 — Classify. Return one of: billing, technical, account, other. Prompt 2 — Rate urgency, with the reason. Return low, normal or urgent. Prompt 3 — Draft a reply, given the email and the category. Prompt 4 — Decide whether a manager is needed, given the urgency and category.

Four prompts, each with one job. Every one can be tested on its own, improved on its own, and swapped without touching the others.

What this buys you

Reliability. Each step gets undivided attention on a narrower task.

Testability. You can run twenty emails through the classifier alone and count how many it gets right. That number is meaningful. “How good is my big prompt” is not a question with an answer.

Debuggability. When the reply is wrong, you look at which step produced the wrong input to it. This is the difference between fixing something and rewriting it.

Different treatment per step. Classification can go to a small, cheap, fast model. Only the draft needs a capable one. That is often a large cost reduction, and E8·L5’s proportionality argument in its practical form.

Human checkpoints. You can put a person between step two and step three for the urgent ones only, which is impossible when everything happens in one pass.

The test for “too much”

Two signals, both easy to spot.

The word “and”. If describing what your prompt does needs an and, it is probably two prompts. “Summarise the meeting and extract the actions” — two.

Uneven quality. If the categories are always right and the drafts are inconsistent, they are competing. Separate them and the drafts improve without you touching the drafting instructions.

The honest cost

Decomposition is not free. Four calls instead of one means four times the latency and roughly four times the cost — although using a cheap model for the simple steps often makes it cheaper overall.

For a one-off task you are watching, one prompt is fine. For anything running repeatedly, unattended, where being wrong matters, the trade is almost always worth taking. That is the line between using an assistant and building something.

Try it now (6 minutes)

Take your most complicated prompt. Write down what it does, and count the ands.

Split it at the first one. Run both versions on the same five inputs and compare the part you care about most.

Check your understanding

1. Why does one prompt doing five jobs do each one worse?
2. The clearest signal a prompt is doing too much:
3. A practical benefit of splitting beyond reliability:

Recap

A prompt with several jobs does each one worse, and the steps quietly influence one another. Split at the word “and”: each piece gets full attention, becomes testable in isolation, can use a cheaper model, and allows a human checkpoint. The cost is more calls — worth paying for anything that runs unattended.

🗂 3 flashcards from this lesson join your daily review.

Previous: Structured output you can rely on · Next: Chaining steps together