Today, people use Agents to do tasks – Claude Code can quickly fix that bug that’s been annoying your customers, or OpenClaw can optimize your calendar each day. But increasingly, Agents are also making decisions on our behalf.

If you’re a SaaS business, this means you’re no longer just selling to a CTO or founder, but the Agents they’re using. Ensuring your product is discoverable, configurable, and trustworthy to an Agent is the next product surface worth designing for and prioritizing.

Agents build what they can’t buy

At Intercom, one of our engineering philosophies is to run less software. Don’t build what someone else has already built better.

Agents should work the same way. But they often can’t, because SaaS wasn’t built for them. And as a result, they end up preferring to build instead of buy.

To sign up for most software products, you open a browser, fill in a form, verify an email, and navigate a configuration UI. Sometimes you even have to get on a call with the sales team. That’s fine for humans, but Agents can’t do any of it (yet). So when an Agent needs feature flags, it probably won’t sign up for LaunchDarkly, it’ll build its own feature flag system from scratch.

Agents love to solve problems on their own and they always try their hardest; they’re not always going to ask you to help them navigate a sign-up flow.

The implications of this for providers are best articulated by Aaron Levie, CEO of Box:

“The platforms that are easier for agents to adopt, and solve the agent (and user’s) problems the best, will get ahead far faster than those that don’t. Agents won’t be going to your webinar or seeing your ad; they’re just going to use the best tool for the job, and you’ll want it to be yours.”

We’re already seeing the first wave of providers prioritizing agentic accessibility. When combined with strong brand recognition, they become an Agent’s go-to solution. For example, when setting up payments, Claude almost always picks Stripe. If you need website hosting, it heads to Vercel.

Right now, the financial impacts of Agents’ software preferences are limited. After all, developers are the largest users of coding Agents and they tend to have their own preferences for software and can steer an Agent elsewhere, especially if they’re working in an existing tech stack.

But over time, as Agents become more capable and non-technical users adopt them to set up and run their businesses, an Agent’s choice of software quickly becomes the market’s default choice. Providers hoping to get a leg up in this environment must make SaaS directly consumable by Agents and not assume that an OpenClaw-style browser and email access will provide a quick fix.

What Agent-first means

Since the launch of ChatGPT, there’s been considerable chatter about Answer Engine Optimization (AEO). It’s the LLM counterpart to Search Engine Optimization (SEO). In brief, you optimize your website and content so it will be understood and cited by an LLM. By doing so, you bring organic traffic and potential customers to you. If the LLMs can’t find you, neither can consumers, and it will only get worse as LLMs take on more search volume.

In a similar way, a Command Line Interface (CLI) is the Agent’s equivalent of easy-to-navigate and appealing UI. It allows Agents to understand and use your product. The better your CLI, the more likely it is that an Agent will choose your product when building. Some providers opt to use a Model Context Protocol (MCP), which functions like a wrapper around an API, but CLIs can take on tasks with multiple steps and help Agents get more done.

Creating a CLI is step one of preparing for the Agent-first future, but step two is having a product that can function out-of-the-box. Not “easy to sign up for” – actually deployable by a non-human without any engineering help.

That’s a much larger product issue, not just an interface one. You can’t wrap a CLI around a product that needs hand-tuning. Agents will hit a wall and look for something else or deliver a disappointing experience to users. This grants a considerable advantage to SaaS providers that are already self-configurable and places pressure upon those that are not.

What we built

I’d been watching the rise of agentic software preferences for a while – talking about it on Slack, posting about it, generally making noise. Jordan eventually told me to stop complaining and actually build something. So we did.

The Fin CLI is built for Agents and can be launched by a single prompt. It signs up to Intercom and Fin, configures the Messenger, pulls in your help content, and sets it live. It also returns contextual feedback to the Agent at each step – what to check, what to set up next, and where to go if something isn’t working.

The vision is this: someone asks Claude to build them a product, then says, “I want to talk to my customers and handle support automatically.” Claude says “yes,” and gets Fin up and running all on its own.

AI Agents orchestrating AI Agents. That’s where this goes.

Check out our CLI at fin.ai/cli

Shipping fast is our priority

We’ve long held a belief that might sound counterintuitive: speed is not the enemy of safety. It’s a prerequisite for it. Accumulating code creates risk. Shipping small batches minimizes it. The faster you ship, the smaller each change is, and the easier it is to catch problems, and roll back when something goes wrong as the context is still fresh in your head.

Today, over 93% of our pull requests (PRs) across our two main codebases are Agent-driven. And over 19% are auto-approved with no human reviewer in the loop.

This post is about that second number, and why we think it makes us safer. Most people hear “AI is approving our pull requests” and think that’s reckless. We think the data tells a different story.

The 2x effort

Last year, our CTO Darragh Curran set an explicit goal: double the productivity of our entire R&D organization within 12 months. Because the faster we can build and ship, the faster our customers get the capabilities they need.

Nine months later, we did it. The results have been significant across the board, but the number that matters most for this post: downtime from breaking code changes dropped 35%, even as our deployments doubled. Shipping faster made us safer. As we modernize how we build and ship software, we systematically surface bottlenecks and tackle them. One of the biggest we’ve found? PR review.

The PR review problem

Humans simply don’t have the time or mental capacity to properly review the volume of AI-generated code we’re now producing.

When an AI Agent can produce a working implementation in minutes, waiting hours or days for a human to review it is an impedance mismatch. The production line is moving faster than the quality gate can keep up.

When that happens, one of two things follows: either the queue backs up and velocity drops, or, more dangerously, humans start rubber-stamping. Glancing at a diff, skimming the description, clicking approve.

Some companies are drifting into this failure mode silently. We chose to confront it head-on and built a rigorous solution.

PR review, done properly, is a genuinely complicated process. A good reviewer assesses the quality of the problem statement based on the PR description. They confirm the changeset actually matches the stated intent. They review the code against best practices, look for logical issues, apply their personal product context to validate the changes make sense, and check for performance issues, safety concerns, and more. No single human reviewer realistically has experience to properly cover every one of these dimensions on every PR, especially not under time pressure. And as we’ll see in the data, the baseline we’ve been comparing against, human review, was weaker than most of us assumed.

So we asked ourselves: what if we could do better?

How our PR review Agent works

Our PR review Agent doesn’t treat code review as a single task. It decomposes it into separate sub-jobs, each handled by an independent sub-Agent. One assesses the quality of the problem description. Another checks whether the diff actually aligns with the stated intent. Another reviews for safety concerns. Another checks for logical correctness. Another reviews against best practices and known anti-patterns. And so on.

The result is that every PR is reviewed as if a dozen of our most tenured and knowledgeable engineers were all looking at it simultaneously, each bringing their own specialist lens. In the past, getting that breadth of review on a single PR was impossible. Now it’s the default.

A human reviewer typically focuses on the actual code changes, the diff. Our Agent goes deeper. It traces execution paths, following the implications of a change through the codebase. This is something humans rarely had time to do, even when they wanted to.

A real example:

While testing our new PR review Agent on a set of historical PRs, we found it flagging a one-line text copy change as incorrect. On the surface, it looked completely harmless, just a text update. We assumed it was a mistake, but it wasn’t. Our Agent caught that the new copy contradicted an existing validation mechanism elsewhere in the codebase. No human reviewer would have realistically found this unless they happened to have written that validation code very recently. Our Agent catches this kind of thing consistently, every time, because it’s always tracing execution.

The review isn’t generic either. It’s grounded in Intercom-specific guidance that our engineers have built and continue to refine, encoding the same context, standards, and product knowledge they’d apply if they were reviewing the PR themselves. When the Agent reviews a PR, engineers flag whether the review comments were helpful or not, and that feedback continuously sharpens the guidance. It’s a flywheel: the more our engineers invest in teaching the system how to think about our codebase, the better every subsequent review gets.

Automated approval is also never forced. Any engineer can request a human review on any change, at any time. The system is a tool, not a mandate. At Intercom, shipping code doesn’t end at merge. The engineer who ships a change is expected to watch it go live, monitor its behaviour in production, and be ready to roll back if something isn’t right. AI approval doesn’t change that. The human who ships the code remains accountable for the outcome.

Not just faster; safer

The naive take on AI-approved PRs is that it’s just a rubber-stamp LLM call so that humans don’t have to bother. A convenience feature. That misses what’s actually happening.

Our Agent is strict. It won’t approve large PRs. If a change is too big, too complex, or too broad in scope, it flags it and requires it to be broken down. Creating a direct, positive incentive for engineers to ship smaller, more incremental, well-scoped changes.

This matters enormously for safety. Small changes are easier to review, easier to test, easier to understand, and, critically, easier to roll back when something goes wrong. This is the same principle that has always underpinned our shipping culture, but now the PR review Agent actively enforces it.

It’s tempting to look at a goal like “>50% AI-approved PRs” and worry that we’re optimizing for the metric rather than the outcome. We see it differently. Our goal was to remove a bottleneck that, if left unchecked, risked pushing engineers towards rubber-stamping reviews under time pressure.

On the surface, our PR review Agent is only a solution to “humans don’t have time to review PRs.” But what it really is, at its core, is a safety mechanism. It ensures we continue shipping fast, in small increments, maintaining and increasing our heartbeat, even as the volume of AI-generated code grows.

The data

We didn’t assume AI review would be good enough, we actively ran an experiment.

Our hypothesis was that AI review could match or outperform human review quality, measured by the outcomes that actually matter: were the changes correct? Did they cause problems in production? How quickly were they reviewed and approved?

We started with a controlled pilot of over 100 PRs through the AI approval pipeline. The results: zero reverts of AI-approved PRs, and a 6–16x improvement in time-to-approval at the 75th percentile. Since then, the system has scaled significantly. In the first four weeks of broader rollout, 497 PRs went fully autonomous, with Claude writing the code and our AI approval system reviewing, approving, and shipping to production.

Beyond the approval pipeline itself, we also looked more broadly at how AI-authored code performs in production compared to human-authored code. AI-authored backend code had a revert rate of 0.53%, compared to 5.39% for human-authored. On the frontend, it was 0.22% versus 2.00%.

AI-authored code, reviewed and approved through our automated pipeline, is being reverted at a fraction of the rate of human-authored, human-approved code. We don’t expect that to hold at zero forever, but the data so far tells us that the quality bar our Agent holds is at least as high as the one humans were holding, and in many cases higher.

And perhaps the most important perspective shift: those product changes that did cause outages in the past? They were all reviewed and approved by humans. Human review is not a guarantee of safety. It never was. It’s a useful heuristic, but one with real limitations that we’ve been quietly accepting for decades.

Staying compliant while we innovate

Everything we’ve described in this post, the sub-Agent architecture, the traceability, the labelling, the data, none of it was built just to make the system fast. It was built to make the system auditable. That was a design constraint from day one.

Every AI-approved PR is labelled, logged, and queryable. The review comments, the approval decision, the test results, the merge event: all recorded. The evidence an auditor expects to see is the same whether a human or an AI approved the change. The “who” may change, but the “what” doesn’t.

We engaged our auditors, Schellman, early, before we scaled. We proactively worked with them to confirm that our automated review processes and the evidence they produce meet the requirements of our compliance frameworks, including SOC 2, HIPAA, ISO 27001, ISO 42001, and AIUC-1, among others. We think AI-driven change management can meet and exceed the standards that human-driven processes set, and we want to help prove that.

We see this as a feature of building the system the right way, not an extra hurdle we had to clear. When you build for safety, compliance follows.

What’s next

You can only go so far with PR review as a safety mechanism, no matter how good the reviewer is, human or AI. Only in production do you discover the unknown unknowns. The majority of Intercom’s largest outages weren’t even caused by changes to product code at all. They were infrastructure issues, unanticipated customer usage patterns, or third-party outages. PR review, whether human or AI, was never going to catch those. That’s why, in parallel, we’re also working on an Agent that proactively diagnoses issues in production. We’ll share more on this soon.

Speed has always been at the core of how we build, not in spite of safety, but because of it. And we’re getting even faster with AI. It’s easy to assume that AI-approved PRs would lead to a drop in quality and safety but our data proves otherwise. We’re just getting stronger.

We’re announcing the most significant new strategic development since the start of the Customer Agent category: Fin now has specialized roles. And starting today anyone can sign up for and deploy the Fin Sales Role in minutes.

Fin is now by far the very best sales agent on the market, and it’s been live with some of the most innovative digital brands for months, conversing with thousands of prospects, aiding discovery, building pipeline, booking meetings and starting trials.

We started the Customer Agent category with a focus on service by launching Fin three months after the launch of ChatGPT. Since then Fin has continued to lead the space, today delivering over 2 million resolutions a week for over 8k customers, including Anthropic, DoorDash, Snowflake, Asana, Mercury, Polymarket and many more exceptional brands.

But our vision for Fin has always stretched far beyond service. And for the past 6 months we’ve been building Fin as a single Customer Agent, delivering a seamless experience across all stages of the customer lifecycle.

We do not believe customers or businesses will want multiple agents for different parts of the lifecycle—because the agents won’t have shared memory and goals, and will have to compete with each other, delivering a poor customer experience and sub-optimal business results.

We’ve more roles to come, including another dropping in two weeks. For now please watch our launch video or visit our launch page to learn more: fin.ai/sales

In my last post, I shared a conversation with Matt, Dan, and Jack about what makes engineers effective with Claude Code. I was trying to understand what’s behind the success that some people are having with these tools – is it years of experience? Deep judgment? Strong mental models? And whatever it is, can we encode it and help everyone get there?

That conversation was with people who’ve been here a while – tenured, senior, already thriving. This time I wanted to talk to somebody new. Salman Shah has only been at Intercom a few months and he’s already having an outsized impact – not just on his team, but on AI adoption across the company. He’s shipping at a rate that stands out. While also contributing to shared tooling, running informal coaching sessions with teammates, and building relationships across the org that most people don’t establish in their first year, let alone their first few months.

I wanted to understand what’s going on – what is it about how he works and thinks that’s producing these results? And what that tells us about the AI traits we should be hiring for?

AI + human, not AI vs. human

Salman’s foundational mindset comes from an unexpected place: a chess book. After Garry Kasparov lost to IBM’s Deep Blue in 1997, he created advanced chess, also known as centaur chess – tournaments where both sides played as AI + human teams. The question was no longer: “Can AI beat humans?” but “What does AI + human look like when it’s working well?”

