The control plane & deployment

1. Control plane vs. data plane

The same split every modern cloud system uses:

2. Three vocabulary words: assistants, threads, runs

The LangGraph runtime exposes your graph through three nouns:

3. Deployment options — pick one

4. Anatomy of a deployable LangGraph project

To deploy via the LangGraph CLI / Platform, a project needs two files at its root:

# langgraph.json — the deployment manifest
{
  "dependencies": ["."],
  "graphs": {
    "jarvis": "./src/jarvis.py:graph"
  },
  "env": ".env",
  "python_version": "3.11"
}

// langgraph.json — the deployment manifest
{
  "dependencies": ["."],
  "graphs": {
    "jarvis": "./src/jarvis.ts:graph"
  },
  "env": ".env",
  "node_version": "20"
}

And in code, you export the uncompiled StateGraph (the Platform adds its own checkpointer + store):

# src/jarvis.py
from langgraph.graph import StateGraph
# ... define nodes / edges as in earlier modules ...
graph = build_jarvis_graph()    # returns a StateGraph, NOT compiled
# The Platform calls graph.compile(checkpointer=..., store=...) for you.

// src/jarvis.ts
import { StateGraph } from "@langchain/langgraph";
export const graph = buildJarvisGraph();

Local dev with the same runtime

# In your project root:
pip install langgraph-cli
langgraph dev          # starts the LangGraph Server locally on :2024
# Visit http://localhost:2024 for LangGraph Studio (control-plane UI for dev).

npx @langchain/langgraph-cli dev
// Opens LangGraph Studio at http://localhost:2024

Same command everywhere: langgraph dev locally, langgraph deploy to ship. The graph code does not change between dev and prod.

5. Calling a deployed Jarvis — the SDK

Once deployed, you hit the data plane over HTTP. The official SDK wraps it:

from langgraph_sdk import get_client

client = get_client(url="https://your-deployment.langgraph.app", api_key=os.environ["LANGGRAPH_API_KEY"])

# 1. Get or create a thread for this user/chat session:
thread = await client.threads.create()

# 2. Start a run on the "jarvis" assistant:
async for chunk in client.runs.stream(
    thread_id=thread["thread_id"],
    assistant_id="jarvis",
    input={"messages": [{"role": "user", "content": "Printer floor 3 jammed."}]},
    config={"configurable": {"user_email": "priya@acme.com"}},
    stream_mode="updates",
):
    print(chunk.event, chunk.data)

# 3. Same thread later — Jarvis remembers:
await client.runs.wait(thread["thread_id"], "jarvis",
    input={"messages": [{"role": "user", "content": "What's the status?"}]})

import { Client } from "@langchain/langgraph-sdk";

const client = new Client({
  apiUrl: "https://your-deployment.langgraph.app",
  apiKey: process.env.LANGGRAPH_API_KEY,
});

const thread = await client.threads.create();

for await (const chunk of client.runs.stream(thread.thread_id, "jarvis", {
  input: { messages: [{ role: "user", content: "Printer floor 3 jammed." }] },
  config: { configurable: { user_email: "priya@acme.com" } },
  streamMode: "updates",
})) {
  console.log(chunk.event, chunk.data);
}

That's the entire user-facing integration. Your chat UI's only code is roughly: get/create thread → stream a run → render chunks.

6. Scaling and the data plane in practice

• Horizontal scale. Add more worker pods. Threads are sticky-but-not-pinned: any worker can pick up any thread's next run because state lives in Postgres.
• Queueing. Long-running runs go on a background queue. Your API returns a run id; client polls or streams.
• Streaming. SSE between data plane and client. Choose stream_mode="updates" for per-node updates, "messages" for token-by-token, "values" for full state snapshots.
• Cron jobs. The control plane lets you schedule runs (e.g. "every Monday at 9am, run the weekly-digest assistant"). No external scheduler needed.
• Webhooks. Configure a webhook URL per run; the Platform pings you when the run finishes.

7. Double-texting — handling concurrent user input

What happens if Priya sends "and book Anuj too" while Jarvis is still mid-run on her previous message? Four built-in strategies, picked per-run with multitask_strategy:

8. Versioning and rollouts

• Each deploy creates a new graph version. Existing assistants keep pointing at their pinned version; new ones get the latest.
• Roll out a prompt change by creating a new assistant on the same graph and routing 10% of users to it (A/B test). Promote when LangSmith evals look good.
• Rollback = re-point the assistant at the previous version. State is preserved.

9. Auth, multi-tenancy, secrets

• Auth: the Platform supports custom auth handlers — typically you'd verify a JWT from your own auth provider and stamp user_id/org_id into config.configurable.
• Multi-tenancy: scope thread_id and store namespaces by tenant. Two orgs' Jarvises never see each other's data.
• Secrets: env vars are set per-deployment in the control plane. Don't bake them into the graph code.

10. Jarvis, deployed