[Feature Request] AG-UI protocol support for external agent backends

[andormarkus]

Summary

LibreChat's agent builder is excellent for the majority of use cases — fast to configure, well-integrated with MCP tools, and fits naturally into the existing UI. However, enterprise users running very complex agentic workflows (multi-step orchestration, stateful pipelines, LangGraph-based agents) currently have no clean way to connect those external agents to LibreChat's UI. This proposal adds AG-UI protocol support as a complementary path, not a replacement for the built-in agent builder.

Problem

• External agents connected via custom OpenAI-compatible endpoints are opaque to the UI — no intermediate steps, tool calls, or state updates surface to the user.
• MCP tool calls are stateless request/response — they can't express a long-running agent workflow with branching, retries, or human-in-the-loop pauses.
• Enterprises already invested in LibreChat for its auth, multi-user management, and RBAC have no path to connect SOTA agent frameworks (LangGraph, CrewAI) without leaving LibreChat entirely.

Proposed Solution

Add an AG-UI endpoint type to the agent or endpoint configuration. When selected, LibreChat acts as an AG-UI client — opening an SSE stream to the configured agent backend and mapping incoming AG-UI events to the existing chat UI primitives.

# librechat.yaml (proposed)
endpoints:
  - type: agui
    name: "My LangGraph Agent"
    url: "https://my-agent.internal/agent"
    auth: bearer

Scope (minimal first pass)

• Consume AG-UI SSE event stream from a configured URL
• Map TEXT_MESSAGE_CONTENT events to streaming token display
• Map TOOL_CALL_START / TOOL_CALL_END to existing tool-use UI
• Map RUN_STARTED / RUN_FINISHED to loading/done state
• Auth passthrough (bearer token, API key header)

What This Is Not

This does not replace or compete with the built-in agent builder. Users who don't need external agents see no change. The AG-UI endpoint type is opt-in and additive — one more endpoint type alongside openai, anthropic, etc.

References

• AG-UI spec: docs.ag-ui.com
• AG-UI TypeScript SDK: github.com/ag-ui-protocol/ag-ui
• AWS Bedrock AgentCore added AG-UI support (March 2026) as a reference implementation

[wigging]

I am very interested in this too. Has there been any updates on LibreChat supporting external agents?

[SirCypkowskyy]

+1. I built an AG-UI proof of concept for LibreChat and would like to contribute a PR covering the scope proposed here: https://github.com/SirCypkowskyy/LibreChat/tree/agui-poc

The same want keeps turning up in different shapes. #9238 asks for it through A2A and has 33 upvotes, #16047 through a reverse-connected runtime, this thread through AG-UI. All three are the same request: people who already run their own agents want a self-hostable chat frontend that can talk to them, instead of rebuilding those agents inside another builder or taking on a chat UI of their own. LibreChat already solves the harder half of that. The connection is the bit that is missing. I keep having that conversation at conferences too, and it's on the table as a use case where I work.

Of the options I looked at, AG-UI has the most frameworks already shipping support for it. That weighed more with me than which spec reads best, so this is where I would put the energy. I have not found another self-hostable chat client that speaks it yet. Being early on this seems worth something.

The fork was largely vibecoded, fast, to find out whether the mapping holds rather than to produce something I would defend line by line. It has 104 unit tests. Every screenshot in the walkthrough was driven by hand against a live pydantic-ai backend. I expect to rewrite parts of it for upstream review.

What it covers today, against the first-pass scope in the opening post: text deltas, the TOOL_CALL_* family as run steps, run start and finish, and auth passthrough as a bearer token resolved server-side from an env var. Across four recorded runs, every event kind that appeared had a counterpart LibreChat already streams, including reasoning deltas and activity labels. No new storage format either, it reuses the existing content types.

One implementation choice differs from the proposal above. There is no type: agui endpoint in the fork. I bound the external backend to an existing LibreChat agent by agentId, which means the picker entry, avatar, permissions and ACL sharing all keep working, and only execution changes. It may not be the right answer. It was cheap, and it kept a lot working.

The walkthrough also covers three things beyond that scope, and I'd keep all three out of a first PR: an AG-UI interrupt landing on LibreChat's existing approval card, a CUSTOM event carrying a ui:// resource rendering through the MCP-UI component already on dev, and the agent putting a question to the user as a picker or a short form. That last one did not need the HumanInterruptType union widened. I had assumed it would.

Two questions:

1. Would you welcome a PR limited to text streaming, tool-call start and end, run start and finish, and auth passthrough?
2. If so, is binding the backend to an existing agent by agentId an acceptable direction, or would you rather it arrive as an endpoint type?

@danny-avila, pinging you directly since CONTRIBUTING asks for approval before work starts on anything off the roadmap, and those two are the parts I cannot settle on my own.