Eoghan Said "Fin for Dentists." He's Right. Here's What That Actually Means.

Last week Intercom launched the Fin API Platform. Contracts start at $250K/year. Apex — their new specialized customer service LLM — reportedly outperforms GPT-5.4 and Opus 4.5 on resolution rate, hallucination rate, and latency.

It's a significant announcement. And most of the takes will focus on the model benchmarks.

I want to focus on one line from Eoghan McCabe's post instead.

"We're never going to build for these specific verticals."

Here's the full quote, buried near the end of his announcement:

"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."

Read that twice.

The CEO of Intercom — announcing what he calls the best-performing customer service model in the world — is openly saying: the vertical implementation work is not ours to do.

That's not a throwaway line. That's a strategic boundary. And it has real implications for anyone deploying Fin with SME clients.

What the API Platform Actually Opens Up

The Fin API Platform gives builders access to four model layers:

• Fin Apex 1.0 — the generative model producing final answers
• Fin RAG API — the full retrieval-augmented generation pipeline
• Fin Retrieval API — a custom retrieval model optimised for customer service
• Fin Reranker API — relevance scoring for retrieved content

This is genuinely powerful infrastructure. The benchmarks on Apex are serious: 2.8% higher resolution rate than frontier models, 65% fewer hallucinations than Sonnet 4.6, 0.6 seconds faster time to first token.

The real-world impact backs this up: Intercom reported that a large gaming customer saw their resolution rate jump overnight from 68% to 75% after the Apex rollout — a 22% reduction in unresolved conversations and the largest single-improvement jump since Fin launched.

But the $250K annual floor tells you exactly who the primary audience is: enterprise companies, startups building vertical agents, and Intercom's own platform competitors who want to license the models.

For the vast majority of SMEs, this isn't direct-access territory. And that's fine — because the API isn't where the value gap lives for them anyway.

The Knowledge Layer Is Still the Moat

Here's what every AI implementation I've run has confirmed, and what Intercom's own AI Agent Blueprint makes explicit:

Resolution rate is not primarily a model problem. It's a content problem.

The Blueprint puts it plainly: "AI Agents are only as good as their inputs." And Eoghan's offhand comment about dentists and car dealerships points at exactly the same thing: you can have the world's best model, but if the knowledge architecture underneath isn't built around how your specific vertical operates, you will not hit meaningful resolution rates.

Apex running on a generic, poorly structured knowledge base will underperform. A well-configured Fin instance running on a clean, vertically-tuned content layer will consistently outperform it.

This is the gap the API platform doesn't close. And it's the gap that matters for SME deployments. If you're building or auditing your content layer, our guide on knowledge bases for AI-powered support covers the foundational principles.

What "Content Before Configuration" Looks Like in Practice

When we talk about content before configuration at dot2.solutions, we mean something specific:

Before you touch a single Intercom setting, you need to know:

• What questions your customers actually ask (not what you think they ask)
• Which questions are highest-volume and lowest-complexity — your fast path to resolution
• Where your existing content is wrong, outdated, or missing entirely
• How your SOPs map to Fin's Procedures format
• What conditional logic your most complex workflows actually require

That's the knowledge architecture. It's not glamorous. It doesn't make for great benchmark slides. But it's the work that determines whether you hit 65% resolution or 30%.

Intercom has built the best model for this. They've also built strong tooling around it — Guidance, Procedures, Simulations, the Topics Explorer. The platform is genuinely excellent. And with the recent Monitors launch, the observability layer is now complete too — meaning you can finally measure whether Fin's answers are meeting your standards, not just resolving conversations.

What they're not doing — by their own admission — is the vertical content work. The deep dive into how a Swiss fiduciaire talks to clients about VAT questions, or how a Geneva-based SaaS company handles churn conversations in French. That's implementation work. That's practitioner work.

The Opportunity This Creates

The Fin API Platform will generate a wave of new vertical agent builders. Eoghan is explicitly inviting them. Some will be well-funded startups. Some will be consultancies rebranding overnight.

Most will start with the model layer, because that's what's new and exciting.

The ones who succeed will eventually learn what every experienced Fin implementer already knows: the model is the easy part. What takes time, judgment, and domain knowledge is the content architecture underneath.

That's the asymmetric opportunity for implementation partners who've already done this work — who've built the frameworks, run the knowledge audits, and learned which content structures Fin actually resolves from versus which ones it deflects around.

The model layer is opening up. The knowledge layer is still the moat.

For a broader view of how proactive AI support strategies compound on top of this foundation, see our piece on proactive AI support in 2026.

A Note on the Benchmarks

The Apex numbers deserve a moment. Comparing favourably to GPT-5.4 and Opus 4.5 on a customer service-specific benchmark is not a trivial claim. Intercom has a 60-person AI team, a decade of customer service data, and years of production signal from millions of Fin conversations per week.

Specialized vertical models outperforming generalist frontier models is exactly what you'd expect to happen in mature AI deployment verticals. Medical, legal, financial, and customer service are all moving this direction. The Fin model suite is ahead of where I expected them to be.

The Fin Escalation Router alone — 98%+ accuracy on handoff decisions, 0.5s faster than LLM-based routing — shows how much compound value sits in the specialized sub-agent architecture rather than the headline LLM.

Beyond the raw model performance, Intercom's full model suite now includes seven specialized models: Apex 1.0, Retrieval, Reranker, Issue Summarizer, Feedback Parser, Language Detector, and the Escalation Router. Each is purpose-built and fine-tuned for a specific stage of the customer service pipeline — a compound architecture that's difficult to replicate with generic frontier models alone.

What This Means for Our Clients

For Swiss SMEs deploying Fin through dot2.solutions, nothing about our core approach changes. The platform you're running on just got meaningfully better. While the custom API platform has a quarter-million-dollar entry ticket, Intercom is integrating the Apex model directly into the standard Fin product. That means Apex is the model behind your Fin instance going forward.

What that improves: resolution accuracy, hallucination rate, response latency, and escalation decisions.

What it doesn't change: the quality of your knowledge base, the structure of your Procedures, the clarity of your Guidance configuration. Those remain the primary levers for resolution rate improvement — and they remain where we spend the most time.

If you're already using Fin, now is a good time to review whether your content layer is keeping pace with the model improvements. The quick questions and resolution strategies we've outlined are a practical starting point.

If you're not yet running Fin and this announcement has you curious: the best place to start is still a knowledge audit, not a tool evaluation.

Content before configuration. That's where your resolution rate is won or lost — regardless of how good the model gets. If you're ready to stop tweaking settings and start building a knowledge layer that actually resolves tickets, let's talk about a knowledge audit.