CreateAgentParams

An optional checkpoint saver to persist the agent's state.

An optional schema for the context. It allows to pass in a typed context object into the agent invocation and allows to access it in hooks such as prompt and middleware. As opposed to the agent state, defined in stateSchema, the context is not persisted between agent invocations.

An optional description for the agent. This can be used to describe the agent to the underlying supervisor LLM.

Use to specify how to expose the agent name to the underlying supervisor LLM.

• undefined: Relies on the LLM provider AIMessage#name. Currently, only OpenAI supports this.
• "inline": Add the agent name directly into the content field of the AIMessage using XML-style tags. Example: "How can I help you" -> "<name>agent_name</name><content>How can I help you?</content>"

Middleware instances to run during agent execution. Each middleware can define its own state schema and hook into the agent lifecycle.

Defines a model to use for the agent. You can either pass in an instance of a LangChain chat model or a string. If a string is provided the agent initializes a ChatModel based on the provided model name and provider. It supports various model providers and allows for runtime configuration of model parameters.

An optional name for the agent.

An optional schema for the final agent output.

If provided, output will be formatted to match the given schema and returned in the 'structuredResponse' state key. If not provided, structuredResponse will not be present in the output state.

Can be passed in as:

• Zod schema

const agent = createAgent({
  responseFormat: z.object({
    capital: z.string(),
  }),
  // ...
});

• JSON schema

const agent = createAgent({
  responseFormat: {
    type: "json_schema",
    schema: {
      type: "object",
      properties: {
        capital: { type: "string" },
      },
      required: ["capital"],
    },
  },
  // ...
});

• Create React Agent ResponseFormat

import { providerStrategy, toolStrategy } from "langchain";
const agent = createAgent({
  responseFormat: providerStrategy(
    z.object({
      capital: z.string(),
    })
  ),
  // or
  responseFormat: [
    toolStrategy({ ... }),
    toolStrategy({ ... }),
  ]
  // ...
});

Note: The graph will make a separate call to the LLM to generate the structured response after the agent loop is finished. This is not the only strategy to get structured responses, see more options in this guide.

An optional abort signal that indicates that the overall operation should be aborted.

An optional schema for the agent state. It allows you to define custom state properties that persist across agent invocations and can be accessed in hooks, middleware, and throughout the agent's execution. The state is persisted when using a checkpointer and can be updated by middleware or during execution.

As opposed to the context (defined in contextSchema), the state is persisted between agent invocations when using a checkpointer, making it suitable for maintaining conversation history, user preferences, or any other data that should persist across multiple interactions.

An optional store to persist the agent's state.

Stream transformer factories baked into the compiled graph. These run automatically for every streamEvents(..., { version: "v3" }) call, after the built-in agent transformers (tool calls, middleware) and before any call-site transformers passed via streamEvents(input, { version: "v3", transformers }).

Use this to add domain-specific streaming projections that should always be available on the agent's run stream. The projection values are accessible via run.extensions.

An optional system message for the model.

Use a string for simple, static system prompts. This is the most common use case and works well with template literals for dynamic content. When a string is provided, it's converted to a single text block internally.

Use a SystemMessage when you need advanced features that require structured content:

• Anthropic cache control: Use SystemMessage with array content to enable per-block cache control settings (e.g., cache_control: { type: "ephemeral" }). This allows you to have different cache settings for different parts of your system prompt.
• Multiple content blocks: When you need multiple text blocks with different metadata or formatting requirements.
• Integration with existing code: When working with code that already produces SystemMessage instances.

A list of tools or a ToolNode.

Determines the version of the graph to create.

Can be one of

• "v1": The tool node processes the full AIMessage containing all tool calls. All tool calls are executed concurrently via Promise.all inside a single graph node. Choose v1 when your tools invoke sub-graphs or other long-running async work and you need true parallelism — the Promise.all approach is unaffected by LangGraph's per-task checkpoint serialisation.

• "v2": Each tool call is dispatched as an independent graph task using the Send API. Tasks are scheduled in parallel by LangGraph, but when tools invoke sub-graphs the underlying checkpoint writes can cause effective serialisation, making concurrent tool calls execute sequentially. v2 is the better choice when you need per-tool-call checkpointing, independent fault isolation, or interrupt() support inside individual tool calls.