The EVA panel being displayed in product wit the words "An AI assistant for insurance agents who can’t afford a wrong answer" next to it.

Overview

Summary

EZLynx is where small insurance agencies run their business. EVA Assist is the AI assistant we built into it. My job was to make it something agents would actually trust and reach for, not a chat box bolted onto the side of software they already knew how to use.

Business Problem

Agents spend about 2.8 hours a day answering questions. Questions from clients, from carriers, from the person sitting next to them. Every answer means digging through a policy record, a PDF, an old email, or a carrier portal. Our 2025 market survey put operational efficiency at the top of what agency owners said they needed.

So the pitch was simple. Put an AI assistant in the product, let agents ask their question in plain language, and give the time back.

Role

Lead Product Designer

What I Owned

User Research

Competitive Analysis

Systems Thinking + User Flows

New Design System

Pilot Programs

UI Design

Status

Shipped. New capability still being validated with pilot agencies before going to GA.

Project Complexities

Four things made this the hardest project I have worked on, and they all pulled in different directions.

01

AI has no happy path

You can’t wireframe one flow when the system gives a different answer every time. Wrong answers, refusals, half answers, and “I don’t know” are not edge cases here. They are the normal weather, and they had to be designed as first-class states.

02

The platform was already there

EZLynx is mature software with users who have real muscle memory, and the right side of the screen was already full of panels. EVA had to fit inside all of that without breaking anything agents already knew how to do.

03

The users repeat the answers to clients

Many of our agents are between 45 and 65 with mixed comfort around new tech. More importantly, an answer EVA gives can end up in an email to a policyholder. A confidently wrong answer is not an annoyance. It is a professional liability.

04

The question space has no edges

Agents ask about coverage, premiums, claims, renewals, billing, carrier appetite, and how to use EZLynx itself. There was no finite task list to design against. We had to find the real question set before a single screen could be drawn.

Project Approach

The project began with a simple question: what do insurance agents actually need from an AI assistant? Answering that question led from research and question analysis, through interaction design and prototyping, to a ten-week pilot with real agencies. The six themes below summarize the key decisions, design principles, and outcomes that shaped EVA’s development.

Defined the Question Space

I reviewed existing AI-chat research and conducted my own questionnaire to understand what agents were being asked. This uncovered 429 unique insurance and workflow questions, which I analyzed and organized into themes that became the foundation for EVA’s response strategy and interaction model.

Designed for AI's Unpredictability

Rather than treating incorrect, incomplete, or uncertain responses as edge cases, I designed them as core parts of the experience. I created reusable response patterns and trust-building mechanisms that helped agents assess AI-generated information before using it with clients.

Reduced Prompting Effort

Research revealed that agents preferred clicking to typing, so I designed guided interactions that used contextual actions and suggested next steps. This reduced the need for prompt-writing skills and made it faster for users to refine responses and continue conversations. 

Integrated AI into Workflows

EVA was being introduced into a mature platform with established user habits and limited screen space. I challenged the original placement strategy and advocated for a solution that aligned with existing workflows, allowing the AI experience to feel familiar without disrupting how agents already worked. 

Accelerated Delivery With AI Tools

I used Claude, Copilot, and Marvin to speed up research synthesis, content exploration, and session documentation. Automating these high-volume tasks allowed me to spend more time analyzing feedback, shaping product direction, and making design decisions. 

Validated With Real Agencies

I established a 10-week pilot program that put EVA in front of real agencies early and created a continuous feedback loop throughout development. Agencies continued testing future releases, giving the team a consistent benchmark for validating improvements and identifying issues before wider rollout.

The Project by the Numbers

These metrics capture the scale of the research, design, and validation effort, and how the work evolved from an initial analysis of agent questions into a continuously validated product.

429

unique agent questions collected and categorised

10

response templates designed as a build spec

11

AI products benchmarked across 6 dimensions

5

pilot agencies, around 70 agents enrolled

12

agencies in the pilot today, with more than 125 agents

Empathize

Uncovering Common Questions

I could not design a single screen until I knew what agents get asked all day. Nobody had that list, so I went and built it.

Step one: read what already existed

Other teams in the business had already done real research on AI chat for agency software. Rather than start from zero, I went through it first. Two things came out of that reading and stayed with me for the whole project.

