Most “AI assistants” are eloquent narrators. They tell you what they could do, ask whether you’d like them to proceed, and describe the steps they’re about to take. That’s the default template for AI product design right now, and I think it’s backwards. Building ROCCO at Tessa, we gave our agent a narrower job, and it’s the whole of our approach to agentic UX: do the thing, then tell you what it did.
This is a contrarian take on a crowded field. Most AI agent design in 2026 optimizes for how well the assistant explains itself. We optimize for whether it actually moved something.
The contrarian rule: if it can only talk, it doesn’t exist
A small, concrete example. ROCCO doesn’t say, “I can rebalance these routes for you — shall I begin by analyzing the current distribution and identifying imbalances…” It calls the tool, rebalances the routes, and reports the result with an undo button sitting right there. The conversation is where an action gets triggered and the outcome gets explained in plain language. It is not a stage where the agent performs its own competence for you.
That choice forced a hard line under the hood, and it’s the rule I’d hand anyone designing AI agents: if the agent can only talk about something, that something doesn’t exist. Every capability ROCCO appears to have is a real tool it calls. Deserialize the request, run the actual operation, log it, return a result. There’s no monologue in the middle where it almost does the work. Tool-calling agents either fire the tool or they don’t — the paragraph in between is where fake capability hides.
The undo button is the other half of the deal. An AI assistant that acts has to be an assistant you can take the action back from. Acting without a reverse gear isn’t confidence, it’s recklessness — and our users, many of them former truck drivers now running collection routes, have zero patience for software that does something irreversible and expensive on their behalf. Act, report, undo. That’s the loop.
Agentic UI is the tool calls, not the transcript
Here’s where I part ways with a lot of current agentic UI writing. The going advice is to surface the agent’s reasoning — stream the planning, disclose every tool call, narrate the multi-step workflow so the user can follow along. Visibility, fine. But visibility is not the product. The tool call is the product. An agentic workflow that streams a beautiful play-by-play and never actually changes your routes is a spinner in an agent costume.
So the real AI UX question isn’t “how clearly did it explain what it was going to do.” It’s “how many things did it do, and could you undo each one.” Measure your agent by the tools it fires, not the paragraphs it writes.
Chattiness, honestly, is what an assistant does when it can’t do anything. The eloquence is compensating. When a system can genuinely act, it gets terse — because the result is right there in front of you and there’s nothing left to narrate.
What good agentic UX feels like
Users don’t want a coworker who narrates the work instead of doing it. They want the work done. The best compliment ROCCO gets from a dispatcher isn’t “it explained that well.” It’s “it just handled it.”
If you’re building in this space, that’s the bar I’d set for agentic UX: not the fluency of the description, but the reality of the action underneath it, and the confidence to hand the user an undo. Design the agent to act. Let the conversation be where the trigger gets pulled and the outcome gets explained — never a stage for performing competence you haven’t actually shipped.
