Agent Chat UI: a Next.js front end for any LangGraph server

What problem Agent Chat UI solves, and for whom

LangGraph gives you a server that runs a graph and streams state. It does not give you a browser window. Agent Chat UI fills that gap: it is a Next.js application that chats with any LangGraph server exposing a messages key, so you can see your graph's output without writing React first. The README frames it exactly that way, and the deployed instance at agentchat.vercel.app exists so you can try the interface before cloning anything.

The audience is narrow but real. If you are building a LangGraph agent and want to inspect its behaviour, demo it, or hand it to a colleague, this is the shortest path. If you are building a product where the chat is the product, you are looking at a starting point, not a finished surface. The repository is a private package with version 0.0.0 in package.json, which tells you how the maintainers treat it: an application template rather than a versioned library with a compatibility contract.

How the client talks to a LangGraph server

The data flow is client to LangGraph server, with an optional proxy in between. In development the browser connects directly, using the LangGraph SDK (@langchain/langgraph-sdk) against the deployment URL you type into the setup form. You supply three things: the deployment URL, the assistant or graph ID, and, for deployed LangGraph servers, a LangSmith API key. The key is what authenticates the run requests.

Streaming is event-driven. The README states the UI normally uses on_chat_model_stream events to render messages as they arrive, which is why tagging a chat model with langsmith:nostream suppresses live output. That is a useful detail: it means the interface is not polling, and it means message visibility is controlled on the server side, in your graph, not in the front end.

Message identity matters too. The UI filters out any message whose id begins with do-not-render-, so hiding content permanently is a matter of prefixing the id before the message is written to graph state and adding the langsmith:do-not-render tag to the model configuration. Artifacts take a different route: they are read from thread.meta.artifact and rendered in a side panel, with the README supplying a useArtifact hook that returns the component and its open state.

Installing Agent Chat UI and running a first conversation

There are two install paths. The npx command scaffolds the app without a manual clone, and the git route gives you the repository to modify. The README lists both.

npx create-agent-chat-app

Or clone and install dependencies with pnpm. The repository ships a pnpm-lock.yaml, so pnpm is the package manager the lockfile corresponds to.

git clone https://github.com/langchain-ai/agent-chat-ui.git

cd agent-chat-ui
pnpm install

Then start the development server. The README states the app will be available at http://localhost:3000.

pnpm dev

On first load you get a setup form asking for the deployment URL, the assistant or graph ID, and a LangSmith API key for deployed servers. If you would rather skip the form, copy .env.example to .env and fill in the values, then restart. The example file ships these keys:

NEXT_PUBLIC_API_URL=http://localhost:2024
NEXT_PUBLIC_ASSISTANT_ID=agent
NEXT_PUBLIC_AUTH_SCHEME=
LANGSMITH_API_KEY=

The default API URL points at a local LangGraph server on port 2024. Note the comment in .env.example: LANGSMITH_API_KEY must not be prefixed with NEXT_PUBLIC_, because that would expose it to the client. When the environment variables are set, the application uses them instead of showing the form. For a LangSmith Agent Builder deployment, set NEXT_PUBLIC_AUTH_SCHEME=langsmith-api-key, which the README says switches the auth scheme automatically.

Where the local-development default breaks down

The default configuration is a development convenience and the README says so plainly. Connecting directly from the client means every user needs their own LangSmith API key and has to know the LangGraph configuration. That is fine for one developer on localhost and wrong for anything with more than one user.

The production section describes the fix: pick one of two authentication approaches, the first being API passthrough via the langgraph-nextjs-api-passthrough package, which proxies requests to your LangGraph server and attaches your LangSmith API key on the server side so users never hold one. The .env.example shows the shape of that setup, with LANGGRAPH_API_URL pointing at a deployment such as https://my-agent.default.us.langgraph.app and NEXT_PUBLIC_API_URL pointing at your own site plus /api. The README's production section is where the documentation thins out: it introduces the two options and then the excerpt ends, so treat the second option as undocumented here rather than absent.

Other limits are structural. The interface expects a messages key, so a graph with a different state shape will not render. It is a Next.js app, so adopting it means adopting that stack and its dependencies, including React 19 and the Radix and Tailwind layers visible in package.json. And there is no release history to speak of: the repository shows no retrieved releases, and the package version is 0.0.0, so pinning to a tagged version is not an option. The last push was on 2026-09-09.

Agent Chat UI versus building your own chat surface

The real alternative is not another product. It is writing the chat front end yourself against the LangGraph SDK, or using a general-purpose chat UI that knows nothing about LangGraph state.

The difference is where the work sits. A general chat UI gives you message bubbles and a text box, and you write the glue: connecting to the server, handling streaming events, mapping graph state to rendered messages, and building any artifact panel. Agent Chat UI already implements that glue, including the on_chat_model_stream handling, the do-not-render- filtering and the thread.meta.artifact side panel with its useArtifact hook. What you give up is control over the presentation and the freedom to use a backend that is not LangGraph. If your agent runs on something else, or if your state does not expose messages, this application is the wrong tool, not a customizable one.

Maintenance, upgrades and the MIT licence

The repository is not archived and the last push was on 2026-09-09, so the code is current. That said, there is no versioned release to upgrade between. Upgrades happen by pulling the branch and reconciling your changes against it, which is the usual cost of forking an application template. The dependency list is wide for a chat client: LangChain core and LangGraph packages, the LangGraph SDK, React 19, Radix primitives, Tailwind, framer-motion, katex, recharts and more. Each of those moves on its own schedule, and the lint script even carries a NODE_OPTIONS preload of scripts/use-typescript6.cjs, a sign that the toolchain needed a workaround at some point.

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permission, not legal advice; if you ship this inside a product, have someone check how the bundled dependencies' licences interact with your distribution model. Nothing in the repository suggests a paid tier or a hosted service beyond the Vercel demo.

Editorial conclusion

Adopt Agent Chat UI if you already run a LangGraph server and want a working chat surface today instead of building message rendering, streaming and artifact panels yourself. Skip it if you need your own authentication model or a non-LangGraph backend; the client talks to a LangGraph server, and the production path depends on proxying through langgraph-nextjs-api-passthrough. Verify first that your graph returns a messages key, that you know which auth scheme your deployment expects, and whether you are willing to run the API passthrough route.

Frequently asked questions

Official sources

1. Issues
2. langchain-ai/agent-chat-ui on GitHub
3. License: MIT
4. Project website
5. README