You wrote one prompt asking the model to (1) summarize a customer email, (2) classify sentiment, (3) propose a reply, (4) flag for escalation if needed, and (5) draft an internal Slack message. The output nails task 1, gives a generic answer for task 2, skips task 4 entirely, leaves a half-finished reply for task 3, and never touches task 5. You re-prompt “do all 5” and get the same shape with slightly different gaps.
Fastest fix: split the stack into one prompt per task. Run the independent ones in parallel and chain only the ones that genuinely depend on each other. A single prompt forces the model to share one output budget across every task, and later tasks consistently get the leftovers. The rest of this page shows how to decide which tasks to split, which to chain, and how to confirm every task actually got done.
Why this happens (it is not just you)
This is a measured effect, not a quirk of your phrasing. A 2025 study across six NLP tasks and several model families (MDPI, Electronics) found that bundling tasks into one prompt degrades accuracy in a way that depends heavily on the model: one model lost only about 3.7% versus its single-task baseline, while another collapsed by roughly 38.8%, and one fine-grained task (emotion classification) fell from 31.1% to 1.5% accuracy once it was bundled with other tasks. Structural tasks (extract a field, return JSON) survive bundling far better than fine-grained semantic ones (sentiment, nuance, judgment).
The practical takeaway, as of June 2026: there is no universal “safe” number of tasks. The more semantic or judgment-heavy a task is, the more it suffers from sharing a prompt, and you cannot predict the hit from model size alone.
Common causes
1. Tasks stacked to save typing
You batched because writing 5 prompts felt wasteful. The result is one prompt that does 5 things poorly instead of 5 prompts that each do one thing well.
How to spot it: the prompt has 3+ numbered tasks.
2. The output budget runs out
The model’s output is finite. Five tasks in one response means each effectively competes for a slice of the same token budget, even though some need a large share to be done well. Later tasks get truncated or skipped because the model has “spent” its output before reaching them.
How to spot it: later tasks are shorter, truncated, or missing.
3. Earlier tasks set the model’s “state”
After answering task 1 in a formal voice, task 2 inherits that voice even when a different register would be better. Within a single response the model is path-dependent: the tokens it already produced steer the ones that follow.
How to spot it: later tasks borrow the tone, format, or framing of earlier ones inappropriately.
4. No per-task success criteria
You said “do all 5” without saying what success looks like for each. The model satisfies whichever tasks are easiest and quietly drops the rest.
How to spot it: the prompt has one success criterion shared across all tasks.
5. Tasks have hidden dependencies
Task 3 depends on task 2’s output. The model handles them in order, but task 2’s answer is suboptimal, so task 3 cascades the error.
How to spot it: the failure of one task corrupts the next.
Which bucket are you in
Use this to decide split vs chain vs batch before you rewrite anything.
| Signal | Likely cause | Fix |
|---|---|---|
| 3+ numbered tasks, all unrelated | Stacked to save typing | One prompt per task, run in parallel (Step 2) |
| Last tasks truncated or empty | Output budget exhausted | Split so each task gets its own output (Step 1) |
| Later tasks copy earlier tone/format | Path-dependent state | Separate prompts or a planner split (Steps 3, 5) |
| One success rule for everything | No per-task criteria | Label tasks + per-task success (Step 4) |
| Fixing task 2 fixes task 3 | Hidden dependency | Chain sequentially with explicit handoff (Step 3) |
Before you change anything
- List every task you stacked. Count them.
- Mark which tasks are truly independent versus dependent on another task’s output.
- For each task, write one line describing what a correct answer looks like.
- Decide parallel (independent) versus sequential (dependent).
- Decide whether each task can fit in its own request, or whether they share a system prompt with one task per turn.
Shortest path to fix
Step 1: List the tasks; default to one prompt per task
Task 1: Summarize the email.
Task 2: Classify sentiment.
Task 3: Draft reply.
Task 4: Flag escalation.
Task 5: Internal Slack message.Default to 5 prompts. Only batch if a real dependency forces it or token cost genuinely outweighs quality for this workload.
Step 2: For independent tasks, run them in parallel
If your platform supports it, fire the independent prompts as concurrent API calls. Each gets the full output budget, and total latency is the slowest single call, not the sum of all of them. The PARALLELPROMPT benchmark found that independent sub-tasks parallelize cleanly with up to ~5x speedup and little quality loss outside highly creative work.
import asyncio
results = await asyncio.gather(
call_model(prompt_1),
call_model(prompt_2),
call_model(prompt_3),
call_model(prompt_4),
call_model(prompt_5),
)If you are inside a single agent loop rather than your own code, you can let the model emit independent tool calls in one turn. As of June 2026, OpenAI enables this by default via the parallel_tool_calls flag (set it to false to force serial calls), and Claude returns multiple tool_use blocks in one response when it judges the tools independent (see Anthropic’s parallel tool use docs). Your runner dispatches them at once and returns all results before the next inference step.
Step 3: For dependent tasks, chain sequentially with explicit handoff
Pass 1: Summarize email. -> <summary>
Pass 2: Given <summary>, classify sentiment. -> <sentiment>
Pass 3: Given <summary> and <sentiment>, draft reply. -> <reply>
Pass 4: Given <summary>, <sentiment>, decide escalation. -> <bool>
Pass 5: Given all of the above, write Slack message. -> <message>Passing each result forward as a named variable keeps quality high and makes the dependency chain explicit, so a bad upstream answer is easy to catch before it poisons the next step.
Step 4: If you must batch, label tasks and give per-task success criteria
Process the email below. For EACH numbered task, output a labeled section.
Do not skip any task. If a task does not apply, output the label and "N/A".
Task 1: SUMMARY (max 30 words)
Task 2: SENTIMENT (positive | neutral | negative | frustrated)
Task 3: REPLY_DRAFT (50-100 words, second person, no emoji)
Task 4: ESCALATION (yes/no + 1-sentence reason)
Task 5: SLACK_MSG (under 40 words, casual)
Output exactly these labels:
TASK 1: ...
TASK 2: ...
TASK 3: ...
TASK 4: ...
TASK 5: ...Explicit labels, hard length limits, and a “do not skip” instruction blunt the “runs out of energy” pattern. Keep judgment-heavy tasks (sentiment, escalation) out of a batch when accuracy matters. Those are the fine-grained tasks the research shows degrade hardest when bundled.
Step 5: Use a planner / executor split for complex multi-task work
Planner prompt: Given input X, produce a step-by-step plan. For each step,
state its goal and the exact output schema it must return.
Then run each planned step as its own prompt, feeding forward only what
the next step needs.This decomposes large, fuzzy work into well-scoped sub-prompts. It is the same decomposition idea behind techniques like least-to-most prompting, which the prompt-engineering survey documents as a reliable accuracy win on multi-part reasoning.
Step 6: Audit for completion
After running, programmatically check that every task’s output is present and well-formed (for example, assert each expected label exists and is non-empty). If a task is missing, re-run only that one rather than the whole stack.
How to confirm it is fixed
- Every task has a complete output, not just task 1.
- Each task’s output passes its own success criterion from Step 4.
- The depth of the last task matches the depth of the first.
- A teammate reviewing the output cannot tell which task ran first.
- Total quality beats the batched version, at the cost of a few more calls or passes.
If it still fails
- The tasks may have more dependencies than you thought. Sequence them (Step 3).
- The model may be carrying too many tasks. Drop the lowest-value one.
- Route the most important task to a stronger model and the rest to a cheaper one.
- For high-stakes work, do not batch. One prompt per task, always.
FAQ
How many tasks is too many for one prompt? There is no fixed number. The 2025 MDPI study found degradation is model- and task-dependent, with semantic tasks (sentiment, classification, judgment) collapsing far sooner than structural ones (extraction, formatting). Treat any prompt with 3+ tasks as a risk and test it against single-task baselines before trusting it.
Is splitting into many prompts more expensive? Usually only slightly. You pay for a bit more input overhead per call, but you avoid re-running a botched batch, and parallel independent calls do not add wall-clock latency. If cost is the real constraint, batch only the cheap structural tasks and split out the judgment-heavy ones.
Does asking the model to “take your time and do all 5” fix it? No. The failure is structural, not motivational. The model still shares one output budget and stays path-dependent within the response. Per-task labels with hard limits (Step 4) help; splitting the prompt helps more.
Parallel API calls or one prompt that emits parallel tool calls?
Use your own parallel calls when you control the code and the tasks are independent. Use native parallel tool calls when you are inside a single agent loop. As of June 2026, OpenAI ships parallel_tool_calls on by default and Claude emits multiple tool_use blocks when tools look independent.
Why does the model skip the same later task every time? Once it has produced the earlier sections, the remaining output budget and the momentum of the response push it to wrap up. Later tasks, especially open-ended ones, are the first to be cut. Splitting the prompt or moving the skipped task to the front confirms this quickly.
Prevention
- Default rule: 1 prompt = 1 task.
- For batched workflows, use the planner + executor pattern with explicit sub-prompts.
- Keep a personal anti-pattern check: “Did I stack tasks?” before sending.
- Audit production pipelines. Any prompt with 3+ tasks, especially semantic ones, is a risk.
- Treat token-saving via batching as a smell unless quality is empirically equivalent.
- Ask “if this fails halfway, what is recoverable?” Batched prompts fail half-completely.
Related reading
- Long prompt degrades output
- Long background hides task
- Unclear task boundary
- Prompt too broad
- No success criteria
Tags: #Troubleshooting #Prompt #Prompt quality #Prompt engineering