The first was a chat UX success checklist: show your sources, answer however the question is asked, give a direct answer, make links obvious, build real “I can’t answer that” states, make capabilities clear, do not prefill prompts, keep history until the task is done. The second was a catalogue of the question types agents ask most often, which gave me a head start on my own research and a way to sanity check it later.

Step two: go find out what agents are actually asked

That research was about a different product and a different user base, so I ran my own questionnaire. It went to a mix of people: an internal subject matter expert who fields agent questions across hundreds of agencies, and customer-facing agents doing the work every day. Asking both let me cross-check what support thinks agents ask against what agents say they ask, which are not the same list.

104 people responded. I compiled every answer into a spreadsheet, stripped the duplicates, and ended up with 429 unique questions. Raw, messy, and long, but for the first time it was an actual list of the job rather than an assumption about it.

Screenshot of the excel file with all the agent questions.

Our Questionnaire Participants

Small agencies, typically with fewer than 20 employees, formed the primary audience. Agents were often between 45 and 65 years old and varied widely in their comfort with new technology. While they were highly efficient in EZLynx after years of use, any new tool needed to fit naturally into workflows they could perform almost instinctively.

Their workday was shaped by constant interruptions. Agents frequently switched between clients, processed large volumes of email, and stepped into unfamiliar accounts with limited background information. The challenge was rarely finding information. It was maintaining confidence and credibility while supporting clients in real time.

This insight shifted the direction of the project. Rather than focusing solely on improving search, the greater opportunity was helping agents quickly understand the context behind a customer interaction. By reducing the time needed to get up to speed, agents could respond confidently from the very first conversation.

Define

Identifying Answer Patterns

I analyzed all 429 questions based on the type of answer they required rather than their insurance topic. Organizing them by topic would have produced traditional insurance categories, but organizing them by answer pattern revealed the interface requirements needed to support them. For example, questions about premium changes and coverage differences may seem unrelated, yet both are best served by a comparison table linked to the relevant source document.

AI helped accelerate this process. At the time, Copilot was the only AI tool available to me, so I used it to generate an initial clustering of the 429 questions. This quickly transformed a long, unstructured list into a workable set of draft groups. I then reviewed every question myself, refining the groupings based on answer patterns rather than subject matter. The AI helped speed up the analysis, but the decisions about which questions truly belonged together remained my own.

Once the patterns were established, I validated each group against the capabilities of our APIs and source documents. This ensured we were designing experiences around answers the system could realistically generate, rather than creating solutions that could never be supported in production.

Question Type Example Answer Shape it Needs
Catch me up Catch me up on this client Natural speech using records, emails and documents
Premium difference and why Why did this policy go up at renewal? Comparison table, limited to the factors that changed
Coverage, limits, exclusions Is water backup covered? Natural speech plus a source reference(s)
Actioning on tasks Send an ID card Click-based workflow
Q&A and 'how to' guides How do I create a commercial applicant? Knowledge base article, sometimes with video
Technical issues Why the Outlook plug-in isn't working? Route to customer service with real contact details
Government and carrier requirements What coverages does a plumber need? Natural speech plus vetted external sources links

The Rule That Changed Everything

One line from the chat UX checklist became the filter I ran every feature idea through.

"Chat UX is for when thinking and typing is less effort than the alternatives, and the resulting value is worth it."

Internal chat UX success checklist

That sounds obvious until you apply it. It kills a lot of features. If a route is short and known, a link is better than a question. If the data is structured, a form is better than a sentence. If we already have everything we need, the right design is to just do it and not ask at all. And if the answer is already on the screen in front of the agent, chat has no reason to be involved.

Problem Statement

Agents need answers they can repeat to a client without checking them first. An AI that returns a wall of text, does not know which client they are looking at, and cannot say where its answer came from will get tried once and abandoned, because agents are already fast in software they have used for years.

How Might We

How might we design an AI assistant that gives agents an answer in a shape they can use immediately, fits into work they are already mid-way through, and is honest enough about its limits that a failure makes them try again instead of giving up?

Design Constraints

Agents need answers they can repeat to a client without checking them first. An AI that returns a wall of text, does not know which client they are looking at, and cannot say where its answer came from will get tried once and abandoned, because agents are already fast in software they have used for years.

