Agent UI in Blazor: Visibility and Control

The .NET team at Microsoft introduced AI components for Blazor.

Components are needed for an agentic interface.

This is what we call a screen that shows what the agent is doing right now and prompts a person before an important action.

For businesses, the release itself matters more than the components.

Models are available to everyone through APIs, so enterprise agents increasingly differ by their interfaces.

People continue working with an agent when they can see its progress and confirm irreversible steps themselves.

We regularly see one pattern in our projects.

The pilot is built as a chat: it responds confidently in the demo, but a month later only two or three enthusiasts use it.

We see three reasons, and all of them lie in the interface.

The first reason: the person does not understand what the agent did.

They received the final text but do not know which data the agent read or which systems it affected. Second: the person is afraid.

If an agent can send a customer email or change a price on its own, a cautious employee is more likely to disable it than take the risk. Third: the result can only be corrected as a whole.

The agent made one mistake in twenty fields, and the user restarts the task from scratch.

All three reasons increase TTU—the time to a useful result. Let’s take a hypothetical example.

The agent saves an employee 10 minutes on a task, while manually rechecking an opaque result takes 8 minutes.

The net saving is 2 minutes, while the risk of error remains.

A CFO would shut down such a project at the first quarterly review, and rightly so.

Blazor Server maintains a persistent connection to the browser through SignalR, so the server sends the user tokens and agent steps as soon as they appear.

The Microsoft.Extensions.AI library provides a unified `IChatClient` interface over different providers, allowing the team to switch models without rewriting screens.

We verify action confirmations on the server.

The “Approve” button is convenient for the user, but by itself it protects nothing.

The server queues a tool call with consequences and executes it only after a specific person provides signed confirmation.

We provide tools to the agent through MCP: each system (1C, PIM, EDI) publishes a limited set of operations with explicit permissions.

An LLM & Security Gateway sits between the application and the models.

It logs every request, masks personal data, and routes tasks between GigaChat, YandexGPT, and Claude based on data-storage requirements. The log shows who confirmed what and when.

These records answer the key questions raised by security teams and auditors.

This is most clearly seen in a product catalog in Akeneo or Pimcore.

The agent writes product-card descriptions, classifies items by taxonomy, and suggests facet values for filters. The content manager sees the agent’s edits for each field, approves the entire batch, or corrects individual values. Only approved content is published.

The user sees one button, but behind it are PIM integration, attribute permissions, change rollback, and an audit log. Accounting processes work the same way.

The agent prepares a document in 1C from the customer’s email and shows where it took each item from, while an accountant posts the document.