Salman read Kasparov’s Deep Thinking and it changed how he approaches working with AI:

“My mindset for every task is not ‘how do I type something and go away?’ That’s where I feel a lot of people have felt frustration. They try and then realize, ‘oh, it just wasted my time.’ Instead, how can you do AI + human through everything?”

You always have to ask: what does the human add, and what does the AI add? Not “can AI do this for me?” but “what does the AI + human version of this look like?”

Nobody said no

Salman and I talked a bit about his career path – seven years across various technology companies before joining Intercom. At those places, you get used to asking permission. At Intercom, the opposite happened.

He said: “Here I have tried asking for permission and people have been like, ‘you don’t need permission to do that.’ I’ve just done so many things and up until now, no one’s come and told me, ‘don’t do this.’”

In his first month, this culture was tested. He pushed something, broke something, got paged at eight o’clock in the evening for a minor incident.

“I was very worried the next day. But then I was told not to worry about it – just get the learning out of it. Which is to have an additional test that would have caught it.”

That feedback emboldened him and the message was clear: we’d rather you move fast and learn than move slow and play it safe. And each time he tested that boundary without getting burned, the boundary moved further out.

“Fueled by AI, but also fueled by energy, ambition, and nobody saying no.”

Claude Code first – in everything

This is the most actionable theme from the conversation, and probably the biggest mindset shift.

Salman doesn’t just use Claude Code for writing code. He uses it in incidents, planning, QA, and code review. His question for every process is: “Can we do Claude Code first in this?“ – and not just within the existing process. Can we tear the process apart and rebuild it around Claude Code?

He built an agentic QA skill that runs test scenarios overnight. The old process: someone prepares a QA sheet, it takes three days to get through QA and fix what comes up. Now by the time a human QA session starts, most issues have already been caught and resolved.

An incident example: Salman threw everything at Claude Code – Sentry MCP, admin tools MCP, the codebase – and had a PR out within 30 minutes, on a part of the codebase he’d never worked in before.

“I did nothing special. It was related to reporting, which I have no idea about. So we had someone from the Reporting team look at it. But the fact of the matter is – can we have this mindset shift, that Claude Code can just do things better than us if we give it the right context and just go Claude Code first in everything?”

That phrase – “if we give it the right context“ – is doing a lot of work. Salman’s insight is that when Claude Code fails, it’s almost always a context problem, not a capability problem. Give it the right MCPs, codebase access, and framing, and it performs. The skill is in the setup.

He’s done this in three incidents now. Each time, he shipped a PR during the incident that would have taken much longer without the tool.

An incident is high-stakes and high-visibility – not an obvious moment to reach for a relatively new tool. But when Claude Code is already your default for everything else, there’s no switching cost. You just use it.

Build the network

Before he even joined Intercom, Salman reached out to Brian Scanlan, one of his interviewers, to talk through whether he should accept the offer.

“I spoke to him once and I was like: ‘hey, I’m not sure, should I join? Can we just chat?’ And he said: ‘okay.’ And then we met in Dublin my first week. And since then we’ve been talking monthly.”

Salman also met Eugene at a talk before he joined Intercom and reached out to set up a chat. Eugene and Brian recommended other people for Salman to meet. Within a few months he’d built relationships with senior engineers across the org, using them to understand the landscape, find problems, build trust, and contribute to shared tooling.

This is the human side of thriving with AI tools, and I think it’s easy to overlook. No amount of Claude Code proficiency replaces the fact that you need to understand the people, the problems, and the context around you. Salman is explicit about this:

“There is always a human aspect of things. When you’re working with people, I think that probably just helps.”

The principle here is to seek out context actively, don’t wait for it to come to you, and invest in relationships that help you understand the system you’re building in. It’s a skill that will compound.

The local maximum problem

We got into a back-and-forth about something I keep seeing: the local maximum problem. Most people don’t know what they don’t know or the extent of these tools’ capabilities.

I described the pattern as I see it:

“Someone adopts Claude Code and starts shipping AI-written code. They get comfortable and that feels like the ceiling. But the ceiling isn’t a missing feature or a tool they haven’t installed – it’s the boundary of what they’ve imagined the tool can do. Someone sees Claude Code as a coding tool, and then one day realizes it can also do code review, or planning, or incident response, and suddenly the ceiling moves.”

Salman sees the same thing from the ground. He put numbers on it: maybe 50% of the org is at beginner, 30% in the middle, 20% advanced. The adoption curve is left-shifted. And the people at the top are compounding each other’s knowledge while everyone else doesn’t know what they’re missing.

This echoes what came up in my earlier conversation with Matt, Dan, and Jack – the forums and channels we have for discussing AI tend to select for the enthusiasts. The people who most need help aren’t represented in the conversation. When Jack ran his learning sessions in London, he was hoping to reach people at the far left of the curve. Lots of people showed up, which was great – but the hardest problem is still reaching the people who don’t yet know what they don’t know, what they’re missing, or how to engage.

Push the graph up

Salman tracks his own DX graph as a personal benchmark. He pulled it up during our conversation – a steady upward trend since his first day at Intercom.

“Whenever I find anything that is blocking me, I put it into a skill and see if I can push this graph up.”

This is his operating principle: each week, what’s slowing me down? Can I make it faster? Encode the answer into a skill. Compound the gains.

For example: the React inbox refactor. 280 PRs in four weeks driven by an autonomous Claude Code workflow. When Anthropic released agent teams, daily PRs went from four or five to 15. And the flywheel doesn’t stop at the end of the project:

“We’re going to spend a week collecting all that information and putting it back into a skill so that the next time we do review, we don’t have to think about those things because they’re already captured.”

This is knowledge encoding – he doesn’t just solve a problem, he encodes the solution so it persists for the next project and the next person. The skill becomes institutional memory.

At Intercom we’re using DX metrics to help us to understand Claude usage and proficiency. Sometimes when I talk to engineers about these metrics, they cite Goodhart’s law, and worry that the metrics are gameable and therefore meaningless. Salman flipped it on its head. For him, it’s not a performance evaluation metric, but rather a self-reflection tool.

“What’s helpful for me at the end of the week, if I’m doing self-reflection, is to ask: ‘is there a way to improve this?’ It’s easy to count. If you want to find how to get efficient, whatever can show you that makes sense.”

He’s deliberately gaming his own graph – but not in a cynical way. He’s not finding low-value PRs to inflate a number. He’s driving through high-impact work while also compounding low-hanging fruit on the side.

The 80/20 split

Salman has always been a split-focus person. Eighty percent on the main project, 20% on side quests – defects, feature flag cleanup, plugin contributions, whatever catches his eye.

“80/20 was always the principle. It’s just now I’m able to close the loop on the 20, even if the 80 gets harder – because AI is doing a lot of it for me.”

Before AI, the 20% was aspirational. You’d pick up a side thread and it would balloon in scope and you’d quietly drop it. Now the closing cost is so low that side quests actually get finished. Last cycle he cleaned up 30 feature flags. This cycle he’s chipping away at defects – two this week, compounding over time.

He’s not precious about it either. His PR close rate is about 7% – meaning roughly one in fourteen PRs he opens, he closes without merging.

“Sometimes you pick up something, you feel like it’s a lot more effort than what you initially thought. You don’t have the mental bandwidth for it. Just close it.”

Energy management over completionism. Starting something new is so cheap, being willing to abandon the ones that aren’t worth finishing becomes a real advantage.

Right time, right place – and right mindset

Salman is self-aware about the luck component. He arrived at Intercom with a lot of energy and a great mindset – but he also arrived at just the right moment.

“I came when the models were just getting better and better. And I leaned into betting on Claude Code, which is what Intercom also bet on.”

Seven years in technology companies and he’s never had this kind of impact before. At one, the culture dampened down exactly the energy that Intercom rewards. At another, the business wasn’t ready to bet on AI. The timing never aligned.

“I’ve never done this in my career. This is the first time I’m doing something like this in a very big way. I have never shipped as much as I shipped last month.”

But it’s not just luck. The combination is specific: culture (Intercom’s permission to fail) + timing (the agentic inflection) + personality (ambition, extroversion, initiative) + AI (the compounding enabler).

“It’s never just one thing. It’s probably a combination of everything. The culture at Intercom allows you to do that. Plus maybe some part of my personality always wanted to. But I have never done this – whatever this is.”

What’s staying with me

My earlier conversation with Matt, Dan, and Jack was about learning from tenured engineers at Intercom who’ve already shifted their mindset and found great success with Claude Code. Salman shows that’s possible even without long tenure at Intercom – with initiative, a compounding mindset, and a habit of treating every friction as something to encode and eliminate. He doesn’t have twenty years of engineering judgment. He has a relentless instinct to close loops, share what he learns, and ask “can I do this with Claude Code first?”

So what are the AI-native traits we should be hiring for? I think this conversation surfaces some of them:

• Initiative without permission.

• The instinct to tear apart a process and rebuild it, not just optimize within it.

• A network-building drive that generates context and trust before you need either.

• The discipline to encode what you learn into something that persists.

• Reaching for Claude Code first – not just as a coding tool but as the starting point for every problem.

These traits reinforce each other: the network gives you context, context lets you deliver, delivery builds trust for bigger bets, and each bet generates knowledge you encode into the next one. Over time, they compound.

I want to push the adoption curve to the right – to accelerate as many people as possible through their own adoption journey. Conversations like this one help. They surface the ways of working that make the difference, and encourage us to create an environment to foster them.

If there’s one thing to take away from this conversation, it’s the question Salman asks himself for every task: “Is there a Claude Code first way to approach this problem?“ That’s the mindset shift. Start there.

To hear more from Salman on what it’s like to work at Intercom, check out this video:

And if you’re looking to join a team that embraces this mindset, check out our careers page.

Nine months ago, we set a very deliberate goal to 2x the productivity of our R&D org within 12 months. We’d already seen early benefits of AI-assisted engineering, but knew there was so much more coming. My instinct at the time was simple: even if AI progress stalled, it was already good enough for us to hit this goal, but we must deliberately chase it and overcome all obstacles in our way, as opposed to being passive and hoping it happens to us.

This level of public accountability was scary, and it wasn’t always clear to me that we’d pull it off, but…. we did it, with time to spare. In fact, looking back over 16 months we’ve 3x’d and I see no signs of plateauing. I anticipate we will 2x again in a short number of months. I want to give you an unfiltered look into the impact we’ve seen holistically for our product and our org, and how to go about making similar changes in your own company.

This will be a multi-part post. This first part will mostly be about what we’ve seen. In the next, I’ll talk about our messy journey, some of the lessons learned along the way, and what’s coming next.

A culture optimized around moving fast

Our culture has always been optimized around building great product, fast. If you think of your R&D org as a factory, ours was a fairly impressive factory, one others would aspire to replicate. However, technological change, in this case with AI, can very quickly raise the ceiling of what is possible, and you must modernize your factory to not fall behind. We’ve never had a shortage of product vision but have always been constrained by executional capacity. AI unlocks an abundance of capacity, dramatically amplifying our ability to execute against our product vision.

We aspire to be at the forefront of exploiting what is possible with AI, and as a result, more quickly and efficiently build our vision for the future, solving customers problems faster than anyone else. Ideas that would previously take weeks or months can now take hours or even minutes.

We aren’t the only large R&D organization deliberately chasing this kind of outcome, and indeed, I respect and applaud large organizations who have also gone really hard (e.g. this wonderful post shared a few days ago by Ramp). But I’ve also talked to enough people to know that most are struggling to make the right changes or see close to the level of impact that’s possible. I hope by being transparent about our journey we can inspire others to follow a similar path and encourage others to push us to go further too.

For context, while we are going through an exhilarating rebirth phase, we are nonetheless a big, old, beautiful, messy company. Thirty thousand businesses rely on us for how they run their business. We’ve almost ~8.5 million lines of application code (across Ruby, TS, JS, Python, Go, Swift, ObjC, Kotlin, Java). Our PlanetScale datastores alone peak above 2 million QPS. Over the last 24 hours, we ran 2,539 Continuous Integration jobs, each consuming days of compute time, and made 313 distinct automatic deployments to production. We see velocity as a strong driver of stability. There are ~500 people building and operating the product and software that we run, these people are spread across four offices in two continents.

In short, we are not a small startup with the benefit of a blank page, but we know full well that if we don’t adapt aggressively we are heavily threatened by them, and so are you.

There are so many companies similar to us, alive today based on great success in the old world, but dead if they don’t adapt aggressively to the new world. We want to thrive in this new world. And we want to show you it’s possible and inspire you to make the, at times, difficult decisions and changes to achieve it.

Wait, you measured what now?

We measured the number of merged PRs divided by the total number of employees in our R&D org. This particular measure is easy to criticize – are we really going to fall into the trap of just looking at the output of the engineering team in this naive way? This isn’t far off measuring LOC? None of this is done in isolation, our thesis for measuring PR throughput is as follows:

• We believe in fast, safe, and frequent shipping. A new engineer on the team will ship to production on their first day. Shipping is our heartbeat.

• Conceptually, our org is a factory for producing high-quality increments to our product. These leave the production line as merged PRs (pull requests). Our job is to increase the throughput of the factory, while maintaining or improving quality and decreasing cost. Time, cost, scope, pick three!

• Putting higher expectations on merged PR throughput puts pressure on the whole system, exposing bottlenecks which we then systematically tackle.

• We also look at this top-down. What we actually want to optimize is how frequently and how quickly we can go from problem to solve or idea, to solution in our customers’ hands. Both views are useful, but at different zoom levels.

• It’s important to highlight precisely how we define our metric, total number of merged PRs, divided by total number of people in R&D (everyone from IC engineers to VP of product design). We divide by all the people, because 1) that’s all the cost; 2) we expect all people to be able to directly and indirectly impact the metric; and 3) it puts healthy pressure on our org design, by default we should assume all our existing org structure patterns are wrong for the new world.

So many people internally and externally get caught up on this question of how to measure this, afraid to measure the wrong thing, or hold back from driving change because they can’t find the perfect measure. My advice to you is to be at peace with potentially imperfect measures, don’t let that hold you back from the outsized outcomes that lie in store.

So, yes, this metric is not quite perfect, but we’ve driven massive movement in it, hit the goal/milestone we set, AND paid close attention to everything else that changed.