Beat the manual route or do not appear

If an agent can get there in three clicks, EVA has no reason to exist in that moment.

Never make them say who they mean

If the agent is standing inside an account, EVA already knows who the question is about.

Clicking beats typing for anything we can predict

Refining a question should not require composing a second prompt.

Confidence must match certainty

A confidently wrong answer is worse than no answer, because it stops the agent from checking.

Ideate

Competitive Analysis

Agents already use AI. They come into EZLynx with habits formed by ChatGPT, Copilot and Gemini, and some already use insurance-specific tools like Qumis. Those habits are free if you match them and expensive if you fight them.

So, I pulled apart eleven AI assistants and captured each one against the same six moments. Not to copy anyone, but to find out which patterns were already conventions and which were just one company’s opinion.

  • Products: ChatGPT, Claude, Gemini, Perplexity, Microsoft Copilot, Grok, Meta Llama, DeepSeek, Qwen, NotebookLM, and Leo AI.
  • Moments: the welcome state, side navigation, what sits on screen while idle, asking a question, how citations are shown, and deleting a conversation.

Three things came out of it that changed my designs.

01

Citations are not standardized

Every product does provenance differently, from numbered footnotes to inline chips to a source rail. There was no convention to inherit, which meant this was ours to decide. We later tested it directly and found agents preferred sources in a dedicated box below the response rather than inline in the text.

02

The empty state teaches the product

Almost every product uses the welcome screen to show capability. In a product where agents genuinely did not know what they could ask, that was too valuable a surface to waste.

03

Nobody else has our context problem, or our advantage

Consumer assistants start from nothing. Ours starts inside a record about a specific person with specific policies. Every competitor has to ask who you mean. We do not, and that turned into the single most valuable thing about the product.

Two Key Ideas

Everything else in this project is execution. These two are the actual bets.

Design the answers, not just the container

Most chat design stops at the panel. But the thing agents judge is the answer. If each bucket of questions gets a designed response format, the AI team has a spec to build against and agents get a consistent shape they learn to scan.

Refine by clicking, not by typing

When a question is ambiguous, the standard move is to ask the user to rephrase. That puts the work on the person least equipped to do it. If we already know the possible answers, we should show them as choices.

Prototype

From Questions to Response Templates

Designing a deterministic interface around a non-deterministic engine means you stop drawing screens and start drawing the shapes the answers will arrive in.

This is the core of the project. Each bucket from the Define stage became a visual template with a defined layout, and the AI development team plugged real content into those templates rather than returning free-form text. It meant the design system extended into the model’s output, not just the panel around it.

Ten templates covered all 429 questions.

Catch me up

Account history synthesized and grouped by category, not listed by date.

Natural speech plus reference

A conversational answer with the source attached below it.

Table plus reference

Comparison answers. The table is limited to the factors that changed, with source links for the full list.

Knowledge based questions

How-to answers from the knowledge base, surfacing the article itself and any embedded video rather than summarizing it away.

Requires document fetch

Answers that need a policy PDF. The document slides in from the right as a modal.

Responses requiring options

The ambiguity case, with a selected state for after the agent chooses.

Responses leading into workflows

Questions that should end in an action, handing off into the real EZLynx workflow.

Sources to external websites

When the answer lives off-platform and the agent will finish the task there.

Canned responses

Fixed answers for the questions that always have the same answer, so the model is not asked to improvise.

Directs to customer service

The honest dead end, with phone, hours, email and ticket link rather than an apology.

Annotating these was as important as drawing them. Things the templates had to specify:

  • Sources sit in a dedicated box below the response, because testing showed that is where agents look for them.
  • When there are four or more sources, the box gets an expand and collapse control rather than growing forever.
  • After a summary, EVA offers a hint to help the agent refine their next question.
  • EVA is an integrated part of the page. Opening her shifts the page content rather than covering it.
  • Documents open in a modal panel from the right, so the conversation stays visible.
  • Closing and reopening from the expanded state returns to the smaller size.
 
Screenshot showing all the templates that EVA uses to form her responses.
close up template of table plus references
closeup template for knowledge-based questions

Click, Don't Type

