Rolling out an AI Agent doesn’t just change how your team works – it changes who your team is.
I learned that in the crucible of a fast-moving launch. Before we launched Fin publicly, our Support team became its first alpha/beta tester and we had to move fast. No roadmap. No step-by-step guide. Just a powerful new technology, and a steep learning curve.
That experience is exactly what led us to create The AI Agent Blueprint – a resource we wish we’d had when we were starting out, and one we hope will give other support teams a clearer path forward.
Looking back, I won’t lie and say I was cool, calm, and confident about how to do this – I was nervous as hell. I had no idea how to implement an AI Agent and ensure it resulted in huge cost savings and stellar customer experiences.
We had older machine learning technology available to us (shout out to our first-gen chatbot, Resolution Bot), but as a complex software business, we really only used it for basic FAQs. In all honesty, we still had a way to go – both in using automation more effectively and in making the chatbot experience actually enjoyable for our customers.
So why the urgency?
When ChatGPT burst onto the scene nearly three (!!) years ago, Intercom’s Machine Learning team immediately spotted the opportunity and dived into building the world’s first (and objectively best) AI Customer Service Agent.
Suddenly, we were being asked to pilot this brand new technology with real customers and go all in ASAP. Because we were selling this powerful new functionality, we had to use it ourselves and show it off in the best possible light so customers would want to use it too. #nopressure
There was no playbook, just a lot to figure out. As a product management leader, I had to switch into rigorous product discovery while staying execution-minded.
Steady involvement, rising resolutions. From February to July, teams maintain a high 87–93 involvement range as resolution rates climb from 65 to 82—signaling how AI-driven workflows can boost support efficiency and outcomes.
How do we do a phased rollout, but scale very quickly?
How do we QA Fin’s responses and make continuous improvements?
How will we produce and manage all the content Fin needs?
What will we do about all the outdated content we already have?
What are the success metrics now? Should they be different to original Support KPIs?
Who’s responsible for the success metrics? Who manages this newcomer to our team?
It was daunting. We had to take a brand new technology, figure out how to use it, build a team around it, and move at breakneck speed to implement every new feature that rolled out. It was ambiguous, fast-moving, and a massive lift.
But we got there and the results speak for themselves: Fin is now resolving over 75% of our inbound support volume.
An isometric blueprint reveals how an AI agent powers modern support—from triage to resolution—linking chat, knowledge, and workflows so teams scale service without losing accuracy, context, or the human touch.
That outcome didn’t happen by accident. We embedded forward deployed engineers with Support, treated our AI Agent like a product creator in its own right, and used gen ai for product prototyping to tighten our iteration loops. We prioritized a customer support AI strategy that balanced containment with quality: containment rate, CSAT on AI-resolved conversations, first-response latency, and recontact rates became our core scorecard.
That success led to real change for me and my team: new roles, new responsibilities, and new career paths. I now run a whole new function that didn’t exist before: AI Support. We’ve created new and elevated roles like Conversation Designers and Knowledge Managers. Fin hasn’t just changed how we support customers – it’s transformed the structure of our team and the trajectory of our careers.
And now, we’re helping our customers do the same.
In all transparency, if I hadn’t been this close to the work, I might have waited to see how generative AI played out before committing. I might have waited for a blueprint for how to deploy and scale an AI Agent. I wish I had something like that when we got started, or even later when we had a solid foundation but needed to scale our AI strategy.
How much less scary would it be to implement an AI Agent if something like that existed?
Whether you’re just getting started or already using AI in some way, you’re not early anymore—and you shouldn’t have to figure it all out alone. Strong product management leadership, a clear change plan, and tight feedback loops are what separate experiments from outcomes.
That’s why we created The AI Agent Blueprint – a practical map for launching and scaling AI in support. It brings together everything we’ve learned from our own journey, and from working closely with our customers who are doing the same.
If you’re ready to operationalize gen ai in support, align on the right metrics, and redesign roles for the future, this blueprint will help you move from pilots to pervasive impact with confidence.
Bold, pragmatic bets separate teams that merely deliver from teams that truly accelerate. As a product leader, I’m drawn to decisions that reduce friction, empower engineers, and compound over time. Intercom’s recent investment in a new frontend direction is a standout example of this mindset—and it offers lessons any product, engineering, or design leader can apply.
Over the past two years, Intercom made one of the most significant changes an engineering organization can make: moving its core frontend from Ember to React. That choice fits a clear pattern of high-agency decision making in service of speed, quality, and developer experience.
Back in 2014, Ember was the right call for their main application. Its strong opinions and “batteries-included” approach aligned with a strategy I respect: make big decisions once, enable teams to move fast, and spend energy on customer problems instead of endless architecture debates. The result was scale few achieve—more than two million lines of code and 100,000+ pull requests merged.
I’ve been in the room when constraints outgrow the original bet. By 2023, “local builds stretched beyond 90 seconds,” and they were stuck on older framework versions that blocked adoption of modern build tools. Even with deep community engagement and contributions to the Embroider Initiative, the cost of staying put was compounding. Something had to change.
What I admire is the rigor behind their pivot. They ran workshops, health checks, and set explicit trigger conditions—then honored those triggers. When the evidence crossed the threshold, they chose a new path and framed the work with a clear, galvanizing banner: “The Future of Frontend.” That’s the kind of governance and narrative clarity that de-risks large platform shifts.
React quickly emerged as the right fit—not because of hype, but because it met practical criteria at scale. “React was already a core technology at Intercom (powering Messenger, Help Center, and our marketing site),” backed by a robust ecosystem, strong documentation, and broad familiarity internally and across the industry. Most importantly, it integrates naturally with AI-driven developer tools—a non-negotiable for the next decade of engineering productivity.
Fast forward to today, and the momentum is clear. “React is now the default for new UI development at Intercom.” That single sentence says a lot about organizational alignment and execution readiness.
The outcomes speak for themselves. “Blazing fast feedback loops: React builds in under 10 seconds locally, with sub-1s rebuilds – much faster than our Ember app’s 90+ seconds.” That kind of drop in cycle time unlocks more iteration, tighter designer–engineer collaboration, and faster learning loops.
Speed without joy is a half-win. “Higher developer velocity: Engineers consistently report being faster, happier, and more effective, particularly when paired with AI tools like Cursor, Augment, and Claude Code.” I’ve seen similar effects: once teams feel flow again, quality and ambition both rise.
Adoption at breadth matters as much as depth. “Wider adoption: Since March 2025, 10+ Product teams have shipped React features, contributing over 840 pull requests.” That level of traction signals a platform shift that’s not just technically sound but operationally viable.
The AI-enabled developer experience is the real unlock. “AI synergy: React just “clicks” with modern AI tooling. Designers and engineers are using agents to write code, generate components from Figma, and even build design playgrounds themselves.” That’s the future: product creators working in shared, generative environments where ideas move from Figma to code in minutes.
One engineer captured the productivity gain perfectly: “The work I had predicted would take me a week to achieve took me two days”. That’s not a marginal improvement—that’s a step-change.
This story isn’t just about frameworks; it’s about preparing for a decade where velocity, AI-native workflows, and developer experience determine competitive advantage. The ambition to “double our productivity over the next 12 months” requires removing friction, leaning into AI, and standardizing on tools that compound learning across teams. React is a pragmatic enabler for that journey.
I also appreciate the organizational design behind the change. A small, focused group—Team Frontend Tech—partnered tightly with Product teams to shape the new stack, build a design system, and accelerate adoption. That model creates a high-trust bridge between platform and product, which is essential for landing a migration at scale.
For leaders navigating similar crossroads, the playbook is clear: set explicit trigger conditions, articulate the future state, pick a stack that compounds with AI, and invest in a cross-functional nucleus to shepherd adoption. For engineers and designers, this is an exciting moment—one where your tools finally catch up with your ambition.
The takeaway I’m carrying forward: make the bold call when the evidence is conclusive, optimize for feedback loops and flow, and treat AI as a first-class partner in the creative process. That’s how we keep shipping fast, raise the quality bar, and focus on what really matters—solving meaningful problems for customers.
Over the past 18 months, I’ve watched the ground shift under support leaders. For many support leaders, the world before and after AI feels drastically different—and I feel it too.
Rewind to before Q1 of 2023, and while the details varied, the challenges support leaders faced were largely the same as they had been for decades. Before AI, support leaders were tasked with improving the customer experience with under-resourced teams; finding ways to improve the cost-to-revenue ratio; preventing team attrition (despite managing people with difficult jobs and low compensation); and representing customers’ needs to teams with competing priorities.
Support was expected to operate behind the scenes, often absorbing work from other departments. Despite being essential for customer retention, it was still viewed primarily as a cost center, and leaders rarely had strong executive advocacy. Those conditions sharpened valuable muscles—creativity, scrappiness, and people leadership—but they didn’t prepare most teams to operate in an AI-first world.
Now with AI, the mandate has expanded. The core responsibilities persist, but the “how” has changed. Leaders are suddenly expected to be AI experts, spearhead large AI implementation initiatives, and keep operations rock-solid while the plane is being rebuilt mid-flight.
They’re being asked to step out from behind the scenes to center stage and lead the company in its first large adoption of AI. They’re being asked to regularly communicate with executives who previously had little interest in their initiatives or ideas. They’re being asked to run high-lift, high-impact, cross-functional projects without the infrastructure in place to manage it. They’re also now expected to hit AI performance metrics that an executive heard somewhere were possible—targets that might be unrealistic for the actual use case.
Oh, and if they fail, they’ll likely lose their job. And if they succeed, they could cause job loss for their team members. I’ve felt that tension firsthand: accelerate AI to drive outcomes, while also protecting the humans who make your customer experience exceptional.
It’s tempting to wait for the storm to pass—to delay AI change until someone else takes it over and hope they don’t undo what you’ve built. I’ve seen that playbook, and it rarely ends well.
There’s a better approach: harness the storm’s energy to elevate your customer experience, your team, and your own influence.
Harnessing AI’s momentum
This new era can reduce your support operation to a transactional, robotic experience—or transform it into what you’ve always envisioned. The outcome depends on how you respond to the demand to implement AI. This is one of the most unique opportunities of your career: you will have your executives’ attention, unprecedented access to product and engineering resources, and far less friction persuading stakeholders that change is essential for customers and the business.
With the right plan, you can reframe your team from cost center to value driver, expand services instead of sweating basic metrics, and move from surviving to thriving.
Here are the three areas I encourage every support leader to master.
Become the AI subject matter expert
Start by learning. Understand what is actually possible with AI now, and what may be possible in the near future. Go at least a layer or two deeper than the average person using ChatGPT. Know what it takes to implement more than a glorified answer bot—especially if your goal is end-to-end resolution, not just deflection.
Then anticipate the pitfalls I see most often in AI adoption.
Not digging deep enough with vendors. Demos often look similar and impressive with minimal lift. The truth emerges in a proof of concept. Run multiple trials with different vendors to uncover real capabilities and limitations—and to calibrate what “good” looks like for your environment.
Only finding a technology solution, not a partnership. Many tools can deliver similar outcomes; partners are not interchangeable. Choose a vendor whose values align with yours, who will support your use cases post-sale, who moves at a pace you can absorb, and who is committed for the long haul (not merely positioning for acquisition in a year or two).
Not knowing what good actually looks like. Ask each vendor about AI involvement rate and AI resolution rate. Ask what AI CSAT typically looks like in your industry. Document these answers to build benchmarks and set realistic expectations with executives.
Not learning from others’ mistakes. Many teams have overestimated AI’s impact and underestimated the human resources still required. Some laid off hundreds of support team members—only to rehire later—damaging their brand and wasting resources. Move with purpose and pace, but not so fast that you repeat these mistakes.
Not communicating your plan effectively. Be able to articulate why deflecting 50% of inquiry volume does not equal a 50% headcount reduction. Cite logistics like coverage windows and redundancy for SLAs, growth needs, natural attrition, and all the non-inquiry work your team handles. Practice a concise, compelling rationale for executives.
Create a clear AI plan
Your company is in uncharted territory. Unless you’ve hired a specialist recently, none of your executives have deployed AI in support. That makes you the most qualified person to draw the map and lead the way. Here’s what your plan should include.
1) A vendor evaluation plan. Define how you’ll research providers, who advances from demo to trial, how many you’ll test, and in what timeframe. Establish criteria for what AI must accomplish and the effectiveness and quality metrics you’ll use to evaluate it.
2) Implementation phases. AI is not a “set it and forget it” tool. Because AI touches customers so quickly, mitigate risk with phased rollouts. Phases don’t have to be slow—just deliberate. Sequence by audience, use case, and channel, and publish a clear timeline so cross-functional partners can plan resources.
3) How you’ll measure success. Reuse your evaluation metrics and go deeper. Track AI involvement rate and AI resolution rate (together, your deflection rate). Measure quality through CSAT and CX Scores, and run regular QA. Quantify impact on your support cost-to-revenue ratio—your CFO cares deeply about this.
4) How your team will use reclaimed time. If your AI program frees 20% of capacity, what value will you create? How will you improve the customer experience, drive revenue or retention, and upskill your team? Quantify the upside and set milestones for capability-building and value-added work. If you fail to plan this, you will be pushed to let too many people go.
5) How you’ll report on progress. Communication failures sink AI programs. Align with your executive sponsor on format and cadence, then over-communicate—regularly, clearly, concisely. You can’t afford to under-communicate.
Own the initiative at a higher level
Support leaders are great at taking ownership, often absorbing projects other teams drop. This initiative is different: it’s highly visible and enterprise-critical. Treat it like a flagship product rollout.
Project management. Use a tool your team can execute in and that lets you summarize progress succinctly for executives. Borrow best practices from your product managers and signal early that you’ll be partnering with them. Learn your sponsor’s preferred update style and tailor to it.
Communication. Overcommunicate—with brevity and rhythm. Don’t let a week pass without your sponsor knowing status. For executives, I recommend weekly or bi-weekly updates with a one-line summary, three impact statements, and a link to the plan. For example: “Saved customers 30K waiting hours M/M,” “Improved full resolution time by 30% M/M,” “Next initiative will improve X metric by Y%.”
Showcase your thought leadership. Reference industry benchmarks proactively when you set goals, and reactively when questions arise. Having succinct, data-backed answers that tie to benchmarks signals expertise and builds trust.
The storm is here—what will you do?
The pressure around AI is intensifying and isn’t fading anytime soon. This storm can crush your team as you know it—or become the wind under your wings that elevates your support operation to its maximum potential. The choice is yours: wait and risk cuts, or step up as the support AI expert, form a plan, and transform your team into a value engine. I’ve chosen the latter—and I invite you to do the same.
At Pioneer 2025, Fin 3 was announced as the most capable AI Agent yet for resolving deep, complex queries across every channel. As a VP of Product Management, I’ve been eager to see whether an agent can match concierge-level service at scale—and this is the first time I’ve seen the pieces come together in a way that genuinely raises the bar for customer experience and operational efficiency.
The goal is simple and ambitious: give customer service teams the tools to deliver concierge-level service to every customer, every time. To do that, the team built Fin 3 and invested deeply in the Fin Flywheel—train, test, deploy, and analyze—so the system learns faster, behaves predictably, and performs consistently across channels like Voice, Slack, and Discord.
The evolution here matters. We’ve come a long way since we launched Fin 1 just over two years ago. It was the very first AI Agent for customer service and focused on using your knowledge content to resolve informational queries, enabling it to do all frontline support and free teams to do higher-level work. Then we launched Fin 2. It answered the question of whether AI Agents could deliver human-quality service (it could).
Since we launched Fin 2, its average resolution rate has continued to climb to 66% across our 6,000+ customers. Over 20% of our customers are getting above 80%.
Those numbers are impressive, but they revealed an important truth I’ve seen across many product organizations: resolution rate isn’t the whole story. Answering a quick FAQ in chat isn’t the same as investigating a payment dispute or verifying a refund over the phone. The real measure to optimize is automation rate—the share of overall workload handled end-to-end. Fin 3 is built for that frontier, with a focus on two levers: solving increasingly complex queries and expanding into more channels.
Procedures are the big breakthrough for training. They let teams encode multi-step workflows and nuanced business logic—like troubleshooting login issues, handling return requests, or investigating potential fraud—so Fin can resolve them from start to finish. In practice, that means Fin is trained to follow your standard operating procedures carefully while exercising judgment just like a seasoned teammate.
1. Natural language instructions
Teach Fin the same way you’d train a new teammate. You can copy and paste your existing SOPs straight in (most support teams already have them written up in Google Docs or Notion) and describe how Fin should act using natural language. The editing experience feels familiar and lightweight, so teams can start writing Procedures immediately without needing engineers or special syntax.
2. Deterministic controls
When a Procedure needs more structure or precision, you can layer in deterministic elements. Data connectors let Fin check information or take actions directly in your tools. Conditional steps handle decision points (for example, whether a refund should be approved) so Fin’s behavior is consistent and predictable. And when absolute accuracy is essential, you can add small code snippets that guarantee the same input always produces the same output. You can also add checkpoints where Fin pauses for approval or hands off to a teammate before taking certain actions, keeping sensitive workflows under human control.
3. Fully agentic behavior
Conversations rarely follow a happy path. Procedures are designed so Fin reasons in real time, moves up and down steps, or switches between Procedures without getting stuck. If a customer changes an answer, Fin adapts and continues naturally. The result is a fluid conversation that still follows your process end-to-end.
4. AI Assistant support
AI Assistant helps teams write and maintain Procedures faster. You can start with a brief overview and supporting documents; it drafts an initial version based on what Fin already knows from your knowledge base and past conversations. As you expand, it suggests additional controls or generates boilerplate code for API connectors, lowering the barrier to entry and accelerating iteration.
Together, these elements let Fin reason like a human with the precision of software. Most teams can begin with no-code or low-code Procedures and bring in engineering only for advanced integrations. That balance of power and control is exactly what high-performing support leaders need.
“Support needs natural conversation and control. Procedures optimize for both – agentic where you want it, designed where you need it – rather than a generic agent builder.”
– Chris Dalley, Director of Product Management at Intercom
Of course, adding agentic power requires robust testing. That’s where Simulations come in. Real-world workflows explode into dozens of paths across policy thresholds, customer states, and edge cases. Manual testing won’t scale, so Simulations let you pick any Procedure, choose a user or segment, and run a full, multi-turn simulated conversation from start to finish. You see exactly how Fin reasons and where to refine, then re-run as needed.
AI Assistant is integrated here too. If a Procedure needs an adjustment, it suggests changes you can accept with a click. It also recommends additional Simulations for complex Procedures to ensure coverage. As you create scenarios, you store them in a Simulation library so that when products, policies, or teams change, you can run the entire suite to catch regressions early. This is how you build confidence that Fin behaves exactly as intended while your automation expands.
Channel coverage is equally critical for customer service. Customers expect help wherever they are. Fin already works across more channels than any other AI Agent, and now it extends to Slack and Discord with meaningful upgrades to Voice.
Fin in Slack feels native—threaded replies, proper formatting, and controls to determine when Fin responds versus when a human steps in. If a teammate joins, Fin automatically steps back. Every interaction is logged for reporting and analysis, which matters when you’re tuning automation rate and resolution quality.
Discord support brings the same benefits to communities that increasingly serve as support hubs. Meeting customers where they are is how you compound both satisfaction and efficiency.
Voice has evolved dramatically since launch, and this matters because phone expectations are different. Rather than waiting on hold, navigating IVRs, or getting one-word answers from a brittle bot, customers get immediate, natural conversation. Since we launched Fin Voice, we’ve added much more power and configurability: better guidance, more customization, better testing and deployment, and call transcripts and summaries. These make Voice practical to run at scale.
Voice isn’t just chat with speech. Latency must be low because long pauses feel wrong. Answer shape matters—shorter, chunked replies outperform long paragraphs. Interruptions and endpointing are the norm, so the Agent must detect when to talk and when to listen. And cost pressures are higher on phone, which makes automation even more valuable.
How natural the Agent sounds shapes customer trust. When a voice bot sounds robotic, people assume it’s limited and escalate immediately. Fin avoids that by speaking naturally, pacing correctly, and adjusting tone as it listens. It can detect sentiment directly from audio—laughter, frustration, or urgency—and respond with empathy to keep conversations on track.
“We’ve seen that how natural the Agent sounds signals to people how smart it is. If it sounds robotic, they escalate immediately – especially on phone where issues are more urgent.”
– Peter Bar, Principal Product Manager at Intercom
Performance has improved significantly, with latency down around 30–40% since launch—conversations now feel fluid rather than stop-start. Unlike voice systems that falter against large help centers, Fin handles real-world knowledge bases at scale using the same reasoning engine that powers chat. Fin Voice is multilingual out of the box and can currently answer calls in 28 languages, with configurable voices and greetings. You can tailor how it operates day-to-day, from call start to escalation rules and office-hour routing. Every call is logged automatically in Intercom, complete with a transcript, summary, and outcome, giving your team full visibility to review performance and refine over time.
Practically, this means Fin can take on more of the phone workload—triaging calls, summarizing transcripts, and handing off cleanly when needed—reducing average handle time and freeing agents to focus elsewhere. Because Voice runs on the same foundation as chat, improvements to Fin’s knowledge apply everywhere, creating consistent behavior across channels.
“Customers often say they’re amazed it’s not a real person – Fin Voice sounds natural, responds in context, and doesn’t feel robotic at all.”
With Fin set up to tackle more complex queries across more channels, the next question is measurement—how well is it working, and where should you improve? The Insights product answers this with upgrades to CX Score, Topics Explorer, and AI-powered Suggestions.
CX Score gives a unified view of support quality across interactions. The new CX Score Reasons provide a more representative and transparent picture—was a low score driven by product feedback or answer quality? These attributes are built into reporting for full filtering and segmentation, which is essential for targeted improvements.
Topics Explorer analyzes and organizes every conversation into topics and sub-topics to reveal what’s driving volume and impacting quality. The new Topic Trends report highlights the most important weekly changes—volume spikes, drops in Fin resolution, and emerging issues—so teams can act before customer experience is impacted. You can now curate topics with merge, rename, move, and create controls, then get AI-powered reporting on the areas you care about most.
AI-powered Suggestions close the loop by proposing exact, ready-to-publish updates to your help content based on what your support team is saying. Suggestions now spots duplications and contradictions, learns from rejections to improve future recommendations, provides one-click updates if you use Zendesk or Salesforce, and proposes changes to data, actions, and guidance—not just content. That last capability is especially important because it helps you unlock higher automation on complex queries.
Fin 3 builds on everything learned since the first AI Agent for customer service launched in 2023. It’s trained through Procedures, tested with Simulations, deployed across every major channel including Voice, Slack, and Discord, and measured through richer Insights. All of it adds up to a simple outcome: Fin now does more of the work for you, resolving the complex, time-consuming queries that used to belong only to humans.
Learn more about Fin 3 here: https://fin.ai/fin3 . Some capabilities are available now, with the rest rolling out quickly. From a product leadership perspective, the takeaway is clear—optimize for automation rate, govern with Procedures and Simulations, expand channel coverage, and instrument with Insights. That’s how you deliver concierge-level CX at scale with a single AI Agent.
At Pioneer 2025, we shared our most ambitious goal since we first set out to build Fin. I’ve spent my career building products that remove friction, and this is the boldest, most consequential shift I’ve seen for customer experience in years.
Fin will not be just the world’s best Customer Service Agent. It will be the world’s best Customer Agent, capable of handling the entire customer experience.
We’ll continue to obsess about Fin’s ability to support your customers, but now we’re broadening our focus. Fin will be able to contact your customers for the very first time; hold their hands through consideration and purchase; be there with them at every step; and know everything about their life with your business. That’s the level of continuity, empathy, and performance I expect from a truly unified AI Agent.
It’s a big shift, and it reflects the changing future of customer service and experience. As someone who lives at the intersection of product strategy and operations, I see an incredible opportunity for teams to elevate their impact.
Customer service leaders have been at the forefront of the AI transformation for the past two plus years. As this next evolution plays out, you’ll be uniquely positioned to lead how AI powers the entire customer experience. Your playbooks, data discipline, and operational rigor are the blueprint for what comes next.
You can watch the full Customer Agent keynote from Pioneer 2025 here.
Why we believe in the Customer Agent future comes down to two clear ideas that I’ve witnessed in practice across multiple organizations.
1. Multiple AI Agents will destroy the customer experience
We know that AI isn’t just changing customer service. Other teams like sales, success, and marketing are seeing the potential and starting to adopt it too. But if every function deploys its own Agent, you’ll end up with competing priorities, fragmented context, and inconsistent brand voice—exactly the kind of friction customers notice instantly.
But if all of these teams use their own AI Agent, you’ll end up with a mess of competing Agents that will destroy the customer experience. Each one will have its own priorities and configuration parameters; they won’t talk to each other or share customer information by default, and will likely engage with customers in different ways. This is a trap we need to avoid.
2. A truly exceptional customer experience is finally possible
If we can avoid that trap, we’ll finally be able to provide the type of seamless experience that customers have long expected, and long deserved. The AI Agents of today, like Fin, are capable of handling many different use cases across the entire customer journey: lead qualification, onboarding, support, success, and upsell. That opens the door for the first time to previously unimaginable customer experience; one that’s truly seamless, personal, and concierge-level.
We’ve reached another turning point in AI’s trajectory, and for customer service leaders, the opportunity around the corner is huge. In my own teams, the leaders who lean in now will shape standards for governance, measurement, and ROI across the business.
Customer service has been the proving ground for AI transformation. The systems, strategies, and learnings leaders in this space have accumulated over the last two years can define how AI is adopted by other functions. The keynote made this clear: you have the opportunity to lead how AI is rolled out across your organization, not just in customer service.
You already manage the most complex, high-volume customer interactions; you have rich data on customer needs and behavior; and you know how AI Agents perform in the real world. Those insights will be invaluable as AI scales across your business. The Customer Agent future will elevate the role of the customer service leader and give you the opportunity to lead AI implementation across the entire customer journey.
To achieve this vision of Fin becoming a unified Customer Agent, it will need to evolve from being a task-based system into a true agentic system that uses AI to make decisions and pursue high-level objectives. That shift—from task execution to outcome ownership—is the inflection point I’ve been anticipating.
Roles: Fin will have a range of roles (customer service being one) that it can fluidly move between and blend together. Each role will be deeply trained to be a world-class expert at what it does.
Goals: Fin will also have goals to pursue. You’ll be able to tell it your objectives and priorities (for your customers, company, and revenue) and Fin will pursue them, making appropriate trade-offs between goals as needed.
Memory: Fin will develop memory that persists and grows over the customer lifecycle, building deep context of who the customer is and what they’re trying to achieve. The customer priorities it learns on day one will be considered in year 10.
Knowledge: Fin will accumulate deep knowledge of your business – every product detail, policy, process, your history, and plans – to act on a complete view of your customer.
Interoperability: Fin will interoperate with different tools, systems, and channels.
This system will be able to do much more than answer questions or complete tasks. It will adapt on the fly, learn to get better, and use all the context it has to efficiently guide each customer to great outcomes. That’s how we turn AI from a helpful assistant into a dependable operator.
The Customer Agent vision isn’t a far-off idea. Many of our most pioneering customers have started to put Fin to work beyond customer service. They’re using it across the customer journey and want to push it further by applying it to other use cases to create a single, seamless customer experience. I’ve seen this expansion accelerate once leaders prove value in one high-stakes workflow.
Here’s an example: fitness wearables company WHOOP, facing one of their biggest product launches ever, needed a way to handle a very large influx of sales conversations. They used Fin to help manage this surge, and it’s now resolving 84% of their sales conversations.
These early examples show how Fin is already capable of handling multiple use cases across the customer journey. The signal is clear: a unified Customer Agent can drive measurable outcomes in both revenue and retention.
The Customer Agent future will be built from the inside out, starting with the customer service leaders who have been pioneering AI transformation since the very beginning. Your frameworks for quality, escalation, and measurement will set the bar for every other team that follows.
You know how to balance powerful AI with human empathy, and how to translate that into great customer experiences. Other teams will look to you, and you have the ability to lead them through this transformation. In my experience, this is the moment to define standards, instrument the journey, and scale wins deliberately.
The very best brands compete on customer experience. The Customer Agent opens that playing field for the brands that jump first. Those who move now will own the new benchmarks for responsiveness, personalization, and ROI.
We’ll be starting to roll out this new functionality to Fin – roles, goals, memory, knowledge, interoperability, and more – over the coming months. Stay tuned.
Your team has a polished GenAI prototype. The review goes well. Then the hard questions arrive: Which customer behavior should change? How often does the system fail? What context does it need? Who owns prompt and model changes? Can you release it without creating a permanent escalation queue?
The gap between an impressive demonstration and a dependable product is usually an operating-model problem. A useful GenAI discovery model connects customer evidence, system evaluations, field behavior, and production ownership. It lets you preserve the speed of AI-assisted prototyping while making each experiment answer a real product decision.
Key takeaways for GenAI product leaders
Prove value and capability separately. Customer demand does not prove that a model can perform reliably, and a strong evaluation score does not prove that anyone will change their behavior.
Begin with a workflow, an outcome, and a bounded role for AI. A generic AI use case is too loose to guide discovery or define acceptable performance.
Maintain an evidence chain. Connect each customer story to an opportunity, each opportunity to an assumption, each assumption to an evaluation scenario, and each released behavior to a product outcome.
Run customer learning and system learning in the same weekly loop. They require different methods, but they must meet at one decision: advance, narrow, change, or stop the bet.
Centralize reusable infrastructure and guardrails, not product judgment. Product teams should own the workflow and outcome while shared capabilities provide model access, evaluation tooling, observability, and policy controls.
Start with the workflow and outcome, not the model
GenAI discovery often starts in the wrong direction. A team gets access to a capable model, generates a list of possible features, and builds whichever idea looks most compelling in a demo. The team may learn that the model can produce something plausible, but it still does not know whether the capability removes meaningful friction from a real workflow.
Reverse the sequence. Start with a person trying to achieve an outcome in a specific context. Understand what that person does now, where the workflow breaks, what consequence follows, and which constraints shape a usable solution. Only then should you decide whether generation, retrieval, prediction, conversation, or agentic action is an appropriate intervention.
Write a bet brief that can be disproved
A GenAI bet should fit into a short brief before anyone commits significant engineering capacity. Use this framing:
For a specific actor in a specific workflow moment, the current behavior makes it harder to achieve a desired outcome. A bounded AI capability may improve an observable behavior, provided it stays within defined quality, control, privacy, and safety conditions.
Make every part concrete enough to test:
Actor and moment: Name who encounters the problem and where it occurs in the workflow. A role such as support agent is not enough; identify the decision or task the person is performing.
Current behavior: Describe what people actually do, including workarounds, handoffs, rework, and information they assemble manually. Ground this in past behavior rather than hypothetical interest.
Desired outcome: Define the customer or business result that should improve. Completion, adoption, rework, escalation, abandonment, and repeat use are product signals. A model-quality score is not the outcome.
AI contribution: State whether the system retrieves information, creates a draft, recommends an action, or performs an action. These are materially different product and risk propositions.
Operating boundary: Specify the data context, permissions, supported cases, human checkpoints, and fallback path. A capability without a boundary cannot be evaluated honestly.
Decision: Write what evidence would cause the team to proceed, narrow the scope, change the approach, or stop.
Suppose the opportunity is helping a support agent respond to a complex case. Producing a fluent answer is not the unit of value. The product may need to retrieve the right account context, create a grounded draft, expose its basis, let the agent correct it, and contribute to resolving the issue without avoidable rework. That framing changes what you prototype, what you evaluate, what you instrument, and what you ask users during discovery.
Choose the smallest coherent release
The right initial scope is not the smallest visible feature. It is the smallest end-to-end experience that can produce credible evidence. A narrow workflow with real context, a clear human checkpoint, outcome instrumentation, and a recovery path is more useful than a broad assistant that performs many disconnected tasks. This is how rapid prototyping becomes a method for reducing uncertainty instead of a factory for disposable demonstrations.
Scope the first release along four boundaries:
A defined user and workflow moment.
A bounded set of data and tools the system may use.
A clear level of authority over the resulting action.
A measurable product outcome and a separate quality floor.
Authority matters because the same model behavior can create different consequences. Showing relevant information is different from drafting a message. Drafting is different from recommending that it be sent. Recommending is different from sending it automatically. As authority rises and reversibility falls, require stronger evaluations, clearer permission boundaries, better auditability, and more deliberate human approval. If an action is costly, sensitive, or difficult to reverse, keep a human checkpoint and a safe fallback in the initial operating envelope.
Keep product success, system quality, and operating viability distinct. Product success asks whether behavior and outcomes improve. System quality asks whether outputs meet defined conditions. Operating viability asks whether the product can deliver that behavior with acceptable latency, cost, support burden, and failure recovery. A bet needs evidence in all three categories before a polished prototype should influence a roadmap commitment.
Build a traceable evidence chain
There are two uses of AI in this work, and leaders should not conflate them. AI can assist the discovery process by transcribing interviews, organizing material, and generating alternative interpretations. AI can also be the product capability under investigation. In the first role, its output is an analytical input. In the second, its behavior is an object of evaluation. Neither role turns model output into customer evidence.
Preserve the customer story before looking for patterns
Good discovery begins with a specific story about past behavior. Capture the person’s goal, the context, key moments in the experience, decisions, workarounds, and the needs or pain points that emerged. Synthesize that interview on its own before combining it with other interviews. This prevents a recurring operational mistake: compressing many transcripts into generic themes that are easy to present but impossible to design against.
A practical single-interview record includes participant context, a transcript-linked quote, the sequence of important moments, and opportunities expressed within that person’s situation. Cross-interview synthesis can then organize related opportunities without severing them from their origins. This separation between individual and cross-interview synthesis keeps insights contextual, actionable, and traceable.
Use AI as a notetaker or an additional analytical perspective, but establish simple provenance rules:
Every direct quote must link to the transcript location where it appears. If the wording cannot be verified, treat it as a paraphrase or discard it.
Every opportunity must identify the participant, workflow moment, and evidence from which it was derived.
Generated summaries must be checked against the original material before entering an opportunity map or decision record.
Tone, hesitation, visible confusion, and body language must come from a human observation note when they affect interpretation; a text transcript cannot preserve them reliably.
AI-generated themes may prompt a second look at the evidence, but they do not become evidence through repetition.
If the interview itself is shallow, automation will only process shallow material faster. A model cannot recover a missing motivation, workflow constraint, or decision context that nobody elicited. When synthesis produces vague insights, inspect the interview quality before rewriting the prompt.
Connect every artifact to a decision
The evidence chain should survive the entire path from discovery to production:
A customer story supports an opportunity.
The opportunity supports a product bet.
The bet contains assumptions about value, usability, feasibility, data, trust, and operations.
High-risk assumptions become experiments and evaluation scenarios.
Evaluation scenarios become regression cases when the product changes.
Field behavior connects the released capability to product and business outcomes.
Production failures feed new scenarios, product constraints, and discovery questions.
This chain prevents evidence laundering. A customer describing a difficult workflow does not prove that a proposed solution is desirable. A user liking a prototype does not prove that behavior will change. Passing an offline evaluation does not prove that the interaction fits the workflow. A successful pilot does not prove that the system is repeatable across customers. Each step answers a different question.
Decision
Minimum artifact
Evidence that advances the bet
What to do when it is missing
Is the problem worth solving?
Interview snapshots and an opportunity map
Specific past behavior, context, consequences, and constraints
Return to interviewing or workflow observation
Can GenAI contribute meaningfully?
Assumption ledger and a thin prototype
The capability performs the bounded task on representative examples
Narrow the task, change the system approach, or stop
Can users understand and control it?
Interaction prototype and failure scenarios
Users can interpret the result, correct it, and recover from failure
Change the interaction, authority level, or human checkpoint
Does it change real behavior?
Instrumented field pilot
Observed usage changes a leading product signal without unacceptable quality loss
Investigate workflow fit, adoption friction, or the original value hypothesis
Can the product be operated?
Evaluation harness, monitoring, ownership, and rollback path
Quality remains observable after release and a named owner can respond to degradation
Keep the release bounded until the operating controls exist
Use a living bet packet instead of a presentation deck
Keep the evidence chain in one lightweight packet. It should contain the current problem frame, links to customer evidence, the assumption ledger, prototype configuration, evaluation results, field observations, outcome measures, and the latest decision with its rationale. It is not a status report. It is the memory of the bet.
A new team member should be able to see why the work exists, which uncertainty is active, what failed previously, and what would change the decision. If the packet grows without changing a decision, reduce it. The purpose is traceability, not documentation volume.
Run a weekly dual-track discovery loop
GenAI discovery has two learning tracks. The customer track investigates the workflow, value, behavior, interaction, and trust. The system track investigates model behavior, context quality, tool use, failure modes, and operational constraints. Running only the first creates attractive concepts with unknown feasibility. Running only the second produces technically impressive capabilities looking for a problem.
A weekly loop is a useful default because it keeps the customer and system evidence synchronized. It also forces the team to choose a decision small enough to advance with the evidence available. The cadence is not a sequence of meetings. It is a sequence of testable changes.
Customer and workflow learning
This track uses customer interviews, workflow observation, usability tests, pilot behavior, support signals, and outcome instrumentation. Each activity should begin with the decision it is meant to inform. Do not schedule an interview merely to gather feedback. Decide whether you need to understand the current workflow, test the meaning of an opportunity, observe a recovery interaction, or determine why pilot users are abandoning the capability.
Invite engineering into customer learning when technical context changes the solution space. An engineer hearing how permissions, data fragmentation, or exceptional cases shape the workflow can identify constraints earlier than a written handoff would. The product manager should still own the connection between those constraints and the desired outcome.
System and evaluation learning
This track needs a scenario set, not a folder of memorable outputs. Build it from ordinary customer cases, meaningful edge cases, prohibited behavior, and failures already observed. Synthetic examples can widen coverage, but they should extend a foundation of real workflow evidence rather than replace it.
Each scenario should record:
The user task and its provenance in customer or field evidence.
The input, relevant context, permissions, and available tools.
Acceptable behavior, unacceptable behavior, and the scoring method.
The model, prompt, retrieval, tool, and data configuration used.
The actual result, the failure category when applicable, and any human correction.
The product consequence of the failure, not merely its technical label.
Define acceptance criteria before reviewing a preferred prototype. Otherwise, a persuasive output can cause the team to move the standard after the fact. Automate checks when correctness is directly observable, and retain structured human review where meaning, usefulness, or trust depends on context.
Treat the scenario set as part of the product, not disposable test material. Prompt versions, retrieval configuration, model changes, data quality, and tool behavior all belong to the release surface. Evaluation harnesses, prompt versioning, red-teaming, and production monitoring therefore need to begin in discovery and continue through CI/CD. A scenario that exposes a real failure during a pilot should become a regression case before the next release.
A decision-oriented weekly sequence
Name the decision. Choose the highest-risk assumption blocking progress rather than the most convenient activity.
Inspect the evidence. Review the relevant customer stories, field behavior, scenario results, and known failures.
Design the cheapest credible test. This may be another interview, a workflow prototype, a prompt or retrieval change, a human-assisted simulation, or a bounded field experiment.
Run offline scenarios first. Find obvious quality, safety, grounding, and permission failures before asking a customer to spend time on the prototype.
Observe the capability in the workflow. Watch what users accept, edit, ignore, misunderstand, override, or abandon.
Update both records. Add customer learning to the opportunity and assumption records; add system failures to the scenario set and failure taxonomy.
Make the decision explicit. Advance, narrow, change, pause, or stop. Record the evidence that caused the decision and identify the next uncertainty.
Parallel experimentation is useful only when each experiment resolves a distinct uncertainty. Generating many prototypes against the same vague question increases activity without increasing decision quality. The advantage of GenAI is a lower cost of learning; spend that advantage on better coverage of assumptions, not a larger pile of concepts.
Promote a prototype only when the evidence changes
A prototype should not graduate because it performs well in a stakeholder demonstration. Move it toward a broader pilot only when the team can show:
A valuable workflow and outcome grounded in customer behavior.
A bounded capability with explicit supported and unsupported cases.
An interaction that helps users understand uncertainty, correct results, and recover.
Instrumentation for product outcomes, system quality, overrides, and failures.
Ownership for monitoring, escalation, and rollback after release.
Keep the value gate and the quality gate separate. A system can meet its quality threshold and still fail because it adds a step, appears at the wrong moment, or solves a low-value problem. It can also attract strong usage while producing unacceptable errors. The first result sends you back to product discovery; the second requires narrowing authority, strengthening the system, or stopping the release. Blending the gates makes both diagnoses harder.
Design the organization around decision rights and learning
A fast learning loop will stall if every product choice waits for a central AI committee. It will also become fragile if each squad invents its own model access, evaluation approach, privacy controls, and incident response. The operating model must distinguish decisions that require local customer context from capabilities that should be reusable across the company.
Keep the product trio accountable for the outcome
The titles can vary, but the responsibilities cannot remain implicit:
Product leadership owns the desired outcome, opportunity framing, assumption sequence, value evidence, and decision record.
Design and research own workflow understanding, interaction behavior, user control, comprehension, correction, and recovery.
Engineering and data own system architecture, context and data quality, repeatable evaluations, observability, reliability, and rollback.
Domain, privacy, security, and risk partners define non-negotiable acceptance conditions and escalation paths where the use case requires them.
Go-to-market and customer-facing partners help identify adoption constraints and connect pilots to real workflows without substituting enthusiasm for evidence.
No single function can answer every release question. Product cannot declare model quality by itself. Engineering cannot infer customer value from technical performance. Governance cannot decide workflow desirability. Clarify who owns each decision, which evidence is required, and who can block a release when a non-negotiable condition fails.
Use forward deployed engineers where context is the constraint
Complex enterprise workflows often hide critical information in customer configurations, permissions, data conventions, and exception handling. A forward deployed engineer can work with product and design in the customer’s environment, shorten the path from observation to prototype, and turn real failures into reusable product knowledge. That field-facing role is especially useful when edge cases cannot be reproduced from a conference-room description.
The role needs a productization boundary. Otherwise, the team may prove that a skilled engineer can manually make each account successful rather than proving that the product is repeatable. Require every customer-specific exception to become one of four things: a reusable product requirement, an explicit configuration option, an evaluation scenario, or a documented unsupported condition. Field learning, end-to-end instrumentation, and responsible guardrails should strengthen the product system rather than disappear into account-specific work.
Centralize the paved road, not product judgment
A shared AI or platform capability should make the safe path easier. Depending on the organization, that can include approved model access, data controls, common logging, an evaluation framework, prompt and model versioning, reusable interaction patterns, cost and latency visibility, incident procedures, and privacy or safety templates.
The embedded product team should still own the opportunity, supported workflow, acceptance criteria, scenario relevance, product experience, pilot design, and outcome decision. A central group cannot judge those elements without the local customer context. It should provide leverage and enforce genuine non-negotiables, not become an approval queue for every prompt experiment.
Governance works best as a quality system with explicit rules:
Which use cases require review before customer exposure.
Which data classes, actions, and model behaviors are prohibited.
Which evidence must accompany a request to expand authority or reach.
Who approves exceptions and who owns the resulting risk.
What monitoring, audit, escalation, and rollback controls must exist after release.
This structure gives teams room to experiment inside known boundaries. It also prevents a common late-stage failure in which privacy, safety, or operational requirements appear only after the team has committed to an architecture and promised a launch.
Replace demo reviews with evidence reviews
A portfolio review should inspect what the team has learned, not how polished the prototype looks. Ask:
Which decision changed since the previous review, and what evidence changed it?
Which customer story and workflow moment support this opportunity?
What is the highest-consequence failure the current prototype still exhibits?
What product outcome must improve, and which quality condition must not regress?
What is the narrowest safe and coherent release that can produce field evidence?
Who owns the capability when its model, prompt, data, or tool behavior changes?
The answers reveal the right next move. No rich customer evidence means the team needs better discovery, not a better prompt. No scenario set means model comparisons are premature. Strong offline performance with weak field adoption points to workflow or value friction. A pilot that depends on hidden manual intervention is not yet a repeatable product. A capability without monitoring and rollback is not ready for production authority.
Take one active GenAI bet and replace its feature pitch with a falsifiable bet brief, a traceable evidence packet, and an explicit quality-and-value gate. Run the next portfolio conversation against those artifacts. Anything important that is missing is not paperwork to add later; it is the discovery work that should happen before the organization makes a larger commitment.
As a VP of Product Management at HighLevel, Inc., I wrestle with the build-versus-buy question nearly every week. It’s a timeless dilemma, now intensified by generative AI. As one summary puts it, “One topic that has been around since the beginning of the tech industry, is whether we should build or buy in order to solve some problem? This question applies to traditional IT, as well as to every product team. There are often one or more buy alternatives, but each comes with an associated cost, and…”
My take: build vs buy is not a procurement question—it’s a product strategy decision. The right answer depends on whether the capability creates durable differentiation, how quickly we need to learn, total cost of ownership, and the risks around data, compliance, and vendor lock-in. In practice, I anchor the debate in product discovery: what problem are we solving, for whom, and how will we know we’ve succeeded?
When I choose to build, it’s because the capability is core to our product’s competitive advantage, relies on proprietary data or unique workflows, or demands tight integration across the end-to-end customer journey. In these cases, my team and I accept the higher upfront investment because it compounds into long-term strategic control and faster iteration.
When I choose to buy, it’s because the capability is commoditized, speed-to-market matters more than novelty, or the vendor brings specialized compliance, uptime, or scale that would be expensive to replicate. Buying can be the fastest path to validated learning—especially when we need to unblock a roadmap dependency or de-risk a complex integration.
The AI era changes the calculus but not the fundamentals. With gen ai, we can prototype quickly using off-the-shelf models, then decide if we should converge on a managed service, an open-source stack, or a hybrid. The hidden work is real: evaluation harnesses, prompt governance, data pipelines, monitoring for model drift, and cost controls for inference. These become part of the true total cost of ownership—not just license fees versus engineering hours.
In my teams, I often deploy forward deployed engineers alongside product discovery to co-create solutions with customers. We use gen ai for product prototyping to validate value early, test prompts and retrieval patterns, and stress-test edge cases. If the prototype proves the value, we assess whether to keep the vendor in place or transition to a build for differentiation, control, and margin.
Here’s the practical playbook I use. First, define the outcome and non-negotiables: data privacy, latency, SLAs, and compliance. Second, run rapid experiments to quantify value—speed beats speculation. Third, model TCO across 12–24 months, including staffing, MLOps, eval frameworks, and expected usage growth. Fourth, pressure-test vendor lock-in: portability of prompts, embeddings, and fine-tunes; data ownership; exit paths. Fifth, stage-gate the decision: buy to learn fast, then build (or stay bought) based on evidence.
One recent example: we launched a gen ai capability using a vendor to achieve immediate time-to-value and validate demand. In parallel, we scoped a build option gated by adoption and unit economics. The vendor path gave us customer outcomes within weeks; the build path unlocked deeper integration and margin once the signal was strong. That dual-path strategy reduced risk without slowing us down.
Ultimately, the smartest build-versus-buy choices align with product management leadership principles: focus on customer outcomes, quantify opportunity cost, design for learning, and avoid irreversible commitments when uncertainty is high. In the age of AI, those principles still apply—only faster.
