{"id":2475,"date":"2026-05-28T04:22:54","date_gmt":"2026-05-28T04:22:54","guid":{"rendered":"https:\/\/tucumandevelopers.com\/index.php\/2026\/05\/28\/agent-ui-is-runtime-infrastructure-focused-labs\/"},"modified":"2026-05-28T04:22:54","modified_gmt":"2026-05-28T04:22:54","slug":"agent-ui-is-runtime-infrastructure-focused-labs","status":"publish","type":"post","link":"https:\/\/tucumandevelopers.com\/index.php\/2026\/05\/28\/agent-ui-is-runtime-infrastructure-focused-labs\/","title":{"rendered":"Agent UI Is Runtime Infrastructure | Focused Labs"},"content":{"rendered":"
\n
<\/div>\n

This lets the front end promise something different than text streaming to a transcript. The transcript can be updated with text in real time. Tool calls can be surfaced as cards with progress and failure states. The latest state of the application can be rendered in real time. Errors can be surfaced with controls to retry. Final output can close the loop.<\/p>\n

The code shape matters because instead of a frontend parsing logs, it subscribes to product nouns.<\/p>\n

<\/a> The event stream needs nouns. <\/h2>\n

A useful agent stream would contain information about the lifecycle of the agent, text messages, tool calls, state, activity, reasoning behind decisions, custom events, and errors. AG-UI, the Agent-User Interaction Protocol, is the cleanest current example of this vocabulary. Its docs describe event-based architecture where events are the fundamental communication units between agents and frontends<\/a>, with lifecycle events, text message events, tool call events, state management events, activity events, reasoning events, special events, and draft extensions that are still under construction.<\/p>\n

Again, the lifecycle portion of the events is more important than it may initially seem. A run can start. Steps start and end. Text chunks attach to a message ID. Tool calls start, finish, error, or disappear. State lands as deltas against the user-facing model of the world. A run can end, interrupt, or fail. The UI can behave like software instead of a chat window watching smoke signals.<\/p>\n

AG-UI did not show up by accident. CopilotKit introduced it as a protocol for streaming a single JSON event sequence over standard HTTP or an optional binary channel<\/a>, carrying messages, tool calls, state patches, and lifecycle events generated during an agent run. The protocol is also supported by Microsoft\u2019s Agent Framework<\/a> for remote agent hosting. The framework supports real-time streaming over SSE, session and state management, human-in-the-loop approvals, shared state, predictive state updates and tool-based generative UI.<\/p>\n

There is also an enterprise adoption signal here. Agent frameworks are being judged by the event contract that their authors expose to application developers, not by the React widgets they use to build a demo application.<\/p>\n

<\/a> Generative UI makes the frontend part of the runtime boundary. <\/h2>\n

The term \u201cgenerative UI\u201d is abused because people believe that the model is painting components in front of them. But the useful part is the boring part. How does work happen in the frontend vs. the backend? How does approval work? How does writing state work? And what can be retried here?<\/p>\n

AG-UI\u2019s tool model gives the frontend a way to define client-side tools and let the agent request them through a structured lifecycle. The AG-UI tool docs<\/a> describe tool schemas, tool calls, and frontend-defined tools that let the application keep sensitive operations under product control while the agent reasons over the interaction.<\/p>\n

That boundary is significant. The calendar component exposing \u201cpropose meeting times\u201d doesn\u2019t grant the agent write access to the calendar. The billing page for plans exposing \u201cprepare plan change\u201d requires a human approval event before commit. The data table with rows and columns for accounts in a given timeframe can expose \u201cfilter this segment\u201d as a UI operation, as opposed to a backend mutation that changes the underlying data, and have the agent ask for it and the product decide to allow it and have the resulting events recorded in the stream of events.<\/p>\n

Once the run context is known, the screen can reflect state, permissions, intermediate artifacts, and interaction history. This is where context starts replacing static design<\/a>. The UI cannot be drawn once and left alone. It has to change in response to each step of the run and the events generated by those steps.<\/p>\n

<\/a><\/p>\n

Protocols matter because the UI is now part of the runtime boundary.<\/p>\n

<\/a> Subagents make transcript thinking collapse. <\/h2>\n

The transcript model gets messier with subagents in the product.<\/p>\n

A supervisor might define a task to research a problem, look up a policy, analyze an account, and then plan a series of remediations. The tradeoffs for multi-agent orchestration with LangGraph<\/a> were laid out in a recent architecture piece. The problem for the UI of such a task is similar to that of a chat transcript. When work is delegated to subagents, the work can be flattened into a single transcript, but this flattening obscures important information about the hierarchy of tasks, which are currently blocked, which have completed, and what results were generated by which child run.<\/p>\n

Deep Agents can handle the UI problem that arises when work is split off to subagents by treating the stream of each subagent as a separate first-class projection. The docs say stream.subagents<\/code> exposes one stream handle per delegated task<\/a>, with scoped messages, tool calls, values, nested subagents, output, path, and lifecycle status. This means a UI could show the effect of the supervising agent\u2019s work, then show off the work that the various child agents did as separate cards, and then drill down into any subagent\u2019s stream without subscribing to the stream of every other subagent as well.<\/p>\n

<\/a> Reconnects and traces belong in the same design conversation. <\/h2>\n

Agent runs continue after a browser tab has been closed, run into problems with flaky API connections, have a human manually intervene at a particular point, and continue after a product update has been deployed. They can fail partially in the course of completing a write. So too the stream of UI events corresponding to a given agent run must also be resumable, corresponding to the fact that runs are themselves resumable.<\/p>\n

This is where the event contract turns into production infrastructure. To follow runtime work, the contract has to map run IDs, thread IDs, parent run IDs, and step names. Ordered value deltas, tool calls, outputs, and results have to be tracked so the frontend does not duplicate side effects. When the UI generates a customer-visible action, it should trace back to the run, using the same identifiers that appeared in the tool card showing the \u201cbilling API failed\u201d error.<\/p>\n

Honeycomb\u2019s agent work points in the same direction. Its Agent Timeline product frames agent debugging as a flight recorder<\/a>. The same information used to present active work in the UI can be displayed in a review of an incident that involved that agent. If the UI showed a step title and the \u201cbilling API failed\u201d tool card, these same run, step and tool identifiers are necessary in the trace for the subsequent steps to accurately present the work done by the agent.<\/p>\n

Integrated agents raise the bar here. In the integrated-agent piece<\/a>, the point was that agents deliver value when they operate within existing enterprise systems and workflows. Processing work through a UI is not enough. The tool\u2019s event stream has to integrate with the product, the platform, and the observability system. They need the same event contract.<\/p>\n

<\/a> What to demand from an AI agent framework. <\/h2>\n

The buying checklist is getting sharper.<\/p>\n

Can the framework stream messages, tool calls, state patches, subagent progress, approvals, errors, custom domain events, and final output as typed projections?<\/p>\n

Can a product subscribe to a subagent, tool call, or state channel without draining the entire run, then reconnect later with the correct run IDs, state, and pending interrupts?<\/p>\n

Can frontend tools stay under application control while the agent requests them through a documented schema?<\/p>\n

Can event identifiers map cleanly into traces, logs, eval records, and incident tickets?<\/p>\n

Does the frontend UI produce useful UI for product work even for partial completion of work by an AI agent?<\/p>\n

A token stream makes things look active. An agent event stream gives a product handles.<\/p>\n

Generative UI needs these handles: lifecycle events for run boundaries, tool events for actions performed through tools, state events for shared context, subagent events for delegated work, approval events for control, error events for recovery, and observability hooks for the receipts.<\/p>\n

A chatbox is okay. People know how to use a chatbox. But a chatbox cannot be the UI for an agent-based product.<\/p>\n

Make the stream a contract. Then build the UI on purpose.<\/p>\n<\/p><\/div>\n<\/div>\n<\/div>\n<\/div>\n

Fuente: Art\u00edculo original<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

This lets the front end promise something different than text streaming to a transcript. The transcript can be updated with text in real time. Tool calls can be surfaced as cards with progress and failure states. The latest state of the application can be rendered in real time. Errors can be surfaced with controls to […]<\/p>\n","protected":false},"author":1,"featured_media":2474,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[41],"tags":[],"class_list":["post-2475","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devto"],"jetpack_publicize_connections":[],"_links":{"self":[{"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/posts\/2475","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/comments?post=2475"}],"version-history":[{"count":0,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/posts\/2475\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/media\/2474"}],"wp:attachment":[{"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/media?parent=2475"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/categories?post=2475"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/tags?post=2475"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}