ag-ui

Your Agent Finally Has a Face: AG-UI in Agent Kernel By Malitha Liyanage !Your agent finally has a face: Agent Kernel now supports AG-UI. Your UI sends one RunAgentInput request over the AG-UI open protocol, and Agent Kernel (running OpenAI Agents SDK, LangGraph, Google ADK, Pydantic AI or Microsoft Agent Framework agents with sessions, memory, hooks, tracing and auth) streams typed events back: RUN_STARTED, TOOL_CALL_START, TOOL_CALL_RESULT, TEXT_MESSAGE_CONTENT, STATE_SNAPSHOT and RUN_FINISHED Most agents today are a black box with a text box in front of it. You type a question. A spinner turns. Thirty seconds later a paragraph appears. Was the agent thinking? Calling a tool? Stuck? Waiting on a slow API? You have no idea, and neither do your users. That is not a model problem. It is a plumbing problem. The agent knows exactly what it is doing at every moment. It just has no standard way to tell the screen. Agent Kernel now speaks AG-UI, and your agent's work becomes something your users can see. The Missing Layer Between Agents and People The agent ecosystem has quietly standardised two of its three connections. MCP connects agents to tools. A2A connects agents to other agents. Agent Kernel already supports both. The third connection, agent to person, has been everyone's custom job. Every team writes its own streaming endpoint, its own event format, its own "is it still thinking?" logic, and its own frontend to match. None of it is reusable, and all of it breaks the day you swap frameworks. AG-UI is the open protocol that fills that gap. It is a simple, event-based wire format: the frontend sends one request, and the agent streams back a sequence of typed events describing everything that happens during the run. With AG-UI support, Agent Kernel now covers all three: tools, agents, and people. That is what we mean by full agentic UI support. What Your Users Actually See An AG-UI run doesn't return a reply. It streams the whole shape of the work: - The answer, word by word as it is written. - The agent's reasoning, as a separate "thinking" stream you can show dimmed, collapse, or hide, never mixed into the answer. - Every tool call, with its name, its arguments as they arrive, and its result. Your UI can render each one as a card: "Looking up order ORD-1001… found it." - What the agent is doing right now (thinking, calling a tool, replying, idle), read straight off the stream instead of guessed from a timer. - Shared state: a JSON object that both the frontend and the agent read and write. Here is what that looks like in practice: an agent that draws an AWS architecture as you describe it. Every box and arrow is a tool call, drawn on the canvas the moment its result streams in, while the reply writes itself into the chat beside it. !An Agent Kernel agent drawing an AWS architecture live over AG-UI: asked for a serverless todo API, it adds Users, API Gateway, Lambda and DynamoDB one box at a time; asked to add sign-in, it slots Cognito in; asked to host the frontend, it adds CloudFront and S3. Each box and arrow appears on the canvas the moment the matching tool call runs, while the reply streams into the chat beside it Shared State: The Agent Edits Your UI, Not Just Your Chat Look at the diagram drawer above. The user says "a serverless REST API for a todo app." In a chat-only world, the agent replies with a paragraph: "Use API Gateway in front of a Lambda that writes to DynamoDB." Nothing on screen changes. The user is left to draw the diagram themselves from a description. With AG-UI, the diagram itself is the agent's to edit. Every box and arrow the agent adds lands on the canvas as its tool call finishes, and the whole diagram lives in shared state that Agent Kernel sends back to the browser when the run ends. So when the user follows up with "add user sign-in", the agent reads the diagram that is already there and slots Cognito into it, rather than starting over. This is the difference between a chatbot bolted onto your app and an agent that actually works inside it. A form that fills itself in. A dashboard filter the agent sets. A cart the agent edits. A draft the agent and the user write together. Built the Agent Kernel Way AG-UI in Agent Kernel follows the same rules as everything else in the kernel. Framework agnostic. Write your agent in the OpenAI Agents SDK, LangGraph, Google ADK, Pydantic AI or Microsoft Agent Framework. The frontend sees the same events either way. Change frameworks next quarter and your UI does not notice. One handler, not a new server. AG-UI mounts alongside your chat API. Same sessions, same memory, same deployment. Scales off the web tier. Runs go through Agent Kernel's queue pipeline. Put SQS, Kafka or NATS behind it, with Redis or Valkey for the replies and the sessions, and agent runs move to their own workers while the web tier just holds the connection and streams the events back. The frontend never knows the difference. Secure by default. AG-UI has no anonymous mode. You plug in your own authoriser. Agent Kernel refuses to start the surface without one, because every run executes an agent on a real user's behalf. Client context stays out of the prompt. The frontend can attach context to a run: the page the user is on, their local time, a selected record. Agent Kernel never pastes that into the system prompt. The agent has to ask for it through a read-only tool, so it reads that context as tool output, not as instructions. Everything still applies. Sessions, memory, hooks, tracing, multimodal attachments: a run over AG-UI goes through the same runtime as any other request. Turn on multimodal support and users can even drop an image or a PDF into the conversation. People stay in the loop. When an agent needs approval before it acts ("may I issue this refund?"), the run pauses cleanly and the frontend gets the question. The user clicks approve or deny, and the agent carries on from exactly where it stopped. Get Started in Five Minutes 1. Install pip install "agentkernel[openai,api,agui]" export OPENAI_API_KEY=sk-... 2. Write the agent # app.py from agentkernel.agui import AGUIPipelineRequestHandler from agentkernel.auth import Authoriser from agentkernel.openai import OpenAIModule from agentkernel.pipeline import IOHandler from agents import Agent class DemoAuth(Authoriser): def authorise(self, token): return "demo-user" if token == "demo-token" else None agent = Agent( name="planner", instructions="You help the user keep a short task list. The list lives in the shared AG-UI " "state under the key 'tasks'. Whenever it changes, write the full new list back with " "update_agui_state.", ) OpenAIModule([agent]) if __name__ == "__main__": IOHandler.run(handlers=[AGUIPipelineRequestHandler(authoriser=DemoAuth())]) Mounting AGUIPipelineRequestHandler is what turns AG-UI on. There is no flag to forget. The agent runs on Agent Kernel's queue pipeline: on your laptop that is still one process with nothing else to install, and pointing the config at a broker, with shared storage such as Redis for replies and sessions, moves the runs off the web tier without touching this code or your frontend. The AG-UI docs list every setting a broker needs. 3. Configure AG-UI # config.yaml agui: default_agent: planner state: enabled: true # gives the agent get_agui_state / update_agui_state client_context: enabled: true # lets the agent read what the frontend attaches 4. Run it and talk to it python app.py curl -N -X POST http://localhost:8000/agui \ -H "Authorization: Bearer demo-token" \ -H "Content-Type: application/json" \ -d '{ "threadId": "thread-1", "runId": "run-1", "state": {"tasks": []}, "messages": [{"id": "m1", "role": "user", "content": "add milk and bread to my tasks"}], "tools": [], "context": [], "forwardedProps": null }' Watch the events stream in: RUN_STARTED, a tool call to update_agui_state, the reply text arriving in pieces, a STATE_SNAPSHOT carrying the new task list, and finally RUN_FINISHED. That stream is everything your frontend needs. 5. Put a UI on it The stream is plain Server-Sent Events, so any frontend can read it with fetch. The quickest start is our example: examples/api/agui is a small React + TypeScript app that renders every event kind: streamed answers, a thinking block, a card per tool call, a live status strip, a shared task-list panel and file attachments. Its code is written to be read, and easy to lift into your own app. The Bottom Line An agent nobody can see working is an agent nobody fully trusts. AG-UI turns your agent's work into something people can watch, follow and steer: the answer as it forms, the reasoning behind it, every tool it touches, and the state it changes in your app. Agent Kernel gives you that with one handler, on the framework you already use, without giving up the security, sessions and observability you already have. Your agent finally has a face. Agent Kernel is open source under Apache 2.0. - AG-UI protocol (official site): docs.ag-ui.com - AG-UI in Agent Kernel: kernel.yaala.ai - Runnable example with a React frontend: examples/api/agui - Human-in-the-loop over AG-UI: examples/api/hitl - GitHub: yaalalabs/agent-kernel --- Originally published at kernel.yaala.ai on October 25, 2026.

