Agentic UI: When AI Stops Talking and Starts Doing

For the last decade, nearly every AI interface has looked the same. You type. It replies. A tennis match — back and forth, one volley at a time. The user is always serving.

Something is shifting. We're watching AI move from talking about doing things to actually doing them. Filling forms. Clicking buttons. Navigating views. Calling APIs. Acting on your behalf.

This is the move from conversational to agentic — and it changes everything about how we design frontends.

The old world and the new

A conversational interface is a canvas: the user paints every stroke. An agentic interface is a stage: the user sets the scene, and the AI performs.

On the left, a user asks a question. The AI answers. Nothing on the page moves. On the right, the user expresses an intent — "Book me a flight to Tokyo" — and the AI goes to work.

That loop — observe, plan, act, report — is the heartbeat of an agentic interface.

The three layers

Every agentic interface needs three clean layers. Mix them and you get bugs. Separate them and you get something testable, safe, and extensible.

The diagram below shows how those three layers connect: the LLM reasons and emits structured tool calls, the tool layer validates and executes them, and only the UI layer ever touches the DOM.

The reasoning layer is the LLM itself. It receives context and produces a plan: a sequence of tool calls. It should never touch the DOM directly.

The tool layer is the API boundary. Each tool is a function with a typed schema and an implementation. This is where you enforce safety: validation, permissions, rate limiting.

The UI layer is React, Vue, or vanilla DOM. It consumes state changes from tool execution and surfaces the agent's activity to the user.

The agent loop

Two safety gates before any tool runs. First: did the user hit Stop? Second: does this tool need confirmation?

Both gates feed into the same principle: scrutability — the user's ability to see, at any moment, exactly what the agent is about to do, what it just did, and why. Every tool call is logged. Every state change is rendered. Nothing happens off-screen.

The core loop in code

for (const action of plan) {
  if (abortSignal.aborted) break;

  const tool = tools[action.tool];

  if (tool.requiresConfirmation) {
    const approved = await requestUserApproval(action);
    if (!approved) continue;
  }

  addLog({ tool: action.tool, status: 'executing' });

  try {
    const result = await tool.execute(action.args);
    addLog({ tool: action.tool, status: 'complete', result });
  } catch (error) {
    addLog({ tool: action.tool, status: 'error', result: String(error) });
  }
}

Tools should update state, not the DOM

This is the single most important implementation detail.

const createTools = (dispatch: React.Dispatch<Action>) => ({
  updateField: {
    schema: { fieldName: 'string', value: 'string' },
    requiresConfirmation: false,
    execute: ({ fieldName, value }) => {
      dispatch({ type: 'SET_FIELD', fieldName, value });
    }
  },
  submitSearch: {
    schema: {},
    requiresConfirmation: true,
    execute: () => dispatch({ type: 'SUBMIT' })
  }
});

Failure and security are part of the design

Two concerns that often get bolted on at the end deserve to live inside the tool layer from day one.

Graceful failure means every tool validates its preconditions before execution and degrades to a manual path when something goes wrong. If submitForm fires against a field that no longer exists, the tool should report a structured error and surface it in the activity log — not silently fail or, worse, throw and crash the agent loop. The user should always be able to take over.

Security lives at the schema boundary. Tool inputs are whitelisted, never free-form. Field references use semantic identifiers (email_field) rather than CSS selectors or DOM paths the LLM could be tricked into constructing. Any tool that can read sensitive state or write to a backend should require explicit confirmation — no exceptions.

The summary

Where to start

Don't try to make your whole app agentic. Pick one multi-step workflow that users already complain is tedious. Good first candidates look like this:

• A multi-field form users dread filling out — invoice creation, expense reports, shipment intake. Three to four tools (updateField, submitForm, validateRequired) get you to a working prototype.
• A search-then-filter flow — "find me all open tickets from last week assigned to the design team and tagged urgent." The agent translates intent into a chain of filter applications you can already do by hand.
• A guided onboarding or migration — moving data between systems, configuring a new project, walking through a checklist. The agent narrates each step and waits for confirmation on writes.

Build the three layers from the start, even if your tool layer only has two tools. Wire up the activity log on day one — scrutability is the feature that earns trust, and retrofitting it later is painful. Gate every write behind confirmation until you've watched real users use it for a week. Then loosen the gates one tool at a time.

The era of AI that talks is giving way to AI that acts. And the frontends that will survive the transition aren't the ones with the cleverest prompts — they're the ones with a tool layer their LLM can't escape, an activity log their users can't lose track of, and a UI layer that still owns every pixel on the page. Build those three things first, and the agentic interface will feel inevitable. Skip them, and you'll spend the next two years bolting safety onto something that should have had it from the start.