Front-end is the hardest part of Agentic AI. Nobody talks about this.

The part everyone skips in the demo

Every agentic AI demo follows the same shape: type a request, watch a spinner, get a clean answer. What it never shows is the other 80% of real usage — the agent that picks the wrong tool, the response that arrives out of order, the step that needs the user to confirm something before it can continue.

That 80% is a front-end problem, and almost nobody is writing about it.

Nondeterminism is a UI problem, not just a backend one

Traditional front-end engineering assumes a request has a shape you can type. An agentic backend doesn't give you that guarantee — the same input can produce a different sequence of steps, a different number of tool calls, or a response that changes structure depending on what the agent decided to do.

You can't build a loading spinner for a process that doesn't know its own step count.

That single sentence broke more of my initial designs than any backend issue did. I had to stop designing for "loading → done" and start designing for a stream of heterogeneous events that the UI has to interpret live.

Three things I had to unlearn

• Optimistic UI stops working. You can't optimistically render the result of an action you haven't seen yet, because you don't know what shape it'll take.
• Error boundaries aren't enough. A single malformed tool call shouldn't crash the whole conversation view — partial failure has to be a first-class UI state, not an exception path.
• "Cancel" is genuinely hard. Canceling a multi-step agent mid-flight means the UI has to reconcile with backend state that may have already partially executed — you can't just abort a fetch and pretend nothing happened.

What actually helped

Treating every agent response as an event stream instead of a request/response pair, and building the UI around a small set of event types (step, tool_call, tool_result, message, error) that every view knows how to render, regardless of which agent produced them. It's less elegant than a typed response model, and it's the only approach that survived contact with a real multi-agent backend.

Why this matters for your career, not just your codebase

If you're a front-end engineer waiting for the "AI stuff" to be a backend team's problem, it won't stay that way. The teams shipping agentic products well are the ones where front-end engineers understood the nondeterminism early enough to design for it — not the ones who bolted a chat widget onto an existing app.