Web search requires Tavily API key
Web search in Deep Agents Code uses Tavily. Add a key using the /auth command to enable web search functionality.
LangChain · Deep Agents · all subjects
configuration
17 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
Slash command /reload refreshes configuration without restart
The /reload command re-reads .env files, refreshes configuration, and re-discovers skills without restarting. It also reloads plugin skills and MCP configuration while preserving conversation state.
Environment variable precedence for configuration
Shell environment variables always take precedence over .env values when configuring Deep Agents Code.
Provider credentials setup with /auth command
Deep Agents Code works with any tool-calling LLM. OpenAI, Anthropic, and Google are available out of the box. Use the /auth command to connect with a provider.
Project-level configuration vs agent definition
Configure the system prompt, skills, memory, sandbox, identity, channels, and schedules through their project files rather than the agent definition. These settings are managed in the project structure.
Channel lifecycle in managed runtime
The managed runtime handles the channel lifecycle: receive messages from provider, verify and normalize event, resolve identity and thread, run agent, post response back to provider.
Runtime channel access for channel-originated runs
Channel-originated runs expose `runtime.channel` to tools and middleware. It contains the normalized event and conversation address, plus methods for posting and updating messages. Ordinary HTTP runs and scheduled runs do not have an originating channel, so `runtime.channel` is absent for those runs.
Default response behavior for channel runs
By default, the managed runner posts the agent's final response to the originating conversation. Provider guides describe how to customize that behavior and send intermediate messages.
Difference between channels and MCP connectors
A channel receives messages that start agent runs and delivers responses. An MCP connector gives the agent tools from a remote MCP server. A project can use either or both.
Scheduled runs can deliver through named channel
Scheduled runs can deliver results through a named channel even though they do not originate from one.
Channel declaration export requirement
Export a module-level `channel` (Python) or a named `channel` (JavaScript) from each channel file.
Slack channel integration available
Slack is a supported channel that allows starting runs from Slack mentions, direct messages, and thread replies.
Provider factory creates channel declaration
The provider factory creates the channel declaration. For example, `channels.slack()` creates a Slack channel. The provider guide contains the complete declaration and setup procedure.
Channel project structure directory
Channel declarations live in the project-level `channels/` directory, with one channel per file. The file name becomes the configured channel name that identifies the channel at runtime and forms part of its inbound route.
Channel inbound route naming
A channel declaration in `channels/support.py` (or `.ts`) receives events at the route `POST /channels/support/events`, where 'support' is the file name. Channel names must be unique within a project.
Channel file naming restriction
Do not name a channel declaration `channels/channel.py` or `channels/channel.ts`.
Channel components: inbound, outbound, deployment
A channel combines three parts: (1) Inbound events: verify and normalize provider events, then start an agent run; (2) Outbound messaging: send the agent's response back to the originating conversation; (3) Deployment requirements: declare the secrets and provider configuration that the deployment needs.