Managed Deep Agents is in public beta and available on LangSmith Cloud in the US region only.
HTTP channels require
managed-deepagents>=0.8.0.Project structure
An HTTP channel declaration lives underchannels/, like any other channel:
Add an HTTP channel
1
Declare the channel
channels/orders.ts
provider is a stable name for the external service, such as orders. It identifies the service for identity and reply routing, and it is separate from the channel name. Declaring the channel registers the provider, so any non-empty name works.2
Verify the request
Managed Deep Agents calls Use a deployment secret for the signing key. A
verify first. Return true to continue to parse, or false to reject the request with 401.verify receives an HttpChannelRequest with a request and the original rawBody bytes. Check a signature against the bytes, not against a re-serialized body:lib/orders.ts
verify callback that raises rejects the request with 500.3
Parse the request into a message
parse converts a verified request into a message that starts a run, or ignores the event. Return one of two shapes:{ type: "message", message: {...} }starts a run.{ type: "ignore" }skips the event.
response, a standard Response.The message carries three fields:userId: The caller’s ID in the external service, resolved from the verified event. Agent Auth maps it to the principal whose credentials the run may use, so derive it from verified data rather than from an unauthenticated field.threadId: The conversation to run in, as a UUID. Managed Deep Agents lowercases it and maps it to a durable agent thread, so the same value continues the same conversation.content: The message text, or an array of LangChain content blocks.
lib/orders.ts
response to control what the provider receives. Managed Deep Agents sends it after the run is accepted for a message, and immediately for an ignored event. Use it to answer a provider’s verification challenge without starting a run:4
Send replies with messaging
Add Managed Deep Agents posts the reply after the run finishes, separately from the response the provider already received. Two cases produce no reply: a run that pauses on an interrupt, and a run whose agent already delivered a final message itself. A
messaging to deliver the agent’s final response back to the external service. Omit it for a channel that only starts runs.messaging receives process.env and returns an object with a post method. post receives the reply content and the original event, and returns the posted message id and an optional url:channels/orders.ts
messaging callback that fails to return a usable transport rejects the request with 500.Call the endpoint
A deployed HTTP channel accepts requests at the channel name, not the provider name:channels/orders.py or channels/orders.ts is reachable at /channels/orders/events. The request body must be standard JSON encoded as UTF-8.
Managed Deep Agents answers with one of these, unless parse returned its own response:
A
202 means the run was accepted, not that it finished. The agent’s answer arrives later through messaging.
Read the event in the agent
Each run carries the provider and the original event as run context, so tools and middleware can read the fields the message text does not carry:raw_event is the parsed request body, preserved as received.
Deploy the agent
An HTTP channel needs no provider authorization, so deployment is the standard command. Managed Deep Agents mounts the endpoint from the declaration..env so mda deploy forwards them as deployment secrets. Then register https://<deployment-url>/channels/<name>/events with the external service as its webhook target.
See also
- Channels overview: understand how channels connect messaging services to an agent.
- Slack: use the provider-managed Slack channel instead.
- Identity: authenticate callers and scope channel runs to the resolved user.
- Deploy an agent: configure and deploy a managed deep agent.
Connect these docs to Claude, VSCode, and more via MCP for real-time answers.

