{"slug": "your-agent-finally-has-a-face-ag-ui-in-agent-kernel", "title": "Your Agent Finally Has a Face: AG-UI in Agent Kernel", "summary": "Agent Kernel added support for AG-UI, an open event-based protocol that streams an agent's run to the frontend as typed events, giving users visibility into tool calls, thinking and shared state instead of a spinner and a text box. The integration mounts alongside the existing chat API, works across frameworks including the OpenAI Agents SDK, LangGraph, Google ADK, Pydantic AI and Microsoft Agent Framework, and requires an authorizer since AG-UI has no anonymous mode. Client context is exposed to the agent only through a read-only tool rather than being pasted into the system prompt.", "body_md": "**Most agents today are a black box with a text box in front of it.**\n\nYou 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.\n\nThat 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.\n\n**Agent Kernel now speaks AG-UI, and your agent's work becomes something your users can see.**\n\nThe agent ecosystem has quietly standardised two of its three connections.\n\n**MCP** connects agents to tools. **A2A** connects agents to other agents. Agent Kernel already supports both.\n\nThe 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.\n\n**[AG-UI](https://github.com/ag-ui-protocol/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.\n\nWith AG-UI support, Agent Kernel now covers all three: **tools, agents, and people.** That is what we mean by full agentic UI support.\n\nAn AG-UI run doesn't return *a reply*. It streams *the whole shape of the work*:\n\nHere 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.\n\nLook at the diagram drawer above. The user says *\"a serverless REST API for a todo app.\"*\n\nIn 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.\n\nWith 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.\n\nThis 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.\n\nAG-UI in Agent Kernel follows the same rules as everything else in the kernel.\n\n**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.\n\n**One handler, not a new server.** AG-UI mounts alongside your chat API. Same sessions, same memory, same deployment.\n\n**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.\n\n**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.\n\n**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.\n\n**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.\n\n**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.\n\n```\npip install \"agentkernel[openai,api,agui]\"\nexport OPENAI_API_KEY=sk-...\npython\n# app.py\nfrom agentkernel.agui import AGUIPipelineRequestHandler\nfrom agentkernel.auth import Authoriser\nfrom agentkernel.openai import OpenAIModule\nfrom agentkernel.pipeline import IOHandler\nfrom agents import Agent\n\nclass DemoAuth(Authoriser):\n    def authorise(self, token):\n        return \"demo-user\" if token == \"demo-token\" else None\n\nagent = Agent(\n    name=\"planner\",\n    instructions=\"You help the user keep a short task list. The list lives in the shared AG-UI \"\n    \"state under the key 'tasks'. Whenever it changes, write the full new list back with \"\n    \"update_agui_state.\",\n)\nOpenAIModule([agent])\n\nif __name__ == \"__main__\":\n    IOHandler.run(handlers=[AGUIPipelineRequestHandler(authoriser=DemoAuth())])\n```\n\nMounting `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](https://kernel.yaala.ai/docs/integrations/agui) list every setting a broker needs.\n\n```\n# config.yaml\nagui:\n  default_agent: planner\n  state:\n    enabled: true          # gives the agent get_agui_state / update_agui_state\n  client_context:\n    enabled: true          # lets the agent read what the frontend attaches\npython app.py\ncurl -N -X POST http://localhost:8000/agui \\\n  -H \"Authorization: Bearer demo-token\" \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\n        \"threadId\": \"thread-1\",\n        \"runId\": \"run-1\",\n        \"state\": {\"tasks\": []},\n        \"messages\": [{\"id\": \"m1\", \"role\": \"user\", \"content\": \"add milk and bread to my tasks\"}],\n        \"tools\": [],\n        \"context\": [],\n        \"forwardedProps\": null\n      }'\n```\n\nWatch 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.\n\nThe stream is plain Server-Sent Events, so any frontend can read it with `fetch`. The quickest start is our example: [` examples/api/agui`](https://github.com/yaalalabs/agent-kernel/tree/develop/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.\n\nAn agent nobody can see working is an agent nobody fully trusts.\n\nAG-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.\n\nYour agent finally has a face.\n\nAgent Kernel is open source under Apache 2.0.\n\n`examples/api/agui`` examples/api/hitl`\n*Originally published at [kernel.yaala.ai](https://kernel.yaala.ai/blog/agui-agentic-ui) on October 25, 2026.*", "url": "https://wpnews.pro/news/your-agent-finally-has-a-face-ag-ui-in-agent-kernel", "canonical_source": "https://dev.to/agent-kernel/your-agent-finally-has-a-face-ag-ui-in-agent-kernel-2hca", "published_at": "2026-11-03 09:21:02+00:00", "updated_at": "2026-11-03 09:28:34.894733+00:00", "lang": "en", "topics": ["ai-agents", "agent-protocols", "ai-tools", "developer-tools", "artificial-intelligence"], "entities": ["Agent Kernel", "AG-UI", "MCP", "A2A", "OpenAI Agents SDK", "LangGraph", "Google ADK", "Microsoft Agent Framework"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/your-agent-finally-has-a-face-ag-ui-in-agent-kernel", "markdown": "https://wpnews.pro/news/your-agent-finally-has-a-face-ag-ui-in-agent-kernel.md", "text": "https://wpnews.pro/news/your-agent-finally-has-a-face-ag-ui-in-agent-kernel.txt", "jsonld": "https://wpnews.pro/news/your-agent-finally-has-a-face-ag-ui-in-agent-kernel.jsonld"}}