An agent asks about John Smith. There are ten John Smiths in the system. The standard AI answer is to ask the agent to be more specific, which means the agent now has to compose a second prompt describing a person they may only half remember.

Instead, EVA shows cards. Each card carries the identifiers an agent would actually use to tell two people apart: address, date of birth, phone, email, number of active policies, and status chips. Nicknames are surfaced on the card, so “Skippy” resolves to John Smith. Co-applicants are labelled, so a spouse on the same address does not look like a duplicate. The agent clicks the right one and the conversation continues.

The same pattern handles policies. If a client has two auto policies, EVA shows a card per policy rather than asking which one. I built card variants for auto, home, business liability, motorcycle, boat and RV, each showing the details that distinguish that line from another of the same type.

Why this matters more than it looks

Nicknames and co-applicants were the two things the system got wrong most often in early testing. Designing the disambiguation card around exactly those two failure modes meant the interface was doing work the model could not reliably do on its own.

Different component states for the customer refinement button card.
Different policy type button cards.

Finding the Right Panel Placement

The direction I was given was to put the panel on the right. That is the obvious call. It is where Intercom lives, where Copilot lives, where every support panel anyone has ever used lives.

I pushed back, and I documented the case rather than arguing it in a meeting. The right side of EZLynx was already carrying notifications, tasks, document previews and several other panels. Adding one more would have squeezed the central working area, especially with the client information panel open on the left at the same time. Our architecture team also confirmed the right side was the harder build.

Before the comparison went to the director, I used Copilot to pressure-test it and look for arguments I had missed on either side. I wanted the case to hold up against the best version of the other option, not a weak one.

Left Panel

The call I made

For

  • Avoids conflicting with the panels already living on the right
  • Lower implementation complexity, confirmed by architecture
  • Agents already look top-left for search, so the trigger sits where they look
  • Supports a clean toggle between EVA and client information in one space

Against

  • Breaks the convention set by every other AI and support panel
  • A learning curve for agents used to right-side panels
 

Right Panel

Not Chosen

For

  • Familiar pattern that matches expectations
  • Agents are habitually working on the right
  • Keeps the client information panel on the left visible

Against

  • Panel overload on a side that is already crowded
  • Squeezes the central working area when both panels are open
  • Reduces multitasking
  • Higher development complexity

I won that argument and the panel shipped on the left. Whether it was the right call is a question that has since reopened, and I come back to it in the Iterations section.

Slide the arrows left and right to see the different between the panel placement.

Left Panel Right Panel

States, Not Screens

Alongside the templates, I mapped the design as a matrix. On one axis, where the agent is: on the EVA homepage, in a record, or working from a communication. On the other, what EVA can do with the question: answer it fully, answer it partly, need one clarification, not be able to do it, or error out. Every cell needed a designed state, including the ugly ones.

That is the part people underestimate about AI design. The happy path is maybe a fifth of the work.

A grid mapping three kinds of request against five response outcomes, with a designed state in each cell.

Tool That Didn't Make the Cut

I initially built the page layouts in Figma and attempted to used Figma Make to generate the first interactive mockups for early concept approvals and iterations. While it helped accelerate exploration, the tool was still relatively new and not mature enough to rely on for production-quality prototypes. So, I returned to building traditional Figma prototypes, which gave me greater control over interactions and edge cases.

The final, pixel-perfect designs used for developer handoff were also created in Figma, ensuring consistency between the prototypes, design specifications, and the delivered experience.

Test

Why We Skipped End-to-End Prototypes

We couldn’t test this with a prototype, and understanding why changed how the whole project was validated.

A clickable prototype can tell you whether someone finds a button. It cannot tell you whether an AI’s answer is any good, because in a prototype I write the answer myself. I would have been testing my own copywriting.

An AI-generated prototype does not solve that either. The answers inside it are still made up. It is not EVA answering a real question about a real client from real data, and that was the only thing worth testing.

The two things I most needed to learn were whether EVA’s real responses were accurate and useful, and whether the response templates held up when real data was poured into them. Both of those required a working system and real client records. So we built the first version, put it in front of real agencies, and made the pilot the test.

The Ten-Week Pilot

Five agencies, around 70 agents enrolled, five sessions over Zoom every two weeks. Between sessions, participants used EVA in their real client work. A survey before the first session, a short pulse survey after each one, and product analytics throughout.

