Agent Chat UI: A Thin Chat Front End for Any LangGraph Server
🦜💬 Web app for interacting with any LangGraph agent (PY & TS) via a chat interface.
At a glance
- What is it?
- Agent Chat UI is a Next.js chat interface that talks to any LangGraph server exposing a messages key. It is handy for demos and internal tools, but its production story depends on a proxy package and a few sharp edges.
- Who is it for?
- Adopt Agent Chat UI if you build LangGraph agents in Python or TypeScript and want a quick, hosted or local chat shell without writing your own message list and streaming logic. Skip it if you need deep control over chat UI internals, offline operation, or a production deployment without an API key proxy.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What Agent Chat UI actually is
Agent Chat UI is a Next.js application that gives you a chat window for any LangGraph server that keeps conversation state under a messages key. It is not an agent framework and it does not run graphs. It is a presentation layer. You point it at a deployment URL and an assistant ID, and it fetches runs and streams responses. The target user is a LangGraph developer who wants a quick way to talk to an agent during development, or a team that wants a branded chat surface without building one from scratch. The README positions it both as a local dev tool and as something you can deploy, with a hosted version at agentchat.vercel.app. The core value is that it works with both Python and TypeScript LangGraph servers, as long as they expose the expected state shape.
How the data flow works
The UI connects directly to a LangGraph server from the browser in development. You enter a deployment URL and an assistant ID, and the app uses those to submit runs and fetch state. Streaming display relies on on_chat_model_stream events. The UI listens for those events and renders tokens as they arrive. If a model is tagged with langsmith:nostream, those events are suppressed, so nothing appears until the message is saved to graph state. For permanent hiding, a message ID prefixed with do-not-render- is filtered out by the UI, regardless of streaming. That filter is a simple string check on the ID. Artifacts are a second channel: the UI reads thread.meta.artifact from the stream context and renders a side panel. The provided useArtifact hook returns a component and a state bag, so your agent can push structured content like a document viewer or a chart next to the chat.
Getting it running: commands and config
The quickest path is the scaffolding command: npx create-agent-chat-app. That clones or initializes the project. If you prefer a manual clone, run git clone https://github.com/langchain-ai/agent-chat-ui.git, then cd agent-chat-ui, then pnpm install, then pnpm dev. The app appears at http://localhost:3000. On first run, a setup form asks for the deployment URL, the assistant or graph ID, and a LangSmith API key when connecting to deployed servers. There is a toggle for Agent Builder deployments that sets the auth scheme to langsmith-api-key automatically. You can bypass the form with environment variables: NEXT_PUBLIC_API_URL, NEXT_PUBLIC_ASSISTANT_ID, and NEXT_PUBLIC_AUTH_SCHEME. Copy .env.example to .env and fill those values. For Agent Builder, set NEXT_PUBLIC_AUTH_SCHEME=langsmith-api-key. The environment variable approach is useful for scripting or for embedding the UI in a demo where you do not want users to type a URL.
Controlling message visibility has two layers
The README describes two separate mechanisms for hiding messages, and the distinction matters. The first is for live streaming only. If you add the langsmith:nostream tag to a chat model's config, the UI will not render tokens as they stream. But the message will still appear after the LLM call finishes, if it gets saved to state unchanged. That is a common pattern for hiding intermediate reasoning or tool-call noise that you do not want to flash on screen. The second mechanism is permanent. You prefix the message ID with do-not-render- before adding it to graph state, and also add the langsmith:do-not-render tag to the model config. The UI filters out any message whose ID starts with that prefix. This is a blunt instrument: it relies on your graph code remembering to do the prefixing. If a message slips through without the prefix, it will render. The tag and prefix must be applied consistently in both Python and TypeScript agents, which adds a maintenance burden across language boundaries.
Rendering artifacts requires agent cooperation
Agent Chat UI supports a side panel for artifacts, but it is not automatic. The UI reads thread.meta.artifact from the stream context. Your LangGraph server must populate that metadata field with a component and a context bag. The README provides a useArtifact hook that returns an Artifact component and an open state setter. Your agent code decides what context to send. The example shows a Writer component that displays a title, description, and content. This is a clever way to move beyond plain text chat, but it means your graph must be written with this UI in mind. The artifact protocol is not a LangGraph standard; it is a convention this UI expects. If you switch to a different chat front end, your artifact logic will not carry over. That is a lock-in consideration, though the MIT license means you can fork and adapt the hook.
Production authentication is the weak spot
The README is candid about the development versus production gap. In development, the browser talks directly to the LangGraph server, and each user supplies their own LangSmith API key. That does not scale to a public deployment. The recommended fix is an API passthrough package called langgraph-nextjs-api-passthrough. It proxies requests from the Next.js server to your LangGraph server, attaching your LangSmith API key server-side so end users never see it. The README calls this the quickest way to productionize. That is a real dependency on a separate package, which may lag behind LangGraph API changes. The README also mentions a second option but the text is truncated, so the full set of production auth choices is not documented in the material I have. That incompleteness is itself a caution: before committing, you need to read the passthrough package's docs and confirm it supports your LangGraph deployment type.
Limitations and when it is the wrong tool
Agent Chat UI assumes your LangGraph server exposes a messages key in its state. If your graph uses a different state key, the UI will not work without modification. The README gives no configuration for renaming that key. The UI also assumes a LangGraph server with a compatible API. It is not a generic LLM chat front end. For a graph that does heavy tool use or requires custom UI controls beyond the artifact side panel, you will likely need to extend the React components. The project has no recent releases listed, only a default branch with active pushes. That means you are tracking main, and behavior can change under you. The hosted site and the npx command are conveniences, but they point at whatever the latest commit is. If you need a stable chat UI for a production product, this is a starting point, not a finished component. You should budget time to fork, pin, and test against your specific LangGraph version.
Alternatives and what makes this one different
The obvious alternative is to build a chat UI directly against the LangGraph SDK, or to use LangGraph's own platform-provided chat interface if your deployment includes one. The difference in approach is that Agent Chat UI is a separate, reusable Next.js app that you can host anywhere, and it decouples the front end from the graph runtime. Another alternative is a generic chatbot UI like Chatbot UI or LibreChat, which talk to OpenAI-compatible APIs. Those do not understand LangGraph's run and thread semantics, so you would need an adapter layer. Agent Chat UI is purpose-built for the LangGraph protocol, including streaming events and thread metadata. That closeness is its strength, but also its limitation: it only works with LangGraph, while a generic UI with an adapter could also talk to other backends. If you already live in the LangGraph ecosystem, the tighter integration saves you from writing a custom streaming handler.
Maintenance, license, and upgrade considerations
The project is MIT licensed, which means you can use, modify, and embed it without paying a fee, and you are not required to share your changes. The repository is not archived and received a push in September 2026, so it appears actively maintained. However, the absence of tagged releases is a real operational concern. There is no version number to depend on. Your package manager will track a branch or a commit. For a production deployment, you should pin the exact commit you test against and review diffs before updating. The dependency on langgraph-nextjs-api-passthrough adds a second moving part to track. The README also mentions a video setup guide, which suggests the setup has enough friction that the maintainers felt a walkthrough was necessary. The environment variable configuration is simple, but the production auth path is the part most likely to change as LangGraph evolves.
Editorial conclusion
Adopt Agent Chat UI if you build LangGraph agents in Python or TypeScript and want a quick, hosted or local chat shell without writing your own message list and streaming logic. Skip it if you need deep control over chat UI internals, offline operation, or a production deployment without an API key proxy. Before adopting, verify that your graph state uses a messages key, that your LangGraph server version matches the SDK this UI expects, and that the langgraph-nextjs-api-passthrough package covers your auth needs. The project is MIT licensed and actively pushed, but it has no tagged releases, so pin to a commit hash if you depend on it.
Community notes