AG-UI protocol

Use AG-UI as a semantic reference for the boundary between an agent runtime and a user-facing application. A user-facing application can be a web UI, mobile app, terminal, Slack, Teams, or another channel. AG-UI does not require React, CopilotKit, Assistant UI, RxJS, HTTP SSE, or any particular agent framework.

Start with the adoption level

Name the level before recommending changes:

1. Conceptual alignment — reuse AG-UI vocabulary, identifiers, lifecycle patterns, and separation of concerns inside an existing system.
2. Semantic compatibility — maintain an internal event contract that can map to AG-UI without losing meaning, while retaining the existing transport and renderers.
3. Wire compatibility — accept the current RunAgentInput shape and emit events that validate against a specific AG-UI version and transport.

Similar names do not establish compatibility. Do not describe a system as AG-UI-compatible unless its input, event shapes, ordering, and selected transport have been verified against the target version.

For ordinary architecture work, prefer the smallest useful alignment. Do not introduce the Ruby AG-UI gem, Sorbet, an AG-UI endpoint, or a new frontend runtime unless the task specifically calls for it.

Work from semantics outward