AI Agents Are Only Half the Product: Building User-Facing Agentic Applications with AG-UI

Aug 24, 202611 min read

Hi everyone. It has been a while.

This is my first article of the year, which feels slightly strange to write out loud. The year has been moving quickly, and I have mostly been busy building, shipping, and spending a lot of time with AG-UI in a live production environment.

After working with it for a while, I wanted to share what stood out to me — not as a tour of the protocol documentation, but from the user-facing side.

When we talk about agents, we often focus on what happens behind the scenes: model reasoning, tool calls, retrieved data, and workflow execution.

That is all important.

But from the user's perspective, there is usually one simple question:

"What is happening right now?"

If the answer is only a spinner, we have probably left a lot of the experience on the table.

A spinner is a bit like putting a "trust me" sign on a locked door. It tells you that something may be happening, but not whether the system is making progress, looking for the right key, or has quietly gone for lunch.

That is the problem I want to explore here.

AI agents are only half the product

AI agents are getting very good at doing things.

They can call tools, query databases, reason through tasks, interact with APIs, and execute workflows with surprisingly little human intervention.

But there is a problem we do not talk about enough:

The agent is only half the product.

An agent can do all the thinking in the world, but eventually a human needs to understand what happened.

What tool did it call?

What did it find?

Did the application state change?

Is it still working?

Does it need approval?

Did it finish successfully?

Building an agent is therefore not only an AI problem.

It is also an application architecture problem.

This is where AG-UI, the Agent-User Interaction Protocol, becomes interesting.

From APIs to agentic applications

Let us start with something familiar.

A traditional application usually looks something like this:

Traditional request-response architecture

You click something.

The application makes a request.

The server processes it.

You receive a response.

Simple.

The request may take a few milliseconds or a few seconds, but the basic mental model remains the same:

send something, wait, and receive something.

For the examples throughout this article, I'll be using an automobile logistics product, Dockie, as our running example.

Now imagine asking an agent:

"Find all delayed shipments, determine which ones are likely to miss their delivery window, and prepare notifications for the affected customers."

That is no longer one request.

The agent might:

Start
  ↓
Query shipments
  ↓
Call tracking service
  ↓
Analyze delivery risk
  ↓
Update application state
  ↓
Generate notifications
  ↓
Ask for approval
  ↓
Finish

There are multiple things happening between the question and the final answer.

Yet if we treat the agent like a normal API, the UI might still show, perhaps:

Loading…

For a few seconds.

Very informative.

The difference is not merely that the agent takes longer.

The difference is that an agentic workflow produces meaningful intermediate activity.

A user-facing application needs a way to receive that activity and decide how it should appear.

In a traditional request-response flow, the final response is often the main event.

In an agentic flow, the journey is part of the product.

So what is AG-UI?

AG-UI stands for Agent-User Interaction Protocol.

At its core, it is an open, lightweight, event-based protocol for connecting AI agents with user-facing applications.

The important word here is:

events.

Instead of thinking:

Request → Response

we can think:

Request
   ↓
Event
   ↓
Event
   ↓
Event
   ↓
Event
   ↓
Done

The application can react to what is happening while the agent is running, rather than waiting for the entire operation to finish.

AG-UI defines standardized events for agent lifecycle updates, text messages, tool calls, and state changes. Its event model gives the client a structured way to understand what is happening during a run.

That may sound like a small distinction.

It is not.

The difference between "here is the final answer" and "here is what is happening as the answer is being produced" is the difference between watching a progress bar and receiving a useful explanation.

Why events matter

Imagine an agent investigating a shipment.

It could communicate something like:

RUN_STARTED

TOOL_CALL_START
getShipmentStatus()

TOOL_CALL_RESULT

STATE_DELTA

TEXT_MESSAGE_CONTENT
"I found that your shipment is currently in transit."

RUN_FINISHED

The user does not necessarily need to see those raw events.

Most users probably do not want to read a protocol trace while waiting for a delivery update. That would be a little like opening the hood of a car every time you wanted to know whether you were moving.

Instead, the application can turn those events into something useful:

Agent activity translated into a user interface

┌──────────────────────────────────┐
│ Shipment Assistant               │
│                                  │
│ ✓ Checking shipment status       │
│ ✓ Tracking information received  │
│                                  │
│ Shipment: SHP-20240              │
│ Status: In transit               │
│ ETA: August 28                   │
└──────────────────────────────────┘

