Skip to main content
A custom frontend is any application you write that calls a deployment directly instead of reaching the agent through a channel or LangSmith Studio. Use one when the agent belongs inside a product surface you control, such as a support console, an internal dashboard, or a customer-facing chat page. Managed Deep Agents deployments run on LangSmith Agent Server. A frontend talks to the same threads, runs, and streaming endpoints that every Agent Server client uses.
Managed Deep Agents is in public beta on LangSmith Cloud.

Choose an identity provider

Every request to a deployment names a caller, and the frontend supplies that name. Which identity provider fits depends on where the frontend code runs, not on the language it is written in. Either server row fits a server-rendered application in any language. Streamlit, Gradio, and Dash run their code on the server, as do a Next.js route handler and an Express proxy. A frontend pointed at mda dev works before you configure a provider, because the local server supplies a test user.
A LangSmith API key reaches every resource in the workspace, not only this deployment, so it must never ship in browser JavaScript. Use an external auth provider when the browser calls the deployment directly, and backend identity when your own server calls it on the user’s behalf.

Connect to the deployment

A frontend needs two values. Deployment API URL. mda deploy prints the LangSmith deployment dashboard URL, not the API URL. Open that dashboard, then copy the API URL from the deployment details view. The local server started by mda dev serves the same routes at the URL the CLI prints. Assistant ID. Clients pass the agent’s name from the agent definition. Managed Deep Agents also uses that name as the graph ID:
agent.ts
Clients address an agent named research-assistant with that same string. Renaming the agent changes the value clients send, so treat the name as part of the deployment’s public interface.

Build a web frontend

The LangChain frontend SDKs connect a browser application to an Agent Server deployment. useStream exposes messages, tool calls, interrupts, and thread state as reactive values: The frontend runs in the browser, so these examples are TypeScript even when the agent is written in Python. Under an external auth provider, the browser sends the access token from the signed-in session. That token rotates, so re-read it whenever the session changes rather than capturing it once at mount:
useAuthHeaders.ts
The highlighted subscription fires on sign-in, sign-out, and token refresh. Without it the hook holds the token captured at mount, and requests start failing with 401 once that token expires. Point the stream at the deployment API URL, the agent name, and those headers:
Chat.tsx
Under backend identity the browser never reaches the deployment. Point apiUrl at your own server and forward the Agent Server routes from there, stamping x-mda-ingress-secret and the user ID your auth layer resolved on each upstream request. For the headers and the shared secret, see Configure identity with your own backend. The same frontend patterns work against a Managed Deep Agents deployment. See tool-call rendering, generative UI, human-in-the-loop approval, queued submissions, and durable rejoin.

Handle authorization interrupts

When the agent needs a user-owned connection the caller has not granted, the run pauses and stream.interrupt carries a credential gate payload. A browser frontend renders the consent links and resumes with stream.respond. For the payload shape and a worked example, see Handle the authorization interrupt.

See also

  • Identity: configure how callers authenticate to the deployment.
  • Frontend overview: message rendering, tool calls, interrupts, and generative UI patterns.
  • Connections: handle the credential authorization interrupt in your UI.
  • MCP endpoint: expose the agent to MCP clients instead of calling the API.
  • Channels: reach the agent from Slack or your own HTTP service.