I used AI to help draft the pilot materials: the discussion guides, the pulse surveys, the KPIs, and later the readiness scorecard. It gave me solid first drafts fast, and I shaped each one around what that session actually needed to prove.

Every session was recorded and transcribed in Marvin. For the ten-week pilot and the first open-pilot round, I used Copilot to turn those transcripts into structured summaries in Confluence: friction points, success moments, and verbatim quotes, tagged by feature. From the round after that, I switched to Claude for the same job. I reviewed every summary before it went into the findings. A synthesis tool can be confidently wrong in the same way EVA can, and that is the exact risk this whole project was about.

One constraint shaped everything: no code changes during the pilot. The version deployed on day one was the version used in week ten. Only the quality of EVA’s answers could be tuned. That sounds limiting, and it was, but it also meant every finding was about the same product rather than a moving target.

I told every participant the same thing up front: we are not testing you, we are testing EVA, and “I never used it” is a useful answer. That one line got me far more honest data than any incentive would have.

The Finding That Changed Everything

Agents split cleanly on when they used EVA and when they ignored it, and the split was not about quality.

Agents reached for EVA when

The answer was buried. Information scattered across several points in an account that would have taken forever to assemble by hand. Catching up on an unfamiliar client. Comparing a renewal to last year. Explaining a coverage scenario.

Agents went around EVA when

The task was easy. If they already knew where the field was, they could get there in EZLynx faster than EVA could answer. Speed beat convenience, every time, and it was not close.

So EVA was winning the hard work and losing the everyday work. That gap is where adoption dies, because the everyday work is what fills the day. It produced two responses: we cut response times in the following release to attack the speed objection directly, and we started moving EVA from something that answers questions towards something that completes tasks.

"I absolutely loved the Catch Me Up. I would say that's my primary use, when the client on the phone isn't mine."

Adam, Lauber & Will Insurance

Trust Was Situational

Nobody said “I trust it” or “I don’t.” They said “I trust it for this, not for that.” Agents verified anything they planned to repeat to a client, and they verified silently, which meant usage numbers could look healthy while trust was quietly poor. I wrote a pulse question specifically to catch that: the last time EVA gave you an answer you weren’t sure about, what did you do next?

Why the Pilot Continued

We fixed what the ten weeks told us to fix and released it. That part is straightforward. The problem was what came next: we had a long list of changes and no way to know whether any of them had actually worked.

A one-shot pilot cannot tell you that. Whole agencies had opted out of individual sessions. One agency’s usage spiked around our check-in calls and dropped between them. A single snapshot cannot separate “we improved” from “different people showed up this time.”

So instead of closing the pilot, I kept it open. The same agencies come back every time we finish a piece of new functionality. Same question set, same people, compared against the last time we spoke. Sessions are retrospective rather than task-based, anchored to “tell me about the last time you,” so we are measuring real work rather than performance in front of a moderator.

Two rules make it work. Keep the question set stable, because rewriting the questions destroys the only reason to ask them again. And keep the same participants wherever you can, because a changed panel and a changed metric look identical in the data.

Keeping Agencies Engaged

That second rule was harder in practice than on paper. With each pilot, some agencies could not continue. Early on, some left because EVA compared badly with the AI tools they already used, like Gemini and Qumis, and they struggled to get real value out of it. Others left because the pilot took more of their time than a small agency can spare.

To keep participant numbers up, we cycled new agencies in as each pilot went on. That makes comparisons messier, so the round-over-round scorecard below is built from agencies that took part in both rounds.

The encouraging part is what happened over time. Three of the five original agencies are still with us, from the first pilot through every release since. And retention has held up better with every release we have shipped. The pilot has grown from 5 agencies to 12, with more than 125 agents taking part today. People choosing to stay in a pilot that costs them real time is a signal in its own right, and it has been one of the more honest ones we have.

The trap I designed around

High usage with low trust. Agents keep asking, the numbers look healthy, and behind the scenes everyone is double-checking every answer. If you only measure usage you ship on a lie. That is why the trust questions were the ones I protected when sessions ran long.

Measuring Readiness