I want to give you an unfiltered and transparent view into a range of benefits we’ve seen, that are well within reach if you push for them with determination.

What has been the holistic impact of our AI acceleration?

1. Product defect backlog shrunk by 54%

Since the start of the year, we’ve reduced a core product defect backlog by 54%, closing all critical and high defects. We are also on track to imminently close all medium defects. Our intent here is to stop wasting time on the drudgery of prioritization and backlog management, the issue ping pong, etc., and instead attempt to operate around an SLO of fixing all reported issues in less than 24 hours (currently at 10.4% and climbing), and maintaining effectively no backlog. Very few product teams I know have ever achieved this high standard, but it’s now well within reach. All this is obviously a well-deserved win for our customers, and just the start of all the ways they’ll start to feel the impact of our internal improvements.

2. >2x product changes, 39% faster from idea to shipped

We’ve started to see two strong trends. We are shipping more product changes, and we are shipping them faster. This is noisy data, not all product changes are equal in size, scope, etc., you can have spiky months, but it’s directionally indicative. Median time from idea to product change is nearly cut in half, and even if we ignore December, we’ve more than doubled our product changes in March vs January. We are able to say yes to more of the things that matter most to our customers, and be more ambitious in what we aim for too.

The faster we can responsibly ship, the faster our customers get leading edge capability, the faster Fin resolves their support conversations, and the faster they can grow their own businesses.

3. Code quality improving, after period of consistent decline

A legitimate worry with the use of coding Agents, is that they won’t write high-quality code and the craft we’ve fought to protect will be undermined by slop cannons. We have a system to rate the structural quality of code contributions using static analysis and various rules/heuristics. It’s clear that prior to agentic coding, this metric would oscillate up and down above the line. As we started to use AI for writing more and more of our code, the overall quality (by this measure) declined. My intuition was that this was inevitable in the short term, but correctable in the medium term, as models and harnesses get better. We are starting to see this and recently had possibly our first ever five-week streak of net positive code quality overall. I’m sure this streak won’t last forever, but my bet is that average quality will continue to trend up.

4. Downtime from breaking code changes down 35%

It’s natural to assume that doubling our deployment throughput means we’re breaking things more often. But that hasn’t happened.

The data shows something even better than “no degradation.” The downtime we can attribute to breaking code changes dropped by 35% over the last 11 months, even as our deployments doubled. Our culture has always been optimized around building great product, fast, but also safely. What’s really happening is that by letting AI handle the mechanical aspects of coding, our engineers have the mental bandwidth to be far more deliberate about architectural quality.

5. AI costs growing exponentially BUT costs per PR cut in half

Our AI spend has been climbing sharply, exactly what we want to see. We’ve not tried to optimize this despite believing there are ample opportunities to do so. For now, our focus is on AI leverage and we believe we are only scratching the surface. This chart is our weekly spend on Claude Code this year. I expect this to continue to grow steadily through the year.

When Agents can do work humans would otherwise do, it’s almost always a huge ROI. One way we look at this is by tracking fully loaded costs per PR. Payroll-related costs massively dominate this, and tend to have strong YoY upward pressure (promotions, pay increases, market adjustments, etc.). However, with ever-increasing PR per head, the overall cost per PR is in a steady decline. December is higher because between time off and other end-of-year stuff, people are far less productive, but the overall trend continues.

6. 93.6% of PRs are Agent-driven

We drove a big behavior change in a short number of weeks. As soon as we made the decision that we’d double down on Claude Code as our primary agentic coding system, we set a goal that within six weeks, >80% of PRs would be driven by Claude Code. We then raised that to 95%, which we are currently hovering just below.

Many of our engineers rarely even use an IDE/editor.

This is all inline and driven by new principles that describe how we should now work. The first and most important is:

“All technical work is becoming agent-first. This is the top priority for R&D.”

We will share our full set of “2x principles” in the days ahead.

7. 19.2% of PRs are now AI-approved. Near-term goal is >50%

Creating PRs isn’t the only part of the “factory” to apply an Agent-first mindset to. With the ramp-up in PRs, unsurprisingly, one of the bottlenecks that gets exposed is PR review and approval. If we want our factory to move faster, we can’t have every increment waiting in a human review queue.

We took an ambitious goal to hit >50% AI PR approvals by the end of April. We’ve started with the lowest risk changes – feature flag cleanups, small bug fixes, focused improvements. Only a few weeks in and we’ve already seen 19.2% of all merged PRs auto-approved with no human reviewer in the loop. The system evaluates roughly 60% of PRs and we expect both coverage and approval rates to climb as we expand the criteria.

This not only reduces the demands on others to spend time on PR review, but reduces the waiting time to get PRs shipped. Auto-approved PRs merge in a median of 14.6 minutes compared to the org median of 75.8 minutes. Eighty-six percent of auto-approved PRs are 20 lines or fewer – exactly the kind of well-scoped changes that shouldn’t bottleneck in review queues.

Perhaps the most striking number: 497 PRs went fully autonomous in the first four weeks Claude wrote all the code, with our AI approval system reviewing, approving the change, and shipping to production. We are also ramping up the percentage of PRs driven entirely by Agents, without humans triggering them.

You’d be right to be anxious about making a change like this, but we are approaching it in a very methodical way, and will share more about our auto-approval approach in a follow-up post.

8. 31% of our org are active contributors to our auto-updating suite of Claude Code plugins

A big turning point in our progress was the decision to go all-in on Claude Code and build a shared platform around it. We spun up a dedicated team (“team-2x”) and created a private plugin marketplace that distributes configurations and skills – specialized capabilities for common tasks – via auto-updating plugins. When someone builds a skill to do a task in the best way possible, everyone on the team immediately benefits. When we improve a skill that everyone relies on, the improvement ships to everyone automatically. In the three months since we started this, our Claude Code plugins repo has become the most actively contributed-to project at Intercom – 153 contributors (31% of R&D) and 267 skills. This isn’t a platform team building for others; modernizing the factory is now part of everyone’s job. Some more details in Brian Scanlan’s viral thread about this.

9. Top 5% of contributors produce 6x the median PR throughput

I still think we are only getting started. We are learning at a rapid pace, but a big area of opportunity is the unevenly distributed nature of progress across our team. There is *huge* latent potential. Some people are really pushing the limit of what is possible, tokenmaxxing, doing really interesting things, while others have only really made incremental changes to how they’re working and don’t see much change in their personal throughput. Ultimately one of the biggest bottlenecks to progress is with humans; how we work together, how we change behavior, etc. We’ve made some great progress and I’m confident we can crack this too, but I want to show a sober view of how unevenly distributed the impact is. In general, the people who are able to spend the most with Claude are having the largest increase in personal throughput.

This scatter plot of our engineering team shows that the vast majority of people who are meaningfully pulling up the average are spending >$1k per month on tokens, but spending >$1k doesn’t guarantee that.

It’s ironic that the sentiment amongst many leaders or CFOs is that this is all becoming too expensive, our evidence suggests that it’s way more expensive in the long run to hold back spend, because of the downward pressure AI leverage plays on the fully loaded cost of a PR, which is dominated by salary costs in almost all organizations.

We need to figure out ways to help everyone move up and to the right. We think about this as a progression from minimal, to elite use of agentic tooling. Our top 5% of engineers operating at an elite level produce >6x the output of the median engineer.

The tiering is computed based on an assessment of an individual’s intensity of AI usage, overall output, depth of AI usage, efficiency of AI usage ($/PR), and prompt quality. All our telemetry on these dimensions helps us spot opportunities to better equip or enable the team to make progress. We will share more on this later.

Changes beyond R&D

The impact has been significant within R&D, but also inspiring beyond R&D. I’ll give a glimpse into that here.

Everyone reflexively uses AI now as part of their job, whether that’s Glean, ChatGPT, Claude, Claude Cowork, or in our case, Claude Code. We’ve 473 people in R&D, our peak has been almost 1,100 active Claude Code users across the company (out of total company size of 1,305). That’s over 600 people who got over the temporary intimidation of learning how to use the command line and are now able to create reports in minutes that would have taken them hours, or that they simply couldn’t have done before. Regularly, I bump into people brimming with excitement, from our finance team, or people team, or recruiting team, or customer service team, or sales team, or legal team, who are on a really fun journey of discovery around what they can get done from an AI Agent with access to the right data and tools. Some of this use is one-off analysis, some of it is replacing complex parts of our operations, with specialized skills being built to report and critique monthly performance. And people push this beyond just reporting, building special purpose tools for sellers or even prototypes of potential product capability.

Cormac wrote about how “every business leader deserves their own data analyst,” which totally undersells the impact of the tooling his team have created. For starters, it’s not every business leader, it’s everyone at your company. The tooling allows you to ask any question you want about the data in Snowflake and any other systems or context you are interested in,has skills for creating interactive reports or mini applications, and then publishing them securely with the right access controls, versioning deployed using Streamlit on Snowflake.

Usage has exploded from initial versions of this in February, and no sign of slow down in April so far, stats here for reports actually published to the internal platform for sharing them:

What next…

I hope I’ve shown you the power in picking a target, no matter how imperfect, and pursuing it with great determination, can lead to massive cultural change and impact for your company. I hope that the transparency I’ve afforded helps motivate and inspire you. I hope it gives you benchmarks to try and smash – or if you’ve already done so, I hope you’ll share your receipts too for further inspiration.

Tune back in soon for my next post, where I’ll share all about the messy journey, how we did this, what we’ve learned along the way, and what’s next.

One last thing, I and other leaders at Intercom have been inundated with customers and peers in the industry wanting to pick our brains and draw inspiration for how we are leveraging AI in our teams. So we are going to do a big group webinar, targeted at people leading organizations like ours, where we’ll go into more depth, and have very open and honest Q&A sessions too. Please save the date, May 19th, 9am PT, 5pm GMT, and register your interest here.

Big thanks to Claire Vo for very kindly reviewing a draft of this post at short notice and providing really useful feedback.

“Product strategy means saying no” became a popular line because it captured something essential: great products are not just collections of useful features. They are coherent systems. In a world full of good ideas, the job was to protect that coherence. To say no to tangents, no to edge cases, no to things that made the product busier but not better.

That is still true. But for years, product teams also lived with hard constraints. Too many good ideas. Too little time. Too few people. In that world, many no’s were strategic: this muddies the product, distracts from the core, or adds more complexity than value. Those no’s still matter.

But many others were different: this could be right for the product, but we do not have the capacity to prioritise it now.

Scarcity did not just kill ideas. It lowered the ceiling on ambition. It trained teams to think in increments. To pitch the safer version. The version most likely to survive planning. We told ourselves we would start small and iterate later. But later often never came. Another urgent problem arrived, we went shallow again, and the pattern repeated.

That tension was always there. The choices were often reasonable, but it never felt great to make a small dent in one important problem, then move on to the next, and rarely have the capacity to go meaningfully deep.

That is what AI changes.

AI changes the economics of software in three ways. Software that was already viable gets cheaper to build and improve. Software that was too niche or too low-value to justify before can now become viable. And the frontier moves outward: ambitious, high-value ideas that once felt out of reach can now be seriously pursued.

That changes opportunity cost too. It used to be the cost of taking capacity away from the obvious priority. Increasingly, it is the cost of not pursuing the more ambitious idea now that it is finally within reach.

So yes, product strategy still means saying no.

But teams that keep operating with the instincts of a scarcer era will miss the shift. The question is no longer just what to cut. It is where to go deeper, move faster, and be more ambitious because the executional constraints have changed.

The best teams will still protect focus. But on the right ideas, they will go harder, deeper, and further than before.

We spent 4 years building a world-class data foundation at Intercom. Trusted models, clean pipelines, proper documentation. And the people who needed it most couldn’t touch it.

When our President wanted to know why pipeline dropped, she filed a ticket with an analyst and waited.

That’s broken.

The access problem

It’s not that the data doesn’t exist. It’s that getting to it requires SQL and a dev environment. Business leaders don’t typically have those things, and they shouldn’t need them.

Meanwhile, generic AI tools can write SQL but they don’t know your data. They can’t tell the difference between your trusted source-of-truth table and the unvalidated one two schemas over. They give your VP a confidently wrong number, and they have no way to spot it.

The experiment that changed our minds

One of our engineers connected Claude Code to Snowflake for two business leaders as an experiment. The BizOps leader produced a private equity partner dashboard in minutes (previously days of analyst time). Our VP of Customer success diagnosed complex conversation volume trends solo.

Their response: “spectacular.”

But the setup needed terminal config, API keys, and multi-repo dependencies. We couldn’t scale that to 50 people, much less >400. So we built something that could.

What we built

We almost built a chatbot with a nice web UI. We didn’t. Because generic AI fails at business intelligence not because it lacks a pretty interface, but because it lacks opinion. Instead we built Claude for Data: an opinionated Agent on top of Claude Code, pre-loaded with our data team’s knowledge. Which tables to trust, how metrics are defined, where the gotchas are. Allowing it to start every session like a seasoned analyst who knows the business.

Four things made it work:

A zero-config installer. SSO auth for Snowflake connections, dependency checks, all handled invisibly. A business user gets their first answer in minutes. This was harder to build than any of the AI, and it mattered more for adoption than anything else we shipped.

A trust hierarchy. The Agent steers toward the best data model for the question. It knows a core, tested table from raw, unvalidated data. It can join across product usage, billing, and CRM to answer cross-functional questions.

A feedback loop. When something goes wrong, we capture the context. Domain experts review and update the guidance. Fixes reach every user automatically. Every bad answer makes the system better.

Shareable reports, and a portal to browse them. This turned out to be the real wow moment. A user can ask a question, get an answer, and then with a single command turn it into a polished, interactive report with charts and tables. That report gets published to the Claude4Data Catalog, a portal where anyone in the company can discover, browse, and learn from what others have built.

The catalog changed the dynamic completely. Before, insights lived and died in Slack threads. Now, someone in Sales can browse what Marketing built last week, fork it, adapt it for their own use case, and publish their version back. Reports show the SQL behind every number, so there’s full transparency on how the data was sourced. People leave comments directly on specific sections, ask follow-up questions, and star the reports they use regularly.

This is what made the tool go viral internally. They could see what their colleagues were producing, click through the catalog, and think “I want to build something like that.”

What happened

