Making AI’s
Work Legible

Everything between “I understand” and “here’s what I did”

Processing transparency is everything the AI communicates between “I understand what you want” and “here’s what I did.” For a simple chatbot, that space might only need a spinner. For an agent, it can contain understanding, retrieval, policy checks, comparisons, decisions, actions, and verification.

The system may perform dozens of backend operations inside that middle space. The design problem is deciding what a person needs to know in order to understand what is happening and judge whether the AI is doing the right thing.

As Otto became more capable, the loading experience evolved in stages.

The turning point was that agentic AI changed what the wait meant. Users were no longer simply waiting for an answer. They were waiting while the AI acted on their behalf.

More information, less understanding

The technical processing state looked transparent internally. Every agent, workflow, tool, and system operation could produce a visible step. Users might see:

From an engineering perspective, the system was showing its work. From a user perspective, the work was mostly meaningless. Usability research found that people struggled with terms like “Payload ID,” “Used tool,” and “Rationalizing.” Customers escalated the experience. Some asked for the information to be reduced. Others asked for processing updates to be removed or turned off entirely.

The problem wasn’t the wait. It was uncertainty during it

The organization was focused on latency. As AI tasks grew more sophisticated, responses naturally took longer, and the concern was that users would abandon a slower experience. I thought we were measuring the wrong thing. If an AI takes ninety seconds to complete something that would otherwise take a person an hour, is ninety seconds actually slow?

I partnered with UX Research on studies exploring latency and output quality, and pushed the framing from wait-time tolerance to perceived value of automation.

The research showed that users tolerated longer waits when the result was meaningfully better, the task seemed complex enough to justify the time, and the system communicated what it was doing.

That shifted my design lens. I mapped the waiting experience around user trust rather than system execution.

Users were not trying to inspect the system. They were trying to decide whether to trust the outcome.

Task, not technology

To find out what users actually understood, I partnered with UX Research on a card sort using real examples of Otto processing steps. We asked three things: What can users understand? What do users actually want to see? Which backend operations feel like one piece of work?

The card sort revealed that users did not create a simplified version of our architecture. They created a different representation entirely. They grouped work around what the AI was accomplishing, not which component was executing.

The useful level sat between technical and generic.

This was the key model-design insight: we were not just simplifying labels. We were deciding which level of system behavior should become visible to a human.

Teaching the system to describe itself

To ensure that every step shown to users carried the right level of detail, communicated in a human-legible way, I authored the processing-state specification. The document defined research-backed behavior rules that engineers could implement through prompting and generation logic. It also carried eval criteria, so they could check the success of the end result.

What was in it:

What the system actually says now

The spec’s output is not a set of strings I wrote. It is the shape every generated step has to take. Run those rules over one HR request, the same request whose raw execution chain opens section 02. This is what has to come out the other side:

Every line is a task rather than a component, in the present tense, specific where specificity proves real context was found, with no agent, tool or table names, in the vocabulary the product already uses, incident, policy, case, and short enough to read out of the corner of an eye.

The pattern for showing work as it happens

The interface then had to decide where that generated information lived, how much attention it demanded, and how it changed over time. I owned the product direction: what information belonged, how prominent it should be, when it should be collapsed or expanded, and how the pattern should scale. I worked with visual design on color, line treatment, hierarchy, shimmer, and visual patterns, and with motion design on where movement clarified active work versus where it became noise.

Two questions were tangled together in those explorations, and they came apart once I stopped treating them as one: how the work should be shown, and where on the message it should sit. They have different answers, and either can be got right while the other is wrong.

Decision 01 · How to show it

None of these is wrong. They are answers to different questions about how much of the work a person should be asked to hold.

Decision 02 · Where to put it

The placement question is not cosmetic. It decides whether the record of the work or the liveness of the work gets the position a reader’s eye is already in.

What we shipped

Meaningful activity surfaces at the top; liveness stays visible at the bottom, wherever the user is reading.

Visible without becoming the main event

What a user needs isn’t the reasoning. It’s the evidence

Agents are getting more autonomous, making judgment calls, writing to records, committing someone to an escalation. A list of completed steps stops being enough to act on. So in the future-state work that followed (internally, the AI Blueprint) I stopped asking “how much reasoning should the AI expose?” and started asking “what evidence does the user need in order to trust and act on the result?” That question sorts agentic work into four kinds of information.

What this changed about how I design AI.

None of the larger ideas in this work arrived fully formed. I started with a product concern about waiting. I challenged the assumption that latency was the problem. That led to research showing that users cared about the value and legibility of the work. That made the existing processing experience look different: we were giving users technical transparency when what they needed was evidence of meaningful progress.

Rather than assume what should replace it, I partnered with research to card-sort the actual processing steps. Users showed us that their mental model was organized around goals rather than infrastructure, which gave me task, not technology. I translated that insight into a research-backed content model. Scale then forced me to turn the content model into model behavior. Shipping that behavior exposed another problem, understandable information can still overwhelm when there is too much of it, which led to the collapsed-by-default AI Steps pattern: visible enough to build trust, quiet enough to keep the result primary. The limits of that shipped pattern then pointed at the next question: not how much of the work to show, but what evidence a user needs in order to act on it.

Each idea came from finding the point where the previous solution stopped working. AI design is not just the design of an answer. It is the design of the relationship between what the system is doing, what the user can understand about it, and how much control they need at each moment. That relationship spans model behavior, content, interaction, and product architecture, and as AI becomes more autonomous, designing it well becomes increasingly important.