Deep Agents Explained: Long-Horizon Autonomous Work

Deep agents are AI systems built to run long-horizon tasks: multi-hour or multi-day jobs that require planning, tool use, memory across steps, and self-correction, without a human re-prompting at every turn. Unlike a single-turn chatbot call, a deep agent breaks a goal into subtasks, executes them with tools, checks its own output, and revises its plan when reality does not match expectations. This article covers the architecture, the failure modes that shallow agents run into, and a working pattern you can build today.

What makes an agent "deep" instead of shallow

Most "AI agent" demos are shallow: one prompt, one or two tool calls, one response. That works for a single lookup or a simple transformation. It falls apart the moment a task spans more than a handful of steps, because the model has no durable plan, no persistent state, and no way to notice it went off track three steps ago.

A deep agent adds four things a shallow agent lacks:

• An explicit plan that survives across many tool calls, not just implicit reasoning inside one context window.
• Persistent state (files, a task list, a scratchpad) that outlives any single model call.
• Sub-agent delegation so the top-level planner is not doing every unit of work itself in one giant context.
• Self-verification that treats "the tool call succeeded" and "the task is actually done" as two different questions.

If you strip any one of these out, you get an agent that looks impressive on a 5-minute demo and falls apart on a 5-hour job. This is the practical difference between deep agents and simple agent loops: depth is about surviving time and complexity, not about having a bigger model.

Why single-context agents fail on long tasks

A single LLM call has a fixed context window. As a long task runs, the transcript of tool calls, outputs, and reasoning grows until it either exceeds the window or, more commonly, the useful signal gets buried in noise long before the hard limit. Two failure modes show up repeatedly:

1. Context rot. The model's attention degrades as the transcript fills with successful-but-irrelevant tool output (a full file read, a verbose test log). By turn 40, the model is reasoning against a haystack instead of the actual current state of the task.
2. Plan drift. Without a written plan the model can check itself against, it silently re-derives the goal from the last few messages. Over a long session this re-derivation drifts, and the agent starts working on a slightly different problem than the one it was given.

Deep agent architectures solve both by moving state out of the conversation and into external, addressable artifacts: a task list, a set of files, a git branch. The model's job at each step is to read the relevant slice of state, act, then write the updated state back out. This is the same reason experienced engineers keep a running doc or ticket instead of holding an entire project in their head.

The core architecture: planner, workers, and a shared file system

The pattern that shows up across most deep agent implementations, whether built on LangGraph, the Claude Agent SDK, or a hand-rolled orchestration loop, has three layers.

1. The planner (orchestrator)

The planner receives the goal and produces a task list, not a single next action. It is deliberately kept out of the weeds: it does not read entire files or execute long shell commands itself. Its context stays small because its job is decomposition and sequencing, not execution.

Goal: Migrate the billing module from Stripe API v1 to v2

Plan:
1. Inventory every file that imports the v1 Stripe client
2. For each file, draft the v2-equivalent call
3. Update the webhook signature verification for v2 payload shape
4. Run the billing test suite, fix failures
5. Verify a manual test purchase end-to-end

2. Sub-agents (workers)

Each plan step, or each file in step 2 above, gets delegated to a sub-agent with a narrow, self-contained prompt. Crucially, the sub-agent gets a fresh context window. It does not inherit the planner's entire conversation history, only what it needs to do its one job: the file path, the target API shape, and any constraints. This keeps each worker's context clean and lets you run several in parallel when the steps are independent.

def dispatch_worker(task: str, context: dict) -> str:
    """Spin up a sub-agent with a fresh context for one bounded task."""
    prompt = build_scoped_prompt(task, context)
    result = agent_client.run(
        prompt=prompt,
        tools=[read_file, write_file, run_tests],
        max_turns=15,
    )
    return result.summary

3. Shared state (the file system, not the chat log)

Instead of passing results back to the planner as more conversation turns, workers write their output to files: a scratch directory, a task-status file, a set of diffs. The planner reads status from these files rather than accumulating every worker's raw output in its own context. This is the single biggest lever for making an agent scale past a handful of steps: state lives in the file system, and the conversation stays a thin coordination layer on top of it.

project/
  PLAN.md          <- planner writes and updates this
  tasks/
    task-01.json   <- status: done | in_progress | blocked
    task-02.json
  scratch/
    worker-01.log  <- sub-agent working notes, not fed back verbatim

Memory: short-term, long-term, and what to actually persist

"Memory" gets used loosely in agent discussions. In practice a deep agent needs three distinct kinds:

• Working memory: the current task's context window. Ephemeral, rebuilt fresh for each sub-agent call.
• Session memory: the plan, task statuses, and intermediate artifacts for the current run. Lives in files for the duration of the job, discarded or archived when the job finishes.
• Long-term memory: facts, preferences, and decisions that should survive across separate runs, days or weeks apart. This is the smallest and most valuable category, and the one most agents get wrong by either storing everything (which degrades retrieval quality) or storing nothing (which forces re-discovery every run).

A practical rule: only promote something to long-term memory if it would change a future decision and is unlikely to change itself. "The staging database uses port 5433, not 5432" belongs in long-term memory. "Ran the test suite at 3:42pm and it passed" does not.

def should_persist(fact: str) -> bool:
    """Heuristic gate before writing to long-term memory."""
    is_durable = not fact.startswith(("Ran ", "Attempted ", "Currently "))
    is_decision_relevant = any(
        kw in fact.lower() for kw in ("config", "convention", "constraint", "prefers", "requires")
    )
    return is_durable and is_decision_relevant

Self-verification: closing the loop

The gap between "the tool call returned success" and "the task is actually solved" is where most deep agents quietly fail. A deep agent needs a verification step that is structurally separate from the step that did the work, because a model that just wrote code is a biased reviewer of that same code.

