Summary
OpenUI should provide a supported way to reuse LangChain/LangGraph integration primitives so users do not need to copy and maintain adapter code inside each app or example.
This does not necessarily need to be a dedicated package. The first decision should be the right maintenance boundary: existing package exports, a small integration helper, docs/recipe code, or a separate package only if we are comfortable owning its dependency surface.
Problem
Integrating LangChain/LangGraph agents with OpenUI currently requires app-specific glue for several concerns:
- converting LangChain protocol
messages events into AG-UI/OpenUI stream events
- forwarding OpenUI-compatible events over a custom stream channel
- proxying browser requests through a server route into LangGraph protocol-v2 endpoints
- converting browser/AG-UI message history into LangChain input messages
- cleaning up internal tool-call history so stateless runs do not replay invalid partial tool transcripts
This is enough integration surface that it should be a clearer supported path rather than example-local code.
Proposal
Explore the smallest maintainable public surface for LangChain/LangGraph integration.
Desired agent-side shape could be:
import { openUIStreamTransformer } from "<openui-langchain-integration-export>";
export const graph = createDeepAgent({
model: `openai:${MODEL}`,
tools: [getWeather, getStockPrice, searchWeb],
systemPrompt: SYSTEM_PROMPT,
streamTransformers: [openUIStreamTransformer],
});
Desired route-handler shape could be:
import { createLangChainStreamResponse } from "<openui-langchain-integration-export>";
import { NextRequest } from "next/server";
export const runtime = "nodejs";
export async function POST(req: NextRequest) {
return createLangChainStreamResponse(req, {
apiUrl: process.env.LANGGRAPH_API_URL || "http://localhost:2024",
assistantId: process.env.LANGGRAPH_ASSISTANT_ID || "agent",
apiKey: process.env.LANGSMITH_API_KEY,
});
}
Potential primitives:
openUIStreamTransformer / streamTransformer: LangChain/LangGraph stream transformer that emits AG-UI events on an OpenUI channel.
createLangChainStreamResponse: route helper that accepts an incoming chat request and returns a streaming Response.
streamOpenUI: lower-level helper for driving LangGraph protocol-v2 runs and relaying only the OpenUI custom channel.
- message conversion/history cleanup helpers, if useful outside the route helper.
Design questions
- What is the smallest supportable public API here?
- Should this live in an existing package/export, a docs recipe, or a dedicated integration package?
- If it is packaged, how do we avoid taking on an unbounded LangChain/LangGraph version matrix?
- Should the API target LangGraph protocol-v2 directly, DeepAgents specifically, or any LangChain stream transformer-compatible agent?
- How should this compose with
AgentInterface and the ChatLLM API?
- Should the route helper return AG-UI SSE directly, or expose an adapter that fits
fetchLLM({ streamAdapter })?
- How much should be supported for local LangGraph server vs LangGraph Cloud/Platform?
- What test harness should lock down the stream transformation semantics?
Acceptance criteria
- Decide the maintenance boundary and public API shape.
- Add reusable primitives or documented recipe code for the stream transformer and server response/proxy path.
- Update the LangChain/LangGraph example to consume the chosen primitive/recipe instead of maintaining unclear local copies.
- Add docs showing the minimal agent setup and minimal route setup.
- Cover stream conversion behavior with focused tests if the code is published as a supported API, especially text deltas, tool calls, errors, and finalization.
Summary
OpenUI should provide a supported way to reuse LangChain/LangGraph integration primitives so users do not need to copy and maintain adapter code inside each app or example.
This does not necessarily need to be a dedicated package. The first decision should be the right maintenance boundary: existing package exports, a small integration helper, docs/recipe code, or a separate package only if we are comfortable owning its dependency surface.
Problem
Integrating LangChain/LangGraph agents with OpenUI currently requires app-specific glue for several concerns:
messagesevents into AG-UI/OpenUI stream eventsThis is enough integration surface that it should be a clearer supported path rather than example-local code.
Proposal
Explore the smallest maintainable public surface for LangChain/LangGraph integration.
Desired agent-side shape could be:
Desired route-handler shape could be:
Potential primitives:
openUIStreamTransformer/streamTransformer: LangChain/LangGraph stream transformer that emits AG-UI events on an OpenUI channel.createLangChainStreamResponse: route helper that accepts an incoming chat request and returns a streamingResponse.streamOpenUI: lower-level helper for driving LangGraph protocol-v2 runs and relaying only the OpenUI custom channel.Design questions
AgentInterfaceand theChatLLMAPI?fetchLLM({ streamAdapter })?Acceptance criteria