In a conversation with Michael Dowden, Google Developer Expert and Angular specialist Manfred Steyer discusses how agentic applications can be designed without sacrificing architectural clarity, safety, or user control. A central idea is that chat should not automatically be considered the default interface for AI-powered applications.

A Chatbot Is Not the End Goal

Many AI applications currently follow the same interaction pattern: a user enters a prompt, a large language model processes it, and the application returns a text response.

Note: This video was generated using AI, adapting the original content and technical insights created by the author of the blog post.

That pattern works well when users primarily need information. It becomes less effective when an AI system is expected to perform tasks.

An agent may need to analyze data, trigger workflows, use external tools, prepare a dashboard, or execute a sequence of actions. In these situations, forcing every interaction through a conversational interface can make the experience unnecessarily complicated.

The important distinction is not whether an application includes a chat box. It is whether the system understands the user’s goal and can select the appropriate interaction model.

An agentic interface might therefore:

• assemble a dashboard,
• visualize relevant information,
• display interactive controls,
• prepare the next step in a workflow,
• or collaborate with the user across several stages of a task.

The user interface does not disappear. Instead, it becomes an increasingly important part of how the agent communicates its state and results.

From Text Responses to Dynamic Interfaces

Text is not always the best way to communicate information.

If a user wants to compare datasets, a table may communicate the result more effectively than several paragraphs. If parameters need to be adjusted, sliders, input fields, or selection controls may provide a better interaction model.

The same applies to complex collections of metrics. A dynamically assembled dashboard can often provide more context than a purely conversational response.

This leads toward generative or adaptive user interfaces: interfaces that can change at runtime depending on the user’s goal, the available data, and the current state of the task.

However, dynamic interfaces also create an architectural problem. If the frontend communicates directly with one particular AI framework, backend implementation, or LLM provider, the user interface can become tightly coupled to technologies that may change quickly.

Open standards such as AG-UI and A2UI are intended to address this separation.

What Is AG-UI?

AG-UI provides a standardized communication layer between an AI agent and the frontend.

Its primary architectural benefit is decoupling.

The frontend should not need to understand which agent framework, backend technology, or large language model is operating behind the application. Instead, the frontend and the agent communicate through defined messages and events.

These interactions can represent activities such as:

• starting or completing an agent run,
• streaming text,
• invoking tools,
• reporting state changes,
• returning action results,
• or emitting events that require a frontend response.

This separation makes it possible to change the technology behind an agent without rebuilding the entire user interface.

That is particularly relevant for enterprise applications because the AI ecosystem is evolving rapidly. An architecture that is tightly coupled to a specific provider or agent framework can quickly become difficult to maintain. AG-UI establishes a clearer boundary between the agent layer and the application interface.

What Is A2UI?

AG-UI addresses communication between agents and applications. A2UI addresses a related challenge: how an agent can request an appropriate user interface.

Instead of allowing a language model to generate arbitrary HTML or JavaScript, the agent can produce a structured description of the interface it needs.

The frontend can then map that description to components that already exist within the application’s design system.

For example, an agent might determine that a user’s request is better represented as a dashboard rather than a paragraph of text. It can describe the required structure and data, while the frontend remains responsible for rendering approved components.

This provides an important balance.

The AI gains the flexibility to select an appropriate interface, but the application still controls which components exist and how they behave. The model operates within predefined boundaries instead of receiving unrestricted control over frontend code.

AI Agent Autonomy Needs Clear Boundaries

The more actions an agent can perform, the more important safety becomes.

A text-generating model has comparatively limited direct impact. An agent that can invoke tools, modify data, or initiate business processes can have consequences beyond the conversation itself.

For this reason, relying exclusively on model-level guardrails is not enough.

A stronger architectural approach is to place deterministic boundaries around a non-deterministic system.

The application should define which tools and actions are available to the agent and under which conditions they can be used. The agent can operate flexibly within those constraints, but it should not receive unrestricted access to the underlying system.

In this model, software architecture itself becomes part of the safety mechanism.

Human-in-the-Loop Does Not Mean Confirming Every Action