I turned the release decision into twelve dimensions, each with its own evidence source and its own bar, rated at the end of every round. No single feature could block a release on its own, but anything red in trust or accuracy did. What mattered was not the rating. It was the direction of travel. Ten of the twelve are below, across two consecutive rounds.

I want to be honest about that table, because the two rows at the bottom are the interesting part. By the second round the product was clearly better, one dimension had gone backwards, and another had not moved at all. That is not a failure of the scorecard. That is the scorecard doing its job.

"I don't even think to use it sometimes."

Jake Ferrara, StreetSmart Insurance

At the same agency, staff said their team would not know the chat history existed. At another, an agent only learned that task importance flags existed when we showed them.

Dimension Round 1 Round 2 What moved it
Trust Yellow Yellow, Up Clearer failure messages read as neutral rather than negative
Applicant context accuracy Green Green Switching clients mid-conversation stopped being a risk
Client-facing accuracy Red Yellow Remaining errors narrowed to reporting terminology
Effort to get an answer Green Green Agents stopped restating who they meant
Answer usability Yellow Green The fixed template shapes made summaries reusable as written
Time saved Yellow Green Renewals and account catch-up named as daily wins
Draft quality Yellow Green Drafts kept rather than deleted and rewritten
Reliability Red Green Failure handling described as more graceful than before
Repeat reliance Yellow Red One agency's use spiked around check-ins and fell between them
Discoverability Red Red The hardest problem, and the last one to move

Iterations

The Three Questions We Had to Answer

Three threads ran through the whole project: where EVA lives, how EVA answers, and what EVA can do. One of them is still unresolved, and it is the one I argued hardest for.

A. Where should EVA live?

I made a documented, defensible call on panel placement and won the argument. Agent feedback since then has reopened it, and it is the one thread here with no ending yet.

01. The Decision

Right side was the obvious answer and the wrong one

Direction was to put EVA on the right, matching Copilot and every support panel agents had used. But the right side of EZLynx already carried notifications, tasks, document previews and more. With the client information panel open on the left at the same time, the central working area would have been squeezed to nothing. Architecture confirmed the right side was also the harder build.

Left placement, documented rather than argued

I built a written pros and cons comparison rather than debating it in a meeting. Left won on four counts: it avoided panel conflicts, it was the cheaper build, agents already look top-left for search so the trigger sat where their eye goes, and it allowed a clean toggle between EVA and client information in a single space. I named the two costs honestly: an unfamiliar convention and a learning curve.

The learning curve was real

First-round feedback was blunt. Left placement went against learned behaviour and was reducing adoption. Panel interactions were interrupting workflows and hiding information agents needed while the conversation was open.

I did not move it. The reasoning behind the original call had not changed, the right side was still crowded, and early-pilot friction with a new interface is not the same thing as a wrong decision.

It is not a learning curve. It is a mental model.

The feedback did not fade the way early-adoption friction usually does. And when agents explained it, they were not saying “I am used to the right.” They were saying that the right side is where they go when they need to put information into a panel. That reads like a rule about how the whole product works, not a habit about one feature.

A learning curve you can wait out. A mental model you cannot. Working out which one this is has become the actual question.

Still on the left, and back under discussion

The panel shipped on the left and is still there. The feedback has reopened the question, and we are in the early stages of working through it. No decision has been made.

Two directions are on the table. Moving to the right, which means solving the crowding problem rather than designing around it. Or a floating panel, which would let EVA sit where agents expect an input panel to be without competing for space with the notifications, tasks and document panels already docked there.

The second option interests me more, because it treats the original constraint as the thing to design past instead of a reason to pick a side.

The related problem: nobody finds it

Discoverability was red in both rounds and is the only dimension that never moved. Agents who use EVA love it. Agents who forget it exists never get that far. One agency’s own staff said the assistant blends into the interface.

The fix is not another entry point. It is putting EVA where the work starts rather than waiting to be opened.

B. How does EVA answer?

Speed, honesty and shape. This thread produced the biggest trust gains and the finding I think about most.

01. The Problem

Too slow to beat three clicks

On easy lookups agents were consistently faster navigating EZLynx themselves. It did not matter that the answer was correct. If getting it took longer than doing it manually, agents did it manually, and every slow answer was a small argument for closing the panel.

Cut the response time in the next release

