A hosted agent gets its own browser: LangChain Managed Deep Agents v0.10

The short version

On October 29, 2026, LangChain shipped Managed Deep Agents v0.10 into public beta. The release has two headline features: a browser for hosted agents, and subagents that can run in the background. The first lets an agent handle websites that have no API and can only be operated by clicking through pages. The second stops a long task from blocking the whole conversation. Neither is flashy. Both address pain points that have limited hosted agents for a while: they could not reach the web, and they could not wait.

One framing note before the details. Managed Deep Agents is LangChain's hosted agent service on LangSmith: developers write a folder of files and deploy with one command, while the platform runs the servers, threads, and sandboxes. Version 0.10 is still in public beta, with no announced date for general availability and no final pricing. This article keeps official claims and open questions separate: what the official blog states is reported as stated, and what it does not say — a GA date, final pricing — is marked unknown rather than filled in.

A browser for the no-API web

Booking travel, canceling a subscription, or filing a claim usually happens on sites designed for people clicking through pages, not on APIs. LangChain's blog states the problem plainly: an agent may be able to reason through the steps but cannot act on a website without an API, and fetching the page with curl does not help either, since it returns HTML from before JavaScript renders anything and offers nothing to click.

The v0.10 answer is a browser for the managed agent. It runs in its own LangSmith sandbox and is declared in a few lines: a browser.py file at the project root calls define_browser, by default giving each conversation its own browser, reused across turns, starting with no cookies or logins from other threads. Two parameters matter. The scope decides whether the browser belongs to one thread or to one person, and idle_ttl_seconds decides when an idle browser shuts down — 600 seconds, or ten minutes, by default.

Declaring a browser automatically gives the agent four tools. browser_snapshot reads the page's accessibility tree and assigns element IDs. browser_run navigates and interacts, through JavaScript or batches of actions against snapshot IDs. browser_screenshot captures the page, optionally saving the image to the sandbox. browser_handoff hands the window to a person. The division of labor reveals a design judgment: the main mode of operation is reading a structured page tree and addressing elements by ID, not guessing coordinates from screenshots. Screenshots are supporting evidence, not the primary interface.

The scope="user" option is the other detail worth pausing on. Under the default thread scope, every conversation's browser is isolated. Under user scope, one signed-in person gets a single browser whose logins carry across all of their conversations, so they sign in to a site once. The trade-off is real: thread scope is cleaner and less likely to leak state across conversations, but forces a fresh login every time the conversation changes; user scope is smoother, but one browser's login state now spans many conversations, and the permission boundary becomes the developer's problem. The official guidance — use a proper API when one exists, and reach for the browser only where none does — should be treated as the default rule, not an optional tip.

The login wall, solved by handing the window back

The most common way a browser agent dies is at a login wall or a two-factor prompt. The usual workaround — stuffing credentials into a prompt or a tool argument so the model can log in — is close to the worst option on security grounds, since the password ends up in message history and trace logs.

Version 0.10 takes a different route with browser_handoff. When the agent needs a login, it calls browser_handoff with a reason, and the user's agent channel — Slack or Studio — shows a link. The person opens it, operates the remote browser directly, signs in, and clicks a Hand back button. The agent then checks the page itself to confirm the login worked before continuing. A few implementation details are worth recording: handoff links expire after 15 minutes; the handoff call returns immediately, so the agent can do other work while waiting; and the password never enters the model's messages or traces.

The underlying judgment is that logging in should not be delegated to the model at all. A person signs in once, and the model takes over only after that. For teams building internal tools, this suggests a new division of labor: the agent does the errands, and the person appears only at the gates where presence is genuinely required. It has limits, too. A 15-minute link means timeouts force a restart, and a workflow with many login gates turns frequent handoffs into a new kind of interruption. Before treating handoff as a skeleton key, count how many login walls your workflow actually contains.

Subagents that run in the background

The second headline feature is asynchronous subagents. The subagent idea is not new: a main agent hands a focused task to a helper with its own context window. But in Managed Deep Agents before v0.10, subagents ran inline — the main agent called one and waited for the answer. For a long task, the person talking to the agent waited too, and fanning out several agents was out of the question.

