Deep Delegation Chains: Hierarchies That Stay Reliable

How to build multi-level agent hierarchies that don't collapse under their own complexity — context isolation, bounded delegation depth, and the deep-agents approach to long-horizon work.

Published on • October 28, 2026

AI Assistant

The single-agent-with-50-tools architecture hits a wall. As tasks get longer and toolsets get bigger, one agent’s context fills with intermediate steps, retrieved documents, and tool results — and quality degrades. The answer most teams converge on is delegation: split the work across specialized sub-agents. But delegation introduces its own failure mode — the deep, fragile chain where context is lost at every hop and nobody can say why step seven failed.

This post is about the middle ground: deep delegation done so hierarchies stay reliable. The pattern is exemplified by the deep-agents library from LangChain — which packages the lessons from building Claude Code-like agents into a reusable stack — but the principles apply to any framework.

Why Delegate at All

Delegation buys three things a single agent can’t easily get:

Context isolation. A research sub-agent accumulates 40 retrieved documents in its context, then returns a two-paragraph synthesis. The orchestrator never sees the noise.
Focused toolsets. A code-writing agent gets file and shell tools; a web-research agent gets search and fetch tools. Fewer, better-matched tools improve tool-selection accuracy.
Parallelism. Independent sub-tasks fan out concurrently, collapsing wall-clock time on long-horizon work.

The cost: every delegation boundary is a place where instructions get paraphrased, intent drifts, and errors hide. Reliability work is mostly about shrinking that cost.

The Deep Agents Recipe

The deep-agents approach (and the pattern generally) rests on three components:

1. A planning tool

The orchestrator maintains an explicit todo list — a writable plan the agent updates as it works. This sounds simple; it’s transformative for long tasks. The plan is scratchpad state the agent can re-read after a sub-task completes, which counteracts context-window pressure and makes multi-step progress visible for debugging.

agent = create_deep_agent(
    tools=["web_search", "write_file"],
    instructions="Research the topic, then write a report.",
)
# Internally: the agent gets a "todowrite"/"todo_read" tool pair

2. A filesystem (virtual or real)

Sub-agents write intermediate artifacts — raw notes, draft sections, data extracts — to files instead of hoarding them in context. A deep research run might write /notes/source-1.md through /notes/source-9.md, then read them back selectively. This is context compression via durable storage: the agent forgets details it can re-fetch.

3. Sub-agents as tools

The orchestrator’s delegation mechanism is itself a tool call. Requesting a sub-agent is an ordinary tool invocation, which means delegation composes with planning, retries, and tracing like any other action:

deep_agent = create_deep_agent(
    instructions="Write a market analysis report.",
    subagents=[
        {
            "name": "researcher",
            "description": "Researches a topic and writes findings to files",
            "prompt": "You are a research specialist...",
            "tools": ["web_search", "write_file"],
        }
    ],
)

The researcher runs with its own context window and toolset, returns a summary, and disappears. The orchestrator stays lean.

Staying Reliable: Design Rules

Bound the depth

Two levels — orchestrator plus workers — handles the overwhelming majority of real workloads. Three levels is occasionally justified (a coordinator delegating to team leads delegating to specialists). Beyond that, error rates compound multiplicatively: if each hop preserves intent 95% of the time, a four-hop chain succeeds only 81% of the time, before any tool errors. Most “we need another layer” moments are actually “our worker prompts are vague” moments.

Make delegation contracts explicit

The sub-agent prompt is a contract. Vague delegation (“research the market”) produces vague results. Good delegation specifies:

Mission — the single objective, in one or two sentences.
Output format — exactly what to return (e.g., “a markdown summary under 500 words; write raw sources to files”).
Boundaries — what not to do (don’t write code; don’t fetch more than 10 pages).
Success criteria — how to know the sub-task is done.

Preserve failure visibility

The classic deep-chain failure: the orchestrator reports “the research sub-agent found nothing” when the sub-agent actually hit a rate limit on step three and silently gave up. Fixes:

Sub-agents must report errors explicitly, not convert them into empty results.
The orchestrator’s delegation tool should return structured results — status, artifacts, error — not just text.
Traces should span the whole hierarchy; a sub-agent run is a child span, inspectable end to end.

Don’t let workers re-delegate by default

Sub-agents spawning their own sub-agents is how runaway costs and infinite loops are born. If you allow it, cap the global depth and require justification. Deep delegation is designed, not emergent.

Passing “the full conversation so far” across a delegation boundary pollutes the worker’s context and leaks irrelevant detail. Pass the plan, the file paths, and the specific sub-task. Workers read artifacts; they don’t inherit histories.

Fan out only what’s independent

Parallel sub-agents for independent research topics: great. Parallel sub-agents whose outputs must interleave precisely (write chapter 1 and chapter 2 with shared terminology): order them or merge through a synthesis step. False parallelism creates integration work that exceeds the time saved.

A Reference Topology

orchestrator (plan + filesystem + delegation tool)
├── researcher-A ── writes /notes/a-*.md, returns summary
├── researcher-B ── writes /notes/b-*.md, returns summary
├── analyst ─────── reads /notes/*, writes /draft/analysis.md
└── writer ──────── reads /draft/*, returns final report

Depth: 2. Parallelism: researchers run concurrently; analyst and writer are sequential because they depend on prior output. The orchestrator’s context holds only the plan, file listings, and worker summaries — maybe 5% of the total information processed. That ratio is the entire point.

When Not to Delegate

Delegation has overhead: prompt construction, sub-agent spin-up, result integration. Skip it when:

The task fits comfortably in one context window — delegation adds latency for nothing.
The task is a single tool call in disguise — “look up this API” doesn’t need a researcher.
Your failure budget is tiny and your prompts aren’t yet solid — fix single-agent reliability first; delegation amplifies existing sloppiness.

Conclusion

Deep delegation works when the hierarchy is shallow (two levels almost always), contracts are explicit, failures are visible, state moves through artifacts, and parallelism is real. The deep-agents pattern — planning tool, filesystem, sub-agents-as-tools — provides the mechanics; the design rules above provide the reliability. Build the hierarchy deliberately, instrument every hop, and remember: the goal isn’t more agents, it’s a lean orchestrator delegating bounded, well-specified, observable sub-tasks.