Within three weeks, weekly active users went from under 100 to nearly 400, mostly from non-technical teams. We’d planned a “Report of the Month” award to celebrate the best work in the catalog. We switched it to weekly because the output was too good to wait.

One member of a non-technical GTM team told us: “I truly believe this tool is the most transformative one I’ve ever seen in my career. My team is building new things every day, and we are not technical teams.”

A RevOps leader replaced a clunky weekly Tableau workflow with a self-serve dashboard in a single session. He called it “the data equivalent of a Waymo.” A Field Marketing manager built a live weekly report that evolved into a global marketing calendar used across the entire org, no data team ticket required. A Product Manager submitted her first-ever pull request to contribute a reusable analytics skill. Her reaction when it went live: “wowowowow.”

The last mile

Every GTM org we know is sitting on this problem: real investment in data, gated behind a small number of analysts. A decade of building dashboards hasn’t removed that bottleneck.

An opinionated Agent that knows what your data team knows, gets smarter from feedback, and turns conversations into reports people can actually share and build on. That’s the last mile.

Claude for Data is built on Anthropic’s Claude Code.

Today we’re announcing the launch of the Fin API platform. Our best-in-class vertical customer service models that power Fin are now available for you to mix and match and deploy at insane scale to create the perfect customer agent for you. In this post, I’ll explain exactly what we are announcing, why we’re doing so, and how I think we’re going to see a lot more of this in the industry at large.

The news

Fin is a customer agent platform that at present resolves over 2M customer issues a week, growing at a rapid exponential pace. It’s relied on by the best brands, large and small, in every vertical you can imagine. From Doordash and Riot Games, to smaller hot upstarts like Mercury and Polymarket. It runs on a family of models trained by our AI group. Last week, we announced Apex, which is the world’s first specialized customer service LLM. In production tests over the last 6 months, it beat every single frontier model, including those from Anthropic and OpenAI, on resolution rate, latency, hallucination rate, and cost.

We’re now going to allow you to access all of this power and all of our core models directly via API, with contracts starting at $250k per year, and usage rates that are by far the cheapest in the industry for each of the model’s subcategories.

But why?

It’s simply that our customers want it. We hear from people far and wide who want to build their own agents. So starting today we’re providing three ways to do so.

First, for the vast majority of companies, they will want to run their operations on the Fin Agent Platform. We have ~8k companies on it today. This takes care of the needs of 99% of customers and allows them to configure it easily without the exhausting consulting engagements of our startup competitors. It delivers the very best resolution rates in the industry, but straight out of the box.

Second, we have also had an offering for people who want to present Fin in a unique context. For this they can use the Fin Agent API. In this mode, you get all of the magic of the Fin platform, but you don’t have to use our messenger (or our email or voice or other prebuilt channel) and can display the agent in bespoke ways.

But there are also companies out there who want to build hyper-specific and specialized agents for their business. Perhaps they want to build an agent that does service and is also a product agent that lets users interact with their product. In this world, the best and most obvious decision for them is to use Apex and the collection of models we use in the broader system, because they’re trained for exactly that purpose—unlike the generalized models. This is our third and new offering launching today.

We’re also excited to see new startups build Fin-like businesses that cater to hyper-specific verticals too. Fin for dentists? Why not? Fin for car dealerships? Sure. We’re never going to build for these specific verticals, but we’d love someone else to. In fact, if any of our direct startup competitors would like to substantially improve their offering and give us a little cut of the action, we’ll be more than happy to license our models to them too. Decagon, Sierra, and the rest, you know where to reach me. Let’s be friends! :)

Coming soon to an agent company near you; the defensive reason

Unlike many, I’m not 100% ready to write off all of software. But it’s true to say that the software landscape is certainly about to change dramatically before our eyes. In extremely recent times, differentiation came from software functionality that acted as a moat because it was hard to build. But building software is simply less hard now.

We’ve already managed to more than double our measurable productivity on our engineering team. We’ve also created insanely deep new products that previously existed as separate businesses, built by single Intercom engineers, in literally one week.

Going forward, the differentiation that came from features and interface is, at the very least, going to diminish. Serious software companies must not only move from being a features company to an agents company, because the work they used to assist with that was done by humans will now be done by agents, but they must also be building those agents on differentiated AI. We do believe that more and more value will accrue to the model layer, and so, as we did when we started to disrupt our software business with our agent business, we will now begin the processes of disrupting our agent business with our AI business.

Where this all ends is anyone’s guess, but it’s hard to not imagine we’ll see this with many other companies too. For now, we’re excited to be out there first and best with this new platform and business and we can’t wait to see what people build.

When you’re a thriving business, it can be easy to fall asleep at the cash register. You’ve had success for so long, you forget how to adapt and react.

Take Blockbuster.

It kept dismissing the internet, there was always a rational-sounding reason to wait: people won’t want to watch movies on their laptop, patrons love the experience of strolling the aisles, the economics won’t work at scale.

Every single one of those lines crumbled. And by the time Blockbuster took the threat of Netflix seriously, it was too late.

Des has been thinking a lot about Blockbuster lately – because he believes most SaaS companies are living that story right now, just with AI. Last week, he joined the Billions podcast to talk about what it takes to avoid that fate and adapt to the AI age.

Here are the biggest takeaways:

A pivot among chaos

Fifteen days after ChatGPT launched in November 2022, Intercom was already building Fin.

The urgency was prompted by a demonstration from Ciaran. He asked ChatGPT how to install Intercom on a mobile app – the kind of question the support team gets regularly – and it answered it perfectly in under five seconds. “No typical human efficiency software would have got to that outcome and then of course it could answer it in any question in any language and it could do it 24/7.”

Even accounting for hallucinations and guardrails, it was clear this would change customer service irreparably.

What followed was a hard pivot: ripped-up roadmaps, reallocated resources, a new domain, and a new brand direction. Prior to that, Intercom’s topline revenue wasn’t shrinking, but growth had slowed and the company had already begun to restructure.

Adding AI to an already manic sea of changes ended up being a blessing in disguise.

Would Intercom have moved as fast if it had been growing at full speed? Maybe not.

According to Des: “The mistake we would have made if the business was doing great and we saw this opportunity, would be underinvestment… We might have said, ‘Oh, that’s cool. Fergal has a fun little experiment. Let’s let him work on that.’”

The fact that the company was already mid-pivot meant one more radical change was easier to absorb. As Des puts it: never waste a good crisis. If the floorboards are already up, fix everything.

Building AI is not like building SaaS

In SaaS, development is deterministic. You talk to customers, you scope the work, you build it, you ship it, you move on.

AI doesn’t work like that. As Des says: “You don’t know what’s possible. And if something’s possible, you don’t know how reliable you can make it.”

The process Des describes looks nothing like traditional product development.

Before a designer or product manager is involved, you start with the model and test for what new capabilities are now possible. This might involve what Des calls a “torture test”. The AI team constructs hundreds or thousands of scenarios with a known correct answer, and run the model against them. You need to ensure it can complete the task reliably, at or above human quality.

Then you can move into productisation, and determine what infrastructure must be built around it for it to work in the real world.

And once it’s live, you’re not done. You run millions of real scenarios through the system, watch how customers configure it, measure how it performs in the wild, and build reporting and oversight tools so customers can see what’s happening in real time.

You should not chase models

It might be tempting to assume that the path to a better AI product is upgrading to the latest model, but Des pushes back hard on this. When a company announces it has switched to a new model two hours after launch, it means one of two things: they had extremely early access, which is possible but rare, or they have no evaluation criteria.

The AI team’s process for evaluating a new model runs thousands of scenarios and compares three things: what current Fin would say, what the candidate model would say, and what the ideal answer looks like – what Des calls “God’s own support agent.” Only when the new model is demonstrably closer to the ideal does it earn a place in production.

Additionally, most of Fin’s improvements haven’t come from model upgrades. They’ve come from better AI architecture, prompting, and ways to disambiguate. Fin runs across 25 subsystems, many of which now run on models post-trained internally for specific aspects of customer experience. Change one subsystem, and you have to re-evaluate the entire system – because there are trickle-up and trickle-down effects you won’t see otherwise.

That kind of rigour is where the real competitive advantage lives.

You have to know what “good” looks like

If you want to do AI properly, you have to take it seriously. And that means having a clear definition of what good looks like. Without one, Des asks, “What are your team doing? They’re just kind of performatively running around in circles.”

In customer support, good is relatively well-defined. There’s a correct answer to “how do I reset my password?” You can write it down, put it in the torture test, and benchmark off of it.

In other domains, it’s harder, but the discipline is the same. Des uses an example of a LinkedIn post generator. The only true measure of good is whether the post performs. You probably can’t see that directly, so you find a proxy: acceptance rate, how often users actually click post.

You then follow these posts and collect examples that performed well, and maybe some human-written examples. Over time, you build a spectrum from terrible to excellent, and you use it to calibrate your model.

It’s difficult but it’s non-negotiable. Every AI team needs to be able to answer: what does great look like, and are we getting closer to it? Without that, you’re not improving.

What founders should do right now

We’re four years into AI. Des’s advice to founders is to stop thinking in co-pilots and start treating it as a reinvention.

The first step: find someone you trust who is genuinely good at AI, and ask them what percentage of your product still requires a human in the near future. For most SaaS companies, the answer is going to be a lot smaller than expected.

According to Des, you then ask yourself: “If you were starting this product again today and you were good at AI, what would you build and where are humans, if anywhere, essential? And you would build a product that uses AI everywhere it can be made reliable… and boring old SaaS UI wherever you need humans involved. That’s your new product direction.”

Getting there will require painful decisions – roadmap cuts, unhappy customers, engineers resistant to new tools. But the alternative is the Blockbuster path: a string of rational-sounding reasons to delay, right up until it’s too late.

The time is now, as Des says: “You might have one or two years left.”

To hear the full conversation with Des, where he talks managing AI hallucinations, pricing AI products, and Fin’s future as a customer experience Agent, watch on YouTube or listen on Spotify.

Last week we quietly shipped the most significant new technology in the customer service agent category since we started it three years ago. It’s a brand new model for Fin trained by our AI Group called Apex, and it’s objectively the highest performing, fastest, and cheapest model for customer service. It beats the very best models in the industry including GPT-5.4 and Opus 4.5.

In this post, I’ll share the news of this launch, the implications it will have for our category, but most importantly, I think, the implications this has for the frontier labs landscape.

The news

Fin was already the highest performing and most sophisticated agent in the customer service space, consistently beating our impressive competitors like Decagon, Sierra and more at an average win rate in the 70s. It operates at tremendous scale, now resolving almost 2M customer issues per week, a number that’s growing at an exponential clip. In its short life it’s grown to nearly $100M in recurring revenue.

As of last week, ~100% of all (English language, chat and email) customer conversations are now running on Apex. Since day 1, the Fin engine has comprised a system of models, and last year we started replacing the off-the-shelf models with our own, custom trained on our proprietary data. But the core answering model was always a frontier labs offering—initially versions of GPT and recently Sonnet 4.0. But now that core answering model is Apex 1.0.

This model resolves customer issues at a materially higher rate than any other model available. One of our largest customers in the gaming space saw their resolution rate improve overnight from 68% to 75% (i.e. a reduction in unresolved conversations of 22%). We’ve never seen a jump this large from a single improvement since we started Fin.

But importantly it’s also dramatically faster, has fewer hallucinations, and is far cheaper than all other available models—all factors that weigh significantly in the consideration of companies deploying these agents to their service operations.

This is an extraordinarily difficult thing to achieve. And we owe this breakthrough to the foundational research coming out of our 60-person AI group run by Fergal Reid. But even for elite teams like his, this cannot be replicated without the domain specific proprietary evals that comprise our billions of human and agent customer service interaction data points created by our Fin resolution engine, which had already been hand tuned to be the most effective in the category. Training with this system makes our setup a flywheel whereby we can continue to train new models that improve at the edge of our system’s abilities. Put another way, I expect that the results we’re enjoying with Apex 1.0 are just the tip of the iceberg.

What this means for the customer service agent category

Service is arguably one of only two or three categories where generative AI has thus far had a material commercial, economic, real world impact. The other being coding, and perhaps the other being the legal industry. The TAM in each of these spaces is insanely large ($250B-$1T?) and as a result they are hotly contested by multiple companies, which have been aggressively capitalized.

We believe that the winners in such spaces must and will become full stack AI companies. And we’ve already seen this just last week with Cursor making the first such move, with Fin being the second. As features become ~free to build, the technology factors that will differentiate the players will be the AI under the hood, and if you’re using the same general purpose off-the-shelf model as everyone else, you have no durable differentiation.

This means that our competitors will indeed need to eventually release their own models. But we see them just starting now to hire for the talent required to do this and so we think we likely have at least a year head start on the space.

Interestingly, 2-3 years ago, this is not how I imagined AI applications would play out. I thought that the points of differentiation would be all of the things we built around the third party models. The AI game will humble you and no doubt make at least some of my predictions in this post eventually look dumb too.

What this means for the AI industry at large

In a podcast interview last week, Andrej Karpathy said:

I do think we should expect more speciation in the intelligences. The animal kingdom is extremely [diverse] in the brains that exist. And there’s lots of different niches of nature… And I think we should be able to see more speciation. And you don’t need this oracle that knows everything. You kind of speciate it. And then you put it on a specific task. And we should be seeing some of that because you should be able to have much smaller models that still have the cognitive core.

The frontier labs still have the very best models, but the open-weight models are not that far behind. So it’s not hard to see pre-training as a commodity of sorts. Where we think the frontier will move next is to post-training. And Karpathy’s prediction is exactly what we’re seeing with Apex (and Cursor’s Composer 2) and what we’re going to see significantly going forward.

As such, the labs are in an interesting position where on one hand the horizontal, general purpose models are actually over-serving the market for specific use cases. E.g. their models are more generally intelligent than is needed for customer service. And on the other hand, the open-weight models are more than good enough where high quality domain specific post-training can make the resulting models superior at the special purpose jobs, and in the ways that matter to that particular job. E.g. in service, the soft factors really matter, like judgement, pleasantness, attentiveness (as well as the hard factors mentioned prior, like the ability to effectively resolve problems, quickly and cheaply).

