managed deep agents: What LangChain's Hosted Runtime Changes

managed deep agents is LangChain's hosted way to run its open source Deep Agents harness, and the v0.10 release on October 29, 2026 added the two capabilities that move it from interesting to worth evaluating: browser use with a human handoff, and asynchronous subagents. The product has been in public beta since August 7, 2026, but most coverage stops at "deploy agents without infrastructure," which is marketing shorthand. This post works from LangChain's announcement, the v0.10 release notes and the documentation to lay out what the runtime actually manages, what the v0.10 additions change in practice, where the beta limits bite, and when a team should use this versus LangSmith Deployment directly or the self-hosted harness. Source

What Managed Deep Agents actually is

The cleanest way to understand the product is the split LangChain draws in its docs. You provide the business logic: the model, instructions, tools, skills and middleware, organized as a directory of files in your own repo. Managed Deep Agents provides two layers underneath: the Deep Agents harness, which is the open source agent loop that plans, calls tools, manages a filesystem and delegates to subagents, and a managed runtime, where every deployment runs on LangSmith Agent Server with its API, threads, runs, streaming and MCP endpoint operated for you. Authoring happens in Python or TypeScript with an mda CLI: mda dev runs locally in LangSmith Studio, mda deploy compiles the project, syncs deploy-owned context to LangSmith Context Hub, uploads the build and creates a hosted deployment. The important architectural point is that the harness is open source and model agnostic, so the code that defines your agent's behavior stays yours; what LangChain sells is the operational layer. Source

The v0.10 additions and why they matter

Browser use is the headline. Agents frequently stall on work that lives behind websites with no API: booking travel, canceling a subscription, filing a claim. In v0.10, you declare a browser at the project root and the runtime gives the agent a browser in its own LangSmith sandbox with four tools: browser_snapshot to read the accessibility tree, browser_run to navigate and act, browser_screenshot to capture pages, and browser_handoff to give a person control of the window. That last one is the design worth studying: when a site demands a login or a two-factor prompt, the agent hands the window to the user through a channel like Slack or Studio, the user signs in, and control returns to the agent. LangChain says handoff links expire after 15 minutes and credentials never enter the model's messages or traces. Scoping is deliberate too: by default each conversation gets its own browser with no cookies from other threads, while scope="user" lets one signed-in person's logins persist across their conversations. Source

Async subagents are the second addition. Previously, subagents ran inline, so the orchestrator called one and waited, blocking the conversation for the duration of a long task. In v0.10, marking a subagent async starts it on its own thread in the background while the agent keeps talking to the user, with tools to check on, update or cancel the task, and a notification model that wakes the agent when the subagent finishes instead of making it poll. The subagent shares the agent's sandbox, so it sees files the agent already wrote, and its run nests under the agent's run in LangSmith. The release also adds thread origins, so replies from scheduled runs and late-finishing subagents return to the Slack thread that started the request, and a Stop button in the thread that cancels its runs. Source

The production primitives underneath

Beyond the release headlines, the beta announcement lists what the runtime manages: durable execution so long-running agents can pause, retry and resume without losing work; streaming; persistence of thread state across restarts; sandboxes scoped per thread or per agent for file and code work; channels so agents receive and reply to events from tools like Slack and GitHub with provider signature verification; agent-scoped memory backed by Context Hub, with files under /memories/ that survive redeploys; and Harbor-based evals, where mda evals init and mda evals compile package the agent into a Harbor-ready artifact so behavior checks cover tool calls and workspace state, not just final answers. On identity, the current model is deliberately basic: an agent runs with a fixed set of credentials, and if you define an OIDC provider, threads are scoped per end user id so each user's conversations stay isolated under one deployment. LangChain says more advanced auth and credential flows are coming. Source

Beta limits to know before you commit

The beta scope is narrow in specific, documented ways. It runs on LangSmith Cloud in the US region only, with additional regions promised later. It is CLI-first while LangChain finalizes the supported API. The identity model covers OIDC thread scoping and fixed credentials, not per-user credential passthrough, which matters for agents that act inside customer accounts. LangChain's docs also draw the boundary cases clearly: if you need custom routes, application code alongside the graph, custom auth logic or direct control over the persistence layer, the recommendation is LangSmith Deployment directly; if you want to operate the harness yourself, Deep Agents is open source and runs on your own infrastructure. Teams with data residency requirements outside the US, or compliance regimes that require operating the runtime, should treat the managed offering as not yet an option. None of these limits are hidden; the announcement states them plainly, which makes the beta easier to scope but no broader than advertised. Source

How to think about it, in our assessment

This section is our read, separate from the sources. The v0.10 browser handoff is the most instructive design in the release, and it matches a principle we push in our AI agent tool permissions guide: keep credentials out of the model's context entirely rather than trusting the model to handle them carefully. Any team building browser-capable agents should borrow that pattern whether or not they adopt this runtime. On the async subagent model, the notification-based wake-up and per-thread sandbox sharing are sensible defaults, but they also increase the number of concurrent execution paths an agent can have, which raises the bar on trace review; our AI agent observability checklist covers the tracing discipline that makes background subagents debuggable. And if you are weighing runtimes, the same procurement logic we applied to new model releases like gpt-6.1 terra holds here: vendor claims, including LangChain's positioning of Managed Deep Agents as the simplest path to production, are hypotheses to test on your own workload in a bounded pilot, not reasons to migrate. The US-only, CLI-first beta scope makes that pilot cheap to bound. Source