The evolution of the Gladly platform. Human Agents → Human in the loop → AI Agents

Human Agents → AI Agents

When I joined Gladly, customer service agents were the center of the product. We focused on designing products that helped them work faster, and gave them context about the customer, so that they could deliever personized service at scale.

Generative AI changed what was possible.
First, AI helped agents write, summarize, and translate.
Soon, it started handling conversations itself.
Gladly shifted much of its focus toward that future, and my work moved with it.

The design problems changed from how do we help people do the work?
to how do people build, improve, test, understand, and trust AI doing the work?

What stayed consistent was the instinct to start with people and make powerful things feel simple.

Select Gladly Team features. Customer list · Order card · Mentions

2021–2022

Designing for the human agent.

For two years, I led design for Gladly Team, the side of the platform customer service agents used to do their work.

The promise was simple: give agents everything they need to help a customer without leaving Gladly.

I worked across the experience: how agents moved between customers, collaborated with teammates, acted on orders, and brought information from other systems into Gladly.

A look at how data was used to define Flexible Cards

App Platform + Flexible Cards

From fixed components to a composable system.

Gladly originally offered Lookup Adapter cards: a handful of predefined card types for displaying external data like orders, flights, and stays, plus a catch-all for custom attributes displayed as key-value pairs.

But businesses had wildly different data and needs. Customers were trying to squeeze their information into structures that weren't designed for them.

Flexibility had to go deeper than the UI
Research I led showed that customers found Gladly's integrations difficult to build, especially compared to more flexible alternatives. We needed to change both how data entered Gladly and how it was displayed.

One system, many configurations
App Platform let customers bring their own APIs instead of transforming their data to fit Gladly's middleware.

Flexible Cards replaced specialized card types with one composable system. I designed the building blocks, composition rules, and visual patterns that let developers configure how their data appeared, while keeping the experience consistent with Gladly.

Before Flexible cards, we required data to follow a specific format.

Flexible cards are a system for displaying external data the same way across the platform.

The system started with customer Profile Cards in Gladly Team and expanded to support rich media experiences in Gladly Chat, from product recommendations to interactive content.

Flexible Cards reduced the time to build and configure a card from 1 month to 1 hour, once business requirements were defined, while giving businesses more control over what data they displayed and how.

1 month → 1 hour
The time it took to build and configure a card, once the business requirements were defined.

2023

ChatGPT happened.

It felt immediately clear that customer service was about to change.

Our first question wasn't how AI could replace the agent. It was how AI could make them better at their job.

Keep the human agent in control. Let AI take on work that makes their job hard. Like saying no when a customer continues to push back. Or writing notes after each interaction.

I led design and research for the first generative AI tools on the Team surface.

AI Authoring and Summaries

Authoring + Summaries

Write better. Catch up faster. 

When we put generative AI writing tools and summaries in front of agents, they immediately saw the value. They could reshape responses, especially helpful for agents who spoke English as a second language; find new ways to respond when customers kept asking for something they couldn't change; and turn long conversations into editable summaries.

AI took on the tedious parts of the job, giving agents more time for what they found rewarding: solving gnarly customer problems.

Rather than selling these capabilities as add-ons, Gladly included them in its core agent offering, supporting an increase in per-agent pricing.

Translating conversations in Gladly

Translation

Make the technology disappear.

I led design for bringing real-time translation into the agent experience. With a tight timeline, we deliberately shipped in stages, knowing the first version wouldn't meet the full customer bar.

At first, agents translated messages one at a time.

Eventually, they could initiate translation once and Gladly automatically translated incoming messages, and defaulted agent responses back to that language.

What started as a problem our customers had to staff around became something agents barely had to think about.

The ol' adage... flying the plane while we build it!

2024–2026

AI became the agent.

Gladly made a much bigger bet. AI wouldn't just help agents handle conversations. It would handle the conversation itself.

We were planning for a future where AI handled 50% of customer conversations. Much of the company shifted toward making that future real.

The product changed. The way we worked did, too.

