1. What is a deep agent?
A deep agent is a tool-using AI system designed to organize and carry out complex, multi-step work. It can break down a goal, gather evidence, delegate focused tasks, save intermediate results and adjust its approach when something fails.
Consider a request to compare three technology providers and recommend one. The four components each have a clear job:
- Explicit Planning: make the work visible. Turn the goal into named subtasks—define criteria, research, compare and review—with dependencies and completion checks. Update progress and change the plan if a required source is unavailable.
- Hierarchical Delegation (Subagents): divide focused work. A coordinating agent assigns bounded tasks to specialists: one investigates security, another pricing. Separate context windows keep detailed investigations from crowding the main task. Independent work can run in parallel when supported.
- Persistent Memory & File System Access: retain useful work. Save source notes, findings and drafts outside the active conversation, then retrieve the relevant parts. Durable storage can preserve them across sessions; a file interface alone does not guarantee persistence.
- Specialized System Prompts & Skills: define how to work. The system prompt sets the role, constraints and tool-use rules. Skills supply reusable procedures, such as applying common comparison criteria, citing evidence and flagging uncertainty instead of guessing.
The software that coordinates these capabilities is often called an agent harness. “Deep” describes the system design—not a new neural network or a guarantee of better reasoning. LangChain’s Deep Agents is one implementation; available capabilities and defaults vary.
2. How is a deep agent different from a shallow agent?
A basic or “shallow” agent typically follows a reactive loop: receive a request → ask the model what to do → call a tool → observe the result → answer or repeat. This is often called a ReAct-style loop. It works well when the task is narrow and only a few steps are needed—for example, finding one provider’s published price and summarizing it.
The difficulty appears as the task grows. Comparing several providers across pricing, security and integration may require many searches and document reads. If all intermediate results stay in one conversation, they compete with the original goal for limited context. Earlier constraints become harder to use, useful evidence may be summarized away, and repeated tool calls can replace meaningful progress.
A deep-agent architecture keeps that same model-and-tool loop but gives the surrounding system more structure. The plan records what remains to be done. A workspace holds detailed evidence. Specialists investigate bounded questions in their own contexts. The coordinator brings their results together, checks gaps and revises the plan rather than simply continuing the last local action.
For example: if pricing is public but a security report is unavailable, a shallow loop might keep searching or produce an incomplete answer. A well-designed deep agent can mark pricing complete, preserve its sources, flag the missing security evidence and ask for access or qualify the recommendation. The improvement is traceable progress and controlled recovery—not a guarantee that the model will always choose correctly.
| Aspect | Typical shallow agent | Deep-agent pattern |
|---|---|---|
| Planning | Chooses the next step in a short loop | Tracks subtasks, dependencies and progress explicitly |
| Context | Relies mainly on the current conversation | Loads relevant information and offloads bulky results |
| Delegation | One agent handles most of the work | Specialists handle bounded subtasks when useful |
| Intermediate work | Often stays in message history | Saved as retrievable notes, evidence and drafts |
| Failure handling | May retry the same local step | Can revise the plan and resume from configured checkpoints |
| Best fit | Quick, narrow requests | Longer tasks with uncertain paths and multiple sources |
These are design tendencies, not strict categories: a simple agent can also have memory or checkpoints. The benefit comes from managing complex work deliberately—not from adding more agents. For fixed steps and calculations, a deterministic workflow is often the better choice.
This distinction follows the architectural emphasis in NVIDIA’s deep-agents overview: longer-running work benefits from explicit plans, isolated delegation and external workspaces. It does not mean that every ReAct agent is stateless, or that RAG is limited to shallow systems.
3. Architecture: the capabilities around the model
A plan that changes with evidence
Each task needs a completion condition. “Security reviewed” should mean the required evidence was checked, not just that the agent wrote those words. If a provider’s certification cannot be verified, the plan should request evidence or flag the gap.
Tools and an execution environment
Tools connect the agent to search, databases and APIs. For example, a document-search tool returns approved security reports. The backend—not the model’s instructions—validates arguments and enforces access.
Workspace and context management
Store a long report in the workspace and bring only relevant excerpts into the current model request. Keep a reference to the original: a short summary can miss an important exception.
Specialist delegation
Give each specialist a clear question, necessary context and an expected result. Security and pricing research may run independently; the final recommendation must wait for both. Parallel execution depends on runtime support and is not automatically cheaper.
Verification, recovery and human control
Check sources, structured outputs and business rules before accepting a result. Configured checkpoints help resume interrupted work. Human approval can pause a sensitive action, such as sending a recommendation externally.
4. Context, state and memory are not the same thing
- Active context: the tokens available to the model in the current request. It is finite and incurs processing cost.
- Run or thread state: messages, task status, tool observations and checkpoints for this execution or conversation.
- Workspace artifacts: documents, extracted evidence, drafts and other intermediate outputs. Their durability depends on the storage backend.
- Long-term memory: selected information intentionally retained across threads, with ownership, permissions, provenance and expiry.
Example: the model reads a short security summary now, the workspace holds the full report, the checkpoint records which providers have been reviewed, and approved long-term memory may retain the organization’s comparison criteria.
A virtual filesystem does not guarantee persistence: an in-memory backend loses data on process exit. Cross-session memory needs durable storage and access rules. RAG retrieves evidence from a document collection; memory retains selected information. A deep agent can use both, with source versions and permissions preserved.
5. Skills, tools and subagents: three different concepts
A tool performs an operation. A skill teaches a procedure: when to use tools, which checks to perform and what a good result looks like. A subagent is a delegated worker running a model loop with its own instructions and context. A skill can guide a subagent, but loading a skill does not create another agent.
Example: a comparison skill says “use the same criteria and cite every material claim”; a search tool retrieves a report; a security subagent applies those instructions to assess it. They solve different problems.
The LangChain skills update adds tool binding, pinning and mid-thread reloading. Binding can disclose tool schemas only when their skill is activated. Pinning lets an application load selected instructions before the next model call. Reloading lets a thread discover changed skills.
These capabilities depend on the implementation. Loading a skill or exposing a tool grants no permission by itself. Review and version skills; untrusted instructions can redirect an agent or introduce unsafe procedures.
6. Where should deep agents be used?
Deep agents are useful for tasks such as software development, deep research and computer-use workflows. The useful question is not whether a task sounds advanced, but whether planning, retained context and delegation solve a real coordination problem.
Deep research and competitive analysis
Example: compare market trends or technology providers using multiple reports. The agent can split research into themes, retain source notes, investigate contradictions and assemble a cited conclusion. Benefit: broader evidence coverage and less repeated collection, with a clearer record of gaps. Citations and conclusions still need verification.
Software development and maintenance
Example: investigate a defect spanning several modules, propose changes and check test results. Planning tracks affected work; focused subagents can inspect different areas; workspace files retain changes and test evidence. Benefit: coordinated work across a larger task instead of isolated suggestions. Execution needs isolation, and consequential changes need review.
Computer-use and application workflows
Example: collect records from a permitted application, navigate several screens and prepare a form where suitable APIs are unavailable. The agent observes the interface after each action and adjusts when the screen changes. Benefit: automation can cover multi-step GUI work without a custom integration for every screen. Interfaces are fragile; final submissions need validation and, where appropriate, human approval.
Document-heavy reviews and supplier assessment
Example: assess supplier evidence or compare a set of contracts against common requirements. Specialists can examine security, commercial terms and missing documents, then return evidence to a coordinator. Benefit: more consistent coverage and a review-ready package, while qualified people retain responsibility for legal, compliance and purchasing decisions.
Operational investigations
Example: connect alerts, logs and support records into an incident timeline, test possible explanations and recommend next steps. Save findings as the investigation develops rather than restarting with every new clue. Benefit: better continuity across sources and handoffs. A proposed explanation is not proof, and production changes require separate controls.
Across these cases, the main benefits are longer-task coordination, focused context, reusable intermediate work and adaptive recovery. Properly configured isolation and approval controls can reduce execution risk, but those protections are not automatic properties of a deep agent.
The common pattern is multiple steps, several sources, an uncertain path and a need to preserve intermediate work. For a single factual lookup, straightforward FAQ or fixed calculation, a simpler system usually has less overhead.
There are trade-offs: more model calls can increase latency and cost; specialist findings can conflict; summaries can lose detail. Use delegation only when its benefit exceeds the coordination effort, and keep deterministic rules outside the model.
7. Why deep agents need a cost and latency strategy
Long-running agents repeatedly send instructions, tool schemas and prior messages to the model. Delegation adds more calls, and retries add more work. Measure cost per successfully completed task, including failed runs, rather than cost per isolated model response.
- Progressive disclosure avoids loading irrelevant skill bodies and tool schemas into every request.
- Context offloading keeps bulky intermediate results outside the active prompt, while preserving retrievable evidence.
- Subagents can protect the parent’s context, but their own token usage and coordination still cost money.
- Prompt caching can reuse model computation for an unchanged input prefix. New input and output still require processing, and a new answer is still generated.
Keep stable instructions and eligible tool definitions early in the prompt; put changing task information later. Mutating an earlier prefix can reduce cache reuse. The exact behavior depends on the provider, model, SDK language and version, cache eligibility and retention.
For example, repeated research steps may reuse processing for stable instructions while still generating new findings. Provider support varies; the savings reported in LangChain’s caching article are workload-specific, not guaranteed. Measure total duration, cache-read tokens and cost per successful task. See the LLM caching guide for more detail.
8. Security, recovery and human oversight
Autonomy increases the number of actions a system can attempt. It therefore increases the importance of controls outside the model. Context isolation is not a security sandbox, and a read-only-looking prompt does not enforce read-only access.
Example: drafting a supplier recommendation and emailing it to an external party are different actions. The draft can be checked automatically; sending it may require a person’s approval and a fresh permission check.
- Least privilege: scope tokens, database queries, file paths and tools to the authenticated user and tenant. Enforce the same controls for subagents.
- Untrusted content: treat web pages, documents and tool output as data, not instructions that can override system policy.
- Execution isolation: if code execution is needed, use a properly isolated environment, restricted network access and resource limits. A virtual filesystem alone is not an OS security boundary.
- Action-specific approval: show the exact target and proposed change. Expire approvals or require renewed approval when facts or action parameters change.
- Bounded recovery: use deadlines, retry limits, cancellation and explicit failure states. Recheck live facts after a long pause; do not blindly replay irreversible writes.
- Privacy: minimize personal data in prompts, files and traces; encrypt stored artifacts and define retention and deletion rules.
Human review and resumable execution need explicit configuration and an authenticated approval path. Retries also need duplicate-action protection: resuming a task should not send the same message or repeat a committed change.
9. Evaluate the workflow—not just the answer
A deep agent can write a convincing final response after taking the wrong path. Evaluate both the trajectory—its tool calls, evidence, decisions and transitions—and the final artifact. Traces should record observable actions and outcomes, not require exposing private model reasoning.
| Test scenario | Expected behavior |
|---|---|
| A source is missing or a claim cannot be verified | Flag the evidence gap; do not invent a citation or mark the review complete |
| Two reports contain different versions of a fact | Check dates and provenance; explain which evidence applies |
| A document instructs the agent to ignore policy | Treat it as untrusted content and preserve tool restrictions |
| A specialist returns conflicting evidence | Reconcile sources or escalate; do not silently choose a convenient answer |
| An API times out or the process restarts | Resume from valid state with bounded retries; do not duplicate writes |
| The user loses permission before execution | Deny the action even if an earlier plan or approval allowed it |
| The deadline or budget is reached | Stop safely, preserve partial evidence and report incomplete work |
Compare the deep-agent implementation with a simpler baseline on representative tasks. Track verified completion rate, evidence accuracy, policy violations, unnecessary delegation, recovery success, human review effort, latency percentiles and cost per successful task. A self-assessed “done” flag is not the success metric.
Production-readiness checklist
- Business contract: clear input, output, allowed actions, success criteria and explicit stop conditions.
- Data contracts: typed schemas, policy versions, provenance, tool error formats and current permissions.
- Persistence: durable thread checkpoints, artifact storage, tenant isolation and a deliberate cross-thread memory policy.
- Control boundaries: least privilege, injection tests, restricted execution, approval gates and idempotent writes.
- Operational limits: timeouts, concurrency caps, token and spend budgets, cancellation, backoff and safe fallback.
- Evaluation: baseline comparisons, edge cases, regression datasets and checks of both action traces and outputs.
- Deployment: background workers for long tasks where needed, durable queues or run scheduling, progress streaming and authenticated resume APIs.
- Release management: version models, prompts, skills and tools; monitor changes; provide rollback and a way to disable risky actions.
The practical takeaway
Use a deep-agent pattern when the work needs adaptive planning, selective context and evidence-backed coordination. Keep predictable business rules deterministic. Make permissions, budgets and approval enforceable outside the model. More autonomy is useful only when the system can demonstrate what it did—and stop safely when it cannot.
References and further reading
Based on the supplied references and official documentation. The four-component overview is a conceptual guide, not a promise that every framework enables all features by default. Persistence, planning, delegation and skills depend on configuration. Explanations, examples and diagrams are original; benchmark results are not treated as universal guarantees.
- DataCamp — Deep Agents tutorial
- NVIDIA — What Are Deep Agents?
- LangChain — Deep Agents overview and current Python capabilities
- LangChain — Deep Agents quickstart
- LangChain — Subagents and context isolation
- LangChain — Skills documentation
- LangChain — Prompt Caching with Deep Agents
- LangChain — Revamping Skills in Deep Agents
