Documentation Index
Fetch the complete documentation index at: https://langchain-5e9cc07a-preview-opensw-1779338558-1a9c41a.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
createDeepAgent has the following configuration options:
- Model
- Tools
- System Prompt
- Middleware, including prebuilt middleware and custom middleware
- Interpreters
- Subagents
- Backends (virtual filesystems)
- Human-in-the-loop
- Skills
- Memory
- Profiles
createDeepAgent API reference.
Model
Pass amodel string in provider:model format, or an initialized model instance. See supported models for all providers and suggested models for tested recommendations.
- OpenAI
- Anthropic
- Azure
- Google Gemini
- Bedrock Converse
- Other
Tools
In addition to built-in tools for planning, file management, and subagent spawning, you can provide custom tools:System prompt
Deep Agents come with a built-in system prompt. A deep agent’s value comes from the orchestration layer the SDK provides on top of the model—planning, virtual-filesystem tools, and subagents—and the model needs to know those exist and when to reach for them. The built-in prompt teaches the agent how to use that scaffolding so you don’t have to re-derive it for every project; tweak it through a profile or your ownsystem_prompt= rather than copying it verbatim.
When middleware add special tools, like the filesystem tools, it appends them to the system prompt.
Each deep agent should also include a custom system prompt specific to its specific use case:
Prompt assembly
Deep Agents builds the system prompt from up to four named parts so that caller-supplied instructions, the SDK’s built-in agent guidance, and any model-specific profile overrides can coexist with predictable precedence. Without this layering, a profile suffix tuned for Claude (for example) could overwrite or be overwritten by yoursystem_prompt= argument depending on call order; the named slots make the ordering explicit and stable.
In practice, most callers only encounter two slots: USER (your system_prompt=) and BASE (the SDK default). Selecting a model with a built-in profile—Anthropic or OpenAI today—adds a SUFFIX. The full four-part assembly is mainly relevant when you author a custom HarnessProfile or debug why a profile’s text appears where it does.
The four named parts (each may be absent):
| Name | Source | Notes |
|---|---|---|
USER | system_prompt= argument to create_deep_agent | str or SystemMessage; omitted when unset. |
BASE | The SDK default (BASE_AGENT_PROMPT) | Always present unless replaced by a profile’s CUSTOM. |
CUSTOM | HarnessProfile.base_system_prompt | Replaces BASE outright when a matching profile sets it. |
SUFFIX | HarnessProfile.system_prompt_suffix | Appended last when a matching profile sets it. |
USER -> (BASE or CUSTOM) -> SUFFIX, joined by blank lines (\n\n). Two invariants follow:
USERis always at the front. The caller’s text precedes any SDK or profile content, so persona/instructions take precedence regardless of which model is selected.SUFFIXis always at the end. Profile suffixes sit closest to the conversation history, where model-tuning guidance lands most reliably.
system_prompt= | profile base_system_prompt (CUSTOM) | profile system_prompt_suffix (SUFFIX) | Final assembled system prompt |
|---|---|---|---|
None | - | - | BASE |
None | - | ✓ | BASE + SUFFIX |
None | ✓ | - | CUSTOM |
None | ✓ | ✓ | CUSTOM + SUFFIX |
str | - | - | USER + BASE |
str | - | ✓ | USER + BASE + SUFFIX |
str | ✓ | - | USER + CUSTOM |
str | ✓ | ✓ | USER + CUSTOM + SUFFIX |
system_prompt_suffix, so a typical call lands in the str + - + ✓ row:
Passing a
SystemMessage (rather than a string) triggers a different concatenation path: the right-hand assembly (BASE-or-CUSTOM plus any SUFFIX) is appended as an additional text content block onto the message’s existing content_blocks. The same logical ordering applies (caller blocks first), and any cache_control markers on the caller’s blocks are preserved — useful for placing explicit Anthropic prompt-cache breakpoints.Subagent prompts
Subagent prompts
The same overlay rules apply to declarative subagents — each subagent re-runs profile resolution against its own model, then applies the resolved profile’s
There is no
base_system_prompt / system_prompt_suffix to its authored system_prompt. The subagent’s system_prompt plays the BASE role; CUSTOM and SUFFIX come from the profile that matches the subagent’s model (which may differ from the main agent’s profile).spec["system_prompt"] | profile base_system_prompt (CUSTOM) | profile system_prompt_suffix (SUFFIX) | Final subagent system prompt |
|---|---|---|---|
| authored | - | - | authored |
| authored | - | ✓ | authored + SUFFIX |
| authored | ✓ | - | CUSTOM |
| authored | ✓ | ✓ | CUSTOM + SUFFIX |
USER segment for subagents — the spec’s authored system_prompt is the closest analog and stays in the BASE slot. A profile that ships only a system_prompt_suffix (the common case for built-in Anthropic / OpenAI profiles) just appends to whatever the subagent author wrote; a profile that sets base_system_prompt will replace the authored prompt outright, so reach for that field deliberately.General-purpose subagent prompt
General-purpose subagent prompt
The auto-added general-purpose subagent follows the same overlay rules with one extra layer: the GP base prompt is resolved as
If
general_purpose_subagent.system_prompt (if set) -> HarnessProfile.base_system_prompt (if set) -> SDK GP default. The profile suffix layers on top either way.The two override fields can both carry a base-prompt replacement, but they are not interchangeable. general_purpose_subagent.system_prompt is GP-specific configuration; base_system_prompt is a global override that primarily targets the main agent. When both are set, the GP-specific intent wins for the GP subagent so a user tuning both fields never sees their GP override silently dropped:| Stack | Final system prompt |
|---|---|
| Main agent | "You are ACME's support orchestrator." + SUFFIX |
| GP subagent | "You are a research subagent. Cite sources." + SUFFIX |
general_purpose_subagent.system_prompt is unset, the GP subagent falls back to base_system_prompt (when set) and finally to the SDK GP default.Middleware
Deep Agents support any middleware, including the built-in middleware listed below, prebuilt middleware from LangChain, provider-specific middleware, and custom middleware you write yourself. Pass middleware to themiddleware argument of create_deep_agent.
By default, Deep Agents have access to the following middleware:
TodoListMiddleware: Tracks and manages todo lists for organizing agent tasks and workFilesystemMiddleware: Handles file system operations such as reading, writing, and navigating directoriesSubAgentMiddleware: Spawns and coordinates subagents for delegating tasks to specialized agentsSummarizationMiddleware: Condenses message history to stay within context limits when conversations grow longAnthropicPromptCachingMiddleware: Automatic reduction of redundant token processing when using Anthropic modelsPatchToolCallsMiddleware: Automatic message history fixes when tool calls are interrupted or cancelled before receiving results
MemoryMiddleware: Persists and retrieves conversation context across sessions when thememoryargument is providedSkillsMiddleware: Enables custom skills when theskillsargument is providedHumanInTheLoopMiddleware: Pauses for human approval or input at specified points when theinterruptOnargument is provided
Prebuilt middleware
LangChain exposes additional prebuilt middleware that let you add-on various features, such as retries, fallbacks, or PII detection. See Prebuilt middleware for more. Thedeepagents package also exposes createSummarizationMiddleware for the same workflow. For more detail, see Summarization.
Provider-specific middleware
For provider-specific middleware that is optimized for specific LLM providers, see Official integrations and Community integrations.Custom middleware
You can provide additional middleware to extend functionality, add tools, or implement custom hooks:Interpreters
Use interpreters to add aneval tool that runs JavaScript in a scoped QuickJS runtime. Interpreters are useful when the agent needs to compose tools programmatically, batch work, handle errors in code, or transform structured data without a full shell environment.
Subagents
To isolate detailed work and avoid context bloat, use subagents:Backends
Tools for a deep agent can make use of virtual file systems to store, access, and edit files. By default, deep agents use aStateBackend.
If you are using skills or memory, you must add the expected skill or memory files to the backend before creating the agent.
- StateBackend
- FilesystemBackend
- LocalShellBackend
- StoreBackend
- ContextHubBackend
- CompositeBackend
A thread-scoped filesystem backend stored in
langgraph state.Files persist across turns within a thread (via your checkpointer) and are not shared across threads.Sandboxes
Sandboxes are specialized backends that run agent code in an isolated environment with their own filesystem and anexecute tool for shell commands.
Use a sandbox backend when you want your deep agent to write files, install dependencies, and run commands without changing anything on your local machine.
You configure sandboxes by passing a sandbox backend to backend when creating your deep agent:
Human-in-the-loop
Some tool operations may be sensitive and require human approval before execution. You can configure the approval for each tool:Skills
You can use skills to provide your deep agent with new capabilities and expertise. While tools tend to cover lower level functionality like native file system actions or planning, skills can contain detailed instructions on how to complete tasks, reference info, and other assets, such as templates. These files are only loaded by the agent when the agent has determined that the skill is useful for the current prompt. This progressive disclosure reduces the amount of tokens and context the agent has to consider upon startup. For example skills, see Deep Agents example skills. To add skills to your deep agent, pass them as an argument tocreate_deep_agent:
- StateBackend
- StoreBackend
- FilesystemBackend
Memory
UseAGENTS.md files to provide extra context to your deep agent.
You can pass one or more file paths to the memory parameter when creating your deep agent:
- StateBackend
- StoreBackend
- Filesystem
Structured output
Deep Agents support structured output. You can set a desired structured output schema by passing it as theresponseFormat argument to the call to createDeepAgent().
When the model generates the structured data, it’s captured, validated, and returned in the ‘structuredResponse’ key of the agent’s state.
Connect these docs to Claude, VSCode, and more via MCP for real-time answers.

