create_agent, parameter by parameter
create_agent is the constructor for the whole domain. Learn its shape once and three modules get easier.
The full parameter surface
Positional first, then everything else keyword-only:
Look at that list and notice how much of it you already understand. state_schema, checkpointer, store, interrupt_before, interrupt_after: all ground school vocabulary, handed straight through to the runtime underneath. create_agent is not hiding the graph from you, it is giving you a form to fill in.
The genuinely new ones for this course are middleware (module 2 lives there) and context_schema.
That last one is worth thirty seconds because it sits next to a parameter you already know and does something different. state_schema describes graph state: the thing that flows through the run, gets merged by reducers, and changes as nodes execute. context_schema describes runtime context: the configuration handed in for a given invocation, which the agent reads rather than mutates. Two schemas, one mutable and one not, and having both on the same signature is exactly the kind of adjacency an exam builds a question out of.
And it returns a compiled StateGraph, as established. Nothing exotic comes back.
The parameter that does not exist
Deprecated is not removed, and the difference matters
create_react_agent and its TypeScript twin createReactAgent are deprecated and relocated, still exported, still functional, and emitting a deprecation warning. They are not removed. Code calling them today runs today.
The precise picture, which is worth holding exactly:
- Python:
langchain.agentsexports onlyAgentStateandcreate_agent.langgraph.prebuiltstill exportscreate_react_agent, and calling it warns at runtime that it has moved. - TypeScript:
createReactAgentis absent from the langchain agents index, but still exported from langgraph-core carrying an@deprecatedJSDoc annotation.
Two different mechanisms doing the same job in two languages: a runtime warning on one side, a compile-time editor squiggle on the other.
Why the precision is the point
There is a failure mode where you read "deprecated" and upgrade it in your head to "deleted", then confidently tell a client their working code is broken. Or you go the other way, see it still exported, and keep writing it into new projects.
Both are wrong and the exam can test either direction. Teach and write create_agent. Describe create_react_agent as legacy but functional. That sentence is defensible against anyone who goes and checks, which is the actual bar.
Note the camelCase. Python is system_prompt, TypeScript is systemPrompt, and that same casing split runs through every single name in the next module.
Try it yourself
The prompt parameter trap
One of these is not a create_agent parameter. It is the single most natural distractor in the whole domain, because it used to be real.
Deprecated versus removed
Getting this wrong in either direction is an error. Overstating a deprecation reads as sloppy, understating it means you write legacy code.
What is the exact current status of create_react_agent / createReactAgent, and where does it still live in Python and in TypeScript?
Where the legacy constructor still lives
A Python-flavoured version of the same question.
Recite the keyword-only surface
Close the lesson, open a scratch file, and write the parameter list from memory before you look.
You can name at least ten of the keyword-only parameters, and you did not write prompt anywhere on the list.