LangChain: Headless tools — agents that call client-side capabilities as first-class tools

Christian Bromann published on June 10, 2026 on the LangChain blog a pattern that changes how agents communicate with the user’s environment. Headless tools (tools without a head — i.e. without a server-side UI) allow agents to call browser and application capabilities — geolocation, clipboard, file picker, local storage — as first-class tools within the agent reasoning loop.

Why can’t server-side tools replace client-side capabilities?

Previous agentic systems relied almost exclusively on tools that execute on the server. This worked for a large number of tasks — fetching data, API calls, computation — but ran into a fundamental limit: certain browser and application capabilities inherently depend on real device permissions and client signals that the server cannot reliably emulate.

When an agent attempts to access a user’s geolocation or local files through the backend, it encounters two problems: (1) the user must explicitly forward that data to the server — a step that disrupts the conversational flow — and (2) sensitive data unnecessarily leaves the client, creating avoidable security and privacy risks.

Architecture: the server decides what, the client knows how

The key architectural idea of the headless tools pattern is a clear separation of responsibilities:

• The server defines what the agent needs to do. It holds the tool schema and reasoning logic.
• The client defines how the tool executes. It registers concrete implementations without exposing browser logic to the server or model.

As Bromann describes it: “The model never needs to know where the tool executes. It sees the tool, decides to use it, and receives the result.”

Technically, when an agent decides to use a headless tool, the server sends the tool call to the client instead of executing it locally. The client executes the implementation — for example, reading geolocation from the browser API — and returns the result. The agent continues reasoning without interruption, not knowing (and not needing to know) where execution took place.

The implementation uses TypeScript and separates the tool definition (tools.ts) from browser-specific implementation via the .implement() method. The client registers implementations without any browser logic leaking to the server or model.

Privacy as an architectural advantage

Headless tools deliver a concrete privacy benefit that is not merely a marketing claim but a structural characteristic of the pattern: sensitive data stays on the client by default.

Geolocation, local files, clipboard content — none of it needs to travel to the backend if the agent can solve the task locally. This is especially relevant in the context of increasingly strict data privacy regulations and growing user distrust of systems that unnecessarily collect data.

The same principle applies to agent memory: rather than being stored on server infrastructure, agent memory can persist in the browser’s native IndexedDB storage — without any server infrastructure requirement.

Concrete applications in practice

Bromann describes two concrete examples that illustrate the class of problems now made possible:

Slidev presentation navigation agent — an agent that directly manages the state of a live Slidev presentation. This is impossible from the backend because it requires direct manipulation of DOM state that exists only in the browser’s context.

Figma sidecar agent — an agent that works alongside the Figma interface as an assistant, directly interacting with design tools. This too cannot be emulated from the server because Figma state lives on the client.

Both examples share the same structural problem that headless tools solve: the agent needs to directly manipulate live application state, which is impossible from a backend perspective.

Broader implications for agentic systems

The headless tools pattern offers a solution to a class of problems that has been systematically worked around in agent design until now. As agents take on increasingly complex tasks involving interaction with user interfaces, local applications, and devices, the ability to call client-side capabilities as first-class tools becomes a prerequisite — not a luxury.

LangChain positions this as an open-source contribution, suggesting the intent that the pattern become part of the broader tooling-framework ecosystem rather than a proprietary solution.