Three verification patterns cover most cases:

• Programmatic checks: run the test suite, run a linter, run a type checker. Cheap, deterministic, catch a large share of regressions.
• Fresh-eyes review: dispatch a separate sub-agent, with no memory of how the work was produced, to review the diff or output against the original requirement. This mirrors why code review works better than self-review in human teams.
• Behavioral verification: for anything with a runtime surface (a web app, an API, a CLI), actually exercise the changed path end to end rather than trusting static analysis alone. If a change touches a checkout flow, click through checkout; do not just confirm the file compiles.

def verify_task(task_id: str) -> bool:
    if not run_tests(task_id):
        return False
    review = dispatch_worker(
        task=f"Review the diff for task {task_id} against its original requirement. "
             f"Report pass/fail and why.",
        context={"diff": get_diff(task_id)},
    )
    return "pass" in review.lower()

Skip this and you get an agent that reports "done" with high confidence and a broken result. This failure mode is common enough that it deserves its own habit: treat "verification before completion" as a required step, not an optional polish pass.

Handling failure and re-planning

Long-horizon tasks hit unexpected obstacles: a flaky test, a missing dependency, an API that behaves differently than documented. A deep agent needs a defined response when a sub-agent reports failure, rather than either silently giving up or blindly retrying the identical action.

A workable escalation ladder:

1. Retry once with the failure message added to context, in case it was transient or the first attempt missed an obvious detail.
2. Narrow the sub-task if the failure suggests the original scope was too broad (a worker asked to "fix the module" when only one function is broken).
3. Escalate to the planner to re-sequence: maybe step 4 depends on something step 2 did not actually deliver, and the plan itself needs updating, not just the failed step.
4. Surface to the human when the agent has exhausted its own options or the fix requires a judgment call outside its authority, such as choosing between two valid architectural approaches.

The planner owning re-planning, rather than each worker independently deciding to retry or give up, is what keeps a long job coherent. Without it you get workers making locally reasonable but globally inconsistent choices.

Building a minimal deep agent yourself

You do not need a heavyweight framework to get the core benefits. A minimal version needs four pieces:

1. A planner prompt that writes a task list to a file before doing any work.
2. A dispatch function that calls a fresh model instance per task, passing only the scoped context that task needs.
3. A status file each worker updates, which the planner reads before deciding the next step.
4. A verification call, separate from the worker that did the task, before marking anything complete.

def run_deep_agent(goal: str):
    plan = create_plan(goal)          # planner call, writes PLAN.md
    write_tasks(plan)                 # one file per task, status=pending

    for task in pending_tasks():
        result = dispatch_worker(task.description, task.context)
        update_status(task.id, "awaiting_review", result)

        if verify_task(task.id):
            update_status(task.id, "done")
        else:
            replan_or_escalate(task, result)

    return summarize_run()

Scale this pattern up with parallel dispatch for independent tasks, a real vector or file-based memory store for long-term facts, and a human-in-the-loop checkpoint before anything irreversible (a deploy, a payment, a force-push), and you have the shape of most production deep agent systems in use today.

Where deep agents fit and where they do not

Deep agents are worth the added complexity when a task genuinely spans many steps with real branching: a multi-file refactor, a research task that needs to synthesize many sources, an end-to-end feature build with tests. They are overkill for a single lookup, a one-shot transformation, or anything you can verify correctly in one glance. Adding planning and sub-agent layers to a task that fits in one prompt just adds latency and failure surface without buying you anything. Match the architecture to the actual horizon of the task, not to what sounds impressive.

FAQ

What is the difference between a deep agent and a regular AI agent? A regular or shallow agent handles a task within a single context window: one plan implicitly held in the model's reasoning, executed in a handful of tool calls. A deep agent externalizes the plan and state into files or a task store, delegates units of work to sub-agents with fresh context, and verifies results before marking a task complete. The difference matters once a task exceeds what fits comfortably in one context window without quality degrading.

Do deep agents require a specific framework? No. The pattern (planner, workers with scoped context, shared file-based state, separate verification) can be built with any orchestration approach, including a hand-rolled loop calling an LLM API directly. Frameworks like LangGraph or the Claude Agent SDK provide scaffolding for this pattern, but the architecture is the important part, not the library.

How do deep agents avoid running out of context on long tasks? By keeping working memory ephemeral and scoped per sub-agent instead of accumulating an entire session's history in one context window. The planner stays lightweight by reading status summaries from files rather than every worker's raw output. State that needs to persist lives outside the conversation, in files or a task store, and gets read back in only when relevant to the current step.

Why do deep agents need separate verification instead of trusting the worker's own report? A model that just produced a piece of work is a biased judge of whether that work is correct, the same reason human code review works better than self-review alone. Separate verification, whether a test suite, a fresh-context review agent, or actually exercising the changed behavior, catches the gap between "the tool call succeeded" and "the task is actually solved," which is where most silent agent failures happen.

Can deep agents run fully unattended for hours or days? Yes, for tasks with well-defined success criteria and a verification step that can catch drift, deep agents can run long unattended stretches. The safer pattern keeps a human checkpoint before irreversible actions (deploys, payments, destructive file operations) and gives the agent a clear escalation path when it hits a decision outside its authority, rather than aiming for zero human involvement on every kind of task.

What is the biggest mistake teams make building their first deep agent? Skipping the state-externalization step and letting the conversation transcript be the only memory. This works fine in a demo and degrades badly on real long-horizon tasks as the transcript fills with noise and the model's effective attention to the actual goal drops. The fix is mechanical: write plans and task status to files, keep each sub-agent's context scoped to just what it needs, and read status back from files rather than from scrollback.