Connecting the UI
There is a temptation to treat the front end as a separate discipline that happens after deployment. It is not. A UI is a client of the Agent Server API, and once you have internalised that, the whole topic collapses into three questions: what does it need, what is it speaking, and what can it recover when something goes wrong.
The UI is a client, and that is the whole story
The deployment exposes the Agent Server API over HTTP. A chat interface creates a thread, starts a run against an assistant, and consumes the stream. Those are the same endpoints a script would hit. There is no privileged channel and no special integration to request.
LangChain publishes an open-source chat interface template intended exactly for this, and using it is the fastest path to a working window. It is called Agent Chat UI, it lives at langchain-ai/agent-chat-ui, and it is a Next.js app that will chat with any LangGraph server exposing a messages key. There is an npx create-agent-chat-app scaffold and a hosted instance if you only want to poke at a deployment.
Treat the template as a convenience rather than as the mechanism. The contract underneath it is what the exam can actually test, and the template is useful here mostly because it makes that contract visible: its entire configuration is the three things in the next section and nothing else.
What it needs to be told
Three things, and no more:
- Where the deployment is. A URL.
- Credentials. An API key or whatever your auth scheme establishes identity with.
- What to run. A graph or assistant identifier, because a deployment can serve several and the client has to choose.
Agent Chat UI is a clean confirmation of that list, because its whole configuration is those three and nothing else:
NEXT_PUBLIC_API_URL=http://localhost:2024
NEXT_PUBLIC_ASSISTANT_ID=agent
NEXT_PUBLIC_AUTH_SCHEME=Note the default port in that first line. 2024 is langgraph dev, so a client pointed at a local development server is the same client pointed at a deployment with a different URL. That is the protocol-not-permission point restated as a configuration file.
Notice what is absent. No compiled artifact, no copy of langgraph.json, no knowledge of your entrypoint. Those are build-time facts the server already resolved, and a runtime client never sees them. Any option handing build-time information to a UI is describing a system that does not exist.
The ui key is not the chat window
There is a ui key in langgraph.json and it does something genuinely different: it declares generative UI components that ship with the deployment, so the agent can emit rendered output instead of plain text.
That distinction is worth holding precisely because the key’s name invites the wrong reading. Your chat interface is a separate application connecting over the API. The ui key is about what the agent can render inside a response.
The refresh bug, and why it is a persistence question in disguise
A user refreshes mid-response. What comes back?
Whatever was checkpointed on the thread, read from Postgres. Not the stream. Streaming output is broadcasted but never stored, and Redis holds only ephemeral metadata, so nothing in the streaming path writes those tokens down anywhere.
A front end that treats the stream as its source of truth loses content on reload, and the fix is not a streaming fix. It is to read thread state on mount and treat the stream as a live overlay on top of durable state. That is the shape of the correct architecture, and it falls straight out of facts you already learned in a completely different module.
Try it yourself
What a chat UI needs to reach a deployment
You are pointing a front end at a running deployment for the first time. Which set is the honest minimum?
Show answer
Correct answer: C — The deployment URL, credentials, and the assistant or graph identifier to run against
A UI is just another client of the Agent Server API, so it needs an address, credentials, and a target to run. The last option is the tempting one because the default assistant genuinely does exist and genuinely does let you make a call without naming one: a real UI still has to know which graph or assistant it is talking to, because a deployment can hold several and the UI has to pick. The first two options both hand build-time artifacts to a runtime client, which is the recurring confusion this whole module is designed to break.
What the ui config key is actually for
There is a ui key in langgraph.json. It is not the key that gives you a chat window.
{
"graphs": { "agent": "./src/agent.ts:graph" },
"ui": { }
}Show answer
Correct answer: A — It declares generative UI components the agent can render as part of its output
The ui key belongs to the what-runs family in the config: it declares UI components that ship with the deployment so the agent can emit rendered output rather than plain text. The tempting wrong answer is the embedded chat interface, because a key literally called ui in a deployment config reads exactly like that is what it does, and because you do get a usable interface from the platform, just not from this key. The Studio-mode option is a distractor built from real vocabulary attached to the wrong object: Graph Mode and Chat Mode are Studio's own views and nothing in your config selects between them.
A UI is a client, nothing more
This reframing is worth more than any specific template, because it survives the template being replaced.
Why is there no special integration required to put a custom front end in front of a deployment?
Reveal answer
Because the deployment exposes the Agent Server API over HTTP, and anything that speaks that protocol is a first-class client. A chat UI is not a privileged component with a private channel; it creates threads, starts runs and consumes streams through exactly the same endpoints a script would use. That is why Studio can point at a local langgraph dev server and a deployed one alike, and why bringing your own front end later is a matter of writing a client rather than requesting a capability.
What the UI is receiving while it renders
Connect this back to the persistence facts, because the two together explain a bug people hit in production.
A user refreshes the page halfway through a streamed response. What can the UI recover, and where does it come from?
Reveal answer
It recovers whatever was checkpointed on the thread, from Postgres, by reading the thread's state. It cannot recover the stream, because streaming output is broadcasted but never stored and Redis holds only ephemeral metadata. So a refresh mid-stream does not replay the tokens; it re-reads state. This is why a UI that treats the stream as its only source of truth loses content on reload, and why the durable read path has to go through the thread.
Sketch the client contract
Paper only. The goal is to be able to describe the contract without naming any particular template.
- Write down every piece of information a front end must be configured with in order to hold a conversation with a deployment.
- Beside each one, note whether it is build-time or runtime information, and which of the nine API groups it is used against.
- Add the sequence of calls for a first message and a follow-up message, naming which identifier is carried between them.
- Finally, write one sentence explaining what the UI loses on a page refresh mid-response and why.