The UI Primitives AI Agents Actually Need

Component libraries were built for CRUD. A user clicks, the system responds, the state changes, the screen settles. Every primitive we have assumes discrete actions, synchronous responses, and static state.

An agent does none of that. It takes twenty sequential steps. It pauses to ask a person something. It streams a partial answer and then revises it. It forks into parallel sub-tasks that finish out of order. It uses a tool you did not know it would reach for. There is no button in any design system for that, which is why so many enterprise agent interfaces are a chat window bolted onto software that deserved better.

Five primitives that keep earning their place

Across enterprise agent work the same small set recurs, independent of model or framework.

Planning visibility. Before execution, show the intended sequence. Not a spinner and not a paragraph of reasoning, a list of steps the user can read in three seconds and interrupt. This is the highest-value primitive in the set, because it converts a black box into something a user can supervise, and supervision is the whole basis of delegating work.

Tool-use disclosure. When the agent queries a database, calls an API, or reads a document, say so inline, at the moment it happens. An accountable user has to be able to reconstruct where an answer came from. Without this, every output is a claim they have to take on faith, and professionals do not build workflows on faith.

Memory surfacing. Agents carry context across turns and sessions. The user needs to see what the system currently believes about them and their work, and be able to correct it. Invisible memory is the fastest route to an agent that is confidently wrong in a way nobody can debug.

Multi-step progress. Long-running, branching work needs a representation that survives the user closing the tab. Which step is running, which are queued, which failed, and what the failure means. A progress bar is a lie about a process that is not linear.

Recovery routing. When the agent cannot proceed, where does the work go? Back to the user with a specific question, to a human colleague, or to a narrower version of the task it can complete? An agent that simply stops has handed the user a mess with no path out of it.

The interface is now generated, which is a design problem

The move that changes the most is generative UI: the agent returning actual interactive components at runtime, a form, a chart, a comparison table, a map, a confirmation step, rather than prose describing what you might do next.

This is straightforwardly better than chat for enterprise work. A user asked to approve three invoices wants three rows with amounts and an approve control, not a paragraph asking them to confirm. Frameworks now support it directly, with streamed reasoning, human-in-the-loop interrupts, thread persistence and multi-agent attribution as first-class concerns.

It also relocates a large design responsibility. If the agent chooses the component, then your component library is no longer a set of options a designer picks from. It is the vocabulary a runtime system composes with, unsupervised, in front of a customer.

That has consequences worth planning for. The set must be small enough that the model picks well and consistently. Each component has to be safe in any context, because you cannot review every arrangement. Every component needs a defined empty, loading, error and partial state, since the agent will produce all of them. And the accessibility has to live inside the component, because there is no design review between generation and the user.

A generative UI is only ever as good as the primitives it is allowed to reach for.

Where the pause belongs

The recurring argument on every agent project is how much autonomy to grant, and it is usually framed as a setting to expose. It is not a setting. It is a design decision, and it is made per action.

Calibrate to consequence and reversibility. An action that is low-stakes and undoable should run without asking and report afterwards. An action that moves money, submits a filing, sends an external communication, or deletes something should stop and wait for a person. The rule of thumb that holds up: a well-designed agent asks permission exactly where a competent new colleague would, and nowhere else.

Get this wrong in one direction and you have rebuilt the manual process with extra latency. Get it wrong in the other and the first surprising action ends the relationship permanently. In regulated industries the checkpoint is not negotiable, and the design work is deciding precisely where it sits rather than whether it exists.

Start from the failure, not the demo

The demo is the easy 20%. The agent understands, acts, succeeds, everyone applauds.

The other 80% is what the product actually is. The step that half-completed. The tool that timed out. The ambiguous instruction the agent interpreted reasonably and wrongly. The action taken while the user was in a meeting. Design those states first and the successful path falls out of them almost for free. Design the demo first and you will be retrofitting recovery into a system with nowhere to put it.

The primitives above exist because those states exist. Build them into the component library rather than into one feature, and the next agent your organisation ships starts from a foundation instead of a chat box.

We design agent interfaces for products that operate under audit. If that is what you are building, we should talk.