📚 Documentation: list chanx as an AG-UI WebSocket transport

Read docs/integrations.mdx alongside spec/1.0/basic/transports, then compare the existing Infrastructure / Deployment entries with the proposed transport listing. Add chanx with the chanx-kit resource link, placement, framing, input delivery, termination and error signals, and the documented JSON-envelope deviation; done means the integration is accurately represented and its caveat is clear.

What this is

chanx is a typed WebSocket layer for Django Channels and FastAPI/Starlette. Its AG-UI kit serves AG-UI over a WebSocket instead of HTTP+SSE.

It is a transport rather than an agent framework, and provider-agnostic: anything that emits AG-UI events can sit behind it. There is a Pydantic AI adapter, and a runnable demo covering approvals, shared state and several browser tabs streaming one run. I maintain these and would keep the entry current.

To be precise about the two names: chanx is the installable library and the transport, and knows nothing about AG-UI on its own. The AG-UI binding is a chanx-kit kit — a small, self-contained component copied into your project, shadcn-style, rather than a second dependency. A listing would name chanx, with the AG-UI kit as the resource link.

Where I think it belongs

docs/integrations.mdx is organised around who emits AG-UI — Frontend Integrations, Agent Frameworks, Infrastructure / Deployment, and so on. This is the other axis: how the events travel.

The closest existing home is Infrastructure / Deployment, where Amazon Bedrock AgentCore sits (added in #1315), or a new Transports heading if you would rather keep that distinction visible. Happy to follow whichever you prefer.

Documenting the transport, per the custom-transport clause

spec/1.0/basic/transports asks a custom transport to document its framing, its input delivery, and its termination and error signals:

• Framing — each AG-UI event travels in a payload field on a flat envelope that also carries topic and seq. The event object itself is unmodified, and a client switches on payload.type exactly as it already does.
• Input delivery — RunAgentInput arrives as an ag_ui_run message on the same socket, so input needs no separate endpoint.
• Termination and error signals — AG-UI has no cancellation event, and a WebSocket has no equivalent of dropping an HTTP request, so an ag_ui_cancel message stops the run in flight. A cancelled run terminates as RUN_ERROR, as do provider failures.

One deviation I would rather flag than have you find

The same section says a JSON transport SHOULD frame events exactly as the SSE binding does, rather than introduce an envelope. This transport does not, for two concrete reasons:

1. One socket carries several conversations concurrently (and non-AG-UI features alongside them), so frames need addressing that SSE gets for free from one request per run.
2. seq is what lets several browser tabs follow a single run in order, including replaying an in-flight run to a tab that connects mid-stream — something SSE has no need for, since each run is its own request.

The event model, the event patterns and the processing rules are preserved unchanged. If you would rather not list a transport that deviates here, that is a fair answer and I would sooner hear it now than later.