The createAgent() function in LangChain is a factory that creates a ReAct agent by connecting an LLM with tools, middleware, and various configuration options for state management, structured outputs, and execution control.

The createAgent() function in LangChain (JavaScript/TypeScript SDK) is the primary entry point for building intelligent agents. It combines a language model with a set of tools and executes them in a loop until the model determines it has a final answer . The agent works by repeatedly calling the LLM with the current conversation history; if the LLM decides to call a tool, the agent executes it, adds the result to the conversation, and loops back to the LLM until a stopping condition is met .

Basic `createAgent` Example

1
model: The language model to drive the agent. Can be a string identifier like "anthropic:claude-sonnet-4-5-20250929" or an instance of a chat model like new ChatOpenAI() . This parameter is required.
2
tools: An array of tools the agent can use. Tools are defined using the tool() helper function, which requires name, description, and a schema (Zod object for TypeScript) . If omitted or empty, the agent will be a simple conversational agent without tool-calling ability .
3
systemPrompt: A string or SystemMessage that sets the system prompt for the agent. This provides high-level instructions that guide the agent's behavior throughout the conversation .
4
responseFormat: An optional configuration for structured responses. Accepts a ToolStrategy, ProviderStrategy, or a Pydantic/Zod model class. When provided, the agent will handle structured output during the conversation flow .

1
middleware: A sequence of AgentMiddleware instances that intercept and modify agent behavior at various lifecycle stages. Middleware can hook into: before_agent (runs once on invocation, good for loading memory), before_model (fires before each model call, ideal for trimming history or PII detection), wrap_model_call (wraps the entire model call for caching, retries), wrap_tool_call (wraps tool execution for validation or enrichment), after_model (runs after model response, natural for human-in-the-loop), and after_agent (runs on completion for cleanup) .

Adding Middleware to `createAgent`

1
stateSchema: An optional Zod object or StateSchema extending AgentState. This defines typed state fields that are persisted between multiple invocations. Can include reducers and special handling through LangGraph's state management .
2
contextSchema: A Zod object defining the shape of runtime context passed to each invocation. Context is read-only, not persisted between calls, and ideal for passing user IDs, permissions, or tenant data .
3
checkpointer: A BaseCheckpointSaver instance (or true) that enables conversation persistence. Used for saving graph state for a single thread (single conversation) .
4
store: A BaseStore instance for persisting data across multiple threads (multiple conversations/users). Different from checkpointer, which is conversation-specific .

Using Context Schema with `createAgent`

1
version: Determines graph version for tool execution. "v1" processes all tool calls concurrently via Promise.all inside a single node. "v2" dispatches each tool call as an independent graph task using Send API, offering per-tool-call checkpointing, better fault isolation, and interrupt() support .
2
interrupt_before: A list of node names to interrupt execution before. Useful for adding human-in-the-loop approval before tool execution .
3
interrupt_after: A list of node names to interrupt after. Useful for returning directly or running additional post-processing .
4
debug: Boolean flag to enable verbose logging for graph execution. When enabled, prints detailed information about each node execution, state updates, and transitions .
5
signal: An AbortSignal for cancelling the agent call. If provided, the call will be aborted when the signal is aborted .

1
responseFormat: This parameter is marked deprecated and will be removed in future versions. Use the response_format property in the configuration instead .
2
systemPrompt: Also marked deprecated—use system_prompt instead .
3
prompt: The framework supports custom prompts beyond the default ReAct template, allowing you to fully control the agent's reasoning format .
4
name: An optional name for the CompiledStateGraph. Automatically used when adding the agent graph to another graph as a subgraph node, particularly useful for multi-agent systems .

1
Tools are fixed at agent creation time. You cannot pass a different tools array to agent.invoke(). For per-session or per-user tool sets, build the agent dynamically; for turn-by-turn control, use middleware to update tool descriptions and guidance .
2
The tools array can be empty or omitted entirely, in which case the agent will function as a simple conversational agent without tool-calling capabilities .
3
You can use model string identifiers like "openai:gpt-4o" or "anthropic:claude-sonnet-4-5-20250929" for simplified configuration, or pass a fully initialized chat model instance .

Scenario Questions

0-2 years experience

1Can you walk me through how you'd use createAgent to spin up a simple agent that uses an OpenAI LLM and a single web‑search tool?
2What happens if you call createAgent without providing a tools array—how does the agent behave?

2-5 years experience

1Your team needs custom logging for every tool call; how would you configure callbacks when calling createAgent?
2An agent built with createAgent is ignoring the temperature you set on the LLM. What could cause that and how would you debug it?

5-8 years experience

1When you have to serve hundreds of concurrent requests, which createAgent parameters become performance bottlenecks and how would you mitigate them?
2Design a reusable factory function that creates agents with different toolsets per user while keeping configuration DRY. What trade‑offs do you consider?

8+ years experience

1Your organization is migrating from LangChain v0 to v1, which changes the signature of createAgent. How would you plan and execute this migration across multiple services?
2Discuss the pros and cons of centralizing all agent configuration in a shared service versus letting each microservice call createAgent with its own parameters.

Follow-up Questions

How would you unit‑test the tool selection logic inside an agent created with createAgent?
What monitoring or logging would you add via callbacks for production agents?
If you needed to version the LLM model used across agents, how would you manage that in the createAgent call?

Sharethis question

Share via WhatsApp, X, Facebook, LinkedIn or copy link. Open Graph preview enabled.