I’m trying to integrate a self-hosted LangGraph Agent Server with CopilotKit using AG-UI.
What surprises me is that the current examples seem to push toward:
graph.compile(checkpointer=...)
add_langgraph_fastapi_endpoint(app, graph, ...)
But this bypasses a large part of the Agent Server runtime configuration:
- thread management
- persistence/checkpointing already configured server-side
- assistants
- stores
- runtime config from langgraph.json
- /threads + /runs APIs
What I would expect instead is something closer to:
CopilotKit
-> AG-UI adapter
-> existing LangGraph Agent Server
/threads
/threads/{id}/runs/stream
In other words:
- keep the LangGraph Agent Server as the source of truth
- reuse its existing configuration
- avoid recompiling/re-exposing the graph
- avoid redefining a checkpointer in a separate FastAPI layer
Right now I ended up writing a custom AG-UI bridge/proxy to translate:
- LangGraph streaming events
- into AG-UI events expected by CopilotKit
This works, but it feels like a missing first-class integration.
Am I missing an existing integration path for:
- CopilotKit
- AG-UI
- LangGraph Agent Server (self-hosted)
where CopilotKit could directly consume the Agent Server runtime similarly to calling /runs or /runs/stream?
Or is the intended architecture really:
- expose a separate AG-UI endpoint
- recompile the graph
- redefine persistence/checkpointing manually?
Would love clarification on the recommended production architecture here.
TLDR: There isn’t a documented “CopilotKit → AG-UI → /threads/{id}/runs/stream” path. CopilotKit is documented as an AG-UI adapter on a custom route co-located with the deployment, not as a direct consumer of the Agent Server REST API.
What the docs recommend
-
Agent Server stays the source of truth: threads, assistants, runs, checkpointing, and store come from langgraph.json and server config. The server injects checkpointer/store at runtime; you should not add your own in a separate FastAPI layer (Agent Server).
-
CopilotKit pattern: mount a thin route via http.app in langgraph.json on the same host as /threads and /runs (CopilotKit integration):
- Python:
add_langgraph_fastapi_endpoint + CopilotKitMiddleware (in-process AG-UI bridge).
- Node:
CopilotRuntime + LangGraphAgent with deploymentUrl pointing at the deployment: this calls the Agent Server APIs instead of recompiling the graph separately.
-
If you don’t need CopilotKit: use useStream or the LangGraph SDK against the deployment URL directly (streaming, assistant-ui).
Your questions
| Question |
Answer |
Missing first-class CopilotKit → /runs/stream? |
Yes, not in LangChain docs. Use LangGraphAgent (Node) or a custom AG-UI bridge (what you built). |
| Intended = recompile + own checkpointer? |
No for Agent Server. Custom AG-UI route yes; separate compile + checkpointer no. |
| Is your proxy reasonable? |
Yes for Python-only CopilotKit until you use Node LangGraphAgent or CopilotKit ships an HTTP-agent bridge for Python. |
Practical takeaway: Don’t run a second FastAPI app that recompiles the graph with its own checkpointer. Register the graph in langgraph.json, add a thin CopilotKit route via http.app, and on Node use LangGraphAgent(deploymentUrl=...). Your stream translator is a valid stopgap on Python-only stacks.
Hey, Ran from CopilotKit.
The path you’re describing is what used to be known as “lamggraph platform” (that’s an older name but the concept remains) which is basically the deployed version by Langchain (either self hosted or Langsmith cloud solution)
The FastAPI is not the right CopilotKit path to consume this. We have the none FastAPI path which does not expose an endpoint but rather use an existing one, expecting a contract that langgraph includes, and works with your existing deployment URL.
Look for the python path that doesn’t say FastAPI and if you have any more questions feel free to reach out!