AI features in web applications are moving beyond simple chat boxes. Modern AI agents can call tools, perform multi-step tasks, stream their responses, and sometimes make decisions that should not happen without user confirmation.
That creates a UI problem for developers.
A normal chat interface is easy to build. But when an AI agent starts doing things such as creating records, sending messages, updating data, or calling external services, the user needs to see what is happening and, in some cases, approve an action before it runs.
.NET 11 introduces experimental Blazor AI components designed for this type of application. They provide building blocks for streaming AI responses, displaying tool activity, handling approval requests, and managing richer agent interactions.
This article looks at how these components can be used in a Blazor application and, more importantly, where they fit in a real AI-agent workflow.
Why AI Agent UIs Need More Than a Chat Box
A traditional chatbot usually follows a simple flow:
User
↓
Message
↓
AI Model
↓
Response
An AI agent is different.
An agent may receive a request, decide that it needs additional information, call a tool, wait for the result, perform another action, and finally return an answer.
For example, imagine an internal support application.
A user asks:
Cancel my order #12345.
The agent might need to:
Find the order.
Check whether it can be cancelled.
Calculate the refund.
Ask the user for confirmation.
Cancel the order.
Return the result.
The UI should not simply show:
Thinking...
for the entire process.
A better experience is something like:
Checking order #12345...
Order found.
Refund amount: ₹2,499
The agent wants to cancel this order.
[Approve] [Reject]
After approval:
Cancelling order...
Order cancelled successfully.
This is the type of interaction the new Blazor AI components are intended to make easier.
What Are Blazor AI Components in .NET 11?
.NET 11 introduces the experimental Microsoft.AspNetCore.Components.AI package.
It provides Blazor components and supporting types for building agent-oriented interfaces.
The package focuses on several areas:
Streaming chat responses
Rich text rendering
Tool invocation UI
Human approval workflows
Application-defined activity and progress
Shared and typed UI state
Rendering different types of AI-generated content
The package is experimental in .NET 11, so it should be treated differently from a mature, stable Blazor component library.
For production applications, evaluate the package version, API stability, and upgrade path before making it a core dependency.
How the AI UI Flow Works
The basic architecture looks like this:
Blazor UI
|
v
UIAgent
|
v
IChatClient
|
v
AI Model / Remote Agent
|
+---- Tool Call
|
+---- Approval Request
|
+---- Streaming Response
The important part is that the UI does not have to understand every low-level AI event.
The AI response can be represented as content blocks that the Blazor UI can render.
For example:
RichContentBlock
FunctionInvocationContentBlock
UIActionBlock
FunctionApprovalBlock
ActivityContentBlock
Each type represents a different kind of interaction.
That makes it possible to build a UI where text, tool calls, progress messages, and approval requests are displayed differently.
Creating the Blazor AI Application
Start with a Blazor application and add the AI components package.
The package is currently experimental, so use the appropriate prerelease version for the .NET 11 build you are targeting.
For example:
dotnet add package Microsoft.AspNetCore.Components.AI
The application also needs an AI client.
The Blazor AI components are designed to work with IChatClient, which provides a common abstraction for communicating with AI models and services.
A simplified service registration can look like this:
using Microsoft.Extensions.AI;
builder.Services.AddSingleton<IChatClient>(chatClient);
The actual IChatClient implementation depends on the AI provider or agent architecture used by your application.
This separation is useful because the Blazor UI does not need to be tightly coupled to a particular model provider.
Building a Streaming AI Chat UI
One of the most useful features is streaming.
Without streaming, the user may submit a prompt and wait until the complete response is generated.
For a long response, that can feel slow.
With streaming, the application can start showing content as it arrives.
For example:
User:
Explain dependency injection in ASP.NET Core.
AI:
Dependency injection is a design pattern...
ASP.NET Core provides...
Services can be registered...
The text appears progressively rather than waiting for the complete answer.
The Blazor AI components can map streamed response content into UI-facing content blocks.
A simplified page might look like this:
@page "/chat"
<ChatPage Agent="agent" />
For more control, you can customize how individual blocks are rendered.
For example:
<ChatPage Agent="agent">
<MessageListContent>
<BlockRenderer TBlock="RichContentBlock" Context="block">
<div class="agent-response">
@block.RawText
</div>
</BlockRenderer>
</MessageListContent>
</ChatPage>
This approach is useful when the default rendering does not match your application's design.
You can add your own CSS, loading indicators, markdown renderer, typography, or other UI behavior without replacing the complete agent pipeline.
Why Streaming Matters for AI Agents
Streaming is not only about making chat feel faster.
It becomes more important when the agent performs longer operations.
Consider an agent that searches several systems.
Instead of displaying nothing for 10 seconds, the UI can communicate progress:
Searching customer records...
Checking recent orders...
Looking up shipping information...
Preparing response...
The user gets feedback while the operation is running.
This reduces the feeling that the application has stopped responding.
However, streaming should not be confused with actual progress reporting.
A streamed text response tells you what the model is generating. It does not automatically mean that every sentence represents real application progress.
For important operations, application-defined activity events are a better approach.
Displaying Agent Activity
AI agents often perform work that users cannot see directly.
For example:
Agent
├── Search database
├── Call shipping API
├── Check refund policy
└── Generate response
The UI can represent this work with activity blocks.
A custom renderer can display application-defined activity:
<BlockRenderer TBlock="ActivityContentBlock" Context="activity">
<div class="agent-activity">
<span>@activity.Title</span>
</div>
</BlockRenderer>
The exact presentation depends on the application.
A customer-support system might show a simple progress indicator.
An internal developer tool could show a detailed activity timeline.
The important design rule is to show useful information without exposing unnecessary internal model details.
Human Approval Before Tool Execution
This is one of the most important features for agentic applications.
AI agents can call tools.
Some tools are harmless:
SearchDocumentation()
GetWeather()
FindProduct()
Others have side effects:
DeleteUser()
SendEmail()
CreatePayment()
CancelOrder()
UpdateDatabase()
The second group should often require explicit user approval.
The Blazor AI components provide FunctionApprovalBlock for this type of interaction.
A simplified renderer could look like this:
<BlockRenderer TBlock="FunctionApprovalBlock" Context="approval">
<div class="approval-card">
<p>
Allow <strong>@approval.ToolName</strong> to run?
</p>
<button @onclick="approval.Approve">
Approve
</button>
<button @onclick="approval.Reject">
Reject
</button>
</div>
</BlockRenderer>
The agent can pause while waiting for the user's decision.
That creates a much safer interaction model than allowing every tool call to execute automatically.
Example: Approving an Order Cancellation
Suppose an AI agent has access to this tool:
public async Task CancelOrderAsync(string orderId)
{
// Cancel order
}
The user says:
Cancel order 12345.
The agent determines that the cancellation tool is required.
Instead of immediately executing it, the application displays:
The agent wants to cancel order 12345.
Refund: ₹2,499
Do you want to continue?
[Approve] [Reject]
If the user clicks Approve:
approval.Approve()
the workflow continues.
If the user clicks Reject:
approval.Reject()
the tool call does not proceed.
This pattern is especially useful for operations involving money, data deletion, account changes, external communication, or other irreversible actions.
Keep Approval Logic on the Server
The UI should not be responsible for deciding whether a dangerous operation requires approval.
For example, this is not a good security model:
if (toolName == "DeleteUser")
{
// Show approval button
}
A malicious or modified client should not be able to bypass the server's policy.
The server or agent configuration should determine which tools require approval.
The UI's job is to display the request and send the user's decision back.
The final authorization should remain server-side.
This separation is important:
Server
↓
Decides approval is required
Blazor UI
↓
Displays approval request
User
↓
Approves or rejects
Server
↓
Continues or stops the operation
Connecting a Remote AI Agent
Not every AI agent needs to run inside the Blazor application.
A common architecture is:
Blazor Application
|
| HTTP / SSE
v
Remote Agent
|
v
AI Model + Tools
For this type of architecture, the .NET ecosystem supports AG-UI integration.
AG-UI allows agent events such as streamed responses, tool calls, approval requests, and state changes to travel between the agent and the UI.
A client can use AGUIChatClient to connect the Blazor application to a remote agent.
A simplified registration looks like:
using AGUI.Client;
using Microsoft.Extensions.AI;
builder.Services.AddHttpClient<IChatClient>(httpClient =>
new AGUIChatClient(
new(httpClient, "https://agent.example.com")));
The actual endpoint and authentication strategy will depend on the application.
This architecture is useful when the agent needs access to backend services that should never be exposed directly to the browser.
Why AG-UI Can Be Useful
A basic chatbot only needs messages.
An agentic application needs more information.
For example:
Text response
Tool invocation
Tool result
Approval request
Approval response
State update
Progress event
Conversation identifier
A protocol such as AG-UI provides a structured way to exchange these events.
That becomes particularly useful when the frontend and agent are separate applications.
For example:
Blazor Web App
|
| AG-UI
|
v
Agent Service
|
+---- Database
|
+---- APIs
|
+---- Internal Tools
|
+---- AI Model
The browser remains focused on presentation while the backend owns the agent's capabilities and security boundaries.
Customizing Content Blocks
One useful aspect of the component model is that you are not locked into one UI.
For example, a tool invocation could be rendered as:
Calling SearchOrders...
or as a detailed card:
Tool
SearchOrders
Customer
John Smith
Status
Searching...
A custom renderer can control the experience.
For example:
<BlockRenderer TBlock="FunctionInvocationContentBlock"
Context="block">
<div class="tool-card">
<strong>@block.FunctionName</strong>
<span>Running...</span>
</div>
</BlockRenderer>
This is helpful for applications where the AI experience needs to match an existing design system.
Streaming Does Not Mean Showing Everything
One mistake developers can make is exposing every internal agent event to the user.
That usually creates a noisy interface.
For example, users generally do not need to see:
Token received
Token received
Function state changed
Internal executor updated
Message fragment received
Instead, convert technical events into useful UI states:
Searching orders...
Checking refund policy...
Waiting for approval...
Processing refund...
Completed.
The goal is not to expose the agent's internals.
The goal is to help the user understand what the application is doing.
Handling Errors During Agent Execution
Agent workflows can fail.
A tool might time out.
An external API may return an error.
The AI provider may become unavailable.
The UI should handle these cases explicitly.
For example:
Unable to complete the request.
The shipping service did not respond.
[Try Again]
Avoid displaying raw exception messages to users.
Instead, log the technical exception on the server and provide a useful message in the UI.
For example:
try
{
await agent.RunAsync();
}
catch (HttpRequestException ex)
{
logger.LogError(ex, "Shipping service request failed.");
// Show a user-friendly error state
}
This becomes even more important when the agent has multiple tools.
Security Considerations
Agentic UI introduces a few security concerns that normal chat applications may not have.
Validate Every Tool
Do not assume that a tool call is safe because the model requested it.
Validate:
User permissions
Input parameters
Resource ownership
Business rules
Operation limits
For example:
if (!user.CanCancelOrder(orderId))
{
throw new UnauthorizedAccessException();
}
Protect Sensitive Tools
High-impact operations should require stronger controls.
Examples include:
Deleting records
Sending external messages
Processing payments
Changing account permissions
Modifying production data
Approval is useful, but it should not replace authorization.
Do Not Trust Model Output
An AI model is not a security boundary.
Never use model-generated text as proof that an operation is allowed.
The application must enforce the rules.
When Should You Use Blazor AI Components?
They make the most sense when your application has an actual agent-style workflow.
Good use cases include:
Customer Support Agents
The agent can search customer records, inspect orders, and ask for approval before making changes.
Internal Business Applications
Employees can use an agent to perform repetitive operations while keeping sensitive actions behind approval steps.
Developer Tools
A coding assistant can show tool activity, file operations, test execution, and approval prompts.
Workflow Applications
An agent can perform several steps while the user watches progress and approves important actions.
For a simple FAQ chatbot, these components may be more than you need.
Common Mistakes to Avoid
Automatically Approving Every Tool
If every tool is automatically approved, the approval UI does not provide any real protection.
Putting Security Rules in the UI
The browser should not decide whether an operation is authorized.
Showing Raw Agent Events
Technical event streams can quickly make the interface confusing.
Treating Streaming as Progress
Generated text is not necessarily real application progress.
Building Around Experimental APIs Without a Plan
The Blazor AI components in .NET 11 are experimental. Keep that in mind when designing long-lived production systems.
Giving Agents Too Many Tools
An agent with unrestricted access to dozens of powerful tools becomes harder to secure and troubleshoot.
Start with the smallest useful toolset.
A Practical Architecture
A production-oriented application can separate responsibilities like this:
┌─────────────────────┐
│ Blazor UI │
│ │
│ Chat │
│ Activity │
│ Approval │
└──────────┬──────────┘
│
AG-UI
│
v
┌─────────────────────┐
│ Agent Service │
│ │
│ Agent orchestration │
│ Approval policy │
│ Session state │
└──────────┬──────────┘
│
┌────────────────┼────────────────┐
│ │ │
v v v
AI Model Tools Database
This structure keeps the browser responsible for interaction while the backend remains responsible for business logic and security.
It also makes the system easier to test.
Production Checklist
Before deploying an AI-powered Blazor application, check the following:
Use server-side authorization for every sensitive tool.
Require approval for consequential operations.
Validate all tool parameters.
Keep secrets out of the browser.
Add timeout handling for external tools.
Log important agent actions.
Avoid exposing sensitive internal reasoning.
Provide clear progress states.
Handle rejected approvals cleanly.
Handle interrupted or failed agent runs.
Keep AI and tool permissions as small as possible.
Test the application when the model returns unexpected tool arguments.
Evaluate the stability of experimental .NET 11 AI APIs before committing to them.
Summary
Blazor .NET 11's AI components are aimed at a problem that simple chat components do not solve well: building user interfaces for AI agents that actually perform work.
The important pieces are streaming responses, activity updates, tool rendering, and human approval. Together, they allow a Blazor application to show what an agent is doing instead of treating the entire workflow as one black box.
The approval flow is especially useful for sensitive operations. An agent can request permission before performing an action, the user can approve or reject it, and the server can continue or stop the workflow.
For larger applications, a remote agent architecture using AG-UI can separate the Blazor frontend from the agent and its tools.
The technology is still experimental in .NET 11, so it is worth testing carefully before using it as a major production dependency. But the direction is useful: instead of building every AI interaction from scratch, Blazor developers get components that understand streaming responses, tool calls, activity, and human-in-the-loop workflows.
Join the conversation! Your thoughts help the community grow.