Personally, I’m still very bullish on the labs. And we remain very heavy customers of Anthropic, whether as part of the broader system of models used for the Fin Engine, or with the depth of our usage of Claude Code in our engineering org. Yet classic disruption (a la the late, great Clay Christensen) is now at their door. The only way out is to disrupt themselves by building cheaper specialized models too. And the only way to do that is to acquire the evals (or the companies with the evals) needed for that specific task. Which means there will be some interesting data partnerships, or M&A consolidation, or you’re going to see some hyper specific model providers who go it alone and compete with the labs head to head. Likely all of the above.

In the meantime, we’re happy to be the only vendor in our space with a custom model that’s also objectively superior to everything else out there. And we’re excited to deploy it far and wide for the benefit of end customers everywhere. Our next announcement that’s coming very soon will help us do exactly that.

A few weeks ago, I spent a lot of time talking to engineers about how they’re using Claude Code. What I’m trying to figure out is how we help everybody become more effective with these tools – especially those who are still to the left of the adoption curve.

One theme kept coming up: some of our most experienced engineers are accelerating faster and having more success with Claude than those earlier in their careers. This is a direct flip of what we saw last year with the AI autocomplete tools (e.g. Cursor). Claude Code is intuitive for a lot of people, but there are skills and ways of working that some are still struggling with or unaware of. I think strong adoption of Claude requires a real mindset shift, and I see engineers quickly hit local maxima before breaking through to the next big unlock. That’s the problem I’m interested in solving.

So, I sat down with Principal and Staff Engineers Matt, Dan, and Jack for an open conversation about what’s actually working. It was informal – on the balcony in the London office, after work, no agenda. We ended up talking for over an hour about best practices and what we’re all still figuring out. I wanted to share what came up as I think it’s stuff we’re all experiencing, but could do a better job of talking about openly.

There isn’t one right workflow

Engineers can have different techniques with Claude, but there tends to be common themes.

Matt writes long, detailed prompts – “war and peace” was the phrase used. He front-loads all the context, constraints, and direction before Claude writes a line of code – like writing a really thorough brief for a teammate. This doesn’t necessarily happen all in one go, it accumulates through many turns. Matt also uses the “superpowers” plugin, which includes some workflows and skills that Claude applies when developing new features.

“I don’t usually ‘notice’ the presence of the plugin, but I definitely felt the improvement in the way Claude works,” Matt explained. “For example, it asks me questions more than it used to, which is great. It means it’s making less assumptions and forces me to give context where I haven’t realized it was lacking.”

Jack, on the other hand, will often start with long rambly prompts (his words) using voice input with WisprFlow – a self-described “yolo”:

“I can watch that stream of bullshit fly past and I’m like – no, you’re going down the wrong track. It’s not like I’m reading every word, but I just know,” he said.

Jack puts less emphasis on writing the perfect prompt and trusts that the LLM will parse his thoughts as he speaks them out loud in real time. He still gives Claude lots of context, but he’s more comfortable letting Claude get to work earlier and intervenes on the fly if he has to.

As he put it: “Don’t overthink it. Fast correction beats perfect prompting. Iteration is cheap. If it generates a mess, delete it, close the PR and go again.”

Despite using different methods, both invest in building up Claude’s context – and both are applying judgment, taste, and critical thinking throughout.

It’s a conversation, not a one-shot prompt

Matt, Jack, and Dan all take many turns to iterate on their plans. They treat it as an ongoing conversation, not something they need to get right the first time.

• Start with the problem, not the solution: “I need to achieve X. Can you look at how this part of the codebase works and help me understand the options?”

• Use Claude to help you gather context: “Explain to me how feature X works in this codebase. What are the key models? How does it connect to Fin?”

• Shape the solution together: “OK, given what you’ve found, I think option B makes more sense because of Y. What do you think? What am I missing?”

• Iterate on the plan before writing any code: “Actually, I’m worried about Z. Can you think about how we’d handle that edge case?”

• Then build it: “Great, let’s go with this approach. Build it.”

That might be five, ten, twenty turns before you’ve written a line of code. That’s fine. That’s the process working well. Each turn builds context that makes the next one better – and it all stays in Claude’s memory for the implementation phase.

The engineers who seem to struggle most might not be investing enough in giving Claude the context it needs. Say to it: “Claude, build me feature X for this,” and it will – it’s very good at doing what you say. But it doesn’t know if what you said is the right thing.

An example from the conversation: someone shipped a feature, it worked and shipped on time. But when asked why they built it that way, the answer was: “I don’t know.” The code was fine, but the understanding wasn’t there. And that matters – for the next feature, for debugging, for knowing whether this was actually the right approach.

The fix isn’t “write better prompts.” It’s “have more turns.” Let the conversation develop. You’ll end up with both better code and a deeper understanding of the system.

Boris Cherny, who created Claude Code, works the same way: 80% of his tasks start in plan mode – multiple turns of back and forth before a single line of code is written. Once the plan is right, he auto-accepts everything, because “it’s just going to one shot it.” All the real work happens in the conversation; the code is the easy part.

Everything still has to happen – it just happens differently

When you look at Claude Code, the instinct is to think about what you can stop doing. It’s natural – the tool is incredibly capable, and we’re being told that things should be faster now.

But to get faster, there are foundational things people need to understand first. As Dan put it: “The mindset is not ‘offload the grunt work to Claude.’ Claude is the means through which you achieve the end.”

What actually works better is a different mental model entirely. Matt shared:

“Remember how we used to build things two years ago – ‘I’ve given myself a week to understand the matching system.’ That would have been an actual weekly goal back then. That comes down to half an hour now. But you still need to do it. If you skip it and go straight to ‘build me X,’ Claude will build you X without the understanding. And you’ll be in the position of having code you can’t explain.”

“Think about how you built something in a perfect way a year ago and take every element from it – every single element – and put it into your AI workflow. Don’t lose a single thing. Some of these things are ridiculously fast now, but every element still has to be there.”

Claude doesn’t replace any of the steps. It replaces the mechanisms – grepping through code becomes “explain this to me,” reading old PRs becomes “research how this was done before,” writing a tech plan becomes “help me think through the approach.” It’s the same process as before, but with these new tools, it’s dramatically faster.

Your claude.md is an investment

The engineers getting the most out of Claude invest in their local claude.md files.

For Jack, this was a minor breakthrough: “I realized you just say ‘can you please write this for my claude.md.’” You don’t have to author these files from scratch. Claude can generate them from what it learned during a session.

I saw this play out in a learning session last week. An engineer was using Claude to diagnose a complex defect, but Claude kept referring back to comments in the GitHub issue that were unrelated – pulling in noise from a different context entirely, which was frustrating and resulted in Claude and the user getting stuck. According to Jack, this kind of thing is bound to happen. The move is to identify the problem and help Claude understand what to do instead by writing it to your claude.md. “You can tell Claude: ‘hey, don’t ever do that again.’”

The engineers who are most effective have invested heavily in their claude.md files over time. Every time Claude makes a mistake or gets stuck on something, they encode the fix. Jack updates his memory multiple times a day. The advice is to treat memory as evolving operating instructions. Extract recurring patterns and encode them so the same problem never costs you time twice.

Our Senior Principal Engineer Brian Scanlan refers to this as “feed the flywheel.” As an organization we need to get better at identifying the best local optimizations and applying them to everyone, but the more we iterate locally, the more we’ll learn.

The anxiety is real – and it’s okay to talk about it

There is real anxiety about this shift, and a lot of people are keeping it to themselves. Apparently, there’s a term for it now: Deep Blue.

Some of it is about jobs. Some of it is about being judged – the worry that saying, “I’m struggling with Claude” will show up in a performance review somehow. And some of it is about something deeper: the craft. If you love building things – writing code, solving problems, that feeling when something clicks – there’s a genuine fear of losing something you care about. That’s okay, that’s human. If we can be open about that, maybe we can accelerate learning for those that are feeling it the most.

One of the people in the conversation described exactly this. They’d been afraid of losing the thing they loved about the job. And then they described the relief of realizing: “I’ve shifted how I build now, but I do still enjoy it the same amount. I feel like an engineer when I do it.” This was a feeling all the engineers shared. Once they let go of the writing code part, they realized they could move much faster and it was a lot of fun.

In my opinion, the best way to work through this anxiety is to lean hard into it. The genie is not going back in this bottle, and I personally would rather be on the forefront of this shift than be left behind. We are lucky to be in an organization that gives unlimited access to these tools. We should make the most of the opportunity.

What’s staying with me

A few things from this conversation that I keep coming back to:

There are new skills to learn. Some of the things that make people effective with Claude – planning, solution design, knowing what context to provide, thinking in problems rather than solutions – are often developed after years of engineering experience. That’s real, and it means we need to actively help everyone build these skills earlier.

Less has changed than you think. The value of Claude is not just writing the code. Every step you’d have taken before – asking for help, getting plans reviewed, researching how things work, iterating on an approach – still maps to a Claude session. The process of building something well hasn’t changed. The tools have. Making that explicit is probably the most useful thing we can do.

The conversation and the strategy are saying the same thing. Principles our 2x team are working to standardize (feeding the flywheel, giving agents problems not tasks, documentation as infrastructure) are emerging organically as engineers experiment with Claude. Best practice can be codified and shared.

If any of this resonates – or you see it differently – I’d genuinely like to hear from you. Especially if you’re in the group that doesn’t usually show up to the AI channels. Drop a comment below or send me a message on LinkedIn.

And if you find this kind of work interesting, we’re hiring across departments. Check out our careers page to learn more.

I was grabbing breakfast in our SF office a few weeks ago when I overheard two people at the next table. “I spent three months building that thing,” one of them said, “but now I can do it in an hour. Pretty sick.” I didn’t recognize either of them. I leaned over and asked if they were talking about our team’s work. They were. I’d never met them. They were from a team I’d never even heard of.

That’s the moment it clicked for me. When people you’ve never met are casually talking about doing in an hour what used to take them three months - using the tool you’re building - something real is happening.

The Bet

Less than a year ago, Intercom made a company-wide decision: all-in on Anthropic and Claude Code. The engineering organization adopted a set of principles that are aggressive even by today’s standards. All technical work is becoming agent-first. Agents write, test, and review code. Give agents problems, not tasks. We are not satisfied until the agent completes the work end-to-end.

Within weeks, hundreds of engineers were shipping at a pace that would have seemed impossible a year ago. This wasn’t a branding exercise. Anthropic’s technology became the foundation of how Intercom builds software.

But Intercom has maybe a thousand people who aren’t engineers. Marketers, sales leaders, accountants, lawyers, product managers, customer success teams, researchers. They work with the same data. They have the same questions. They need to build things - reports, analyses, tools, automations, even apps - just as urgently as engineers do. And they had no way to participate in this revolution.

A small team of us - you can count us on one hand - decided to change that. Not by building a dumbed-down interface. Not by creating yet another dashboard tool or chatbot wrapper. We decided to give everyone the real thing: Claude Code, with its full power, connected to every system in the company - and make it work for people who have never written a line of code.

What We Built

We didn’t build a new product from scratch. We built on top of Claude Code - because Anthropic designed it to be extended. This is the part a lot of people miss about Claude Code: it isn’t a closed tool you use as-is. It’s a platform. It supports plugins, skills, integrations, and open protocols like MCP that let you connect it to anything. We treated it like infrastructure and built a company-specific intelligence layer on top.

We packaged everything into a single installation - one click and you have Claude Code installed, connected to Snowflake, Google Drive, Slack, other tools, and every skill your domain needs. From there, we covered the full workflow: building, publishing, and distributing what people create so the whole organization benefits. Three things made this work.

One Conversation, Everything Connected

In a single conversation with Claude Code, someone can pull data from Snowflake, enrich it with context from Google Drive, build an interactive visualization, publish it to a shared catalog, post it in Slack, and schedule it to auto-refresh every Monday morning.

No switching between tools. No understanding how any of these systems work under the hood. Claude handles the plumbing. The human handles the thinking.

This is what the Anthropic partnership made possible. Not just a powerful AI model - a platform designed to be woven into the fabric of a company. Plugins for company-specific capabilities. MCP for connecting to any data source. Skills for encoding domain knowledge. Claude Code isn’t just an interface to Claude; it’s the connective tissue between a person’s intent and every system in the organization.

From Conversation to Published Page

People were building incredible things in their Claude Code sessions - interactive charts, analytical tools, data explorations - but everything lived and died in individual conversations. There was no way to share what you made.

So we built a publishing platform. In the same conversation where you create something, you say “share this” and your work - a fully interactive web app with charts, tables, and filters - gets published to a shared catalog with its own URL. It has versioning so you can iterate. Multiple people can contribute to the same page. View tracking so you know who’s using it. A comment sidebar so colleagues can discuss findings inline.

This is the moment that consistently blows people’s minds. They go from “I asked Claude a question” to “I published an app my whole team uses” without ever leaving the conversation. People across every function - marketing, finance, product, sales - started publishing pages for their teams within days.

We built this catalog in weeks. Every single line was authored with Claude Code. We were shipping multiple features a day - dark mode, a collaboration sidebar, performance optimizations, a full design system overhaul - a small team moving at a speed that only makes sense when you’re building with the same tool you’re building for. We were our own best case study.

Teaching Claude Your Company

Claude is extraordinarily capable, but it doesn’t know your company. It doesn’t know which Snowflake table holds your ARR data. It doesn’t know that “5-box” means something specific in your finance org. It doesn’t know that your GTM team measures pipeline in stages S1 through S6, or that your customer success metrics live in a completely different schema than your product metrics.

So we built what we call “guidance skills” - domain-specific knowledge packs that load into Claude automatically. A finance skill that maps every metric to the correct table and knows the business logic behind the numbers. A go-to-market skill that understands the sales funnel. A customer success skill. When a VP asks “show me pipeline by stage this quarter,” Claude doesn’t guess - it knows exactly where to look, which joins to make, and what caveats to flag.

We built the first skills ourselves, but domain experts across the company quickly started building their own. The system improves every time someone contributes - and Claude can discover and invoke skills on its own, even when the person asking a question doesn’t know they exist. If they discover a pattern worth sharing, they contribute it back so the whole system gets smarter for everyone.

The engineering org had framed this transformation as “2x” - doubling engineering output through AI. What we discovered is that when you extend Claude Code beyond engineering, you don’t get 2x. You get something qualitatively different. You get a company where anyone can build software.

What Happened Next

We launched to the company a month ago. The adoption convinced me this isn’t a productivity story. It’s a structural change in how an organization works.