Teams became more fluid. Roadmaps got shorter. Priorities shifted constantly as the technology, our customers, and our understanding of what was possible changed underneath us.

I stopped thinking much about what team I was on and started moving to wherever the next important problem was.

At the same time, a new AI development lifecycle was taking shape at Gladly and across the industry. There wasn't a playbook yet. We were figuring out the questions as we built the answers.

How do you build an AI Agent?
How do you know if it's good?
How do you make it better?
How do you test it before customers meet it?
How do you understand why it did what it did?

Those questions shaped the next few years of my work.

Suggested Answers

Suggested Answers

Turn every handoff into a way to get better.

Gladly could show customers which conversations their AI Agent was handing off to humans. But I pushed us to answer the next question: So what now?

Knowing where the AI Agent struggled was useful. Helping customers eliminate those handoffs was better.

Suggested Answers analyzed conversations that had been handed off to human agents, identified how those agents resolved the issues, and drafted new knowledge base content for customers to review and publish.

Instead of leaving customers with another report to interpret, we gave them a way to act on what they'd learned.

Simply by accepting Gladly's Suggested Answers, Smith Optics increased its AI Agent's resolution rate from 10% to 50%. It was one of the clearest examples of how quickly customers could turn insights into results.

10% → 50%
Smith Optics' AI Agent resolution rate after accepting Suggested Answers.

Deterministic and automatic topics

Automatic Topics

AI couldn't just use the Topics humans used.

Topics are foundational to how contact centers understand why customers are reaching out. When we introduced AI Agents, customers needed that same visibility into AI conversations.

But automatically applying the right Topic wasn't straightforward. Some customers had 20 Topics. Others had 400. Even businesses in the same industry organized them completely differently. And Topics weren't just for reporting. They triggered rules, automations, and actions.

There was also a technical constraint. AI couldn't reliably classify conversations against hundreds of Topics. We needed to reduce the number of choices without losing coverage of the scenarios customers cared about.

I led design research to answer the question: Could customers use a standardized, industry-specific set of Topics, or did they need to keep their own?

Three patterns emerged:

1. Predictability mattered. Customers needed confidence that the right Topic would be applied, especially when Topics triggered downstream workflows.
2. Classification needed to be automatic. Customers didn't want human agents assigning Topics to AI conversations after the fact.
3. Existing Topics mattered. Customers wanted consistent reporting and workflows across human and AI conversations.

The design challenge became: How could we reduce the number of Topics AI had to choose from without asking customers to abandon the Topics they already relied on?

Three ways forward
The answer wasn't to make AI do everything. It was to understand where customers needed certainty, where they needed scale, and which approach was right for each.

Certainty → Deterministic Topics. CX managers explicitly assigned Topics within the Guides their AI Agents followed.

Scale → Automatic Topics. AI classified conversations using a smaller, customer-approved set of Topics when one hadn't already been assigned through a Guide.

To help customers create that set, we used an LLM to analyze their existing Topics and propose a smaller, more MECE set. Customers could add, remove, or refine Topics before enabling automatic classification.

Discovery → Unsupervised clustering. Looking further ahead, we began exploring how AI could surface emerging patterns customers didn't already know to look for.

Simulations

We needed to rethink the experience, not just simplify it.

Simulations started as an engineering-led prototype built around a technical understanding of how AI Agents work. It was powerful, giving customers a way to create scenarios, define success criteria, and see how their Agent would respond before deploying changes.

I joined the project already in motion, working to make a complex experience more approachable. I put it in front of customers to understand what made sense, what didn't, and whether they could actually use it.

Customers saw the value.
They couldn't see themselves doing the work.

I led research that surfaced two challenges:

1. Creating scenarios required a different way of thinking. Customers had to imagine situations outside the happy path, anticipate what might go wrong, and define what success should look like.
2. Mock data was a technical hurdle. Customers struggled to understand how tool calls, actions, and the data behind them connected to create a simulation.

The research raised a more fundamental question: What were we asking customers to understand and do in the first place?

What if the starting point was a real conversation?

