Why agents stopped trusting the screen.

Kaluza is an energy platform used by OVO and others, and I lead design on its agent experience. Weekly agent sessions since 2021 kept showing the same behaviours. Uncertainty. Repeated processes. A lot of refreshing. The cause is a quiet one. The platform processes things asynchronously, so an agent submits a read, the UI says accepted, and then nothing for 30 seconds or more, with no word when it's done. Agents refresh, hunt other pages for clues, and sometimes repeat the whole process because they can't tell it worked the first time.

A simple way to frame feedback is three questions an interface should always answer. What's happening? What will happen next? What just happened? We were failing all three. This had sat on our opportunity solution tree, the map our research keeps feeding, without fitting any one team's roadmap, exactly the kind of problem that never gets picked up unless someone picks it up. So I made the case for a dedicated UX quality week and led it.

A cross functional workshop with design and engineering produced a pile of ideas, then it hit a wall. We couldn't reliably tell agents how long things would take, and crucially couldn't tell them when they were done. So I paired with an engineer to find out what was actually possible. He built a polling proof of concept that imitated a system response. It worked, but it meant more API calls and more logic in the UI, and the tech leads rightly called it what it was. A plaster over a crack. The real fix is better endpoints upstream.

That stung, and it was the most useful thing the week produced. It put the weakness in front of the people who can fix it, and it helped inform the platform's future state work, the programme deciding how the platform gets rebuilt. I built a conceptual prototype to show exactly what the right endpoints would unlock, so the case came with a picture, not a complaint.

We differentiated the feedback types properly, the banners, form errors and callouts, created a new toast component, and I wrote the guidance on when to use each, standardising the API messages with our content designer. All of it went back to the design system, so every team building on the platform inherits the patterns rather than reinventing them. Two of the three questions answered, with the third waiting on the upstream work.

45k reads a week, 30 seconds or more each, 375 hours of waiting, refreshing and hunting for clues. We can't just delete that from handling time, but we can make it useful. And the metric underneath is trust, the hardest one to move and the one everything else depends on, because when agents can't trust the information you can't change how they work.

Before the changes, none of the six agents we interviewed could say how long a read takes to process. Asked again after release, all six said around 30 seconds.

The learnings fed straight back into Submit a photo.

• A knocked back proof of concept still moved things. The rejection carried the problem upstream, with a prototype showing what fixing it buys.
• Pairing with an engineer found the real constraint in days. Designing around assumptions would have hidden it for months.
• Framing the problem and outcome before the week started kept it focused when the solution kept collapsing.