AG-UI & A2UI: Building Agent-Powered Interfaces Beyond Chat How event-driven agent interactions and generative UI are changing the way we build AI-powered frontend applications. 1. Why Are Chat Interfaces No Longer Enough? Most AI applications start with a familiar interface: a text input, a message history, and a streaming response. This works well for question answering, summarization, and conversational experiences. However, agent-based applications introduce a different set of interaction requirements. Consider an AI assistant that analyzes a user's investment portfolio, investigates market movements, or prepares a technical report. A conventional chat interface might return a response containing: - A summary of the analysis - A list of recommendations - Several data points - A suggested next action But what if the user needs more than a textual response? What if the application needs to display: - Interactive charts - Dynamic forms - Data tables - Approval workflows - Progress indicators - Context-aware actions - Multi-step interfaces that evolve as the agent works We could build every possible interface in advance and ask the model to select the appropriate components. This approach works for predictable workflows, but it becomes restrictive when the interaction itself is dynamic. Another option is to allow the model to generate HTML, React components, or JavaScript directly. However, executing arbitrary model-generated code introduces significant security, maintainability, and governance challenges. This is where two interesting technologies enter the picture: AG-UI (Agent-User Interaction Protocol) and A2UI (Agent-to-User Interface). Although their names are similar, they address different problems. AG-UI standardizes how agents communicate with user-facing applications. A2UI provides a declarative format for describing interfaces that client applications can safely render using their own component libraries. Together, they provide an interesting foundation for building agent-powered applications beyond traditional chat interfaces. References: AG-UI Documentation · Google A2UI 2. What Is AG-UI? AG-UI stands for Agent-User Interaction Protocol. It is an open, lightweight, event-based protocol designed to standardize communication between AI agents and frontend applications. The underlying problem is straightforward. An agent does not always produce one response and finish. It may execute multiple tools, delegate work, update its state, request additional input, and continue processing. A traditional request-response model does not necessarily represent these interactions well. For example, imagine an agent performing a database analysis: 1. The user requests an analysis. 2. The agent starts executing the task. 3. It calls a database tool. 4. The query completes. 5. The agent processes the returned data. 6. It generates a chart. 7. It asks the user to confirm an additional filter. 8. It completes the analysis. If the frontend only receives the final response, the user has no visibility into what happened during execution. We could implement custom WebSocket messages, HTTP streaming events, and application-specific state synchronization. But every application would need to define and maintain its own communication contract. AG-UI provides a standardized event model for this interaction. It allows agent backends to communicate execution events, messages, tool calls, state changes, and activity updates to the frontend. The protocol is intentionally not tied to one agent framework or frontend technology. You can build the backend using LangGraph, Google ADK, CrewAI, or a custom runtime, while the frontend uses React or another supported client implementation. The important point is that AG-UI does not define how an agent reasons or executes its internal logic. It defines how that execution is communicated to the user-facing application. Reference: AG-UI — Introduction 3. How Does AG-UI Work? AG-UI follows an event-driven architecture. Instead of treating an agent interaction as a single response, the backend emits a sequence of typed events that the frontend consumes. A simplified architecture looks like this: User | v React Application | v AG-UI Client | Event Stream / SSE | v Agent Runtime | +--------+--------+ | | | v v v LLM Tools Subagents | | | +--------+--------+ | v Agent Events | v AG-UI Client | v Update UI The frontend and backend have separate responsibilities. Backend responsibilities: - Execute agent logic. - Handle model interactions. - Execute tools. - Maintain execution state. - Emit standardized events. - Handle additional user input and resume interactions. Frontend responsibilities: - Initiate agent runs. - Consume event streams. - Render messages and activity updates. - Synchronize application state. - Present tool activity. - Handle user interactions and approvals. AG-UI is transport-agnostic. Common integration patterns include Server-Sent Events (SSE), WebSockets, and webhooks. The official HttpAgent client supports HTTP SSE and an HTTP binary transport. This separation means we do not have to make frontend components understand the implementation details of the backend agent framework. Reference: AG-UI — Core Architecture 4. Understanding AG-UI Events Events are the foundation of AG-UI. Rather than sending an unstructured text response, an agent can communicate different types of events depending on what is happening during execution. The main event categories include: 4.1. Lifecycle Events These events describe the execution lifecycle. | Event | Purpose | |---|---| | RUN_STARTED | An agent run has started | | RUN_FINISHED | An agent run has finished | | RUN_ERROR | An execution error occurred | | STEP_STARTED | A new execution step started | | STEP_FINISHED | An execution step finished | This allows the frontend to display meaningful execution states instead of relying on a generic loading indicator. 4.2. Text Message Events These events represent streaming messages. | Event | Purpose | |---|---| | TEXT_MESSAGE_START | Starts a message | | TEXT_MESSAGE_CONTENT | Sends a text chunk | | TEXT_MESSAGE_END | Completes a message | The frontend can append each text chunk as it arrives. This provides a familiar streaming experience while keeping the underlying event structure explicit. 4.3. Tool Call Events Tool execution is an important part of agent workflows. AG-UI defines events such as: - TOOL_CALL_START - TOOL_CALL_ARGS - TOOL_CALL_END - TOOL_CALL_RESULT These events allow the frontend to display which tool is being used and follow its execution lifecycle. For example, an interface might display: Analyzing repository... | v GitLab: Fetching merge request | v Code Review: Analyzing changes | v Security Check: Completed | v Generating report One distinction is important: receiving a tool-call event does not automatically mean the frontend should execute that tool. Tool execution and authorization remain responsibilities of the appropriate runtime or application layer. 4.4. State Management Events AG-UI also defines events for synchronizing application and agent state. | Event | Purpose | |---|---| | STATE_SNAPSHOT | Sends a complete state snapshot | | STATE_DELTA | Sends incremental state changes | | MESSAGES_SNAPSHOT | Synchronizes conversation history | For example, an agent might update the current analysis status: { "type": "STATE_SNAPSHOT", "snapshot": { "status": "analyzing", "completedSteps": 3, "totalSteps": 5, "currentTask": "Evaluating transaction data" } } The frontend can consume this state and update progress indicators, dashboards, or other components. 4.5. Activity and Subagent Events Modern agent systems often involve multiple agents working together. AG-UI includes activity and subagent-related events, allowing a frontend to represent more complex execution patterns. For example: - A research agent starts working. - A data analysis agent receives a delegated task. - The security agent completes its review. - The coordinator produces the final result. This makes it possible to build interfaces that expose useful execution activity without requiring users to understand the internal implementation of each agent. The current AG-UI v1.0 schema documents event families for lifecycle, text, tools, state, activity, subagents, reasoning, and custom events. A critical implementation consideration: reasoning-related events should not be treated as permission to expose raw model chain-of-thought. User-facing applications should expose approved progress summaries and operational status instead. Reference: AG-UI — Event Types and Specification 5. How to Integrate AG-UI with a React Application AG-UI provides a TypeScript SDK that can be used to connect frontend applications to compatible agent endpoints. The official package is @ag-ui/client. Step 1: Install the package pnpm add @ag-ui/client @ag-ui/core Step 2: Create an HTTP agent The HttpAgent class provides a client for communicating with an AG-UI-compatible backend. import { HttpAgent } from '@ag-ui/client'; const agent = new HttpAgent({ url: '/api/agent', agentId: 'portfolio-assistant', threadId: crypto.randomUUID(), }); The configuration defines the backend endpoint and identifies the agent and conversation thread. Step 3: Send a message and consume events We can use the agent's addMessage and runAgent methods to start an interaction. import { HttpAgent } from '@ag-ui/client'; import { EventType } from '@ag-ui/core'; const agent = new HttpAgent({ url: '/api/agent', agentId: 'portfolio-assistant', threadId: crypto.randomUUID(), }); agent.addMessage({ id: crypto.randomUUID(), role: 'user', content: 'Analyze my portfolio and summarize its performance.', }); await agent.runAgent( { tools: [], context: [], }, { onEvent: ({ event }) => { switch (event.type) { case EventType.RUN_STARTED: console.log('Agent execution started'); break; case EventType.TEXT_MESSAGE_CONTENT: console.log(event.delta); break; case EventType.TOOL_CALL_START: console.log('Tool started:', event.toolCallName); break; case EventType.RUN_FINISHED: console.log('Agent execution completed'); break; case EventType.RUN_ERROR: console.error('Agent execution failed'); break; } }, }, ); The example demonstrates the client-side event handling pattern. In a complete application, event handlers would update React state, render tool activity, and maintain conversation state. The agent SDK also supports shared state, event subscriptions, middleware, and cancellation through abortRun(). Step 4: Synchronize agent state with React One of the most useful capabilities is the ability to keep frontend and agent state synchronized. For example, an agent can update task progress while the frontend renders the current status. With a framework integration such as CopilotKit, this can be implemented through hooks such as useAgent. Conceptually: import { useAgent } from '@copilotkit/react-core/v2'; function TaskProgress() { const { agent } = useAgent(); const progress = agent.state.progress ?? { completed: 0, total: 0, }; return ( <section> <h3>Agent Progress</h3> <p> {progress.completed} / {progress.total} completed </p> </section> ); } The component reacts to changes in the agent's shared state. The important architectural detail is that AG-UI defines the communication contract, while libraries such as CopilotKit provide additional frontend integration and application-level abstractions. We are not required to use CopilotKit to implement AG-UI. A custom frontend can consume the protocol directly. References: AG-UI TypeScript SDK · CopilotKit Shared State --- 6. What Is A2UI? AG-UI solves the communication problem, but there is another question: What if an agent needs to generate an actual user interface instead of returning text? A2UI stands for Agent-to-User Interface. It is an open-source project initiated by Google that provides a declarative protocol for generating and updating user interfaces from structured JSON messages. The central idea is simple. Instead of asking an LLM to generate HTML, JavaScript, or React code, we let it describe what the interface should contain. For example, an agent may want to display: - A title - A summary card - A table - A date picker - A confirmation button It can describe these elements using A2UI messages. The frontend then maps those descriptions to its own approved components. This creates a separation between UI generation and UI execution. The agent describes the interface. The application decides how that interface is rendered. Why is this important? Imagine allowing an LLM to generate the following: function Dashboard() { // Arbitrary model-generated code } Executing model-generated React code directly would create substantial security and maintenance problems. Instead, we can let the model return structured data: { "component": "Card", "children": [ { "component": "Text", "text": "Portfolio Summary" } ] } The frontend maps Card and Text to components that already exist in its design system. The model never needs to execute arbitrary JavaScript to create the interface. This is the main architectural idea behind A2UI. Reference: Google A2UI — Official Documentation 7. How Does A2UI Work? A2UI uses a JSON-based streaming protocol. The agent sends messages to the frontend, and the frontend processes those messages to create or update UI surfaces. A2UI v0.9.1 defines four primary message types. 7.1. createSurface Creates a new UI surface. A surface represents a UI region that contains components and associated data. { "version": "v0.9.1", "createSurface": { "surfaceId": "portfolio-dashboard", "catalogId": "https://a2ui.org/specification/v0_9_1/catalogs/basic/catalog.json" } } 7.2. updateComponents Defines or updates the components within a surface. The components are represented as a flat list with references that define their relationships. For example: { "version": "v0.9.1", "updateComponents": { "surfaceId": "portfolio-dashboard", "components": [ { "id": "root", "component": "Column", "children": [ "title", "summary" ] }, { "id": "title", "component": "Text", "text": "Portfolio Overview", "variant": "h1" }, { "id": "summary", "component": "Text", "text": "Your portfolio analysis is ready." } ] } } The renderer understands the component definitions and constructs the corresponding UI tree. 7.3. updateDataModel Updates the data displayed by the components. A2UI separates component structure from application data. This is particularly useful because changing data does not necessarily require sending the entire component tree again. For example: { "version": "v0.9.1", "updateDataModel": { "surfaceId": "portfolio-dashboard", "path": "/portfolio", "value": { "totalValue": 125000, "currency": "USD", "change": 4.2 } } } Components can reference values in the data model using JSON Pointer paths. When the data model changes, the renderer can update the relevant parts of the interface. 7.4. deleteSurface Removes a previously created surface and its associated components and data. { "version": "v0.9.1", "deleteSurface": { "surfaceId": "portfolio-dashboard" } } This is useful for managing dynamic UI regions as an interaction evolves. The complete flow User Request | v Agent Runtime | v LLM Generates A2UI Messages | v JSON Stream | v A2UI Message Processor | v Component Catalog | v React / Flutter / Angular Renderer | v Interactive User Interface The process can happen incrementally. The agent can create a surface first, add components later, and update the data model as more information becomes available. This is different from generating an entire interface in one response. References: A2UI Protocol v0.9.1 · A2UI Quickstart 8. Integrating A2UI with React A2UI provides an official React renderer and a shared web core library. The relevant packages are: - @a2ui/react - @a2ui/web_core Step 1: Install the packages pnpm add @a2ui/react @a2ui/web_core Step 2: Create a MessageProcessor The MessageProcessor handles protocol messages, surface lifecycle, component definitions, and data models. For the v0.9 implementation: import { useState } from 'react'; import { MessageProcessor, } from '@a2ui/web_core/v0_9'; import { A2uiSurface, basicCatalog, } from '@a2ui/react/v0_9'; The processor is initialized with the component catalog that the application allows the agent to use. const processor = new MessageProcessor([ basicCatalog, ]); Step 3: Process agent-generated messages For example, we can create a surface and populate it with components: processor.processMessages([ { version: 'v0.9', createSurface: { surfaceId: 'main', catalogId: basicCatalog.id, }, }, { version: 'v0.9', updateComponents: { surfaceId: 'main', components: [ { id: 'root', component: 'Column', children: ['heading', 'description'], }, { id: 'heading', component: 'Text', text: 'Hello from A2UI', variant: 'h1', }, { id: 'description', component: 'Text', text: 'This interface was described by an agent.', }, ], }, }, ]); The MessageProcessor maintains the surface and its component model. Step 4: Render the surface Once the surface has been created, the React renderer can display it. function DynamicUI() { const [processor] = useState(() => { const instance = new MessageProcessor([ basicCatalog, ]); instance.processMessages([ { version: 'v0.9', createSurface: { surfaceId: 'main', catalogId: basicCatalog.id, }, }, { version: 'v0.9', updateComponents: { surfaceId: 'main', components: [ { id: 'root', component: 'Column', children: ['title'], }, { id: 'title', component: 'Text', text: 'Generated Interface', variant: 'h1', }, ], }, }, ]); return instance; }); const surface = processor.model.surfacesMap.get('main'); if (!surface) { return <p>Preparing interface...</p>; } return <A2uiSurface surface={surface} />; } This is a minimal rendering example. A production implementation should create and manage the processor at the appropriate application or session scope, rather than reconstructing it for each update. As new A2UI messages arrive, the application can pass them to the same processor. The surface model drives the React renderer's updates. Step 5: Handle user interactions An interactive UI needs a return path. For example, the agent may generate a form containing a confirmation button. When the user clicks that button, the frontend captures the associated action and sends it back to the agent through the selected transport. The flow becomes: Agent Generates UI | v A2UI Renderer | v User Interacts | v Frontend Captures Action | v Application / Agent Endpoint | v Agent Processes Input | v New A2UI Messages | v Updated Interface A2UI v0.9.1 uses an external communication channel for these return interactions. Its v1.0 candidate specification introduces additional structured function-call and response mechanisms. This distinction matters when designing the frontend-backend contract. References: A2UI React Renderer · A2UI Client Setup 9. What Is the Difference Between AG-UI and A2UI? This is probably the most important distinction in the article. AG-UI and A2UI are complementary, but they are not interchangeable. | Area | AG-UI | A2UI | |---|---|---| | Primary purpose | Agent-frontend communication | Declarative UI generation | | Main abstraction | Typed events | UI surfaces and components | | Data flow | Run events and state updates | UI structure and data updates | | Main responsibility | Interaction lifecycle | Interface representation | | Frontend role | Consume and handle events | Render approved components | | User interaction | Agent runs, tools, state and interrupts | UI actions and data context | Consider an agent that needs to create a dynamic approval dashboard. AG-UI can communicate: - The agent has started processing. - The data retrieval step is complete. - A tool has returned results. - The agent has updated its state. - A user approval is required. A2UI can describe: - An approval summary card. - A table of requested changes. - A confirmation button. - A detailed information panel. The frontend can render both the interaction lifecycle and the generated interface. Can we use them together? Yes. A possible architecture looks like this: User | v React Frontend | v AG-UI Event Stream | v Agent Runtime | v LLM | +-----+-----+ | | v v AG-UI Events A2UI JSON | | +-----+-----+ | v Frontend Host | v A2UI Renderer | v Native React UI AG-UI manages the interaction boundary. A2UI describes the interface that should be rendered. One protocol does not replace the other. A2UI can also be transported over A2A, MCP-related integrations, SSE, or WebSockets. It is designed to remain independent of a particular transport. References: AG-UI Architecture · A2UI Transport Decoupling 10. How Do They Fit Into the Existing AI Ecosystem? We have already discussed MCP, ACP, and A2A in previous articles. Adding AG-UI and A2UI gives us another important architectural layer. | Technology | Responsibility | |---|---| | MCP | Agent ↔ Tools and external data | | ACP | Coding Agent ↔ Client Application | | A2A | Agent ↔ Agent | | AG-UI | Agent ↔ Frontend interaction | | A2UI | Agent → Declarative UI | A typical enterprise AI platform could use several of these technologies simultaneously. For example: 1. An application communicates with an agent using AG-UI. 2. The agent accesses internal services through MCP. 3. The agent delegates a specialized task to another agent using A2A. 4. The agent returns dynamic interface definitions using A2UI. 5. The application renders those definitions through its own component system. ACP can be used independently when we need to integrate coding agents with a client application. This is not about adopting every protocol. It is about keeping architectural boundaries clear. 11. How Do These Approaches Compare With Traditional Generative UI? AG-UI and A2UI are not the only ways to build agent-powered interfaces. There are several approaches worth understanding. AI SDK Tool-Based UI Vercel AI SDK already allows applications to render custom UI based on tool calls and structured message parts. For example, a model can call a weather tool, and the frontend can render a weather card instead of displaying only raw text. This is a good approach when: - The application has a known set of components. - UI behavior is closely tied to model tool calls. - The application owns the entire interaction contract. However, it does not automatically provide the same cross-framework UI specification and agent interaction model as AG-UI and A2UI. MCP Apps MCP Apps extend MCP tools with interactive UI experiences. A tool can expose a ui:// resource containing its interface, which an MCP host can render in a sandboxed iframe. This is particularly useful when a tool needs to provide its own interactive experience, such as a dashboard, form, or specialized workflow. It solves a different problem from A2UI: the UI is associated with a tool rather than being a general declarative UI surface generated by an agent. A2UI A2UI focuses on agent-generated interface descriptions and framework-specific rendering. The same declarative description can be consumed by compatible clients with different native component implementations. AG-UI AG-UI focuses on the interaction protocol rather than the visual representation. It can be used with ordinary chat interfaces, custom React components, or declarative generative UI approaches. | Approach | Best suited for | |---|---| | AI SDK Tool UI | Application-defined component rendering | | MCP Apps | Interactive UIs provided by individual tools | | A2UI | Agent-generated, declarative interfaces | | AG-UI | Standardized agent-frontend communication | These approaches are not mutually exclusive. References: AI SDK — useChat · Vercel — MCP Apps Integration · Google A2UI 12. Advantages and Trade-offs Introducing these technologies can improve architecture and developer experience, but they also introduce new responsibilities. AG-UI Advantages Standardized event communication Teams can consume a consistent event model instead of maintaining separate custom streaming contracts. Frontend-backend separation The frontend does not need to understand the internal implementation of each agent framework. Better visibility into execution Tool calls, progress updates, and agent state can be represented in the UI. Framework interoperability Different backend agent implementations can expose a common interaction contract. Support for human-in-the-loop workflows Applications can build approval, clarification, and user-steering experiences around agent execution. AG-UI Trade-offs - Existing agent frameworks may require adapters or event translation. - Teams must manage protocol versions and event compatibility. - Application state and agent state can become inconsistent if ownership is unclear. - Authentication, authorization, and event validation remain application responsibilities. - For simple chat applications, a custom endpoint or ordinary AI SDK integration may be sufficient. A2UI Advantages Declarative and safer UI generation Agents send structured data rather than executable React or JavaScript code. Framework independence The same UI description can be mapped to different client-side component systems. Reuse of existing design systems Applications can expose their own approved component catalog. Incremental rendering The UI structure and data can be updated without resending everything. Separation of structure and data Components can remain stable while the agent updates the underlying data model. A2UI Trade-offs - A component catalog must be designed and maintained. - The renderer must support the required component types. - Complex application-specific interactions require additional integration. - Schema and protocol version compatibility require attention. - Debugging streamed component updates can be more difficult than debugging ordinary React components. - Cross-platform rendering does not guarantee identical visual behavior on every platform. An important point: declarative JSON is safer than arbitrary executable code, but it is not automatically trustworthy. The application must still validate messages, restrict available components, and authorize actions. 13. Security and Production Considerations This is where the difference between a successful demo and a maintainable production implementation becomes important. 1. Never execute arbitrary generated code An agent should not be able to send arbitrary JavaScript, HTML, or React code and have the application execute it. A2UI's declarative component catalog provides a safer approach. The application should only render components it explicitly supports. 2. Validate incoming messages AG-UI events and A2UI messages must be treated as untrusted input. Validate event structures, protocol versions, component definitions, data paths, and payload sizes before processing them. 3. Control available components Not every component should be available to an agent. For example, an internal banking application might allow: - Summary cards - Data tables - Charts - Read-only forms - Approval request components However, a sensitive transaction operation should not become available merely because the agent can generate a button. The backend must authorize the actual business operation. 4. Keep application state under application control There should be a clear distinction between UI state, agent state, and authoritative business state. An agent-generated UI should not be considered a source of truth for financial transactions, permissions, or other business-critical information. 5. Require human approval for sensitive actions A dynamically generated interface can make it easier for an agent to request user confirmation. However, the approval must be verified on the backend. Hiding or disabling a frontend button is not an authorization mechanism. 6. Handle interrupted streams and reconnection Streaming applications need predictable recovery behavior. Consider: - Reconnecting after network failures - Handling duplicate events - Recovering from incomplete UI updates - Preserving task and surface identifiers - Handling cancellation - Expiring stale sessions AG-UI and A2UI define communication structures, but the application still needs an operational strategy for stream recovery and state consistency. 7. Audit agent-generated interactions For enterprise applications, it should be possible to understand: - Which agent generated a UI. - Which components were requested. - Which actions the user performed. - Which backend operations were executed. - Whether an approval was obtained. - What the final result was. This is particularly important when AI interfaces are used to interact with internal business systems. 14. What Can an AI Chapter Lead Contribute? I believe this is where these technologies become particularly valuable. The opportunity is not simply introducing generative UI into an application. It is establishing a reusable frontend-agent architecture that product teams can build on. 1. Establish a Shared Agent-Frontend Integration Layer Instead of every team implementing its own event handling and agent-state synchronization, we can define a shared integration layer based on AG-UI. It can provide: - Event subscription and processing - Streaming message handling - Tool execution indicators - State synchronization - Cancellation and error handling - Human approval workflows This reduces duplicated infrastructure across applications. 2. Create a Governed Component Catalog A2UI introduces an interesting opportunity to connect agent capabilities with an organization's existing design system. For example, we can define an approved component catalog: | Component | Purpose | |---|---| | SummaryCard | Display structured summaries | | DataTable | Render tabular information | | LineChart | Display time-series data | | ApprovalPanel | Present approval requests | | DateRangePicker | Collect date filters | | StatusIndicator | Display execution status | The agent can request these components, while the frontend maps them to existing React components. This means teams can introduce dynamic interfaces without giving the model unrestricted access to the frontend codebase. For organizations with established design systems, this could be particularly valuable. 3. Define Reusable Frontend Patterns We can establish standard patterns for: - Agent progress indicators - Interactive forms - Approval interfaces - Dynamic dashboards - Multi-step workflows - Tool execution views - Subagent activity panels These patterns can become shared components and examples that product teams reuse. 4. Standardize the Security Model A shared approach should define which components agents can request, which actions require approval, and how the backend validates every operation. This is especially important for applications interacting with sensitive business systems. 5. Build a Reference Implementation A small reference application could demonstrate the complete interaction: 1. A user asks an agent to analyze a dataset. 2. The agent starts execution and sends AG-UI events. 3. The frontend displays progress and activity. 4. The agent generates an A2UI dashboard. 5. The React renderer maps the description to approved components. 6. The user modifies a filter or submits an action. 7. The frontend sends the interaction back to the agent. 8. The agent updates the interface with new results. This would help developers understand how the protocols work together in a real application. 6. Measure the Developer and User Experience We should not evaluate generative UI only by how quickly an agent can produce a visual result. Useful metrics include: - Time to interactive UI - Agent-to-frontend event latency - UI schema validation failure rate - Unsupported component requests - Rendering errors - User interaction completion rate - Human approval rate - Frontend integration effort These metrics can help determine whether generative UI actually improves the application experience. 15. What Is the Current State of A2UI and AG-UI? Both projects are evolving, so protocol versioning matters. As of November 1, 2026: AG-UI AG-UI publishes a versioned v1.0 specification and provides TypeScript client libraries, event schemas, and integrations with different agent frameworks. Its ecosystem includes integrations with projects such as LangGraph, CrewAI, Google ADK, and other agent runtimes. A2UI A2UI currently identifies v0.9.1 as its production protocol release. The v1.0 specification is a candidate release, not the production version. The project also provides an official React renderer, shared web core, Lit renderer, Angular renderer, and Flutter-based support. There is an important migration consideration: the v1.0 candidate introduces changes to the protocol model and should not be assumed to be wire-compatible with v0.9.1. For production applications, I would start with the stable v0.9.1 protocol and its matching renderer, and evaluate v1.0 separately before planning a migration. References: A2UI Repository and Status · A2UI Roadmap · AG-UI Specification Conclusion AG-UI and A2UI address two important challenges in building modern agent-powered applications. AG-UI standardizes the interaction between agents and frontend applications through a structured, event-driven communication model. A2UI allows agents to describe dynamic interfaces using declarative JSON messages, while applications remain in control of the actual components and rendering process. Together, they make it possible to move beyond traditional chat interfaces and build applications where AI agents can communicate their progress, update application state, and generate context-aware user interfaces. For engineering teams, the opportunity is to establish reusable interaction patterns, govern agent-accessible components, maintain security boundaries, and integrate generative UI into existing design systems. My recommendation: Start with a small React application that uses AG-UI for streaming and state synchronization, then introduce A2UI for one clearly defined dynamic interface. Evaluate rendering reliability, security, and user experience before expanding the approach. The goal should not be to make every screen dynamic. It should be to make the interface adapt when a conversation or workflow genuinely requires it. --- References and Further Reading AG-UI 1. AG-UI Official Documentation — Introduction, architecture, events, and integration. 2. AG-UI GitHub Repository — Protocol implementation and SDKs. 3. AG-UI Architecture — Event-driven architecture and client-server communication. 4. AG-UI Event Reference — Lifecycle, messages, tools, and state events. 5. AG-UI TypeScript SDK — Client implementation and event handling. A2UI 6. Google A2UI Official Documentation — Project overview and developer resources. 7. A2UI Protocol v0.9.1 — JSON protocol, surfaces, components, and data models. 8. A2UI Quickstart — Full-stack example and generated UI workflow. 9. A2UI React Renderer — React rendering implementation. 10. A2UI Client Setup — Framework integration and component catalogs. 11. A2UI Renderer Development — Building custom renderers and integrating design systems. 12. A2UI v1.0 Candidate Specification — Upcoming protocol capabilities and changes. Related Technologies 13. Vercel AI SDK — useChat — Conversational streaming and frontend state. 14. Vercel — MCP Apps Integration — Interactive tool UIs in AI SDK applications. 15. CopilotKit — Shared State — Bidirectional state synchronization between React and agents.