Human-in-the-loop patterns are often associated with confirmation dialogs.

An agent proposes an action, the application asks whether the user is sure, and the user confirms or rejects it.

That approach becomes impractical for longer agentic workflows. Requiring approval for every intermediate decision removes much of the benefit of delegating work to an autonomous agent.

A more useful model is to provide visibility and meaningful opportunities for intervention.

For example, an interface can use action cards to show what an agent is doing or has already done. Instead of requiring prior approval for every action, the application might offer an undo mechanism.

Users should also have an obvious way to stop an agent when a workflow appears to be moving in the wrong direction.

Human oversight therefore becomes less about continuous approval and more about transparency, intervention, and recovery.

Why Agentic Applications Need Continuous Feedback

A long-running agent should not leave the user looking at a loading indicator without any indication of what is happening.

During a complex task, users need enough information to understand whether the system is still working, what major actions have occurred, and whether intervention is possible.

This does not mean exposing every internal reasoning step produced by an AI model. The interface should instead communicate meaningful application-level activity.

For example, users may need to know:

• what the agent is currently doing,
• whether an action has changed data,
• what stage the workflow has reached,
• and whether they can stop or modify the process.

Feedback is therefore not merely a cosmetic UX feature. It is an essential part of creating understandable and trustworthy agentic systems.

Feedback Loops Instead of a Black Box

Agentic applications differ from conventional software because their behavior is not completely predetermined.

Traditional application logic is largely deterministic: known inputs and states should produce predictable outcomes. Large language models are probabilistic.

That does not mean the entire application has to become unpredictable.

Reliable software architecture can surround probabilistic AI behavior with deterministic rules, interfaces, and constraints.

Feedback loops are a central part of this model.

An agent performs an action, receives the resulting state, evaluates that result, and decides what to do next. At the same time, the application and the user can verify that the workflow continues to operate within the permitted boundaries.

The interaction therefore becomes an iterative cycle of goal, action, result, and adjustment rather than a single request followed by a single response.

How Should Agentic UIs Be Tested?

Agentic applications also require a different testing strategy.

Testing for an exact text response from an LLM is often fragile because the underlying model may produce different but equally valid outputs.

The more useful question is whether the application behaves correctly.

Developers can test questions such as:

• Can the agent access the intended function?
• Does the application render the correct component?
• Can the user interact with the generated interface?
• Does the agent remain inside the defined architectural boundaries?

Steyer therefore highlights black-box testing at the component level. The focus is placed on observable application behavior rather than internal implementation details or identical model responses.

For Angular applications, Vitest is also relevant to this testing approach.

The model itself does not have to produce deterministic text. The application’s rules, boundaries, and observable outcomes should remain testable.

Agentic UI Changes the Role of the Frontend

Agentic AI is not exclusively a backend concern.

As soon as agents interact directly with users, the frontend becomes part of the agentic architecture.

It has to represent state, render dynamic components, display tool results, communicate agent activity, provide intervention mechanisms, and return user feedback to the agent.

At the same time, the frontend should remain separated from the implementation details of the agent backend.

Standards such as AG-UI provide a communication boundary, while approaches such as A2UI offer a structured way to describe dynamic user interfaces.

The result is not software in which AI replaces the frontend. Instead, AI agents, conventional application logic, and user interfaces each take responsibility for the tasks they are best suited to perform.

The Goal Is Not More AI in the Interface, It Is a Better Interface

The larger product question is not how to add an AI chat box to every application.

Developers instead need to determine where natural-language interaction is useful and where structured interfaces provide a better experience.

That requires answering architectural and product questions such as:

• Where should natural language be used?
• Where does the user need a structured interface?
• Which decisions can an agent make autonomously?
• When should a user be able to intervene?
• How can the frontend remain independent from the agent implementation?
• How can a probabilistic AI system be integrated into a reliable application?

Some of the most interesting AI-native applications may therefore emerge precisely where the traditional chatbot interaction ends.

Agentic UI is not simply about placing AI inside an existing interface. It requires developers to reconsider how people, software, and autonomous agents collaborate to complete tasks.