Can the agent talk back?
Every agent needs a place to review its work and hand back feedback. Where that surface lives, in the conversation or in the interface, is decided by one question.
When an agent gets something wrong, you do not go looking for an undo button. You just tell it. That it misread you, that this is not what you wanted, that it should try the other way. The correction happens in the conversation, the same place the work was headed.
That is one of the subtler differences between a chatbot and an agent. A chatbot exchange tends to be one round, a question and an answer, and you move on. Working with an agent there is back-and-forth, before it starts and while it runs. So the moment it drifts, you correct it in line, the way you would nudge a colleague.
Where the correction lives
That changes where the design work goes. In a normal app, catching mistakes and offering a way back is interface work, buttons, states, flows. With a conversational agent, most of that is not interface work at all. It is harness work. You are teaching the agent to notice when it is unsure, to admit when it does not know, to ask before it charges ahead. The place the user recovers is the agent’s own reply.
Until there is no conversation
The catch is that not every agent has a conversation to be corrected through. A background agent goes off and works on its own, with nothing open to it while it runs. There the design flips back. With nowhere to talk, you have to build the recovery into the interface again, a place to see what it did and hand something back. The stranger part is that the more autonomous the agent, the more traditional the design problem becomes.
What they both need
Underneath both is the same thing. Every agent needs a review surface, a place where you see what it produced and give back your reaction, which it takes and works on. The only question is where that surface lives. In the exchange, for a conversational agent. In the product, for a background one. And notice what decides it: whether the agent can talk, a design question, settles how much of this is engineering and how much is interface.
When the background agent speaks
For the background kind there is also a question of when. Since it cannot check in along the way, the natural moment to surface is completion. It finishes, it brings you the work, and that is when the review surface appears. The interruption is the delivery, which puts the weight on what it delivers into.
A good review surface fits the work
And a good one fits the thing being reviewed. When an Omaru agent builds you a founder website, the review is the rendered site itself, not the files behind it. If it had written backend logic instead, a diagram of how it flows would tell you more than the code. The best version is when the agent picks the representation, showing the output in whatever form lets you judge it fastest. This is the one place generative interfaces win me over. Building a whole app on the fly still smells like overkill. Generating the right way to review a result does not.
None of this is the part that gets talked about. The attention goes to the agent itself, how clever it is, how much it can do on its own. But a surprising amount of whether it feels good to work with comes down to something plainer, whether there is a good place to see what it did and tell it what to change. Get that right and the agent feels like something you are working with. Get it wrong, and it does not much matter how capable the agent is.