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.py
provider names the external service, and it is separate from the channel name. Managed Deep Agents sends it to Agent Auth with the caller’s ID, resolving the principal whose credentials the run may use. The provider therefore namespaces caller IDs.Share one provider across channels that serve the same service. Two Shopify channels, channels/orders and channels/refunds, both declaring provider: "shopify", resolve the same Shopify user to one principal. A channel declaring provider: "slack" resolves to a different principal, even when the caller ID is identical.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 may be async def.verify receives an HttpChannelRequest with a Starlette request and the original raw_body bytes. Check a signature against the bytes, not against a re-serialized body:lib/orders.py
verify callback that raises rejects the request with 500.Resolve channel credentials from the environment, not with connections.get, which requires a run. For credentials the agent’s tools use during a run, see Manage connections.3
Parse the request into a message
parse converts a verified request into a message that starts a run, or ignores the event. It receives the same HttpChannelRequest as verify, so request headers are available here too, and it may be asynchronous. Return one of two shapes:{"type": "message", "message": {...}}starts a run.{"type": "ignore"}skips the event.
response, a Starlette Response.The message carries four required fields:user_id: The caller’s ID in the external service, as a string, 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. Convert a numeric provider ID withstr().thread_id: 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.target: A JSON value that identifies the reply destination in the provider. This is separate from the agent thread UUID. Include it even when the channel only starts runs.content: The message text, or a list of LangChain content blocks.
parse to the lib/orders file that contains verify. Combine the imports from both examples at the top of the file, keeping only one import of HttpChannelRequest:lib/orders.py
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:This example uses Starlette’s JSONResponse. Add Starlette to your project dependencies before using it:4
Send replies with post
Add an async 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 failed
post callback to deliver the agent’s final response to the external service. Omit it for a channel that only starts runs.post receives one input with the verified target and a message. Automatic replies use type: "content" with a content field. Explicit native messages use type: "native" with a native field. Return the posted message id and an optional url.These examples support content messages and reject native messages. The target is the order ID returned by parse.channels/orders.py
post is logged as a delivery failure.Add an optional async on_error(error, target) callback to handle run or delivery failures. It replaces the default error reply. It receives the verified reply target.Call the endpoint
A deployed HTTP channel accepts requests at the channel name, not the provider name:channels/orders.py is reachable at /channels/orders/events.
Your parse callback decodes the request body. It can read JSON, form data, text, or bytes. The examples above expect JSON.
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 post, if configured.
Read the event in the agent
Each run carries channel data in run context. The parser examples explicitly include the provider event. These fields appear inside the channel context:raw_event from parse to expose JSON provider data at runtime.channel.raw_event and runtime.context.channel["raw_event"]. If omitted, the context has no raw_event key and runtime.channel.raw_event is None.
Managed Deep Agents builds runtime.channel.event from the parsed message. It does not decode the body again or preserve the provider event automatically.
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 your agent of choice via MCP for real-time answers.

