Task Decomposition & Delegation

In a lead-and-workers system, the quality of the whole system is capped by two things. One is how well the lead splits up the task. The other is how well it briefs the workers. Most the agents did dumb things post-mortems trace back to one of these two. This lesson treats splitting and delegating as engineering problems with real outputs: a plan format, a brief and a scheduler.

Splitting a job: what makes a good sub-task

• Independent enough to run without constant chatter. If a worker needs another worker's result half way through, they are not separate tasks.
• Bounded. It has a clear definition of done and a limit on effort.
• Checkable. You can tell, by a rule or a checklist, whether it succeeded.
• Right-sized. Big enough to be worth the cost of a model call, and small enough to fit comfortably in one context window.

The plan is data, not prose

Ask the lead to write its plan as structured data that you can check and schedule. Do not ask for a paragraph you hope to parse. A plan that lists its dependencies lets plain code, and not another model call, decide what can run at the same time.

{
  "goal": "Compare the top 3 vector databases for a 10M-document RAG workload",
  "tasks": [
    {
      "id": "t1",
      "objective": "Summarize pricing and scaling limits for Pinecone",
      "depends_on": [],
      "output_schema": "VendorSummary",
      "tools": ["web_search", "fetch_page"],
      "max_tool_calls": 8,
      "done_when": "pricing tiers, max index size, and p95 latency claims are each cited"
    },
    { "id": "t2", "objective": "…same for Weaviate", "depends_on": [] },
    { "id": "t3", "objective": "…same for pgvector", "depends_on": [] },
    {
      "id": "t4",
      "objective": "Build a comparison table and recommendation",
      "depends_on": ["t1", "t2", "t3"],
      "tools": []
    }
  ]
}

The delegation brief

Workers start with nothing except what you give them. A one-line instruction like research the semiconductor shortage is the classic way to get repeated work, overlapping scopes and gaps. A good brief has five parts:

• Objective: one clear outcome, plus the reason why, so the worker can make sensible choices.
• Output format: the exact structure to return, so combining the results is easy.
• Tools and sources: which tools to use and which to avoid, and where to look first.
• Boundaries: what is out of scope, and what the other workers are covering, so work does not overlap.
• Effort budget: how many searches, tool calls or minutes, and when to stop. Agents cannot judge the right amount of effort on their own.

You are a research worker. Your single task:

OBJECTIVE: Find Pinecone's current pricing tiers, maximum index size, and any published
p95 query-latency figures. We're comparing vector DBs for a 10M-document RAG workload,
so cost-at-scale matters more than the free tier.

OUTPUT: Return JSON matching VendorSummary { pricing:[{tier,price,limits}],
max_index_size, latency_claims:[{claim,source_url}], gaps:[string] }.

SOURCES: Prefer the vendor's own docs and pricing page; use independent benchmarks only
to cross-check. Ignore SEO comparison blogs.

BOUNDARIES: Do NOT research Weaviate or pgvector — other workers cover them. Do not make
a recommendation; the lead does that.

BUDGET: At most 8 tool calls. If a figure can't be verified, put it in "gaps" rather than
guessing. Stop as soon as every field is filled or reported as a gap.

Scale the effort to the question

Put clear scaling rules in the lead's instructions, because models tend to over-invest in simple questions. A simple fact lookup needs one worker and a handful of tool calls. A direct comparison needs two to four workers. A broad, open question might need ten workers with clearly divided jobs. Without such rules, you pay for a whole research team to answer a trivia question.

A minimal scheduler

async def run_plan(plan):
    done: dict[str, Result] = {}
    pending = {t.id: t for t in plan.tasks}

    while pending:
        ready = [t for t in pending.values() if all(d in done for d in t.depends_on)]
        if not ready:
            raise PlanError("cycle or missing dependency")  # validate plans up front too

        batch = await asyncio.gather(*(run_worker(t, done) for t in ready),
                                     return_exceptions=True)
        for task, result in zip(ready, batch):
            if isinstance(result, Exception):
                result = await handle_failure(task, result)  # retry / replan / mark gap
            done[task.id] = result
            del pending[task.id]
    return done

Replanning

Plans meet reality. A worker reports that the source does not exist, or shows that the question was framed wrongly. Give the lead a limited replanning step. After each wave of results, it may add, drop or rewrite the remaining tasks. But limit the total number of replans. And keep the original goal fixed in the context, so the plan cannot drift away from what the user asked.