What a Browser Agent Carries Into Its Next Conversation

A new conversation with an agent does not necessarily mean a fresh browser session. Cookies, login state and other retained browser data can connect a new task to earlier work.

In Browser Use in Managed Deep Agents, LangChain's Sydney Runkle describes two session scopes. Conversation scope gives each thread its own browser without cookies or logins from another thread. User scope shares browser state across that user's threads, while giving each conversation a separate window.

The article also describes handing the browser to a person for login. The person signs in directly, hands control back and lets the agent continue using the authenticated session. With user scope, that login can carry into later conversations.

Retained access needs a current task

Consider a hypothetical property-management assistant asked to retrieve maintenance invoices for one building. A manager signs in to the supplier's portal, then hands the browser back so the agent can retrieve the requested records.

Later, the manager starts another conversation about a different building. A shared login may avoid another sign-in, but the portal could still have the earlier building selected. The agent needs to check the active account and property before treating the displayed invoices as evidence for the new request.

The portal might also let that account approve charges. A request to retrieve invoices does not authorize the assistant to use that capability. Retaining a session preserves access; the current goal still determines which permitted work the agent should perform.

Separate windows can prevent two conversations from clicking on the same page, while shared cookies or account settings can still connect their activity. Window separation and session separation therefore answer different questions.

Make session scope part of deployment review

Our background-agent authority note asks which account applies when work starts. Here the additional concern is what browser state persists when that same user starts another task.

For WTK's catalog packages compiled into target runtimes, we would want the deployment description to identify whether sessions are separate or shared, how human login handoff works and when retained state is cleared. A different runtime default could change those conditions without changing the package's stated purpose.

Our browser-action note follows a request through to its effect. Session state supplies part of the starting condition for that action: which account, property and page the agent is actually using.

People can define the allowed accounts, task scope and session-retention policy before routine work proceeds. Human login handoff can support that workflow while leaving subsequent actions bounded by the task already agreed.

Source: Sydney Runkle, Browser Use in Managed Deep Agents, LangChain, October 29, 2026. The property-management example and WTK interpretation are ours.