In conversations I led with customers, it became increasingly clear that simplifying the interface alone wouldn't overcome these barriers.

We had already explored using historical conversations as a starting point for scenarios. But what if we went further, bringing along the context, tool calls, and actions instead of asking customers to recreate them?

That led to a team decision to pursue historical customer conversations as the foundation for a reusable golden dataset, preserving the information needed to run meaningful simulations.

Beyond making simulations easier to create, this became the foundation to help internal teams test changes to the algorithm for regressions.

Agent Creation

The wizard wasn't the problem. The journey was.

Gladly wanted Shopify to become a self-serve channel. A path where smaller businesses could discover Gladly, sign up, build an AI Agent, and get it live without a high-touch implementation.

There was already a setup wizard. But when I mapped the experience with customers and internal teams, it became clear no one had designed the whole journey.

New customers had no intentional starting point. The wizard and product used different names for the same things. “Published” didn't always mean what customers thought it meant. And once setup was complete, there wasn't a clear answer to: now what?

I partnered with our new Marketing team on the Shopify channel strategy and led the research, journey mapping, design, and rapid prototyping around one North Star:

How quickly can a new customer create and publish their first Agent?
The work became less about fixing a wizard and more about designing the front door to Gladly, from first sign-in through setup, publishing, and what to do next.

For a self-serve channel to work, customers didn't just need to complete setup. They needed to trust that what they'd built was ready to talk to their customers.

AI Voice

Before we could improve Voice, we had to define what good sounded like.

I was the first designer on Gladly's AI Voice team. There wasn't an established playbook for what made an AI conversation feel good, and we didn't yet have automated evals to tell us where things were going wrong.

I listened. Hundreds of calls. I studied conversational design, identified recurring experience problems, and developed principles for evaluating voice conversations. We used those principles to categorize issues, spot patterns, and prioritize what would make the biggest difference.

This was a product without much of an interface. The design was in the behavior.

Turn detection. Interruption handling. Latency. Filling silence. Pronunciation. Voice selection.

I helped shape how the Agent behaved across each of these, from pronouncing a brand name correctly to knowing when someone had finished speaking, when to wait, and how to make silence feel intentional.

And when humans needed to understand what happened, I designed the interface around it too: transcripts, summaries, and reviewing conversations that moved between AI and human agents.

Defining voice quality

Core principle – always evaluate conversations from the point of view of the customer.

Take off your engineering, ML or systems hat.

Ask, “If I were this customer, how would this experience feel?”

Even if you understand the underlying cause, rate the experience as it was lived, not under the technical constraints it was built.

Quality Bar

Hold a high bar – “acceptable” is not the target.

Be specific and descriptive in notes.

Assume feedback will directly influence product roadmap & UX improvements.

Going deeper

Some of this work deserves the full story

Signals
How do you know if your AI Agent is actually good?
I led design for Signals, Gladly's approach to evaluating AI conversations at scale, from defining what you want to measure to testing whether the evaluator itself can be trusted.

Read the Signals case study →

AI Sessions
When an Agent does something unexpected, you need to know why.
As Gladly's Agent architecture evolved, I led the design of the tools customers used to understand what the Agent knew, what it did, and why it responded the way it did.

Read the AI Sessions case study →

2026

The year making software changed.

Claude Code gave everyone at Gladly the ability to build. For designers, that changed the conversation again.

We weren't limited to designing what should be built. We could prototype in code, work directly in the codebase, and get much closer to the shipped product.

Around the same time, our design organization changed dramatically. I wrote down what I believed the next chapter of design at Gladly needed to be and spent the following months pushing on three things:

Designers become builders.
Use AI and code to move beyond describing the experience and start making it.

Quality becomes the differentiator.
When almost anyone can quickly produce 70% of a good product, the last 30% matters more. We needed better ways to define, evaluate, and raise the quality bar.

Systems matter more, not less.
When everyone can build, shared patterns and a strong design system become even more important to keeping the product coherent.

Over my time at Gladly, I watched AI change our product, our customers' jobs, our business, the way we built, and my own practice.

#gladlyAI