That is the important part.

AG-UI is not the interface.

It is the communication layer that allows the application to build the interface around what the agent is actually doing.

The protocol can support streamed text, tool-call visibility, lifecycle indicators, state synchronization, and user interaction without forcing every application to invent its own event format.

The application still decides what the user should see.

A tool call might become a small status indicator.

A state update might refresh a recommendation card.

A request for approval might become a button.

A long-running workflow might become a progress timeline.

The protocol provides the signals. The product decides how to translate them into an experience.

And this is where things get interesting

One of the easiest mistakes to make is to think AG-UI is simply "streaming AI responses."

It is not.

Text streaming is only one piece.

An agent can also:

call tools,
update state,
start and finish runs,
send structured information,
interact with application state,
and involve the user in the middle of a workflow.

That changes the relationship between the agent and the application.

The agent is not simply returning data anymore.

It is participating in the application.

This is also why AG-UI is different from a conventional chat-completion stream.

A chat stream primarily communicates generated content.

An agentic application needs to communicate both content and behavior:

What is the agent doing?

What changed?

What can the user do next?

That distinction becomes especially important when the agent is not operating in a standalone chat window.

The response is no longer just a message.

It may be a status update, a card, a form, a confirmation request, or a change in application state.

AG-UI, MCP and A2A are not the same thing

If you have been following agentic architecture, you have probably encountered MCP, A2A, and AG-UI.

And yes, the AI ecosystem has apparently decided that every important protocol must have three letters.

At this point, I would not be surprised if the next one were called UXR lol.

But they solve different problems.

A simplified mental model is:

                AI Agent
                    │
        ┌───────────┼───────────┐
        │           │           │
       MCP         A2A        AG-UI
        │           │           │
      Tools      Agents       Users
      /Data      /Agents    /Applications

MCP helps agents interact with tools and external data.

A2A focuses on communication between agents.

AG-UI focuses on communication between agents and user-facing applications.

They can therefore complement each other rather than compete.

A useful way to think about the relationship is:

MCP connects an agent to capabilities and context.
A2A connects one agent to another.
AG-UI connects agent activity to the application and the person using it.

For example, an agent might use MCP to access a shipment tracking system, use A2A to delegate a specialized analysis to another agent, and use AG-UI to communicate progress and results to the application.

Each protocol has a different job.

That separation matters because it prevents one protocol from becoming responsible for every part of the system.

The agent can access tools, collaborate with other agents, and communicate with the user-facing application without forcing all three concerns into one custom integration.

The Agentic Protocol Stack

This is not the only possible architecture, but it is a useful mental model.

MCP is about what the agent can access.

A2A is about who the agent can collaborate with.

AG-UI is about how the agent's work becomes visible and actionable in the application.

The bigger idea

The interesting thing about AG-UI is not that it gives us another way to stream text.

It is that it gives agents and applications a shared language for interaction.

Instead of the application guessing what:

{
  "status": "doing_something"
}

means, it can respond to structured events representing things like:

run started
tool called
state changed
message streamed
run finished

That creates a cleaner boundary between the agent and the application.

The agent can focus on doing the work.

The application can focus on turning that work into an experience.

This boundary also makes the system easier to reason about.

The UI can render progress, expose tool activity selectively, update local state, request confirmation, and handle failures without needing to understand every internal detail of the agent's reasoning.

The future is not just better agents

I think this is the part that gets overlooked.

We are spending a lot of time asking:

"How capable can we make our agents?"

But there is another question:

"How should humans experience those capabilities?"

Because a production agent is not just a model with tools.

It is a system that interacts with people.

Sometimes it needs to explain what it is doing.

Sometimes it needs to ask permission.

Sometimes it needs to update application state.

Sometimes it needs to recover from failure.

And sometimes it just needs to tell you:

"I do not know."

That last answer may not sound very impressive, but it is often more useful than an agent confidently doing the wrong thing while the UI displays a cheerful loading animation.

I strongly believe the better our agents become at taking action, the more important their relationship with the application — and ultimately the user — becomes.

That is honestly one of the reasons why I find AG-UI interesting.

AI agents are only half the product.

The other half is everything that lets humans understand, control, and interact with what those agents are doing.

And that is where agentic application engineering gets really interesting.

One question to leave you with

If an AI agent can already think, call tools, modify state, and take action…

What should the user actually see while all of that is happening?

That, more than anything, is the problem AG-UI is trying to help us solve.