In v0.10, adding async to a subagent definition lets it run on its own thread while the orchestrator keeps talking to the user. The orchestrator gets a set of async task tools to start, check on, update, and cancel these tasks. Every served agent also gets a background copy of a general-purpose subagent, so it can decide at runtime whether delegated work runs in the foreground or the background. Async subagents notify the orchestrator on their own, so it never sits in a polling loop. What happens next depends on what the orchestrator is doing when a subagent finishes: if it is mid-run, it checks unfinished tasks before each model call, so the result arrives mid-run; if idle, it is woken with a new run; if paused on an approval, the approval is left alone and the result arrives once the user answers.

The shared sandbox is the easily overlooked part of this design. An async subagent shares the orchestrator's sandbox, so it picks up files the orchestrator already wrote. In Slack, its approvals post back to the original thread, and answering there resumes the subagent. Taken together, this is what makes background execution usable rather than fire-and-forget: tasks, files, and approvals keep flowing through the same conversational context.

Background execution has a cost, though. Once tasks multiply, their state has to be visible: which subagent is running, which is stuck on an approval, which has timed out. Version 0.10 ships supporting pieces for exactly this: runtime.thread gives every thread a record of where it started and who is on it, Slack threads get a native Stop button that cancels a thread's runs, and Studio can cancel runs on Slack threads. These are not headline features, but they are preconditions for background mode — without observable, cancellable background work, "async" just becomes "uncontrolled."

A migration cost worth flagging

Version 0.10 also carries a breaking change that deserves its own warning. The old connectors.mcp() call and the connectors/ layout are gone; MCP servers must now be declared in tools/mcp.ts or tools/mcp.py. The sandbox scope option is removed as well, and for LANGSMITH_* variables, shell environment variables now override a project's .env file.

For projects already running v0.9, upgrading is not just a version bump: MCP declarations have to move, and environment variable precedence has to be rechecked. The good news is that LangChain put this change in a visible spot in the release post rather than burying it in a footnote. The bad news is that it lands during a public beta — the very phase whose point is that interfaces may still change, so migration costs paid now may have to be paid again. Weigh that against the feature gains when deciding whether to adopt now.

What this means for vibe builders

If you are vibe-building a small product with an agent inside, the two features suggest two different adoption postures. The browser fits workflows where the agent must visit a site with no API, and where login gates are few and one login lasts a while. Run the official check first: does this site really have no API? If it does, the browser route is a detour that adds login state and a sandbox to manage.

Async subagents fit a different shape: products where one user sentence triggers half an hour of background work, such as batch research or gathering material from many sources. Before adopting, ask three questions. Can users see the task's state? Can they cancel it midway? And when a subagent is stuck on an approval, does the main conversation look dead? Version 0.10 has mechanisms for all three, but mechanisms existing is not the same as defaults being sufficient — the Slack Stop button, approval replies, and thread records all need to be wired up in your deployment.

There is also a broader signal. LangChain's blog cites a third-party observation that agentic browser requests jumped 4.7x in a single September. That figure is a vendor-cited observation, not LangChain's own measurement, so read it with a discount. But the direction it points to is real: more and more agents are operating web pages directly, and web pages are designed for human clicks. How mature browser tooling, login handoffs, and background tasks become will decide how far agents get — not just whether models get a little smarter, but whether agents can walk the last mile across real-world interfaces.

Finally, back to the release status itself. Version 0.10 is a public beta, deployment requires beta access, and the GA date and final pricing are unknown. For production projects, the steadier posture is to trial the browser and async subagents on non-critical flows first, verify that login handoffs and background tasks behave in your scenario, and widen usage once the interfaces stabilize. The value of a public beta is early validation, not early dependence.

Sources and scope note

The primary source for this article is LangChain's official blog post "Managed Deep Agents v0.10: Browser Use and Async Subagents," marked as published on October 29, 2026 at 16:54 UTC and updated on October 30, 2026. All feature descriptions, tool names, parameter names, and default timeouts and expiry times follow that post; the DataDome 4.7x figure is a third-party observation cited in the post and is labeled as such in the text. This piece is distinct from an earlier site article on LangChain's payment and x402 settlement layer: that one was about how agents pay, this one is about how agents operate web pages and background tasks.