The numbers moved fast. Over a thousand people now have access. More than 300 are active every week. 330 pages published in the last week alone. Over 2,500 views in a single week. Sixty percent of Director-level and above are active users. And people started onboarding their own teammates without us being involved - they just showed a colleague and said “you need to try this.”

One example. Our VP of Demand Generation sat down with Claude Code for the first time, and the next day he’d published a full Global Marketing Calendar - an interactive app that pulls 270+ events from Coda across five regions and enriches each one with campaign metrics and attendance. Filters by status, event type, region. It replaced scattered spreadsheets with a single living page his whole team now uses. One day - from zero to a published app - with no prior experience in Claude Code.

But the numbers only tell part of the story. People who had never built anything were publishing pages their teams use daily. People who had never touched a code editor were contributing skills back to make Claude smarter. One person told the company: “It has unlocked an army of high-agency individuals. Friends at other tech companies are nowhere near this level.” Another wrote: “I truly believe this tool is the most transformative one I’ve ever seen in my career.”

The Flywheel

We didn’t fully anticipate this part. When you give everyone Claude Code with the right skills and integrations, people don’t just use the system. They improve it. When someone notices Claude pulling from the wrong source, they fix it. When someone builds something useful, they share the pattern so it works for everyone. The system gets smarter every week - not because our small team makes it smarter, but because hundreds of people across the company are finding edges and closing gaps for everyone else.

What This Means

There’s a pervasive assumption in the industry that AI coding tools are for developers, and that non-technical people need a different kind of product - a chatbot with a friendly UI, a dashboard builder, a no-code platform. Something simpler.

We’ve found the opposite. The most powerful thing you can give a non-technical person is the same tool engineers use, enhanced with a layer of company-specific intelligence that makes it safe, accurate, and productive. You don’t need to simplify the tool. You need to adapt it - teach it your company’s language, connect it to your systems, and let it meet people where they are.

Anthropic built Claude Code to be exactly this kind of platform - extensible, connectable, designed to be shaped by the organizations that use it. The Intercom-Anthropic partnership didn’t just change how our engineers work. It dissolved the boundary between who can and who can’t build software.

What the engineering org set out to achieve - making all technical work agent-first - turned out to be a much larger idea than anyone planned for. It’s not just engineers who can work this way. It’s everyone.

To be honest, we just wanted to help people answer their own questions. But when you give a thousand people the ability to build anything they can describe in a conversation, something shifts. They don’t just work faster. They start thinking differently about what’s possible.

Welcome to “Acquired Taste”, a limited series from Fin Ideas, exploring the relationship between AI productivity and human taste.

As an AI company, our teams are always experimenting with new ways of working, discovering what’s possible in this era. Fin Ideas is where they come to speak about their findings and document their processes. Recently, as AI tools have grown in sophistication and embedded themselves deeper in our workflows, commonalities have emerged across disciplines. While Agents can handle more than ever before, their abundance of output can quickly feel overwhelming. When ability is no longer the bottleneck, intent and judgement become important gatekeepers, distinguishing adequacy from excellence.

Over the coming weeks, we’ll bring you stories from across our organization that explore what it means to produce truly great work with AI, the value of human taste, and how it can be maintained in a world of abundance.

At Intercom, how we design and build software is unrecognizable from 12 months ago. Our engineering team is already at the point where 90% of pull requests are authored by Claude Code, part of an internal initiative called 2x, where the explicit goal is to double productivity using AI.

For designers, there are commonalities, but the picture is different. We’re able to do significantly more than before, and we’re doing it faster. As my colleagues Thom and Emmet described previously, we’re using AI to rapidly prototype and build out the roadmap, generating working code from rough ideas so we can test and iterate sooner. We’re also taking more ownership of the front end. But this is only the start. The deeper shift isn’t just speed, it’s where design effort sits.

As the rate of execution accelerates, the role of design becomes sharper. Agents can generate artefacts, but they cannot decide which problems matter, set intent, resolve trade-offs, or hold the bar for quality. Our craft shifts with that reality. This means less time refining pixels and more time defining systems, tests, and guardrails that preserve quality and coherence at scale.

Agents will own the middle, the build. Design’s value concentrates at the edges, deciding what to build and then determining whether the output is good enough.

Design’s value shifts to the edges: shaping the roadmap and owning quality.

What’s happening

Intercom isn’t the only organization moving faster. Companies like Spotify and Anthropic are also adopting AI-only engineering workflows. And models keep getting better. A raft of updated LLMs landed between late 2025 and early 2026 with stronger reasoning, larger context windows, and better coding ability. Andrej Karpathy, one of the most influential voices in the field, captures the shift that’s underway:

Engineering productivity is accelerating; it won’t stop at 2x, and that has a profound impact on how we design.

In conventional product development, there’s a natural rhythm that allows for deep thinking. The time it takes to write code creates built-in pauses for reflection and planning. Design and PM use those pauses to iterate, test, and refine. That rhythm could disappear as multiple Agents enable teams to dramatically increase the speed of production.

Thinking time won’t just shrink, it will change shape entirely. Instead of one stream of work with natural gaps, you’d be evaluating outputs from parallel workstreams at the same time. Less like working with a team, more like managing a hundred people who’ve all been given marching orders at once.

But speed is only part of the story. Early AI tools could answer general questions about design or code, but they had no awareness of what you were actually building. The latest tools operate inside your codebase, with access to your components, patterns, and constraints. And that changes everything. Working with AI within a shared context, you stop asking generic questions and start directing specific outcomes. That’s why our designers are now primarily working in code. By doing so, we can go deeper into the problem space earlier and minimize the gap between design intent and reality.

LLMs are obviously great at writing code at pace. But they’re not great at knowing what to build next, or if the result actually works for users. That’s where design comes in. The teams that adapt fastest and harness these tools will have more influence over what gets built than ever before.

What we’ll do differently

When code is cheap and fast, everyone moves upstream. The boundaries between PM, design and engineering will continue to blur. What design brings to that space is distinct: user understanding, experience quality, and the ability to make ideas tangible. A working prototype is worth more than any strategy doc, and AI makes it faster than ever to go from a rough idea to something tangible people can react to. As design, we create compelling visions for what’s possible, building momentum that pulls the whole team forward.

An example by Daria V, a designer on our team, who used Claude Code to prototype with fine-grained controls for a background tint feature to a level of detail that would normally take weeks of back-and-forth with engineering.

Our relationship with quality changes too. Definitive handoffs and perfection on the first pass matter less, instead we focus on the speed and rigour of the iteration loop. The bar for craft doesn’t drop, but instead of spending days polishing a small number of iterations, we explore a wide range of options, get fast feedback, and converge on the right solution sooner.

However, speed without direction is just noise. The old pauses in the development cycle happened by accident, the new ones need to be deliberate. As the pace of output increases, the ability to quickly evaluate becomes the most valuable skill in the process. That means tighter briefs at the start, fast review cycles, and clear criteria for what good looks like. It’s critical that we create the space to ensure what’s created is ultimately worth shipping. The faster Agents move, the more valuable design judgement will become.

There’s something else worth noting. Working with AI isn’t just faster, it’s different. These models don’t approach problems the way a colleague would – they make connections across domains and challenge assumptions you didn’t know you were making. The back-and-forth often reframes the problem entirely, giving us new input into the design process.

A prototype of an agentic UI by designer James Cash. Built within production environments with live data to learn from real-world use. AI helps explore possibilities, but nuance and edge cases only show up in the wild.

For design leaders, that means moving from gatekeeper to orchestrator. When anyone in the organization can design, our value comes from setting the standard for what good looks like and holding that quality bar. By doing so, we raise the capability of everyone around us.

What this looks like in practice

These shifts are already underway internally. If last year was about experimentation, we are now focused on scaling what works and building a consistent level of AI fluency across the team through a series of deliberate changes:

1. Promoting AI fluency
   We run structured training, shared rituals, and focused exploration time so every designer can use these tools confidently. Demo sessions, office hours, and deliberate experimentation are becoming part of our rhythm.

2. Challenging orthodoxies
   We are no longer defaulting to Figma, which is increasingly being used more like a whiteboard. Starting in code changes removes some abstraction and forces earlier decisions about structure and states while surfacing edge cases. It also accelerates iteration. When the cost of generating functional UI approaches zero, the value shifts to intent and judgment.

3. Cross-functional collaboration
   Designers work closely with engineers and product managers to share tooling patterns and workflows. Fluency cannot sit in silos. The 2x initiative explicitly expects non-engineers to contribute directly to the codebase. Our design system work is how we make that possible at scale. It becomes a shared resource that raises the quality bar across the organization.

4. Design system as agentic infrastructure
   In a world where Agents write most of the code, design systems become the infrastructure that protects quality. Components, libraries and guidelines are the foundation that Agents and teams build on top of. The better the system, the better everything produced. Strong systems allow quality to scale without adding review overhead. The Surge design system playground is an example that enables designers to prototype directly with production components.

5. From makers to curators
   Code generation can scale but human attention cannot. As Agents explore widely, our role becomes more curatorial. We shape trajectories, recognise patterns across options, and deliberately converge where it matters. Exploration expands, but convergence becomes the craft.

The Surge design system playground enables designers to prototype using production components

What still matters

Not everything changes. Some things become more important.

Critical thinking, judgment, and taste sit at the top of that list. AI can generate a hundred variations of a solution. It cannot tell you which one is right. That decision still depends on context, experience, and an understanding of trade-offs that models do not truly possess. Knowing when something is good enough, and when it needs another pass, becomes more valuable as production speed increases.

Craft still matters too, but how we define it is changing. It’s the small decisions that make something feel intentional and considered rather than procedural or AI-generated. Users won’t care how something was made. They’ll care whether it feels right. Our job is making sure it does.

The tools have changed, and the speed has changed. But the core of what makes design valuable has not. We are still the people who look at what exists and see what it could be, and decide whether it should.

The difference now is that the distance between seeing it and shipping it has never been shorter. That’s not a threat to design. It’s the best thing that’s ever happened to it.

We built an internal Claude Code plugin system at Intercom with 13 plugins, 100+ skills, and hooks that turn Claude into a full-stack engineering platform. Here’s what we learned building it - the highlights that went viral on X this week (730K+ views).

The wildest one: a read-only Rails production console via MCP

Claude can now execute arbitrary Ruby against production data - feature flag checks, business logic validation, cache state inspection. Safety gates: read-replica only, blocked critical tables, mandatory model verification before every query, Okta auth, DynamoDB audit trail. I launched it by saying “It is either the worst thing in the world that will ruin Intercom, or complete genius.” It is used a lot. No issues so far. Last time I looked the top-5 users weren’t engineers - design managers, customer support engineers, product management leaders were all actively using it! The console is part of a broader Admin Tools MCP that gives Claude the same production visibility engineers have: customer/feature flag/admin lookups etc. A skill-level gate blocks all these tools until Claude loads the safety reference docs first. No cowboy queries.

Full lifecycle observability with OpenTelemetry

We instrumented every Claude Code lifecycle event with OpenTelemetry. SessionStart, UserPromptSubmit, PreToolUse, PostToolUse, PermissionRequest, SubagentStart... 14 event types flowing to Honeycomb. Privacy-first: we explicitly never capture user prompts, messages, or tool input. Session transcripts sync to S3 (with username SHA256-hashed for privacy). We can analyze how people actually use Claude at scale. On SessionEnd, a hook analyzes the entire session transcript with Claude Haiku looking for improvement opportunities. It auto-classifies gaps (missing_skill, missing_tool, repeated_failure, wrong_info) and posts to Slack with a pre-filled GitHub issue URL. This creates a feedback loop: real sessions -> detected gaps -> GitHub issues -> new skills -> better sessions.

A forensic flaky test fixer

Our flaky test fixer is a 9-step forensic investigation workflow with a 20-category taxonomy of flakiness patterns. Hard rules: - NEVER skip a spec as a “fix” - NEVER guess root cause without CI error data - Downloads failure data from S3, classifies against the taxonomy Sweeps for “sibling” instances of the same anti-pattern. Fixes common patterns widely. This matters a lot when you’ve got hundreds of thousands of tests.

PR workflow enforcement at the shell level

Claude Code hooks enforce our PR workflow: 1. A PreToolUse hook intercepts raw “gh pr create” and blocks it unless the create-pr skill was activated first 2. The skill extracts business INTENT before creating - asks “why?” not just “what changed?” 3. Another hook blocks ALL modifications to merged PR branches (push, commit, rebase, edit) 4. After PR creation, a background agent auto-monitors CI checks using ETag-based polling (zero rate-limit cost)

Evidence-based permissions and tool management

After 5 permission prompts in a session, a hook suggests running the permissions analyzer. It scans your last 14 days of session transcripts, extracts every Bash command approved, and classifies them into GREEN (safe), YELLOW (caution), and RED (never auto-allow). Then writes the safe ones to your settings. Evidence-based, not prescriptive. We also maintain good defaults! A separate PostToolUse hook detects “command not found” errors and BSD/GNU incompatibilities in real-time. Spots things like “grep -P” failing on macOS. Once per session, suggests the fix. Installs via Homebrew and updates Claude’s config files so that it knows the tool exists in future sessions. Self-improving developer environment!

QA and video analysis

Video transcript skill: feed it a Google Meet recording, get a markdown transcript with intelligently-placed inline screenshots at moments where the speaker says “as you can see” or “look at this.” QA follow-up skill: takes QA session documents through a 7-stage pipeline that identifies issues, investigates the codebase, filters for quality, and creates GitHub issues to track. Far easier QA!

Claude4Data: beyond engineering

Our data team built a Claude4Data platform with 30+ analytics skills - Snowflake queries, Gong call analysis, finance metrics, customer health reports. Sales reps, PMs, and data scientists all use it. One internal quote: “Friends at other tech companies are nowhere near this level of sophistication.”

Keeping it all running

We automatically ship our marketplace and keep it up to date on our Macs using JAMF. We run reports on skill creation and usage, and keep an eye on quality. The most used skills have high quality evals and are reviewed regularly.

And there’s more

• A weekly GitHub Action job that fact checks and updates all CLAUDE.md files. Needs to go further and continually learn

• Code Review agents with manners that only post important feedback - LSP servers for all main runtimes, speeding up code search

• Production log ingestion into Snowflake with a very well-tuned skill for incidents and troubleshooting, working alongside trace data in Honeycomb and infrastructure metrics in Datadog

