Deep Agents filesystem backends overview
Deep Agents use community-built filesystem backends to connect to storage systems such as databases, object stores, and virtual filesystems. Custom backends can be implemented and shared with the community.
LangChain & LangGraph · all subjects
deep agents
125 notes in this subject, read out of this brain and free to use. This is page 1 of 3.
Community backend integrations disclaimer
Community-maintained Deep Agents backend integrations are contributed on an open-source basis and are not managed or maintained by LangChain.
MongoDB VFS Adapter for Deep Agents
The MongoDB VFS Adapter is a virtual filesystem backend backed by MongoDB Atlas that persists Deep Agent files including memories, artifacts, and conversation history in a MongoDB collection. Source: mongodb-developer/MongoDB-LangChain-DeepAgents-VFS-Adapter.
How to implement a custom Deep Agents backend
Custom backends connect Deep Agents to storage systems. To build your own backend, follow the custom backends guide available in the backends documentation.
LangChain agents use LangGraph primitives
LangChain's agent implementations use LangGraph primitives. If deeper customization is required, agents can be implemented directly in LangGraph.
Multi-agent patterns available
Multi-agent patterns blend LangChain agents with LangGraph workflows. These patterns include subagents for delegation, handoffs for state transitions, routers for query distribution, and skills for on-demand context loading.
Deep Agents built-in functionality
Deep Agents include built-in functionality for managing context, a virtual filesystem, and other common agent requirements.
Code mode output structure
After a successful init or update, a repository includes: openwiki/ (generated Markdown wiki with quickstart, architecture, operations, and related topics), openwiki/INSTRUCTIONS.md (user-authored brief for scope and priorities, read on init and update, not rewritten by normal runs), openwiki/.last-update.json (metadata for last successful documentation change to avoid no-op update loops), and AGENTS.md / CLAUDE.md (with OpenWiki-inserted <!-- OPENWIKI:START --> … <!-- OPENWIKI:END --> blocks that tell coding agents when to consult the wiki, with existing content outside blocks left untouched).
OpenWiki outputs Markdown, not static HTML
OpenWiki's durable output is Markdown (OKF), not a static HTML site. To explore the wiki in a browser, run openwiki visualize, which serves a viewer only on your local machine (127.0.0.1). To host a human-readable site, render the Markdown with another tool such as GitHub Pages, MkDocs, or an OKF-compatible viewer.
Code mode commands
Code mode can be invoked with: openwiki, openwiki --init, openwiki --update, or by passing the mode explicitly: openwiki code --init, openwiki code --update, openwiki code --update --print.
Code mode generates repository wiki for coding agents
Code mode builds a repository wiki in openwiki/ with durable details such as architecture, integrations, and workflows. Coding agents use that wiki as context to work in the package more efficiently, with less rediscovery and fewer tokens. Agents discover the wiki through pointers OpenWiki adds to AGENTS.md and CLAUDE.md.
Open Knowledge Format (OKF) v0.1 structure
OpenWiki emits Google Open Knowledge Format (OKF) v0.1 bundles. A concept is an ordinary wiki Markdown page (one topic file) with YAML front matter containing a non-empty type field and optional standard fields. index.md and log.md are reserved scaffolding files, not concepts: index.md is a directory listing, and log.md is update history. Nested indexes contain no front matter, while the root index declares okf_version: "0.1". Valid timestamp values and producer-defined extension fields are accepted and preserved during updates and migrations. Standard Markdown links between concept documents express relationships.
Customize wiki scope with INSTRUCTIONS.md
Edit openwiki/INSTRUCTIONS.md to steer scope, priorities, and preferred writing conventions for repository documentation (tone, terminology, what to emphasize or skip). OpenWiki reads this file on init and update runs. You can also ask OpenWiki in chat to revise the brief by running: openwiki "Update openwiki/INSTRUCTIONS.md to prioritize the public API and skip internal tooling". Normal --init and --update runs do not rewrite this file.
.openwikiignore syntax and behavior
.openwikiignore files in the repository root keep generated docs from reading or describing private, generated, or irrelevant paths. Syntax supports comments, blank lines, * and ** globs, directory rules, and ! negation. When .openwikiignore has active rules, OpenWiki filters filesystem discovery and restricts shell execute so ignored paths stay out of the run. This is a read boundary: ignored paths are never read, scanned, or reproduced in generated docs, but does not guarantee a topic will never be mentioned because the agent may still infer an ignored area from other allowed evidence such as tests, README, commit messages, or the existing wiki.
Mermaid diagram handling in OpenWiki
OpenWiki embeds Mermaid diagrams where they clarify a concept better than prose. After each run, it validates Mermaid fences. A diagram that fails validation is converted in place to a plain text fence with a short comment, then repaired on a later --update run when possible. For validation that matches GitHub rendering more closely, install the Mermaid parser: npm install mermaid jsdom. When the parser is present, OpenWiki uses it; when absent, OpenWiki falls back to a lightweight check. Diagram generation works either way.
OpenWiki agent instruction files AGENTS.md and CLAUDE.md
On each code run, OpenWiki maintains `AGENTS.md` and `CLAUDE.md` at the repository root. It creates the file if it does not exist, rewrites only the `<!-- OPENWIKI:START -->` … `<!-- OPENWIKI:END -->` block when the file already exists, and leaves the rest of the file content untouched. That block instructs coding agents to consult the generated wiki when they need repository context.
OpenWiki wiki instructions files
OpenWiki reads wiki instruction files during runs. In Code mode, it reads `openwiki/INSTRUCTIONS.md` which is a shared, user-authored brief for repository documentation scope and priorities. In Personal mode, it reads `~/.openwiki/INSTRUCTIONS.md` which is a global personal wiki instructions file. Normal `--init` and `--update` runs do not rewrite these files.
.openwikiignore file for excluding paths
Create `.openwikiignore` at the repository root to exclude private, generated, or irrelevant paths from documentation runs. The syntax and behavior are the same as described in Code mode ignore-paths.
OpenWiki telemetry never collects
OpenWiki never collects file contents, repository data or names, credentials, prompts, model output, connector payloads, error messages, file paths, URLs, model IDs, run duration, IP address, or personal information. GeoIP enrichment is disabled.
OpenWiki telemetry collection details
OpenWiki collects anonymous, aggregate usage data by default. On a single `openwiki_run` event keyed by a random install ID, it records every run: the command (`init` or `update`) and outcome (`success`, `failure`, or `no-op`), plus a coarse error category on failure (never the error message). Interactive chat, `auth`, and `ingest` are not recorded. At setup (on init only), it records brain mode (`code` or `personal`), model provider, and configured connector names (never their contents). Scheduled and CI runs are tagged separately under a shared CI identifier and are not counted as distinct installs.
Disable OpenWiki telemetry
To disable telemetry collection, export `OPENWIKI_TELEMETRY_DISABLED=1` or `DO_NOT_TRACK=1`. To disable telemetry collection permanently, add `OPENWIKI_TELEMETRY_DISABLED=1` to `~/.openwiki/.env`. In CI, set it in the workflow environment. To inspect exactly what a run would send, add `--telemetry-file=<path>` to any run.
OpenWiki local configuration directory structure
Both code and personal mode store machine-local state under `~/.openwiki/`. The directory contains: `~/.openwiki/.env` (both modes) for provider config, API keys, and connector OAuth tokens; `~/.openwiki/openwiki.sqlite` (both modes) for conversation checkpoint database; `~/.openwiki/install-id` (both modes) for random install ID for anonymous telemetry; `~/.openwiki/wiki/` (personal mode) for personal mode wiki output; `~/.openwiki/INSTRUCTIONS.md` (personal mode) for personal wiki brief; `~/.openwiki/onboarding.json` (personal mode) for personal onboarding preferences and connector schedules; `~/.openwiki/connectors/` (mostly personal) for connector raw data and config, with personal sources using this path and code-mode LangSmith ingestion also able to cache raw data here. Code-mode repository artifacts such as the generated wiki, `openwiki/INSTRUCTIONS.md`, and `openwiki/.last-update.json` live in the project, not under `~/.openwiki/`.
OpenWiki Open Knowledge Format
OpenWiki can emit OKF v0.1 Markdown bundles with front matter, indexes, and linked concepts.
OpenWiki Claude integration
OpenWiki does not provide a formal connector for Claude or Codex. In code mode, it adds pointers to the generated wiki in the repository-root 'AGENTS.md' and 'CLAUDE.md' files, so compatible coding agents can discover and consult the wiki.
OpenWiki built on Deep Agents
OpenWiki is built on Deep Agents and supports tracing with LangSmith.
OpenWiki initialization and update commands
Bare 'openwiki --init' and 'openwiki --update' run in code mode. Use 'openwiki personal --init' or 'openwiki personal --update' for the personal wiki.
OpenWiki Personal mode
Personal mode is invoked with 'openwiki personal'. It generates documentation to '~/.openwiki/wiki'. Personal mode is used when you want to build a local personal brain from configured sources such as git repos, Gmail, Notion, web search, Hacker News, and X/Twitter.
OpenWiki Code mode
Code mode is the default mode, invoked with 'openwiki' or 'openwiki code'. It generates Markdown documentation under 'openwiki/' in the current repository. Code mode is used when you want repository context and documentation for coding agents. It wires generated docs into 'AGENTS.md' and 'CLAUDE.md' files in the repository root so coding agents can discover and consult the wiki.
OpenWiki installation
Install OpenWiki CLI globally with 'npm install -g openwiki', then initialize documentation for the current repository with 'openwiki --init'.
OpenWiki reduces token cost for agents
Agent work is faster and cheaper in tokens when using OpenWiki: agents read a curated wiki first, then inspect source only where they need more detail.
Deep Agents is a LangChain module for agent development
Deep Agents is a module within LangChain that provides tools and abstractions for developing agents. It can be accessed at https://reference.langchain.com/python/deepagents.
Deep Agents documentation covers planning, subagents, and file systems
Deep Agents documentation includes capabilities for building agents that can plan, use subagents, and leverage file systems for complex tasks. Reference APIs are available for both Python and JavaScript/TypeScript.
Deep Agents deprecation policy
When deprecating features in Deep Agents, the team provides deprecation warnings in advance when possible, includes migration guidance in release notes, and removes deprecated features in subsequent minor releases.
Deep Agents path to 1.0
Deep Agents will reach 1.0 when core APIs have stabilized based on community feedback, the package has been battle-tested in production environments, and breaking changes are no longer expected for core functionality. After 1.0, Deep Agents will follow the same semantic versioning and LTS policies as LangChain and LangGraph.
Deep Agents pre-1.0 status and API stability
Deep Agents (deepagents) is currently in pre-1.0 development. As a pre-1.0 package, APIs may change between minor versions. The package aims to minimize disruption by providing clear migration guidance when changes occur. Features marked as experimental or alpha are subject to more significant changes.
Deep Agents release cadence
Deep Agents minor releases (e.g., 0.1.0 to 0.2.0) may contain new features and potentially breaking changes as the package matures. Patch releases (e.g., 0.1.0 to 0.1.1) contain bug fixes and minor improvements without breaking changes.
Deep Agents pre-1.0 status
Deep Agents (deepagents) is a pre-1.0 package under active development. The API may change between minor versions, though breaking changes are minimized when possible. Deep Agents will adopt the same LTS policies as LangChain and LangGraph after reaching version 1.0.
Upgrade Deep Agents Python
To upgrade Deep Agents in Python to the latest version, run 'pip install -U deepagents'. To upgrade to a specific version, run 'pip install deepagents==0.1.0'.
Deep Agents Code terminal agent
Deep Agents Code is a terminal agent interface. Install it using: pip install deepagents-code. Run an interactive terminal agent using the deepagents command.
Deep Agents built-in capabilities
Deep Agents includes the following built-in capabilities: Planning (automatic task decomposition for complex requests), File system (virtual filesystem for reading, writing, and managing context), Subagents (spawn child agents for parallel subtask execution), Context management (automatic context compression for long conversations), Sandboxed execution (run code in isolated environments including Modal, Runloop, Daytona), and Protocols (ACP, MCP, and A2A support for interoperability).
Deep Agents compatibility requirements
Deep Agents requires Python 3.10+ or Node.js 22+. It requires a model that supports tool calling.
Deep Agents JavaScript/TypeScript installation
Install Deep Agents for JavaScript/TypeScript using: npm install deepagents langchain @langchain/core
Deep Agents Python installation
Install Deep Agents for Python using: pip install deepagents
When NOT to use Deep Agents
Do not use Deep Agents for simple tool-calling agents without planning or subagents—use LangChain agents instead as they are lighter weight. For custom graph-based orchestration with explicit control flow, use LangGraph directly. Deep Agents is the highest-level abstraction and trades flexibility for convenience.
Deep Agents purpose and use cases
Deep Agents is an agent harness built on LangChain core building blocks and LangGraph runtime. It is designed for building agents powered by LLMs with built-in capabilities for task planning, file systems for context management, subagent delegation, and long-term memory. Use Deep Agents when you need to build agents fast with sensible defaults and minimal configuration, handle complex multi-step tasks that benefit from automatic planning, manage context with a built-in virtual filesystem for large inputs, delegate subtasks to specialized subagents, run code safely in sandboxed execution environments, or use a terminal agent via Deep Agents Code.
Create a deep agent example
Example showing how to create and invoke a deep agent: ```python # pip install deepagents langchain-anthropic from deepagents import create_deep_agent def get_weather(city: str) -> str: """Get weather for a given city.""" return f"It's always sunny in {city}!" agent = create_deep_agent( model="anthropic:claude-sonnet-4-6", tools=[get_weather], system_prompt="You are a helpful assistant", ) result = agent.invoke( {"messages": [{"role": "user", "content": "What is the weather in SF?"}]} ) ``` This example demonstrates creating a deep agent with a tool and invoking it with a user message.
Deep Agents related projects
Deep Agents is built on three related projects: LangChain provides core building blocks, LangGraph provides the runtime that powers Deep Agents' durable execution, and LangSmith is used to trace, evaluate, and deploy deep agents.
define_deep_agent function parameters (Python)
The Python define_deep_agent function accepts these parameters: name (sets the agent and default deployment name), model (selects the chat model), tools (adds tools the agent can call), middleware (adds behavior around model calls, tool calls, and agent lifecycle), subagents (defines specialized agents for delegated tasks), permissions (controls path-level access for filesystem tools), interrupt_on (pauses before selected tool calls for human approval), and response_format (defines a structured output schema).
Managed Deep Agent project structure
A Managed Deep Agent project has a root-level entry file: agent.py for Python or agent.ts (or agent.tsx) for JavaScript. The agent definition must be exported as a named export called 'agent'.
Human-in-the-loop pausing in Managed Deep Agents
The interrupt_on parameter (Python) or interruptOn parameter (JavaScript) is used to pause before selected tool calls. This is used for actions that require a person to approve, edit, or reject the call before it runs.
Permissions in Managed Deep Agents
Filesystem permission rules can be passed in the permissions parameter to control which paths the agent's built-in filesystem tools can read or write.
Structured output in Managed Deep Agents
The response_format parameter (Python) or responseFormat parameter (JavaScript) is used when the agent must return data that matches a schema instead of an unconstrained text response.
Tools in Managed Deep Agents
Tools are passed in a tools list (Python) or tools array (JavaScript) to let the agent call application logic or external services. Tools can be defined in local modules, imported into the agent entry, and added to the definition. For tools from remote MCP servers without importing them into the agent entry, use MCP connectors.
Initialize Managed Deep Agent with Gateway flag
You can scaffold a Managed Deep Agent project to use LangSmith Gateway from the start by running 'mda init my-agent --gateway'.
Middleware in Managed Deep Agents
Middleware is passed in a middleware list (Python) or middleware array (JavaScript) to add behavior around model calls, tool calls, and the agent lifecycle. Middleware runs in the order it is specified.
defineDeepAgent function parameters (JavaScript)
The JavaScript defineDeepAgent function accepts these parameters: name (sets the agent and default deployment name), model (selects the chat model), tools (adds tools the agent can call), middleware (adds behavior around model calls, tool calls, and agent lifecycle), subagents (defines specialized agents for delegated tasks), permissions (controls path-level access for filesystem tools), interruptOn (pauses before selected tool calls for human approval), and responseFormat (defines a structured output schema).
Basic Managed Deep Agent definition example (Python Anthropic)
```python from managed_deepagents import define_deep_agent agent = define_deep_agent( name="research-assistant", model="anthropic:claude-sonnet-4-6", ) ``` This example shows the minimal configuration for a Managed Deep Agent with Python using Anthropic's claude-sonnet-4-6 model.
Agent name requirements and usage
The name parameter is required for define_deep_agent. The name must be a static string that starts with a letter and contains only letters, numbers, underscores, or hyphens. MDA uses the name as the LangGraph assistant ID and the default LangSmith deployment name. The deployment name can be overridden with 'mda deploy --name' without changing the agent definition.
Subagents in Managed Deep Agents
Subagents can be passed in the subagents parameter when the agent should delegate specialized or context-heavy work. Each subagent can have its own prompt, model, and tools.
System prompt and configuration via project files
The system prompt, skills, memory, sandbox, identity, channels, and schedules are configured through their project files rather than the agent definition.