Connecting to your agent
Your agent is deployed. The next question is entirely practical: how does anything talk to it, and what is the shape of the surface it is talking to?
The surface, in nine groups
The Agent Server API is organised into nine groups, and knowing the grouping is worth more than knowing any individual endpoint, because during a semi-open-book exam the grouping is your index.
Assistants, Threads, Thread Runs, Stateless Runs, Crons, Store, A2A, MCP, System.
Read that list as three clusters. The first four are the runtime objects you already know: configuration, state, work-with-state, work-without-state. Crons and Store are the two things that outlive a single conversation, scheduled work and long-term memory. A2A, MCP and System are the outward-facing edge: two interoperability protocols so other agents and other tooling can reach your deployment without bespoke glue, plus the operational group.
What connecting actually requires
Strip away the SDK ergonomics and a client needs two things: a deployment URL to send requests to, and credentials to be let in. That is it.
Notice what it does not need. It does not need the graph’s entrypoint, because that was build-time information the server already resolved. It does not need an assistant up front, because every graph has a default assistant, so a first call can happen before you have thought about configuration at all.
Streaming, and the thing people assume about it
You will stream. Long agent responses are unusable otherwise. The fact worth carrying out of this lesson is what streaming does not do.
Streaming output is broadcasted but never stored. Redis in this architecture holds ephemeral metadata only, explicitly not user data and not run data. So the stream is a delivery mechanism, not a record.
If you want to know afterwards what the agent said, you read the thread’s checkpointed state out of Postgres. The transcript exists because the state was checkpointed, not because the tokens were streamed. That is genuinely surprising the first time, and it is exactly the sort of negative fact a well-built question is made of.
The habit worth building now
When a question asks where something lives or how something is reached, translate it into a group name before you reach for the docs. “Start a run with no conversation” becomes Stateless Runs. “Read long-term memory” becomes Store. “Schedule this nightly” becomes Crons. The translation costs a second and saves a minute, and across forty questions that arithmetic is the entire difference between finishing and not.
Try it yourself
The nine API groups
You do not need every endpoint. You need the shape of the surface, because the grouping tells you where to look.
Name the nine groups of the Agent Server API.
Reveal answer
Assistants, Threads, Thread Runs, Stateless Runs, Crons, Store, A2A, MCP, and System. The one worth noticing is the split between Thread Runs and Stateless Runs, which is the persistence question expressed as two separate groups of endpoints. A2A and MCP are the two interoperability surfaces, letting other agents and other tooling talk to your deployment through protocols they already speak, and System is the operational group.
What a client actually needs to connect
You are wiring a script against a running deployment. Which set is the minimum you must supply?
Show answer
Correct answer: A — The deployment URL and an API key
A client needs somewhere to send the request and credentials to be allowed in. Everything else, including which assistant to use, is chosen per call rather than at connection time, and the default assistant means you can make a first call without naming one at all. The tempting wrong answer is the second one, because the entrypoint feels like part of the identity of the thing you are calling: it is build-time information that the server already resolved, and a client never sees it. The last option is worth rejecting on principle, since the whole auth module exists precisely because deployments are not open doors.
Finding an endpoint under exam conditions
You have two minutes, the docs are open, and you need the exact shape of the request that starts a run without creating a thread. Where do you look first?
Show answer
Correct answer: D — The Stateless Runs group, since running without a thread is what that group names
The groups are named after what they do, so the fastest lookup is to translate the question into the group name before you open anything. Running without a thread is Stateless Runs. The tempting wrong answer is the Threads group, because runs and threads are so tightly coupled in every other part of this course that the association fires automatically: the whole point of a stateless run is that it does not touch that group. Practising the translation from question to group is worth more than memorising any individual endpoint.
A stream is a delivery mechanism
This one is a negative fact, and the negative is more examinable than the positive.
You streamed a long response to a user and now you want to read it back later. Where does the durable copy come from, and why not from the stream?
Reveal answer
The durable copy comes from the thread's checkpointed state in Postgres. Streaming output is broadcasted but never stored, so the stream itself leaves no record. Redis holds ephemeral metadata only, no user data and no run data, which means nothing in the streaming path writes the tokens down. You watched them go past; none of them were persisted as tokens. If you need a transcript, it exists because the state was checkpointed, not because the stream happened.