• Local development environment setup and troubleshooting - very necessary as more non-engineers use developer environments

• LOADS of incident/troubleshooting investigation skills, converging around progressive disclosure in a solid core skill. We have a goal to make all runbooks follow-able by Claude in the next 6 weeks

The wild thing is we’re just getting started. All technical work and our entire SDLC is getting skill-ified. Remote agents will accelerate things even more.

The Research, Analytics, and Data Science (RAD) team at Intercom, building Fin, drove this transition. What we learned goes beyond tools. It’s a different way of thinking about what data teams are for.

This is that bridge. And the more we lean into it, the more it feels like we’re witnessing a turning point in our industry.

The era of legacy BI tools

For decades Tableau, Looker, and Power BI were the bedrock of data visualization. They helped organizations turn rows of numbers into meaningful charts. They made data accessible across teams. They were the default.

At Intercom, Tableau has played that role powering company-wide reporting, surfacing key financial and product metrics, and giving teams a shared language of insight.

But here’s the thing: those tools were built for a different age. They were designed for:

• Pre-defined metrics

• Manual configuration over code

• Reporting as a static output

As a data scientist, these tools now feel almost prehistoric. Gone are the days of scraping the Tableau Community Forum, or waiting on your workbook to become usable and editable with the spinning wheel of death…

Enter code-first visualization

The cost of writing software collapsed. That’s what changed everything.

Generative code assistants have fundamentally changed the way of working for data scientists across the stack. What once required a multi-day sprint with handoffs to engineering and reviews can now be scaffolded in a single sitting. The barriers that separated data scientists from full-stack development quietly disappeared.

That’s when we stopped thinking about dashboards and started thinking about interfaces.

The Streamlit moment

There was a moment when we realized something simple but profound:

We could stop thinking of charts as “views” and start thinking of them as “interfaces.”

Streamlit made this possible.

Writing a visualization became:

• Query Snowflake directly in Python

• Transform and shape the data programmatically

• Expose controls and filters native to the code

• Deploy web apps with minimum overhead

The results went beyond accelerated workflows. We were starting to build interactive tools driven by data.

But Streamlit still lived in a Python-centric world. It had limited UI flexibility and wasn’t designed for large-scale, shared application logic.

It was great for rapid prototyping. But as we started to think bigger, we wanted something more.

Introducing full-stack data apps: React + FastAPI

This is where the real leap happens.

Why constrain data visualization to a single page or tool when the rest of the product world has moved on?

With React on the frontend and FastAPI on the backend, data visualization becomes:

• Dynamic rather than static

• Composable rather than fixed

• Interactive rather than constrained

• Reusable across teams and contexts

What you end up with is a data application. At Intercom, that became Cockpit, an internal data surface built as a true product.

Cockpit isn’t “another dashboard.” It’s a platform:

• Metrics flow through APIs directly linked to our Enterprise Data Warehouse rather than static extracts

• Filters are true frontend state objects

• Component libraries ensure consistency and quality

• Real-time interactions feel like product logic rather than report navigation

Why this isn’t just hype

Here’s a telling moment:

We introduced a new metric definition in our financial data model. In Tableau, rolling that change through the relevant dashboards, adjusting filters, and republishing took almost an entire day.

In Cockpit? Because the metric and UI were both defined in code, and our testing/CI workflow is automated…that same change went live in about an hour.

A full 10× improvement in iteration speed is a major shift in how insight becomes action.

It means that when product teams ask for exploration surfaces, we don’t deliver a report. We deliver an interactive tool they can use, question, extend, and act on.

Some might worry that this feels like another tech trend. But if you strip away the tool names, the underlying theme is clear:

Visualization in the AI era needs to be interactive, trustworthy, and extensible — and code gives you that.

Generative AI has accelerated this shift by lowering the cost of writing production-grade code. Tools that once required deep frontend expertise can now be scaffolded by AI with minimal friction. This means data scientists can operate further up the stack than ever before — and that’s reshaping what we build.

Data viz is no longer the end of an analytics workflow. It’s the surface of a data product.

What’s possible now

When the interface is code, the possibilities expand:

• AI-assisted narrative summaries that sit alongside charts

• Real-time alerting tied to visual state

• Personalized data surfaces for different roles

Each signal moves the interface slightly further from “here is a chart, interpret it” and closer to “here is what’s happening, and here is what to do.” The human is still in the loop, but the loop is tightening.

Where this is heading

The next shift moves past visualization entirely. The dashboard gets replaced by an agent that acts on data directly: surfaces the right insight, to the right person, at the moment it matters, without waiting to be asked. When that happens, the measure of a data team’s success changes too. Dashboard views and report adoption give way to something simpler: business outcomes.

Despite having been around for 11 years, ChatGPT’s arrival in 2022 made it clear that Intercom and its helpdesk were under threat.

This was a moment of reckoning, a time for radical action. As Des puts it: “You can’t just fight to protect something that’s inevitably going to die”. Instead, the company moved to create a product fit to compete in the AI age, even if it meant changing everything about itself.

Des recently joined the Scaling Europe podcast to talk about this transformation, why great product leaders must think beyond customers’ immediate needs, and what he looks for in AI startups.

Here are the biggest takeaways:

Becoming an AI company takes sacrifice

Pivoting a company as large as Intercom required a decisive CEO who saw an inconvenient truth and embraced it. That looked like ripping up roadmaps, reallocating resources, buying a new domain, and pushing the entire brand in a new direction.

Being a private company helped. Telling investors you’re handing back revenue to pursue something unproven is a hard sell, and Des thinks that’s why public companies were slower to react. You also have to communicate your new goals with your team, otherwise they may try to delay or dilute them.

Now, companies reach out to Des to find out how the management team pulled it off. The conversation always follows the same pattern. Once he describes the pain, the cannibalization, the internal resistance, they ask: “Is there not an easier way? What’s the diet version?”

Unfortunately, there is no diet version.

Your customers are experts in their problems, not your solutions

When asked how do you balance the desires of customers and taking big bets on AI, Des reaches for a classic Henry Ford quote: “If I’d asked my customers what they wanted, they’d have said faster horses.”

But then he reframes it. A great product leader hearing “faster horses” doesn’t write down “horse.” They write down “speed.” Then they ask: “what else?” And the customer might say comfort, reliability, warmth, being able to see at night. You end up with a list of requirements that has nothing to do with horses.

Customers are not there to solution for you. They’re not technical experts and they don’t know what’s possible. But they are experts in what they want. So you have to work both sides: what customers care about, and what technology is making possible.

In customer service, the signal was already there. Teams used macros (prewritten messages) because they were dealing with an overwhelming number of repetitive questions. Nobody was handcrafting artisanal responses to every query. Intercom built AI that could handle informational queries, showed it to customers, and the response was immediate. Then customers started asking for more: the ability to solve complex queries, automated refunds, and third-party integrations. Intercom went back to the lab, built it, came back, and each cycle reinforced the next.

As Des says, if we’d waited for customers to ask for AI, it would have been 2025, and we’d be dead.

Reality check for AI startups

Beyond his work at Intercom, Des is also a prolific angel investor. When it comes to AI startups, he looks for four characteristics:

• Solving a real problem.

• Differentiated AI.

• Pricing power (not a thin wrapper on top of a frontier model).

• Some margin or a clear path to it.

He’s also candid about how volatile the space still is. He has watched as Intercom’s engineering team has moved between coding tools multiple times – Cursor to Windsurf to Augment to Claude Code, and back again. At any given point, any one of them looked like the clear future of software development. He thinks we’re still in an experimental phase where everyone is trialing everything and prosumer churn is nasty – which is reinforced by the flood of VC money keeping prices artificially low, making it easy to buy and easy to leave.

What Des would do differently

Des is excited by the enthusiasm for Fin for Zendesk and Salesforce but looking back,

he wishes he’d launched Fin beyond our helpdesk sooner. However, what was most important in 2023 was building trust because customers were still dubious of AI’s abilities. It was a balancing act between conviction and credibility.

Today, the market context has changed and Des believes companies should move with ambition. Not to mention, the increased pace of technological development thanks to agentic coding tools. Adapting for new verticals or building features can now take weeks rather than quarters, so think big.

To hear Des’s thoughts on the state of European tech, the potential of Fin, and how to think about product direction in the AI era watch the full conversation on YouTube or Spotify.

Fin is the leading Service Agent product by any interesting metric. Customer count (8k), average resolution rate (67%), revenue (approaching $100M). Our average win rate against all ~three dozen competitors is in the 70s. And the most impressive brands in the world, like Anthropic, Snowflake, and Polymarket, run on Fin.

But it’s leading in a very crowded field. With this round, the total amount raised in just 3 years in service agents alone is over $1B.

In this game, differentiation is everything. So how do we compare?

1. We’re a product, not a consulting contract. Yes, we too have the charming forward deployed engineers who will come and eat your snacks. But in 2026, you want to move fast and use a robust, purpose built platform, and then manage it yourself too.

2. We have a help desk, not just an agent. Agents are about to do all the things, but humans are not going away for a long time either. We have many great customers on Zendesk, Service Cloud, and more. But most love the seamlessness of Intercom + Fin.

3. We have the highest performing agent because we run on our own AI, not just the generic models that our competitors must use. Our models are trained on billions of proprietary human customer experience datapoints and built by our 60 person strong AI group.

Not bad.

This might be just fine if your author was satisfied with win rates in the 70s.

…

Your author is not satisfied with win rates in the 70s.

And so we’ve been building item number 4 on this list, the Customer Agent.

Answering service questions is a neat trick, makes customers happy, and saves a pretty penny. But it’s not nearly taking advantage enough of the tech we’ve got in 2026. In the very near future, every single digital business customer will have an intimate, warm relationship with an agent that never leaves their side. From day zero, to year ten. It will know and remember every single pertinent thing about the individual it’s serving. It will thread the needle between the customer’s goals and the business’ goals, for their mutual success and satisfaction. We announced this plan in October 2025 at our customer event, Pioneer, and recently our competitors have started to talk about this too. But the vision I’ve described thus far is where theirs stops, and yet we’re only getting started. Our agents will be more than a “concierge.” Ours will handle more than what, in the lingo of yesteryear, our competitors call “interactions.” These agents will be sellers and advisors, teachers and experts. They will achieve so much more than efficiency, they will allow what was heretofore impossible with humans: truly perfect customer experiences.

I’ll stop myself before I get lost in my own hot air and say only that we can’t wait to show you what we’ve built. Very soon. We have significant brands now running large parts of their customer operations in a way that just months ago they never thought would be possible. We’re generating tens of millions in additional pipeline for one customer alone. And delighting their customers in the process. And we’re doing it with a new conversational paradigm that’s never been seen before.

There are some advantages to being ✨ an incumbent ✨. One is cashflow. Our white hot startup competitors have raised hundreds of millions over the past couple years. But we have hundreds of millions in gross profit to spend EVERY YEAR. So, thus far, we’ve been able to go way harder and move far faster than the new guys. But the Customer Agent opportunity is just too damn big to not go even harder at, and that’s what this new capital is for.

One fun part of this story is that this $250M is… debt! There’s bountiful equity ready to go for AI companies, and we raised $100M last year for an employee tender offer. But if you ask me, diluting your shareholders for capital you can get at a mere fraction of the cost with debt is undisciplined. Access to debt is yet another advantage the late stage companies have that I expect we’ll see a lot more use as they pivot to AI.

We’re excited to partner with Hercules Capital on this deal and to bring you major new Customer Agent releases this year, with the first next month.

PS: We’re very much hiring. 650 new people this year alone. All the roles in all the places—SF, Dublin, London, Berlin, Chicago, Sydney.

Companies are speed-dating Agents, falling in and out of love like college students. They’re making decisions in weeks that used to take quarters. They sign a contract, go live, and then a few months later, do it all over again with someone else.

Not because the technology failed, and not entirely because the market shifted. But really, because the first decision was never really a decision, it was an experiment that resulted in a contract. They are flirting with Agents, not getting serious.

Welcome to the era of provisional AI buying. And if you’re an executive with an AI strategy, you should be deeply uncomfortable with what that means, because breaking up is way harder to do than you might think.

Commitment phobia

The Agent market now has over 100 vendors with real customers. These are not just paper launches and demo videos; these are actual production deployments handling real support volume, and this figure doesn’t even count the myriad build-your-own attempts in the market.

You could argue this is healthy competition – there are more options, there’s more innovation, better outcomes for buyers. In reality, what’s happening is fragmentation. Vendors are finding footholds by being narrowly easier: faster to set up (maybe); cheaper per ticket (at first); simpler to manage (at first); more comfortable for teams that aren’t ready to fully commit to AI.

Some win by specializing in a single vertical. Some win by offering pricing that removes the risk of commitment. Some win by showing up in the room before anyone else – through investor networks, founder connections, or sheer speed – and capturing attention or creating FOMO before a proper evaluation happens.

These are real competitive advantages in the moment, but they erode over time. Speed-to-deploy doesn’t matter at month six, low commitment pricing stops being an advantage when you need the product to do more, vertical specialization narrows what’s possible, and showing up first only works until someone starts asking harder questions.

This is a market where decisions get made fast and unmade almost as fast. We see this firsthand because in addition to Fin, we also have a helpdesk platform in Intercom, where customers can install competitor AI tools into their workspace. Our Intercom data shows us how long those competitors stay plugged in.

There’s a not-uncommon pattern we see: exploration peaks a few months after deployment but the honeymoon period is short. Vendors who sold in based on a speed or simplicity advantage get quietly dumped because they’re not robust enough for the operational reality.

The buying is provisional, and provisional buying is expensive in ways most people haven’t calculated. It has a unique switching cost.

The switching costs nobody’s pricing in

Software companies spent decades building switching costs into their products strategically. Switching is destructive, it’s a pain point for the buyer, and in SaaS it means a mess of data migration and retraining. It’s painful, but there are limits to the pain – just enough to make it hard to leave.

But with Agents it’s different. When you run an Agent in production, your organization adapts around it. Your knowledge base gets structured for how that system retrieves information. Your escalation workflows assume specific handoff patterns. Your team evolves based on how the agent behaves – when it handles things well, when it needs help, etc. Over time, your support operation and the Agent become interdependent.

