Agent Server graph compilation approaches
Two ways to register a graph in application structure: (1) Compiled graph (recommended) - export an already-compiled CompiledGraph instance. Server loads it once at container startup and reuses for every run with no compilation overhead per request; (2) Factory function - export a function that server invokes each time it needs the graph. Use only when needing per-run graph customization (e.g., choosing different models or tools based on assistant config). Factory functions add overhead on every invocation; compiled graphs do not. The server automatically injects the checkpointer and memory store configured at runtime and these should not be configured in graph code.
Agent Server runtime deployment modes
Agent Server supports three runtime configurations: (1) Single host - API server manages task queue directly with no separate queue workers. Default for self-hosted deployments, suitable for development and low-traffic use cases; (2) Split API and queue - dedicated queue workers handle run execution on separate hosts from API server. For self-hosted deployments, enable by setting 'queue.enabled: true' in configuration. Each tier scales independently (API servers scale on request volume, queue workers scale on pending run count); (3) Distributed runtime - API and queue processes run separately with one process for orchestration and one for execution. For large-scale deployments with high concurrency requirements.
Agent Server container architecture
A typical Agent Server deployment consists of two kinds of stateless but persistent long-running containers built from the same Docker image: (1) API servers - handle client requests (creating runs, reading thread state, streaming results) but do not execute agent code themselves; (2) Queue workers - the execution engine that listen to durable task queue, execute graph code, and write checkpoints. At least 1 queue worker must listen to task queue at any time to ensure no runs are orphaned. Containers can serve many runs over their lifetime. API servers and queue workers are separate container pools and scale independently.
Agent Server run execution lifecycle steps
Run execution flows through these steps: (1) Client sends request to API server, which creates pending run in durable task queue; (2) Queue worker picks up run, acquires lease on it, loads appropriate graph, and begins execution. Queue enforces at most 1 run executed per thread at one time; (3) As graph executes, worker writes checkpoints to persistence layer (frequency depends on durability mode) and broadcasts streaming events over configured pubsub provider; (4) If client opened /stream connection, API server subscribes to pubsub channel and forwards events to client via server-sent events in real time; (5) When execution completes, worker updates run status and releases its slot for next run.
Agent Server concurrent job execution per worker
Each worker executes up to N_JOBS_PER_WORKER runs concurrently (default: 10), so a single worker container serves many runs in parallel. This bounds concurrent run execution but not the number of API requests the deployment can serve. API servers handle requests independently and scale separately, so request-serving capacity is not capped by N_JOBS_PER_WORKER.
Agent Server task queue purpose
When a client creates a run, the API server enqueues it and a queue worker picks it up for execution. Workers can be signaled to cancel a run in progress and publish output events that open /stream connections forward to the client in real time. Redis handles the signaling, cancellation, and streaming pub/sub between API servers and queue workers. Redis stores only ephemeral data—no user or run data persists in Redis. Run data itself is always read from and written to PostgreSQL.
Agent Server does not require LangGraph-specific graphs
Graphs do not have to be written with LangGraph. You can deploy agents built with other frameworks—such as Strands, Claude Agent SDK, Google ADK, and more—using the LangGraph Functional API or the deployments-wrap-sdk package.
Agent Server built on assistants and persistence concepts
LangSmith Deployment's Agent Server is built on the concept of assistants, which are agents configured for specific tasks, and includes built-in persistence and a task queue. It supports creating and managing assistants, threads, runs, and cron jobs.
Agent Server database management
LangSmith cloud manages the database automatically. If deploying on your own infrastructure, you need to set up the database yourself.
Managed Deep Agents deployment documentation
LangSmith provides deployment documentation for Managed Deep Agents, which is a beta feature. The documentation is located at the path /langsmith/python/managed-deep-agents-quickstart.
LangSmith deployment prerequisites
To deploy an application to LangSmith Cloud, you must have: a LangSmith account on the Plus plan or above with an API key; the LangGraph CLI installed via `uv tool install langgraph-cli`. Docker is optional—Docker Desktop can be installed for local builds, but if not available, `langgraph deploy` triggers a remote build automatically. On Apple Silicon (M1/M2/M3), Docker Buildx is optional for cross-compiling to `linux/amd64` during local builds.
langgraph.json requirement for deployment
`langgraph deploy` deploys any project whose `langgraph.json` configuration file exports a graph. Any app that exports a graph from a `langgraph.json` config deploys the same way, regardless of which framework was used to author the agent.
Frameworks that deploy via LangGraph CLI
Agents authored with Claude Agent SDK, Strands, CrewAI, AutoGen, or Google ADK deploy through the LangGraph CLI once they expose a graph from `langgraph.json`.
Two production requirements for deployed LangGraph agent
The two production requirements for setting up a deployed LangGraph agent are: (1) a LangSmith account on the Plus plan or above with an API key, and (2) a `langgraph.json` configuration file that exports a graph.
Setting LangSmith API key for deployment
The LangSmith API key can be set either by adding `LANGSMITH_API_KEY=lsv2_...` to a `.env` file in the project root (which `langgraph deploy` reads automatically), or by passing it inline: `LANGSMITH_API_KEY=lsv2_... langgraph deploy`.
Default deployment behavior with langgraph deploy
Running `langgraph deploy` from the project directory creates a Serverless deployment named after the project directory by default. Use the `--name` flag or `--deployment-type dedicated` flag to override the defaults. For organizations on previous pricing until October 1, 2026, use `--deployment-type prod` or `--deployment-type dev` instead.
Updating existing deployment after code changes
To update an existing deployment after making code changes, re-run `langgraph deploy`. It finds the existing deployment by name and updates it in place.
LangGraph CLI deployment commands
The LangGraph CLI provides these deployment management commands: `langgraph deploy` to deploy, `langgraph deploy list` to see all deployments, `langgraph deploy logs` to tail runtime logs, and `langgraph deploy delete <ID>` to remove a deployment.
Testing deployed agent with Studio
Studio is an interactive agent IDE connected directly to a deployed LangGraph application. After deployment is ready, go to LangSmith, select Deployments in the left sidebar, select the deployment, and click Studio in the top right corner. Studio allows sending messages, inspecting intermediate state at each node, editing state mid-run, and replaying from any prior checkpoint without writing code.
Python SDK sync client for deployed LangGraph
Example of calling a deployed LangGraph application using Python SDK synchronously:
```python
from langgraph_sdk import get_sync_client
client = get_sync_client(url="your-deployment-url", api_key="you••••••ey")
for chunk in client.runs.stream(
None, # Threadless run
"agent", # Name of assistant. Defined in langgraph.json.
input={
"messages": [{
"role": "human",
"content": "Say hello.",
}],
},
stream_mode="updates",
):
print(f"Receiving new event of type: {chunk.event}...")
print(chunk.data)
print("\n\n")
```
Install with: `pip install langgraph-sdk`
JavaScript SDK client for deployed LangGraph
Example of calling a deployed LangGraph application using JavaScript SDK:
```js
const { Client } = await import("@langchain/langgraph-sdk");
const client = new Client({ apiUrl: "your-deployment-url", apiKey: "you••••••ey" });
const streamResponse = client.runs.stream(
null, // Threadless run
"agent", // Assistant ID
{
input: {
"messages": [
{ "role": "user", "content": "Say hello."}
]
},
streamMode: "messages",
}
);
for await (const chunk of streamResponse) {
console.log(`Receiving new event of type: ${chunk.event}...`);
console.log(JSON.stringify(chunk.data));
console.log("\n\n");
}
```
Install with: `npm install @langchain/langgraph-sdk`
REST API call to deployed LangGraph
Example of calling a deployed LangGraph application via REST API:
```bash
curl -s --request POST \
--url <DEPLOYMENT_URL>/runs/stream \
--header 'Content-Type: application/json' \
--header "X-Api-Key: <LANGSMITH API KEY>" \
--data "{
\"assistant_id\": \"agent\",
\"input\": {
\"messages\": [
{
\"role\": \"human\",
\"content\": \"Say hello.\"
}
]
},
\"stream_mode\": \"updates\"
}"
```
Local development server for deployment testing
The `langgraph dev` command starts a local development server and automatically opens Studio, an interactive agent IDE. This allows testing before deploying to LangSmith Cloud.
Common LangSmith Deployment setups
Common setups include: (1) Managed hosting on Cloud where LangChain hosts the control plane, data plane, and databases paired with LangSmith Cloud; (2) Agents in your VPC via Hybrid where LangChain hosts the control plane and you host Agent Servers and data plane, paired with LangSmith Cloud or self-hosted; (3) Full data residency with self-hosted LangSmith Deployment where you host the control plane and Agent Servers; (4) Agent runtime only via Standalone Agent Server with no control plane and optional traces to LangSmith Cloud or self-hosted.
Update deployed agent behavior without redeploying
Once deployed, agents can have their prompts and versioned contexts managed through the prompt context hub, allowing behavior changes without a full redeployment.
RemoteGraph for deployed graphs
Deployed graphs can be interacted with using RemoteGraph, which allows calling your deployed graph from client code as if it were a local compiled graph.
Self-hosted LangSmith Deployment with control plane
In this setup, you run the LangSmith Deployment control plane and Agent Servers in your own Kubernetes cluster alongside self-hosted LangSmith. This requires the Enterprise plan with LangSmith Deployment enabled.
Hybrid LangSmith Deployment
In Hybrid deployment, LangChain manages the control plane while Agent Servers and their data plane run in your infrastructure. Traces flow to LangSmith Cloud or a self-hosted LangSmith instance.
Standalone Agent Server deployment
Standalone Agent Server deployment provides the Agent Server runtime only without a control plane. You deploy Agent Server containers with Docker, Compose, or Kubernetes and bring your own PostgreSQL, Redis, and LangSmith license. Optional LangSmith tracing can be sent to Cloud or a self-hosted instance.
Agent Server execution model components
After deployment, agents work with Agent Server's execution model which consists of three components: assistants for configuration, threads for state, and runs for workloads.
LangSmith Deployment framework support
LangSmith Deployment is framework-agnostic and supports deploying agents built with LangGraph, LangChain, Google ADK, Claude Agent SDK, Strands, CrewAI, AutoGen, and other agent frameworks.
LangSmith Deployment definition
LangSmith Deployment is a workflow orchestration runtime purpose-built for agent workloads. It provides managed infrastructure for agents to run reliably in production at scale, supporting the full lifecycle from local development to deployment.
LangSmith Deployment environments
LangSmith Deployment supports four environment options: Cloud (fully managed by LangChain on AWS and GCP, requires Plus plan or above), Self-hosted with control plane (run control plane and Agent Servers in your own Kubernetes cluster, requires Enterprise plan with LangSmith Deployment enabled), Hybrid (LangChain-managed control plane with Agent Servers in your infrastructure), and Standalone server (deploy Agent Server with Docker, Compose, or Kubernetes without a control plane).
Cloud deployment setup
LangSmith Deployment on Cloud is fully managed by LangChain on AWS and GCP. Deployments can be created from GitHub in the LangSmith UI or with the langgraph deploy CLI command. This setup requires a Plus plan or above and pairs with LangSmith Cloud.
Database migrations for persistence implementations
When using database-backed persistence (Postgres, Redis, Oracle) for short and long-term memory, run migrations to set up the required schema before use. Most database-specific libraries define a setup() method on the checkpointer or store instance to run migrations. Run migrations as a dedicated deployment step or ensure they execute during server startup.
Requirements for runtime.executionInfo and runtime.serverInfo
Requires deepagents>=1.9.0 (or @langchain/langgraph>=1.2.8) for runtime.executionInfo and runtime.serverInfo support.
runtime.serverInfo attributes
When running on LangGraph Server, runtime.serverInfo provides server-specific metadata with attributes: assistantId (string) - The assistant ID for the current deployment; graphId (string) - The graph ID for the current deployment; user (BaseUser | null) - The authenticated user if custom auth is configured. serverInfo is null when the graph is not running on LangGraph Server.
Access server info in a node
When a graph runs on LangGraph Server, access server-specific metadata via runtime.server_info which surfaces assistant_id (str), graph_id (str), and user (BaseUser|None) with authenticated user if custom auth is configured. server_info is None when the graph is not running on LangGraph Server.