Case Study 1 of 4SHIPPEDEcolab® Virtual Agent

Enterprise AI Assistant, End to End

In March 2025, Ecolab’s employees and support teams had AI features scattered across 70+ products, no AI product that tied them together, and no one designing for AI.

I became Ecolab’s first solo AI and agentic designer and designed one assistant every product could share.
It knows what is on the user’s screen, searches the company’s data, and keeps a person one action away.
Live in 40–50% of the portfolio by July 2026, and the foundation of Ecolab’s agentic platforms.

At a glance

40–50%
Of Ecolab’s product portfolio had the assistant live by April 2026, across responsive web, desktop apps for Windows and macOS, native iOS and Android, and Microsoft Teams
70+
Existing, independent commercial products the assistant had to live inside, each with its own data, tone and first-run experience, and each already in daily use by customers and field teams
16 mo
From the first proof of concept on GPT-4o in November 2025 to a Claude-based product with a live escalation path to a person in April 2026

The Decision

What I Chose

I chose to create one universal Ecolab Virtual Agent experience that adapts to every environment it appears in. At its center is a page-aware copilot side panel, which Ecolab called Ride-Along and I’ll call the copilot from here. It sits in the last third of the screen and:

Reads what the user is already looking at
Answers questions across the company’s databases
Suggests what to try next when something goes wrong

The page reflows to two-thirds so nothing is covered, and the assistant only expands to full screen when the user consents.

I chose this direction because every product it would live inside was work in progress, and it could not be a forced fit. If an AI experience can’t adapt in my hands, it won’t feel right in a user’s. One universal experience also meant 70+ products could feel like one product as the user moved between them, with memories and chat history that still made sense.

What I Rejected, and Why

A modal-like takeover chat window. It is the fastest thing to build and the most common pattern in enterprise software, and it hides the dashboard, form or map the user is trying to act on. Across 70+ products that failure compounds: every product would teach people that opening the assistant means losing their place.
A bare chat widget with no room for in-chat tools. It can hold a question, but not a support ticket, a hand-off to a person or a multi-step task.

The copilot panel cost engineering a real layout spec instead of a simple overlay. That was the price of an assistant people would actually keep open.

Context & Constraints

Constraints

70+ Products Already in Use
Web, Desktop, Mobile & Teams
Every Employee, Office & Field
Non-Deterministic Model
No AI Design Function

In March 2025, the product team was stuck on a problem it couldn’t name. Ecolab had AI features, but no AI product and no one designing for AI. So when my boss sighed, I volunteered, and became the company’s first solo AI and agentic designer.

I started from the research that already existed:

Field sales and service research
The living journey map I had built for Sales & Service
Conversations with anyone who would humor me

I designed first for corporate employees, then for admin, middle management and field service. It quickly became clear that rigid persona work doesn’t fit AI: with a non-deterministic model and hyper-personalization, we couldn’t predict every small variation in how people would use it.

The Ecolab Virtual Agent became the brand for all of Ecolab’s next-generation AI. I:

Set its agentic vision and strategy
Designed its new patterns and experiences
Built a new AI and agentic design system to support the whole design department
Led cross-functional work to build AI fluency

Where it had to live: 70+ existing, independent commercial products across responsive web, desktop apps, native mobile and Microsoft Teams, including offline and slow-data states. Each had its own data, tone and kind of help, and customers used them every day, so the assistant had to earn its place without changing what people came for.

Who it launched to: Ecolab’s employee products first, in the office and in the field, and the support teams behind them (a ServiceNow help desk, regional multilingual phone centers and live-chat agents). Only after that did it expand to commercial customers.

How it worked: the first proof of concept ran on GPT-4o, and the product shipped on Claude. Trigger phrases I tuned with data analysts routed each request to the right data, and answers drew on legacy databases, Databricks and Snowflake through retrieval (RAG).

My working philosophy from day one was lift and shift: borrow patterns people already trust, like the side panels they knew from Salesforce, IBM and Microsoft and the ServiceNow ticket form, then honor what those patterns promise. A familiar shape that behaves in an unfamiliar way is worse than a new one.

Four States, and a Yes Before the Screen Changes

I specified how the assistant moves between states, not just what the panel looks like, and made the one transition that rearranges the user's screen a moment of consent.

Zero state. The work has the whole screen.
A mini-player tab. The conversation stays alive while the user works.
A one-third side panel, Ecolab's Ride-Along. The canvas reflows to two-thirds; nothing is covered.
The assistant offers. The user chooses.
Deep research and analysis. Entered only when the user says yes.

Zero state. The work has the whole screen.

Follow the arrows: the one move that rearranges the user’s screen passes through a consent gate first.

01 No Chat
Zero state. The work has the whole screen.
Shipped
02 Minimized-Active
A mini-player tab. The conversation stays alive while the user works.
Shipped
03 Copilot Panel
A one-third side panel, Ecolab's Ride-Along. The canvas reflows to two-thirds; nothing is covered.
Shipped
Consent
The assistant offers. The user chooses.
04 Full-Screen
Deep research and analysis. Entered only when the user says yes.
Concept · cut from production

User
Agent
Gate
Log

Follow the arrows: the one move that rearranges the user’s screen passes through a consent gate first.