The Human in the Loop: Designing Approval-Based AI Systems Building AI agents is one thing. Building systems people can trust with real-world consequences is another. Hello guys, it’s been quite a while. I think this is my third article this year, and honestly, I’ve missed writing here. Recently, I had the opportunity to give a virtual talk at SailsConf 2026 titled The Human in the Loop: Designing Approval-Based AI Systems. I spoke about something I’ve found increasingly interesting while working around AI-powered products: how do we build AI agents that can actually do things for us without giving them the freedom to mess things up? We’ve all seen the demos. An agent searches the web, writes code, calls APIs, updates records, and completes tasks that would otherwise take us hours. It’s impressive stuff. But there’s a small question I think we sometimes overlook in the excitement of making AI do more. What happens when it gets something wrong? Do we just hope it gets everything right? I don’t think so. And that’s what I want us to explore in this article. So, What’s the Problem With Giving AI More Freedom? Let’s take a step back. Imagine you’re onboarding a new engineer into your team. Would you give them unrestricted access to your production database on their first day? Probably not. You’d establish permissions, explain how things work, and put safeguards in place before allowing them to make certain changes. Interestingly, we sometimes approach AI agents differently. We give an agent access to several tools, write a detailed system prompt telling it what it can and cannot do, and expect everything to work as intended. But a prompt isn’t a permission system. This isn’t just theoretical. In 2025, Replit’s AI coding agent reportedly deleted a production database during an experiment by SaaStr founder Jason Lemkin, raising questions about safeguards around autonomous coding agents. Fast Company covered the incident here. The lesson isn’t that AI agents are useless or that we should stop giving them tools. It’s that the ability to perform an action and the permission to perform that action are two different things. And we need to design our systems with that distinction in mind. !AI Agent Permissions and Safety Enter Human-in-the-Loop The concept is pretty straightforward. Instead of allowing an AI agent to execute every action immediately, we let it prepare the work and ask a human to approve actions where approval matters. Think of an agent preparing an email to a customer. It gathers the relevant information, writes the email, and presents it to you for review. You can approve it, edit it, or reject it. Simple enough, right? The agent does most of the heavy lifting, while you retain control over the final decision. !What Is an Approval-Based System Now, here’s where it gets interesting from an engineering perspective. What happens if the agent asks for approval in the chat but proceeds with the action anyway? Well, then the approval was practically useless. We cannot rely on the model to remember to ask for permission every single time. The application itself needs to enforce that rule. Asking for permission is a conversational behaviour. Enforcing permission is an engineering responsibility. Should Every Action Require Approval? Absolutely not. Imagine having an AI agent ask you for permission before every little thing it does. “Can I read this document?” “Can I summarise it?” “Can I format the summary?” At that point, I might as well do the work myself lol, kind of like taking matters into my hands. I remember Claude Code was like this at some point, not until recently. I like using football to explain this. Imagine a referee blowing the whistle every time a player goes down, even for the slightest contact, during a league final. The match would never end, and before long, everyone would be frustrated and the game would lose its excitement. VAR exists to review specific decisions that matter, not every movement on the pitch. Our AI systems need a similar approach. Of course, the context matters. Updating a draft and updating a financial record aren’t the same thing. The goal isn’t to maximise human involvement. It’s to make human involvement meaningful. Not every action needs a human: !Not Every Action Needs a Human The Interface Is Part of the Solution Too Now, for those of us building user-facing applications, this is where things get even more interesting. An approval workflow isn’t just a backend feature. It’s also a user experience problem. Imagine receiving a notification that says: > The agent wants to update this shipment. Approve? Okay, but which shipment? What exactly is changing? Why is the agent proposing this update? If I have to investigate everything myself before I can make a decision, how much time has the agent really saved me? A good approval interface should tell the user four things: - What is about to happen? - Why is the agent proposing it? - What will change if I approve? - What are my options? The user should be able to understand the proposed action and, where appropriate, edit it before approving. !Approval as a Tool Call There’s also the question of what happens when the user rejects an action. Does the workflow stop completely? Does the agent try another approach? And what if the user simply closes the page? The trick is to design the experience so that users are interrupted when their judgment is actually needed, not whenever the agent takes another step. !Sample Anatomy of a Good Approval Flow Okay, But How Do We Build This? Let’s get a little technical. One practical approach is to treat approval as part of the agent’s workflow rather than an isolated button click. When an agent reaches an action that requires approval, it requests permission. The application pauses the workflow and presents the proposed action to the user. Once the user responds, the system validates that decision and either continues, modifies, or stops the workflow. !Agents Are Only Half the Product There are a few details worth paying attention to here. 1. Preserve state If a user takes ten minutes to review an action, the agent shouldn’t have to start from scratch. 2. Enforce approval on the server Disabling a button in the frontend isn’t a security measure. The backend must verify that the approval is valid and applies to the action being executed. 3. Make retries safe Networks fail. Requests time out. Users click buttons twice. We need to make sure retrying a workflow doesn’t accidentally execute the same payment or external action twice. This is where idempotency and deduplication become important. 4. Keep an audit trail We should be able to answer simple questions: What did the agent propose? Who approved it? What actually happened? 5. Handle failure properly What happens if an approval expires, the underlying data changes, or the workflow crashes halfway through? An old approval shouldn’t authorise an action that has materially changed since the user reviewed it. These aren’t necessarily the things that make an AI demo look impressive, but they’re the things that make a production system dependable. A Quick Note on AG-UI Another part of this problem is how the frontend knows what the agent is doing. This is where AG-UI (Agent-User Interaction Protocol) comes in. It provides an event-based way for agents and user interfaces to communicate about agent runs, tool calls, and state changes. For example, the interface can show when an agent starts working, when a tool is running, when its state changes, and when the workflow finishes. But displaying a loading spinner isn’t enough. !AG-UI: The Event Stream The user needs to understand what the agent intends to do and have a way to intervene when necessary. The interface shouldn’t simply observe the workflow. It should help the user understand and control what happens next. !Typical Approval-Based System at Enterprise Level So, Are We Trying to Remove Humans From the Process? I think the real goal of automation is to reduce unnecessary human effort, not eliminate human judgment. Some tasks can be handled independently by an agent, others need human approval, and some should never be allowed. Keeping a human in the loop doesn’t mean we don’t trust AI. It means we’re deliberate about the responsibilities we give it. There’s a difference between building an agent that can complete a task and one that can do so safely, recover from failures, and leave users confident about what happened. That’s where the real engineering work lies. Final Thoughts Looking back at my talk, one idea keeps coming back to me: autonomy is a slider, not a switch. I don’t think the answer is to let agents do everything or keep humans involved in every little thing. It’s about knowing where to draw the line. In the systems I build, I try to give agents room to act while being intentional about what they can do and when a human needs to step in. As someone who resonates with Dostoevsky, I keep coming back to the relationship between freedom and responsibility. I think that matters just as much in the systems we build. Thanks for reading, guys. See you in the next one. References and Further Reading - My SailsConf 2026 talk: The Human in the Loop: Designing Approval-Based AI Systems - AG-UI: Agent-User Interaction Protocol — Event-driven communication between AI agents and user-facing applications. - AI Agents Are Only Half the Product — Building User-Facing Agentic Applications with AG-UI. - NIST AI Risk Management Framework — A framework for identifying and managing risks associated with AI systems. - Replit’s AI Agent Database Incident — Fast Company — A real-world example of why agent permissions and safeguards matter.

