Can the agent talk back?
Every agent needs somewhere you can inspect its work and respond. Whether that place is the conversation or a purpose-built interface depends on how the agent works.
When a conversational agent gets something wrong, my first instinct isn’t to hunt for an undo button. I tell it what it misunderstood and ask it to try again. The correction happens in the same conversation where I gave the task.
That back-and-forth is an important part of using an agent. You clarify the task before it starts, interrupt when it drifts, and comment on the result. It feels less like submitting a form and more like nudging a colleague while the work is underway.
Where the correction lives
This moves some familiar interface work into the agent harness. Instead of designing a button for every recovery path, you teach the agent to notice uncertainty, say when it doesn’t know, and ask before taking a consequential step. The conversation itself becomes the recovery interface.
Until there is no conversation
Background agents don’t have that channel. They leave, work on their own, and return later. Without an open conversation, the product needs a dedicated place to show what happened and collect feedback. Oddly, greater autonomy brings back a fairly traditional interface problem: review, approve, reject, revise.
What they both need
Both kinds need a review surface: somewhere to inspect the output and give the agent another instruction. For a conversational agent, that surface may simply be the exchange. For a background agent, it has to live in the product. The agent’s working model determines how much of the recovery belongs in the harness and how much belongs on screen.
When the background agent speaks
Timing matters too. A background agent usually surfaces when it finishes, so its notification is also a delivery. That puts extra weight on the destination: the user should land somewhere they can understand the result and respond without reconstructing the whole task.
A good review surface fits the work
The review surface should match the work. If an Omaru agent builds a founder website, show the rendered site rather than a folder of source files. If it writes backend logic, a diagram may be easier to judge than the code. I’m sceptical of generating an entire app for every task, but generating the right representation of a result is genuinely useful.
Agent demos naturally focus on capability. In daily use, the handoff matters just as much. I need to see what the agent did, judge it in the right form, and tell it what to change. If that loop is awkward, raw capability doesn’t rescue the experience.