Show the work, keep the magic
Designing with live model output means deciding what the user should see while an agent works, what can stay hidden, and when a result is ready for its reveal.
Omaru’s onboarding asks a handful of ordinary questions. While you answer, it researches you in the background. At the end, it shows you a picture of yourself assembled from more than the answers you typed in. I designed the flow around that reveal.
Holding information back so a reveal can land isn’t a new idea; storytellers and magicians have always cared about timing. The unusual part here was that I couldn’t know the exact content of the reveal in advance. It came from the model and changed a little each time.
Most software interfaces are designed around known content and predictable states. Agent interfaces aren’t. The output at the centre can change in length, quality, and timing, so the design has to decide what to do with it as it arrives rather than merely reserve a box for it.
You cannot hold everything back
An agent that works in silence quickly looks like a stalled agent. The user needs some evidence that work is happening, but not a dump of every internal detail. I tend to hide the mechanism and show the activity: enough motion and progress to make the system legible without spoiling the result.
Showing the life is three things
I’ve found it useful to separate that activity into three parts, because each has a different job.
First is the thinking stream: tokens moving past while the agent works. They’re usually too fast to read, so I don’t treat them as information. They’re closer to a heartbeat. They show that the system is active and add a bit of spectacle while the user waits.
Second is the action trail: searches, file edits, and other tool calls. These are discrete enough to follow. This is the useful record of what the agent actually did, especially when something goes wrong.
Third is the result itself. The stream reassures, the action trail explains, and the result is what the user came for. Treating them as separate layers keeps one from drowning out the others.
More can be more
Omaru sometimes has several agents working at once. We show them as differently coloured cursors moving around the desktop. You’re not expected to track every cursor. The overall scene communicates parallel work, while the familiar cursor movement makes a fairly abstract idea, several agents operating computers, easy to grasp.
What you can actually stage
Onboarding can be choreographed because we control the sequence. Open-ended agent work can’t. A search may take longer, a tool may fail, or the agent may choose an unexpected route. In those cases, the design isn’t a fixed script. It’s a set of rules for what deserves attention and how prominently to show it.
Those rules only make sense when you understand what the agent is doing underneath: when it’s searching, when it’s stuck, and what kind of result it may produce. Working on Omaru has made the boundary between designing the interface and building the system feel increasingly artificial.