The Key to Reliable Agent Delivery: Mastering Task Decomposition

Same model, same task — why does one person's Agent produce garbage while another delivers a complete, polished result? The gap rarely comes down to the model itself. It almost always comes down to one thing: whether you've taught your Agent to break the work apart.

This article, based on a talk by a technical creator on Bilibili, systematically walks through the methodology of task decomposition for large language models — from the classic failure mode of "stuffing an entire project into a single prompt, burning through 200K+ tokens, and getting fabricated data" all the way to a structured approach that enables stable, reliable delivery.

Why You Can't Feed Large Tasks to an Agent All at Once

There's a common intuition trap here: models keep getting stronger, context windows keep getting longer — so why not just dump the entire project into the conversation and let the model figure it out?

Reality is harsh. A classic failure case: an Agent ran a full page of output, burned through 200K+ tokens, filled the first three pages with industry history using entirely made-up data, and by page five had forgotten what product it was even supposed to be analyzing.

This happens because of three hard constraints:

• Attention follows a U-curve: In long texts, models tend to remember the beginning and the end — but lose track of what's in the middle. This is formally known as the "Lost in the Middle" problem.
• Errors compound: If each step is 90% reliable, five steps chained together leaves you with only ~59% overall success.
• Working memory is finite: When intermediate results flood the context, the model loses track of what it was trying to accomplish.

Here's an analogy: you buy a bare-shell apartment, tell the renovation crew "make it livable, I'm going on a business trip" — and just leave. Would you dare? Electrical work, plumbing, carpentry, painting — each phase needs its own instructions and sign-off. Agents are no different. Large tasks can't be swallowed whole. They have to be broken down. Task decomposition is the construction schedule of the AI world.

Technique #1: Separate Planning from Execution (Plan and Execute)

The most widely used backbone in mainstream Agent frameworks is Plan and Execute:

• Planner only thinks, never acts: Breaks the large task into a numbered task list.
• Executor only acts, never thinks: Picks up tasks one by one and carries them out.

Why keep them separate? Because separation enables focus. During planning, execution details create distractions; during execution, it's easy to lose sight of the overall goal. Separating the two roles dramatically improves stability.

More importantly, what you're producing isn't a linear checklist — it's a DAG (Directed Acyclic Graph). Take competitive analysis as an example: collecting data on three competitors is independent work that can run in parallel; cleaning the data depends on collection being done; analysis depends on cleaning being done. Arrows represent dependencies — tasks with no dependencies run first; tasks that depend on others wait until their inputs are ready. With this dependency graph, scheduling becomes principled, and it's immediately clear which steps can run in parallel to save time.

How Granular Should You Go?

So does finer always mean better? Actually, no.

• Too coarse: You haven't really decomposed anything — it's still too large to execute reliably.
• Too fine: Thirty micro-tasks means the overhead of passing context between them becomes exhausting, costs explode, and no one can see the big picture.

The right criterion comes down to one sentence: Each subtask should be completable in a single LLM call, with clear inputs and verifiable outputs. Something like "analyze the market" is still too coarse — it needs further breakdown.

Inside Each Subtask: ReAct Loop Drives Execution

Within each subtask, the Agent runs a loop — ReAct: Think (Thought), Act (Action), Observe (Observation).

Sound familiar? It's exactly how we debug code — make a guess, run it, check the logs, adjust. Debugging is fundamentally a feedback loop. Without Observation, an Agent is just guessing with its eyes closed. With it, every step can self-correct in real time.

Plans Must Be "Live": Dynamic Replanning

A one-shot plan is one of the most common illusions in Agent design. What happens at step three when the API suddenly goes down? The whole DAG becomes useless.

That's why plans must support dynamic adjustment. When an Observation doesn't match expectations, hand control back to the Planner to replan: if the API fails, switch to web scraping; redraw the affected portion of the DAG rather than starting over from scratch.

A reliable Agent = a good initial plan + the ability to admit failure and change course.

Context Management: Pass Summaries, Not Chat History

There's another critical handoff step that often gets overlooked — context passing.

When an electrician hands off to the next trade, they give a concise handover note — which pipes go where, where the switches are — not the full transcript of every conversation they had with the client.

Agents work the same way. The raw output of each subtask must be compressed into a summary before entering the next context window. The raw source material goes into long-term memory (a vector store) and gets retrieved only when needed. Remember: context is expensive real estate. Don't fill it with garbage.

Acceptance Criteria: Every Subtask Needs a Closed Loop

How does an Agent know when a subtask is done? It can't just go by feel.

The answer is acceptance criteria, written directly into the task definition. For example: "the price table must have at least three rows and must include source URLs." Pass the check and the task gets signed off; fail and it goes back into the ReAct loop to be redone.

Without acceptance criteria, decomposition is just theater. Errors that slip through to the next step become the downstream task's problem.

Three Common Production Pitfalls — and Three Guardrails

Pitfall #1: No Termination Condition

If a step keeps failing, will the Agent keep retrying? Yes — it will keep retrying until your account balance hits zero. This is the number one source of production incidents.

Three-part protection:

• Set a maximum iteration count for each subtask;
• Set a global budget cap;
• When limits are exceeded, trigger a fallback strategy: either degrade gracefully or escalate to a human.

Teaching an Agent to say "I can't do this" is part of making it reliable.

Pitfall #2: Context Pollution and Parallel Dirty Reads

Stuffing all intermediate results into the context dilutes attention and causes the Agent to get lost in its own notes — the fix is what we covered earlier: pass summaries, not raw data.

The other pitfall is parallel dirty reads: Task B fetches Task A's output before Task A has finished writing it, and reads a half-complete file. Remember: parallel execution only belongs to nodes that are truly independent. Dependent nodes must have gates — they only proceed once the upstream task has passed its acceptance check.

Three Guardrails for Production Reliability

For real production deployments, you need three guardrails:

1. Constrain outputs with JSON Schema. Giving the model free rein is the beginning of chaos; structured output is the beginning of governance.
2. Add human checkpoints at critical nodes. Before sending mass emails. Before dropping databases. Stop and ask a human.
3. Log everything. Record every Thought and Action in the logs. When something goes wrong, you can replay what happened and pinpoint exactly where things went off the rails. Without this, it's a black box — you won't even know how it died.

Summary: Four Principles for Reliable Agent Delivery

Distill the entire methodology into four lines:

• Large tasks are construction schedules (separate planning from execution, decompose into a DAG);
• Subtasks are closed loops (one call, one output, ReAct feedback, acceptance check at every step);
• Context is expensive real estate (pass summaries, not raw material);
• Reliability comes from guardrails (iteration caps, budget caps, human checkpoints, full logging).

Same model, same task — just add a structured task plan, and you go from failure to stable delivery. That's the value of task decomposition.

Once you've got decomposition right, can you have multiple Agents each take a branch? That's the territory of multi-agent collaboration. But remember: all collaboration starts with decomposition. Without good decomposition, adding more Agents just gives you more people dropping the ball.