The diagram shows the four states. Two things it can’t:

The arrow that matters most is the move into full screen: the assistant says what it wants to open, and the user chooses. That consent moment was the first piece of the disclosure and consent system I later designed for all of Ecolab’s AI, which is Case Study 2.
Why the transitions were specified, not just the panel: engineers got layout behavior they could build and test, not a panel drawn once, and every AI platform team could adopt the same four states without me in the room. With no positional authority, that is how the model spread to all of them.

A Helpdesk Inside the Chat, Not a Link Out of It

I brought support ticketing into the conversation as the first in-chat tool, so asking for help never ends in a dead end, and the assistant became a place where work gets done.

Before this, ticketing lived in ServiceNow, outside the assistant, so the help content ended exactly where people needed the most help: a link out, a new tab and a form to fill in from scratch.

I designed Case Support as an in-chat tool, built as a micro-frontend (a small, separate app that runs inside the conversation):

Its own header and cancel path, with the chat still visible behind it
Pre-filled with what the system already knows about the user and the issue they’re chatting about
Fields that mirror the ServiceNow form one for one, so nothing breaks for the support teams downstream
Case history grouped by recency, so the user can find the case they opened last week
Twenty-five annotated screens for creating, tracking and escalating a case, with loading and hover states specified

The same container later held live chat with a live agent from the help desk, and every later in-chat tool inherited its shape: profile settings, task management, and Document Search & Share, which was in the pipeline when I left. This is the moment the assistant stopped being a question-and-answer box. The panel and its in-chat tools carried into Ecolab’s Intelligence Platforms, which is where Case Study 4 picks up the story.

A Person Is Always One Action Away

I designed escalation as a ladder with three rungs in one container, a self-serve answer, an in-chat case and a live agent, with a rule for when the assistant stops trying.

The hand-off happens in the panel the user is already in, and hands back with next steps.

Escalation was designed as a ladder, not a fallback:

The assistant answers from the company’s data and suggests what to try.
If that doesn’t resolve it, the user opens a case without leaving the chat.
If it’s urgent, they hand off to a live agent inside the same container. When the support person is done, the user is back with the assistant and a set of next steps.

The rule that shipped: after three clear attempts at the same problem, the assistant offers a live agent by phone or chat, checks who is available and connects them. In regions without live agents, it gives a phone number. Three attempts is a common industry convention, and I would tighten it now (see What I’d Do Differently).

A rung we hadn’t planned: user acceptance testing (UAT) showed the Teams beta was far weaker than the main assistant, so a bad answer there was a dead end. From a thumbs-down, people could post their question to the CORE+ community forum without leaving the assistant.

The principle underneath all of it: if the model can’t answer, the product still has to get the user to an answer.

Escalation Pathways to Help

Disclosure, consent, feedback and escalation are not separate features. They work as one system that keeps the user in charge and, just as importantly, keeps them safe:

The user always knows they are talking to AI
Nothing rearranges their work without a yes
Every answer can be questioned with a reason
A person is reachable from every state

The full disclosure and consent system, and how it brought Ecolab’s AI products into compliance with U.S., E.U. and international AI law in May–June 2026, is Case Study 2.

Evidence & Outcome

40–50% of the Portfolio
Live by April 2026 across responsive web, desktop apps, native mobile and Teams. The copilot panel, the self-service help escalation path and the Teams experience went live on April 10, 2026, and the Teams experience was later demoed at AIFest to a strong reception.
New Platform Extended Central Model
By July 2026, every product team understood how to implement the core Ecolab Virtual Agent experience, was implementing it, or had already launched a version of it. The Intelligence Platforms that followed were built on it (Case Study 4), and the AI & agentic design system underneath it is Case Study 3.
Thousands of UAT Scenarios
A scenario matrix of realistic and rare-but-plausible cases across devices, browsers, languages and levels of emotional urgency, with LLMs generating cases beyond what I could imagine on my own. The four-state spec, 25+ Case Support screens and a one-page decision framework went to engineering, and no design was sent back as infeasible.

What It Cost, and What I’d Do Differently

What It Cost

Full screen was cut from production.
A thin first impression: many people first met the assistant in its thinnest version, search with suggested prompts, before the in-chat tools that make it useful had reached them.
Data silos: the first version tied what the assistant could answer to the product the user was in. Being aware of the page was right, but to get an answer that lived in another product’s database, the user had to travel to that product first.

A colleague’s “art of the possible” concept later showed the better model: existing products brought into the conversation as in-chat tools, so the user could retrieve what they needed from one place. It asks users to think about those products a little differently, and it removes the travel.

What I’d Do Differently

Escalate to a person sooner. Three tries is an industry convention, not evidence, and it asks users to sit through more failure than they should have to. I would escalate on the second miss, or on signs that the user is struggling rather than a count, and measure every way people try to reach a human so the threshold comes from data instead of a rule.
Define the language up front: the difference between a bot and an agent, and between an in-chat tool and an MCP server (the connection that lets a model reach a tool or a data source). People used those words interchangeably, and that clarity on day one would have made every conversation after it easier.
Separate what the assistant knows about the page from what it can reach, so being aware of a product never means being limited to it.