AG-UI is an open source protocol that connects AI agents to frontends. It streams typed events so your app can show live text, tool calls, and state changes. See the repo: ag-ui-protocol/ag-ui t.co

MCP vs A2A vs AG-UI: The Protocol Stack, Fact-Checked > Originally published on DevToolHub. MCP vs A2A vs AG-UI is the comparison chart making the rounds right now, and the framing is right — these are three different, complementary layers, not competing standards. But a couple of its headline numbers are either stale or don't hold up against the protocols' own sources, and it skips the actual news: MCP's July 2026 spec update is a real breaking-change event, not a one-word "stateless" bullet point. Here's what each protocol actually does, fact-checked against their own docs and GitHub repos, plus what the chart got right and what's worth correcting. For the agent concepts underneath all three, see our AI agents explained guide. The Three Protocols, What Each One Actually Connects The "vs" in every comparison title is misleading — you don't pick one. Each protocol solves a different connection problem, and a real agentic system typically uses all three at once: - MCP (Model Context Protocol) — built by Anthropic — connects an agent to tools and data. Anthropic's own docs describe it as a standardized way to connect AI applications to external systems, "like a USB-C port for AI applications." If your agent needs to read a file, query a database, or call an API, this is the layer — see our MCP registry breakdown for how big that ecosystem already is. - A2A (Agent2Agent Protocol) — built by Google, now governed by the Linux Foundation — connects one agent to another. It's how two independent agents, possibly built by different teams on different frameworks, discover each other and hand off work. - AG-UI (Agent-User Interaction Protocol) — built by CopilotKit and its open-source community, not Google (a detail the viral chart gets right, worth double-checking since AG-UI's name invites confusion with Google's A2A) — connects an agent to the human watching it work. It's an event-based protocol for streaming an agent's state and output into a real UI, not a chat log. None of these three compete for the same job. A production agent that reads your CRM (MCP), delegates a sub-task to a specialist agent (A2A), and shows a human the live progress bar while it works (AG-UI) is using all three simultaneously. MCP's July 2026 Spec Update Was Bigger Than "Stateless" The chart's MCP row says "Stateless spec, July 2026" and leaves it there. That's the right headline, but it's doing a lot of work in one line — per MCP's own 2026-07-28 changelog, this is the largest rewrite since launch: protocol-level sessions and the Mcp-Session-Id header are gone, the initialize handshake is gone, and Roots, Sampling, and Logging are now formally deprecated with a twelve-month removal window. We already covered the full breaking-change list and a real server-migration checklist in MCP Server Authentication: What the 2026-07-28 Spec Broke — if you're migrating an MCP server, that's the piece to work from. What's actually new to check, and what the chart doesn't carry at all: per Anthropic's own announcement, MCP is at 400M monthly SDK downloads as of that July 28 update — a real, sourced number that's meaningfully below the chart's "close to 500M" claim, and the real reason for the stateless move is architectural: "MCP moves from a bidirectional stateful protocol to a request/response model. Servers can now deploy on serverless and edge infrastructure" — something the old session-pinned design couldn't do cleanly. A2A's Real Status — v1.0, Signed Agent Cards, and a Number Worth Correcting The chart says A2A hit "v1.0 with signed Agent Cards, March 2026." The version and date both check out — A2A's GitHub releases show v1.0.0 published March 12, 2026, and the live spec's section 8.4 ("Agent Card Signing") does define canonicalization, signature format, and signature verification requirements so agents can cryptographically sign their Agent Cards for authenticity. Worth knowing if you're building against it today: v1.0 isn't the current patch anymore — v1.0.1 shipped May 28, 2026 with HTTP binding and TaskStatus fixes. Governance checks out too: Google originally built A2A and donated it to the Linux Foundation, and as of August 20, 2026 it formally joined the Agentic AI Foundation (AAIF) — the same body that already hosts MCP — putting both protocols under one neutral governance structure instead of two separate vendor-led ones. A2A's Technical Steering Committee includes representatives from AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, and ServiceNow. The one number worth double-checking: the chart lists A2A at "150+ organizations behind it." I couldn't find a primary source attributing that specific figure to A2A alone. What I could verify, directly from the Linux Foundation's own press release, is AAIF's total membership — the body that now governs both A2A and MCP — which states it "grows to 247 member organizations with the addition of 57 new members over the past three months." That's a materially different, larger number than "150+," just measuring the whole foundation rather than one protocol's backers specifically. If the chart's figure is from an earlier AAIF member count, it's stale now. AG-UI's Real Adoption — 16.7k Stars and a Fourth Integration the Chart Skips AG-UI's chart row says "15K+ GitHub stars." Checking the ag-ui-protocol/ag-ui repo directly, it's actually at 16.7k stars — the chart's number is accurate but already a bit behind. More interesting: the chart lists three 1st-party framework integrations (Google ADK, Microsoft Agent Framework, AWS AgentCore). The repo documents a fourth — AWS Strands Agents is also officially supported, alongside AWS Bedrock AgentCore, not instead of it. If you're picking an agent framework specifically because it has AG-UI support baked in, Strands is a real option the chart doesn't mention. Where ACP Went The chart's footer note — "Where's ACP? IBM merged it into A2A in August 2025" — checks out exactly. IBM Research's Agent Communication Protocol, built to power its BeeAI platform, overlapped heavily with A2A (both covered agent-to-agent discovery and messaging). The original ACP repository itself confirms it: archived August 27, 2025, with a banner reading "ACP is now part of A2A under the Linux Foundation!" and a link to the migration guide. If you see ACP referenced in older material, it's a dead end now — the real destination is A2A. Do You Need All Three? A Practical Decision Guide - Your agent needs to read or write something external — a CRM, your docs, a GitHub repo, a database: that's MCP. One server, any MCP-compatible client can use it — our best MCP servers by category guide is a starting point. - Your agent needs to hand off a task to a different, independently-built agent — possibly on a different framework, possibly a different vendor: that's A2A. The Agent Card is how the other side learns what your agent can do before the handoff. - A person needs to watch your agent work and approve or steer its steps in real time, not just read a final answer: that's AG-UI. It's the layer between the agent's internal state and whatever UI framework renders it. - You're building a single-tool integration with no multi-agent handoff and no live UI — you may genuinely only need MCP. Don't add A2A or AG-UI to a system that doesn't have another agent or a human-in-the-loop UI to connect to. Frequently Asked Questions Q: Are MCP, A2A, and AG-UI competing standards? A: No. They connect different things — MCP connects an agent to tools and data, A2A connects one agent to another, AG-UI connects an agent to the person watching it. A single system can use all three at once. Q: What actually changed when MCP went stateless in July 2026? A: Sessions, the initialize handshake, and three features (Roots, Sampling, Logging) all changed at once — see our full MCP server authentication breaking-change checklist for the complete list. The number worth knowing that isn't in that piece: Anthropic's own blog puts MCP at 400M monthly SDK downloads as of this update. Q: Who governs MCP and A2A now? A: Both are hosted projects under the Agentic AI Foundation (AAIF), part of the Linux Foundation. A2A joined AAIF on August 20, 2026, after Google donated it; MCP was already a founding AAIF project. AAIF's own press release puts total membership at 247 organizations. Q: Does AG-UI only work with Google, Microsoft, and AWS AgentCore? A: Those three are 1st-party supported, but so is AWS Strands Agents — a fourth framework with official AG-UI support that's easy to miss if you're only going by popular comparison charts. Q: What happened to ACP (IBM's Agent Communication Protocol)? A: It merged into A2A. The original repository was archived August 27, 2025, with a notice directing developers to A2A's migration guide. Quick Summary: - MCP, A2A, and AG-UI are complementary layers (tools, agent-to-agent, agent-to-human), not competing alternatives - MCP's July 28, 2026 spec update (sessions, the initialize handshake, Roots/Sampling/Logging all changed) is covered in full in our MCP server authentication piece - Per Anthropic's own blog, MCP is at 400M monthly SDK downloads as of that update — not "close to 500M" - A2A hit v1.0.0 in March 2026 (now on patch v1.0.1) with real signed Agent Cards; AAIF's own total membership is 247 organizations, a different number than "150+" - AG-UI is at 16.7k GitHub stars with four 1st-party framework integrations (Google ADK, Microsoft Agent Framework, AWS Bedrock AgentCore, and AWS Strands Agents) - ACP (IBM) merged into A2A in August 2025 and is a dead end if you see it referenced The real answer to MCP vs A2A vs AG-UI is: pick protocols by the connection you actually need, not by which chart you saw first — and if you're touching an MCP integration built before July 2026, check it against the real breaking-change list above before assuming "stateless" just means a minor version bump.

Encore un standard ! AG-UI (Agent-User Interaction Protocol) : un protocole open source qui standardise les échanges en streaming entre une interface utilisateur et une API agentique. Déjà intégré aux principaux frameworks du marché. ag-ui-protocol/ag-ui

Encore un standard, je l'avais raté celui-là ! 😅 AG-UI (Agent-User Interaction Protocol) : un protocole open source qui standardise les échanges en streaming entre une interface utilisateur et une API agentique. Déjà intégré aux principaux frameworks du marché. ag-ui-protocol/ag-ui

"考え中"とかちゃんと出すために逐次イベント送信してあげるわけですね　それプロトコルあるんだ ag-ui-protocol/ag-ui #ginzajs