Bedrock AgentCore AG-UI: Real-Time Agent Frontends Without Custom Event Plumbing

On March 13, 2026, AWS announced that Amazon Bedrock AgentCore Runtime now supports the Agent-User Interaction protocol, better known as AG-UI. That is more important than it sounds. Most agent demos look fine until you need to show real progress, intermediate tool activity, partial answers, and recoverable errors in a user-facing application. At that point, plain token streaming stops being enough.

AG-UI is AWS acknowledging that production agent interfaces need a protocol for runtime state, not just a pipe for text.

AWS describes AG-UI as an open, event-based protocol for how AI agents communicate with user interfaces. In AgentCore Runtime, it complements MCP and A2A rather than replacing them. MCP is for tool integration, A2A is for agent-to-agent communication, and AG-UI is for the agent-to-user surface. That separation is practical. It keeps your UI contract from becoming an accidental side effect of your tool contract.

As of April 10, 2026, AWS says AG-UI servers in AgentCore Runtime are supported across fourteen AWS Regions. AWS also says AgentCore Runtime handles authentication, session isolation, and scaling for AG-UI workloads, which is exactly the kind of infrastructure work teams should avoid rebuilding in their frontend stack.

What AWS Actually Shipped

The launch is not just “you can stream text now.” AWS specifically called out:

• streaming text chunks, reasoning steps, and tool results as they happen
• real-time state synchronization for UI elements such as progress bars and dashboards
• structured tool call visualization
• support for both Server-Sent Events and WebSocket transport

The implementation details in the AgentCore documentation matter too. When you deploy an AG-UI server in AgentCore Runtime, AWS expects the container to listen on port 8080, use /invocations for HTTP or SSE traffic, and use /ws for WebSocket connections. Deployment also requires the AG-UI protocol selection rather than treating the service as a generic HTTP runtime.

Those details sound small, but they are exactly the kind of details that usually create friction between platform and frontend teams.

Why AG-UI Is Better Than Ad-Hoc Frontend Events

The usual way teams build an agent UI is messy:

• stream tokens over SSE
• invent custom events for tool start and tool finish
• bolt on another event for approvals
• add one more event for errors
• keep patching the contract every time the agent grows new behavior

That approach works until you have two frontends, one mobile app, one admin console, and three different agent workflows. Then your “temporary” event format becomes permanent technical debt.

AG-UI gives you a more defensible boundary. The runtime can emit typed interaction events, and the frontend can render them without pretending that everything is just chat text. If you are already building agent-heavy systems like AWS Bedrock Agents for DevOps, this matters because the UI is part of the product, not decoration.

It also fits naturally beside the more tool-centric patterns in Bedrock AgentCore Stateful MCP Servers. Stateful MCP is about the lifecycle of a tool interaction. AG-UI is about the lifecycle of what the user sees while that interaction happens.

A Good Production Pattern

The cleanest way to think about AG-UI is as a presentation protocol, not a workflow engine.

A solid production design usually looks like this:

1. The frontend subscribes to AG-UI events from the agent runtime.
2. The runtime emits structured interaction state such as run start, partial text, tool progress, clarification prompts, and final completion.
3. The agent invokes tools or workflows elsewhere, often through MCP servers, Gateway, or deterministic backends.
4. Durable business actions still happen in proper application services or orchestrators.

That last point matters. AG-UI is not where you should hide payment capture, production deployment approval, or irreversible infrastructure changes. If a workflow needs durability, retries, auditability, and explicit state transitions, the handoff still belongs in something like EventBridge + Step Functions.

AG-UI makes the interaction visible. It does not replace disciplined backend design.

What the Frontend Team Gets

For frontend engineers, the biggest win is predictability.

Instead of inferring agent state from raw text, you can render explicit runtime events. That makes it easier to build:

• timeline views that show what the agent is doing right now
• panels for tool calls and tool results
• progress indicators that are tied to actual runtime events
• approval prompts that are part of the same session
• retry and error states that do not require refreshing the entire page

A generic event might look like this:

{
  "type": "TOOL_STATUS",
  "toolName": "deployment_readiness_check",
  "status": "running",
  "message": "Comparing the proposed change against the last successful production release"
}

That is the kind of payload a real UI can work with. It is also much easier to debug than a spinner with no semantics.

If your team is building coding or operations agents, pair this with the runtime capabilities in Build Coding Agents on AgentCore: Shell Commands and Persistent Session Storage. AG-UI solves the visibility side. Shell execution and session storage solve the execution side.

When AG-UI Is Worth It

AG-UI is a strong fit when the user benefits from seeing work unfold. That usually includes:

• coding copilots
• incident investigation tools
• analyst workbenches
• approval-heavy enterprise agents
• long-running retrieval or synthesis workflows

It is a weaker fit for simple one-shot helpers. If your assistant only answers a question and never shows intermediate work, a plain HTTP response may be simpler.

This is the key architectural question: does the user need the final answer, or do they need to understand the run in progress?

If the answer is the second one, AG-UI is usually the better interface contract.

Practical Engineering Advice

Three implementation choices matter more than the protocol itself.

First, separate presentation events from durable workflow state. A progress event is for the UI. A deployment approval record belongs in a datastore or workflow engine. Do not confuse them.

Second, keep your event vocabulary small. Teams get carried away and emit dozens of event types that no one can reason about. Start with run lifecycle, partial text, tool status, clarification request, and terminal states.

Third, instrument the runtime like infrastructure, not like a toy demo. You want metrics for active sessions, event throughput, run failures, tool latency, and reconnect behavior. The logging and dashboards in AWS CloudWatch Deep Dive are still relevant here because “the UI looks stuck” usually ends up being an observability problem.

The Main Trade-Offs

AG-UI improves the interface layer, but it does not forgive bad orchestration.

If your agent loops pointlessly, asks redundant questions, or invokes tools in a noisy way, AG-UI will expose that more clearly. That is good for honesty, but it also means the quality bar is higher. A richer protocol makes weak agent behavior easier to see.

You also need to decide whether the browser should talk directly to the runtime or through a backend-for-frontend. AWS supports SigV4 and OAuth 2.0 authentication for AG-UI workloads. In practice, many teams will still prefer a thin server-side layer so browser clients do not need to hold broad AWS-facing credentials. That is an application design choice, not a protocol limitation.

Should You Use It

If your current agent frontend relies on custom SSE event names, brittle JSON patches, and hand-rolled state sync, AG-UI is worth serious attention. AWS gave teams a cleaner contract on March 13, 2026, and the launch details are concrete enough to matter: open event-based protocol, SSE and WebSocket support, managed authentication and scaling, and deployment support across fourteen AWS Regions as of April 10, 2026.

The simplest way to think about AG-UI is this: MCP helps agents use tools, A2A helps agents talk to agents, and AG-UI helps users trust what the agent is doing while it works.