This is a good thing. It’s actually the whole point. With a good Agent, the product and the team learn together, and collectively, their performance compounds through use. But it means that every month of operational learning you’ve accumulated and all the collaboration that was poured into the Agent gets zeroed out when you switch.

Companies that treat Agents like interchangeable utilities – swap one in, swap one out – are discovering that the accumulated operational intelligence matters more than the sticker features.

Why the fast wins don’t last

In any market with high uncertainty and a lot of vendors, there’s a playbook for winning early: get in the room before the competition. Lower the barriers to saying yes (often by slashing prices at the start), make the first deployment feel effortless, worry about depth later.

It’s a rational playbook. And right now, it’s working – for a certain definition of “working.”

Some vendors are winning by positioning as the zero-effort option: no knowledge base cleanup needed, no workflow design, no complex configuration. Just turn it on.

These wins look convincing at the point of sale. But the pattern that follows is remarkably consistent. Month one looks great. The Agent is live, it’s handling volume, the team feels relief.

Month three, operational reality starts to surface. Escalations aren’t clean, edge cases pile up, the things that were easy to set up turn out to be hard to refine, and security or compliance gaps that weren’t visible in the initial deployment start to matter.

Month four or five, someone starts looking at alternatives. Not always with urgency, more like a slow loss of confidence. A quiet exploration.

And then the cycle repeats.

The vendors winning on speed aren’t building durable customer relationships. They’re building a pipeline of future re-evaluations.

The fragmentation trap

The market isn’t consolidating around a few strong players. It’s splintering.

Some companies are now running three AI tools simultaneously: one for B2B customers where quality matters, another for B2C where cost matters, and a third for internal operations. Three knowledge bases, three sets of analytics, three systems that don’t learn from each other.

This looks like maturity, but it’s actually a compounding tax on complexity. The operational overhead of managing multiple tools grows while the performance of each individual tool stagnates, because none of them have the full picture.

The fragmentation isn’t evidence that the market needs dozens of specialized Agents. It’s evidence that most buyers haven’t yet committed to a platform that’s deep and broad enough to replace the patchwork.

What separates the Agents that stick

If this is the era of provisional buying – and the evidence strongly suggests that it is – then the question for every executive evaluating AI is straightforward: what kind of product survives provisional buying?

Not the fastest to deploy. Speed wins the first contract, not the renewal.

Not the cheapest per interaction. Low price wins in segments where support is a pure cost line, but it puts a ceiling on what the product can do, and eventually, companies outgrow that ceiling.

Not the most specialized. Vertical focus wins a niche, but it also limits what’s possible as your needs expand.

The products that survive provisional buying are the ones that compound.

Performance that improves the longer you use them, not just because the models get better, but because the product learns from your specific operation.

Resolution rates that climb month over month as the system absorbs more of your knowledge, more of your edge cases, more of your customers’ patterns.

Self-management that reduces your team’s burden over time, rather than adding to it. The best Agent goes beyond just resolving conversations, it reduces the operational overhead of running AI support. It gets easier to manage at scale, not harder.

And a platform broad enough that you don’t need three tools for three problems. One system that handles chat, email, voice, and the internal workflows around them. One knowledge base, one set of analytics, and one place where every interaction makes every future interaction smarter.

Robb Clarke, Head of AI at RB2B, had the same hesitation a lot of leaders have going in:

“Initially, I was hesitant about using Fin. I’ve experienced the last decade or so of terrible chatbots and didn’t want our users to have a poor experience of getting stuck and frustrated. But now I know that Fin is completely different. It allows our users to solve problems anytime, and if I could go back, I would have integrated it into our process much sooner. What really made me realize that it was working was suddenly my days weren’t consumed with solely answering support tickets.”

That’s what it feels like from the inside: a gradual shift in what running support actually looks like.

This is the compounding test. At month six, is your Agent better than it was at month one – because you’ve been using it? Or is it exactly the same, and you’re doing all the improving yourself?

The bet you’re actually making

Every company deploying AI in customer support right now is making a bet, whether they realize it or not. Not about which vendor has the best feature list. Feature lists converge – they always do. The bet is about trajectory.

There are products that reward commitment. Resolution rates that climb month over month. Operational overhead that decreases as the Agent handles more.

And there are products that feel good on day one and plateau at day ninety. Where switching feels painless because, truthfully, not that much would be lost.

The companies still cycling through Agent trials when this market consolidates won’t just be behind. They’ll have spent a year accumulating nothing.

If you haven’t asked that question yet, you’re probably on your second or third Agent already. And you’re about to be on your fourth. The problem travels with you. Switching vendors doesn’t fix a readiness gap, it just resets the clock.

Try Fin

The predicament that the SaaS industry is in is not that surprising. No, we didn’t quite realize that AI was going to commodify code. But we did know that in the face of disruption, a force not new to tech in any way, the only way to have a place in the future is to destroy your past. The failure of essentially all software companies to do so in the age of agents has left them in an extra sticky spot now that the stock market is less excited about conventional software.

In this post, I’m going to offer Intercom, the company I run, as a case study to help me explain how SaaS companies can be saved, and share the things we did, starting three years ago, to find relevance in this new world. We’ve found ourselves being referred to as the poster-child for success as a late stage SaaS company in AI, and I’d like to first share some numbers and background context to help you understand why that is.

Three years ago, our future was looking pretty bleak. I jumped back into the CEO role after a two year hiatus while sick, when we were heading quickly towards negative growth. All SaaS growth rates fell as the ZIRP days waned, and ours fell extra hard due to an unfocused business strategy that led to poor product market fit. A month later, ChatGPT was announced and we all began our collective, gradual, and still ongoing journey to try to understand what it all means. I’ll give you the simplified meme version of the story first—“step 1: AI; step 2: ????; step 3: profit”—because I’ll be explaining the how shortly thereafter. But, in summary, we launched our new service agent, Fin, in the summer of 2023, and our business began to violently recover thereafter.

We’re now at $400M ARR overall, with Fin about to pass $100M. But most remarkably, while growth rates amongst our peers have continued their decline, we’ve doubled our overall growth rate each year for the past two years, and are now on our way to being the fastest growing, large software company (per our knowledge), private or public, in the world. This is structural acceleration that comes from the aggregate of two businesses, one being the hypergrowth business Fin growing at ~3.5X and about to be half of our revenue early next year.

For anyone in this industry, particularly if you’ve been in it for a decade or more, you’ll know that the chart above has essentially never been seen before. It’s so strange, it’s been hard for us all to believe. For everyone else, please take my word for it that what just happened at Intercom is kind of insane.

Anyway, I want to talk about destroying the past, but before that, some acknowledgements. We had a lot in our favor that got us out ahead of the journey that everyone else must now take. For one, we were desperate for new growth. We were performing far worse than average, we had less to lose. That makes hard decisions less scary. Beyond that, we had a CEO change. It’s far easier for someone new to come in and say they don’t like how the last guy did things and rip everything up. CEOs who’ve been in seat the whole time have to wrestle with their egos and blind spots to see that great change to their own plans is the only way. And finally, we were in the right place at the right time. Conventional service software was so obviously going to be decimated by agents, and we had been building AI bots with our own AI team for years. We didn’t have a standing start.

But we made plenty of strong and brave decisions as well, the essence of which I’m asking you to do now too: We turned our back on everything we held dear. We actively, literally killed our old business. We followed the only path out of this mess, which is actual creative destruction.

In a world of agent abundance, the workflow tools sold by our industry are clearly far less important, and also must drastically change. Agents don’t need workflow tools, and the humans working with the agents need different tools too. The tough pill you must swallow is that if you can’t become an agent company, your CRUD app business has a diminishing future. But what about cannibalization? “I’ll damage the revenue from my workflow tools if I pump my customer base with agents which don’t need those tools.” YES, YOU WILL. And if you don’t, someone else will gladly oblige. This is why we call it creative destruction.

At Intercom, we destroyed so many things, big and small. We ripped up our old values, and created new, disruptive ones which we then hired and fired against to drive the behavior we needed in this new world. We rewrote our mission to focus on our agent goals. We changed our targets to Fin revenue. We switched up our board, removing “mature and experienced” leaders for startup founders. We moved our R&D focus to be nearly 80% on Fin, while that business was still a single digit percent of our revenue. We created a whole new brand, and a separate site, with a separate $1M .ai domain—ouch—and drove 100% of our paid traffic to it. Every bit of marketing effort said Fin Fin Fin, not Intercom. And was risky, big picture brand and positioning marketing to hopefully pay off later vs incremental performance marketing to definitely pay off that quarter. Again, while Fin was a single digit percent of our revenue. All because we needed the market to give us a new look for a new category. We aggressively promoted and compensated our AI team above others. We grew it from ~6 to ~60 people in 3 years with real, Phd level AI scientists and researchers. We built out our own AI, and trained our own foundational models. (More on that soon.)

This slow work behind-the-scenes hurts when your nearly 30k customers are asking for new features. Almost all product launches were about Fin. All podcast interviews, all events. We announced that we would spend $100M of our cash reserves—of course, a paltry figure now —back when many were convinced AI was pure hype. We actively managed our entire customer base to a new, risky pricing model—we invented “outcome based pricing” that everyone in the agent space now talks about—that focused monetization on our helpdesk and agent combo, while reducing pricing for everything else, killing ~$60M ARR in the process.

We did not hold back on the creative destruction. And that really is the only idea I’m trying to sell here. We deserted our past to make way for our future.

To my peers in software: This shit is insanely hard. (And if it’s not hard it’s unlikely you’re doing it right.) The shift from on-prem to cloud wrecked many companies, but the change was not nearly as fast. And while it proved quite difficult for the previous generation to adapt quickly enough to keep up with my own, the shift in approach, skillset, go-to-market, and more was not nearly as dramatic. But, still, this shift is possible. Little, old, left-for-dead 15 year old Intercom did it. You can do it too! You have the brand, the customer base, the cashflows, and the access to debt. And you have the workflow tools that can be adapted for their new future for use alongside your agents too. Most of you have started moving towards this world already, but in contrast to what most AI-pilled technologists believe, I don’t think it’s too late if you haven’t! The tech is moving so fast, but customer adoption in many places will remain slow. Many large software companies will die and be bought for parts, but many will survive. As someone who’s been grinding alongside you for decades in this industry, I know how scary this time is. I want you to survive it and win. All it will take is destroying everything you love. Good luck.

Subscribe now

When the world is changing around you, it can be tempting to freeze. Letting go of what you know is uncomfortable. But AI is a transformational force, it will eventually make its way into every vertical and workflow. You’d rather be leading the charge than chasing the pack. As Paul says, transitioning into an AI company is “brutally hard, but anyone can do it if they are prepared to take big risks.” Let’s look at where those risks have taken us and where we’re still trying to go.

Admiring the view

This week, our own AI transformation came up in two conversations.

The first was on Odd Lots, a podcast from Bloomberg, where we were cited as an example of a legacy player that successfully pivoted towards AI. According to guest Jared Sleeper: “They got very aggressive about building out an AI product called Fin… It really accelerated their business and that’s the mega bull case.”

The whole episode is a great way to check in with the current SaaSpocalypse, you can watch it here.

We were also delighted to see our very talented Creative Studio (ICS) receive recognition in AColorBright’s Aesthetics of AI wrap-up.

According to AColorBright, as AI models race to one up each other, the product landscape has gotten rather boring. The real fun is happening in the branding and design space, where Utopian Dreamers and Bold Builders fight over the look of the future.

We were examples of six of the 14 aesthetics, including: contemporary realism, technical illustrations, morphing objects, outer space, and shades of off-white.

If you’re in need of brand inspiration, don’t miss the full report.

Our dedicated readers already know all about the cool work our ICS team is doing thanks to M.C. Madrigal’s “Tools that shape thought.” But if you missed it, catch up here.

Complex work just got easier

To make Fin even more capable, on Wednesday we announced 12 big updates to its Procedures and Simulations capabilities.

Procedures make it possible for Fin to tackle complex work, while Simulations ensure you can thoroughly test these Procedures before they reach customers.

Teams can now:

• Build and manage Procedures using natural language.

• Apply the controls and data needed for accuracy.

• Test every scenario before it reaches a customer.

All without needing engineering support.

To get all the details, watch the full updates video or read a complete breakdown.

Calling the future

We’ve all had abysmal experiences with automated phone support.

But with AI, those days may soon be behind us.

At our latest Fin Meetup, great minds from Intercom and Cartesia shared what they’ve learned from scaling voice AI.

The highlights:

• Voice AI may have crossed the uncanny valley: A growing number of customers will actually engage with it.

• Answer quality is still king: Impressive latency and natural voice mean nothing if the agent can’t solve the actual customer problem. In voice AI, you’re judged by your worst answer, not your best.

• Production is 10X harder than demos: Most projects cut 90% of their original scope when they hit real-world challenges—background noise, edge cases, and integration with actual business operations. Voice isn’t just chat with audio added.

You can read the full run down of events here.

AI IRL

If you’re having a case of AI FOMO, don’t worry, we have some upcoming events.

First, if you’re experiencing the unrelenting rain in London, this machine learning meetup will be sure to brighten your day.

Join us in our London offices on March 4th at 6pm GMT where you’ll hear from members of our AI Group and Machine Learning Scientist team.

Cathal will be giving a talk entitled: “All of Training is a Stage: Understanding LLM Training through the Lens of Role Play.” Exploring how each stage of LLM training relates to this idea of “role play,” why it makes models both powerful and fragile, and what it means for the future of AI alignment.

While Sagar will follow this up with “Specialists, Not Geniuses: A Journey from Weights to Agents,” where he asks that question: “what if the secret to reliable AI isn’t more intelligence, but better constraints?”

And of course there will be snacks, drinks, and mingling.

RSVP by March 3rd.

We’ll also be saying bonjour to Paris for our three-day Fin Labs event.

We’ll be offering a unique learning space in the heart of the city to explore transforming customer experience with AI. Including interactive daytime sessions on scaling AI performance and redesigning teams for impact, followed by evening discussions on how organizations are adapting to AI.

Join us from March 24-26th and you’ll hear from leaders at Intercom, Anthropic, and more.

See the full schedule and book your spot here.

Our parting thought

AI is not a feature tacked on for the sake of relevancy. It is a way of working. As it becomes more capable, teams embracing the chaos will reap the rewards. Try new things, ask big questions, and be open to what’s next. We’ve learned it’s the way of the future.