The clearest objection from the pilot got the most direct answer. We prioritized response speed in the following release rather than adding features, because no amount of capability compensates for an assistant that is slower than the thing it replaces.

We also added progress text during processing, since silence on a slow response reads as broken rather than busy.

EVA refused work it could actually do

Agents were being told EVA could only help with insurance-related questions, in response to questions that were plainly about insurance. Worse, some quietly stopped asking that whole category of question and never tried again.

"An initiation to just abandon the question and go on to the next one."

CJ Burk, Lauber & Will Insurance, on how the old flat refusal felt

Show your work, even when you fail

Failure messages now say what EVA searched for and which queries it tried. That single change turned dead ends into rephrases, because the agent could see exactly what to say differently. Where EVA genuinely cannot help, the customer service template gives real contact details rather than an apology.

"It actually parsed out exactly what it was searching and the different queries it was using to find the information. I thought that was helpful."

CJ Burk, Lauber & Will Insurance, after the change

Sources where agents actually look for them

Testing showed agents looked for sources in a dedicated box below the response, not inline in the text. Source links now open the exact record the answer came from, so verifying costs one click. When there are four or more, the box expands and collapses rather than growing forever.

"You can click on the source and it'll take you right to the policy. I do think that's nice. Saves a couple clicks."

Adam, Lauber & Will Insurance

The templates earned their keep

Because each question bucket had a defined response shape, agents could scan an answer between phone calls instead of reading it twice. Policy status in two or three sentences. Account summaries in the same structure every time. History grouped by category rather than listed by date.

By the second round, agents were pasting EVA’s renewal summaries straight into client notes without editing them. Answer usability moved from yellow to green.

A confident zero is worse than an honest "I don't understand"

An agent asked how many of their accounts were with a particular carrier. EVA said zero. The real number was not zero. The word “carrier” did not match the field name used in agency-wide reporting, and EVA answered the query it understood instead of flagging the one it did not.

A wrong zero does not invite a retry. It sounds like an answer. A separate agent got a confident refusal on a different filter, took it at face value, and never rephrased. Both cases point at the same design rule, and it is the one I would put above all the others.

"It seemed confident that it couldn't give it to me. So, that's when I tried asking it a different way."

Adam, Lauber & Will Insurance

Before and after comparisons of an EVA refusal message and of a free-form answer versus a templated answer with sources.

C. What can EVA do?

The pilot’s loudest message was that answering questions was not enough. This thread is the move from assistant that tells you things to assistant that does things.

01. The Problem

EVA could describe the work but not do it

Agents kept asking for the same three things: create the task, draft the email, write the note. Every session, at every agency. Meanwhile they were losing 15 to 30 seconds per email filing 10 to 30 emails a day by hand.

Drafted notes and tasks, with a confirm step

EVA summarizes a communication and drafts the note or task from it. Critically, it asks before saving rather than saving automatically. That confirm step is what made agents comfortable letting it near the client record, which is a shared document their colleagues rely on.

"I just felt like it was smooth and it worked every time I tried it."

Adam, Lauber & Will Insurance

Auto ID cards by email and text

Sending proof of insurance is a daily task, roughly one per person per day and up to five on a busy one. EVA now drafts the outbound message and presents it for review with the recipient. Where an account has several email addresses or mobile numbers, it shows them and lets the agent pick, and there is a designed state for when there are none on file.

The renewal note, which is the one that actually landed

Pulling premium change figures for a renewal used to mean digging through the retention centre and typing them into a note by hand. Now it is one question and a save. One agent rated it five out of five and said it changes his day, on every single client.

"Now I can just ask EVA, spits it out to me in 10 seconds, saves it as a note. I've saved a ton of time, and that's on every single client."

CJ Burk, Lauber & Will Insurance

The selection cards finally shipped

The applicant and policy cards I designed early on did not make the first build. During the pilot an agent asked a question on an account with six policies, got a plain bulleted list back, and had to type which one he meant.

Both card sets shipped in a later release. It is a small interaction, but it is the difference between structured disambiguation and a conversation that makes the agent do the work.

"It listed them, but then you still have to type which one."

Adam, Lauber & Will Insurance, before the cards shipped

Managing work, not just creating it

