Bring your own UI
The last lesson of the course is also the one that ties the loosest knot, because it is less a new topic than a permission slip. You are not obliged to use the interface you were given.
The only requirement
A deployment exposes the Agent Server API over HTTP. Anything that speaks that protocol is a first-class client. That is the entire gating condition.
Notice what does not appear in that requirement. Not a deployment tier. Not a config declaration naming your application. Not a property of how the graph was authored. The ui key in langgraph.json is about generative UI components the agent can render inside a response, which is a genuinely different thing and a genuinely tempting misreading.
The contract, as a sequence
Your front end needs three pieces of configuration: where the deployment is, credentials, and which graph or assistant to run against. Then it does this, in order:
- Create or reference a thread.
- Start a run, pairing an assistant configuration with that thread.
- Consume the stream for live output.
- Carry the same thread identifier forward on every subsequent turn.
Step four is the whole mechanism of conversational continuity, and it is boringly simple once the vocabulary is solid, which is why the vocabulary came first.
The responsibility that quietly moves onto you
When you replace a supplied interface with your own, one obligation transfers without announcing itself.
Streaming output is broadcasted but never stored. Redis holds ephemeral metadata only, no user data and no run data. So a client that treats the stream as its source of truth loses the response on a page reload, and the bug looks like a streaming bug while being a persistence fact.
The correct architecture reads thread state on load and treats the stream as a live overlay on top of durable state. That is not a workaround, it is the design the storage layer implies, and it falls straight out of a fact you learned in the memory module rather than anything about front-end engineering.
Everything else stays server-side. The run advances the checkpoint; no client commits anything. The default assistant already exists; no client provisions one. Authorization already happened before your request was served; no client is trusted to scope itself.
Where this leaves the whole course
Nine API groups, one protocol, and a straight line from a request arriving to a scoped, checkpointed result coming back. The UI is a client. Studio is a client. A script is a client. A custom route is code you mounted on the same server so it could inherit the identity work rather than repeat it.
Which is the argument for going back to the capstone and drawing the whole thing one more time, with a front end hanging off the edge of it, and defending every arrow out loud.
Try it yourself
What makes something a valid client
You want to replace the supplied interface with a front end of your own. What determines whether that is possible?
Show answer
Correct answer: B — Whether your client speaks the Agent Server API protocol
Speaking the protocol is the whole requirement, which is exactly why Studio can point at a local dev server and a deployed one alike. The tempting wrong answer is the ui key, because it is a real config key with a suggestive name sitting in the same file you would be editing anyway: it declares generative UI components the agent can render inside a response, not the identity of an external client. Nothing about the deployment tier or the way the graph was authored has any bearing on who may connect.
Studio is a client too
Reframing the tool you have been given as one instance of a general category is the point of this lesson.
What does the fact that Studio connects to any protocol-compliant server tell you about your own front end?
Reveal answer
That Studio has no privileged channel and no special integration: it is a client of the same public HTTP API your code would call, which is why it works against a local langgraph dev server and a deployed one without knowing the difference. Your own front end is therefore in exactly the same category. There is no capability to request and no integration to be granted; there is an API to call. Studio is described as a specialized agent IDE, and the word that matters there is specialized rather than privileged.
What your front end has to handle that the template did
You replace the supplied chat interface with your own. Which responsibility moves onto you and is easiest to forget?
Show answer
Correct answer: C — Reading thread state on load, because the stream is broadcast and never stored
Reading thread state on load is the responsibility that quietly moves onto you, because streaming output is broadcasted but never stored, so a client that treats the stream as its only source of truth loses everything on a refresh. The tempting wrong answer is the checkpoint one, because it sounds like exactly the sort of bookkeeping a client might own and the vocabulary is correct: the run advances the checkpoint server-side, and no client commits anything. The default assistant already exists without anyone provisioning it, which rules out the last option on a fact from module one.
The contract you are implementing
State it as a sequence, because a sequence is what you will actually be coding against.
List what a custom front end must do, in order, to hold a multi-turn conversation with a deployment.
Reveal answer
Be configured with the deployment URL, credentials, and which graph or assistant to run against. Create or reference a thread. Start a run pairing an assistant configuration with that thread. Consume the stream for live output while remembering it is not durable. On any reload, read the thread's state rather than expecting to recover the stream. Carry the same thread identifier forward on every subsequent turn, which is the entire mechanism by which the conversation has continuity.