In the final days before the product keynote at mabl's annual conference in Boston, the team kept getting exciting new features across the finish line. Some were ready just hours before we went on stage, and there was no doubt that we needed to show off the hard work. So we kept rewriting the talk track, reshuffling the demo, and finding ways to squeeze more in. It was a little chaotic, genuinely exciting, and ultimately made for a much better story. I was also reminded of the awkward business that is demoing AI agents.
How do you show work nobody can see?
A lot of the interesting work happens behind the scenes with agentic workflows. Agents are gathering context, making decisions, calling tools, and coordinating with each other. The user might see a chat message and a result. That’s great for the product experience, but pretty weird for a demo.
We had to figure out how to make the work understandable without narrating every tool call. The audience needed to see enough to appreciate what was happening, without sitting through a technical explanation of the machinery underneath. These challenges translate to daily questions around design decisions, as well.
How do I get the point across?
Watching an agent complete a task is impressive, but it doesn’t necessarily tell someone whether they should trust it.
We wanted to show the moments where the agent needed a person. Asking a clarifying question before writing a test. Keeping changes on a branch. Recognizing that a failed assertion might represent a real product defect rather than something to quietly fix. Those interactions mattered more than showing a long list of completed tasks.
We ended up using a completed conversation to establish the broader workflow, then interacting with the product to show test selection, execution, and results. It gave us room to explain the important decisions without making the audience watch every step.
How do you demo something that’s changing tomorrow?
The product was moving faster than our ability to rehearse it. We were also showing capabilities that different people would experience differently. A developer working in their IDE might want agents operating quietly in the background. A QA manager might want to understand what happened, what changed, and where their team needs to intervene. Trying to communicate both experiences in a single demo was tricky.
What I took away
I’ve worked on plenty of demos over the years, but this one felt a little more unhinged than usual…in a fun way. The product was evolving right up until we showed it, and we were learning how to tell the story almost as quickly as the team was building it.
I came away with a friendly reminder of just how tricky it is to make agent behavior understandable, and an even greater appreciation for the people I get to work with. Every last-minute addition meant someone on the team had cracked another hard problem, and we had something new worth showing.
One final lesson is that if you're going to make a habit of last-minute demo changes, surround yourself with people who have a good sense of humor and a remarkably high tolerance for nonsense.