EVA can create a task but not close or append to an existing one, which two agencies raised independently. The direction agents keep pointing at is broader than that: read the inbox, triage it, tell me what needs doing today. Each new capability goes back to the same pilot agencies first and only goes wide once the feedback supports it.

For this next stage, I have started using Claude Code to explore concepts for new features and experiences internally, before they go to the pilot agencies or to engineering.

Final Solution

EVA Assist has shipped across three releases. The pilot never closed, and it has grown to 12 agencies and more than 125 agents. Each new capability goes to them first and only goes wide once the feedback says it is ready.

It answers in designed shapes

Ten response templates, each matched to a type of question and each annotated as a build spec. Agents learn the shapes, which is what makes an answer scannable between calls.

It knows where you are

EVA anchors to the record you have open, shows which client it is answering for, and follows you when you move. Agents stopped restating who they meant, which was the most-requested change from the first pilot.

It lets you click instead of type

Ambiguous questions return selection cards, not a request to rephrase. Applicant cards handle nicknames and co-applicants. Policy cards cover auto, home, business liability, motorcycle, boat and RV.

It shows its receipts

Sources sit in a dedicated box below the answer, where testing showed agents look for them, and each one opens the record it came from.

It fails out loud

When EVA cannot do something it says what it tried. When it genuinely cannot help, it routes to customer service with real contact details rather than apologizing.

It does the work, then asks

Notes, tasks, auto ID card emails and texts are drafted and presented for review. Nothing saves or sends without an explicit confirm.

What Agents Said

"I would still use it every day if you guys made zero improvements from today."

Adam, Lauber & Will Insurance

"Right now where we are with EVA, I think it's indispensable."

CJ Burk, Lauber & Will Insurance, unprompted, in the same session

Two people used the word indispensable in one session without being asked to rate anything. That is the moment I knew the trust work had landed. It is worth saying where that confidence was concentrated: renewals and account catch-up. Both are tasks with a slow, obvious manual baseline to beat. The assistant earned its trust by winning clearly in a narrow place first.

Take Aways

Design the Response, Not Just the Chat

The most important design surface in an AI assistant is the answer itself. Rather than relying on the model to determine how information should be presented, I created a library of response templates for each question type. This gave the AI team clear implementation guidance and provided agents with consistent, predictable outputs they could learn and trust.

Confidence Must Match Certainty

Trust is not just about accuracy. It is also about communicating uncertainty appropriately. During the pilot, we found that agents were more likely to validate responses when the system acknowledged limitations. When confidence in the interface exceeded confidence in the underlying data, trust eroded quickly. Designing transparent uncertainty became as important as designing successful answers.

AI Chat Interfaces Can't Be Prototyped

A traditional prototype can test navigation and interaction patterns, but it can’t test the quality of AI-generated responses. The only meaningful evaluation came from putting EVA in front of real agencies and observing how it performed against live customer data and real-world workflows.

Continuous Validation Beats One-Time Research

The decision to keep the pilot running after launch proved more valuable than any individual research study. It allowed the team to track how trust, usage, and reliability changed across releases rather than relying on a single snapshot in time. Ongoing participation also became an unexpected measure of product value, with retention emerging as a strong indicator of whether improvements were resonating with agencies.

Learning Curves and Mental Models Are Different Problems

One of the most debated decisions was placing EVA on the left side of the screen. Initially, I viewed the unfamiliar placement as a learning curve. Pilot feedback suggested it may instead conflict with an established mental model about where users expect supporting panels to appear. The lesson was that users eventually adapting to a design is a hypothesis, not evidence, and should always be validated.

Use AI for Scale, Not Judgment

AI accelerated the high-volume parts of the project, including research synthesis, question clustering, documentation, and session analysis. However, the critical decisions remained human: defining response patterns, interpreting findings, prioritizing opportunities, and determining product direction. AI increased speed, but judgment remained the responsibility of the designer.

Adoption Is Won in Everyday Tasks

EVA performed well on complex questions from the start. Adoption challenges came from everyday tasks where agents could already find answers in a few clicks. Improving adoption required focusing on speed, reducing friction, and solving a small number of high-value tasks exceptionally well before expanding into broader use cases. The greatest competition was not another AI product. It was the workflow agents already knew by heart.