The Stack — Intercom Fin

Intercom Fin is an AI customer support agent that resolves tickets end-to-end without human handoff

What It Is

Intercom Fin is an AI-powered customer support agent built on top of Intercom’s existing helpdesk platform. It’s designed to fully resolve customer inquiries — not just suggest answers — by drawing on a company’s knowledge base, support docs, and conversation history. Its primary users are B2B SaaS companies and e-commerce brands that want to deflect tier-1 support volume without sacrificing response quality.

The Architecture

Intercom has publicly confirmed that Fin is built on top of frontier models rather than a proprietary LLM. Their engineering blog and product announcements have acknowledged using models from Anthropic and OpenAI as the core reasoning layer — the specific versions in use today are not publicly disclosed, but given Intercom’s emphasis on instruction-following and safe, grounded responses, the architecture almost certainly involves Claude Sonnet 5 or a comparable balanced-tier model as a default, with routing to a faster budget model for simpler resolution paths.

The most important infrastructure layer isn’t the model itself — it’s the retrieval architecture sitting in front of it. Fin uses RAG (retrieval-augmented generation) over a customer’s connected content sources: Intercom Articles, Zendesk imports, Confluence docs, PDFs, and URLs. Intercom has published that Fin can ingest and cite multiple sources within a single answer. This means they’re running a vector store (likely managed internally or via a cloud vector database) with per-workspace indexing — each customer’s content is chunked, embedded, and stored separately, which is a significant per-tenant infrastructure commitment.

Intercom has also disclosed that Fin includes a confidence-based routing system. If the model can’t resolve a query with sufficient confidence, it escalates to a human agent rather than hallucinating an answer. This is not purely model-side self-evaluation — Intercom’s engineering has indicated this involves classifier layers that assess whether the retrieved content is sufficient to ground a response. That’s a meaningful architectural choice: they’ve essentially built a retrieval-quality gate, not just a model-confidence gate.

Latency management appears to rely on streaming responses (confirmed by the product UI) and likely pre-warming of retrieval indexes per workspace. Scale is handled through Intercom’s existing cloud infrastructure (AWS-based, per their compliance documentation), with model calls proxied through the API layer rather than self-hosted inference. This keeps operational complexity low but ties Fin’s unit economics directly to per-token API pricing from their model providers.

The Smart Decision

The smartest architectural decision Intercom made with Fin is the answer-grounding enforcement — Fin is explicitly constrained to only answer from connected sources, not from the model’s parametric knowledge. If the information isn’t in the retrieved context, Fin says so and escalates. This is a deliberate product and infrastructure choice, not a model default.

This matters enormously for enterprise adoption. The failure mode that kills AI support tools is confidently wrong answers — a model that invents a refund policy or fabricates a feature that doesn’t exist. By treating the retrieval corpus as the only valid source of truth, Intercom sidesteps the hallucination problem at the architectural level rather than trying to solve it with prompting alone. The tradeoff is a higher escalation rate, but for B2B support use cases, that’s the right tradeoff: customers would rather wait for a human than receive a plausible-but-wrong answer.

The implementation likely involves both prompt-level grounding instructions and a post-generation check that validates citations against retrieved chunks. This two-layer approach — constrain generation, then verify — is more robust than either technique alone, and it’s something most developers building support bots skip.

The Tradeoff

Fin’s per-resolution pricing model (publicly available: customers pay per resolved conversation, not per seat or per API call) creates a structural tension with its infrastructure design. Because Fin only charges when it successfully resolves a ticket without escalation, Intercom is absorbing API costs on every conversation — including the ones that escalate. Failed resolutions cost Intercom inference and retrieval compute with no corresponding revenue.

This means the model routing and confidence-threshold decisions aren’t just UX choices — they’re revenue levers. Setting the escalation threshold too low burns margin; setting it too high risks billing for hallucinated or low-quality resolutions that customers dispute. Intercom has to tune this threshold globally and per-customer, which is a continuous calibration problem. As model costs shift with each new generation, the economics of the per-resolution model shift too. A 40% cost increase from a tokenizer change in a new model tier — even at unchanged list price — could meaningfully compress margins if Intercom doesn’t actively manage model version selection per conversation tier.

What You Can Steal

• Ground your agent to a corpus, not the model’s priors. Explicitly block parametric knowledge from surfacing in outputs when you can’t verify it. The retrieval corpus is the knowledge base; treat the model as a reasoning and formatting layer only.
• Build a retrieval-quality gate, not just a model-confidence gate. Before passing retrieved chunks to the model, score whether the retrieval result actually addresses the query. A low-relevance retrieval should trigger escalation, not generation.
• Per-tenant vector indexes are the right call for B2B. Shared indexes across customers create data isolation risks and retrieval noise. The operational overhead of per-workspace indexing is worth it.
• Streaming is table stakes for support UX, but escalation triggers shouldn’t stream. Structure your response pipeline so the model commits to an escalation decision before generating visible output — partial answers that then cut to “let me transfer you” erode trust.
• If you’re pricing on outcomes, model version selection becomes a financial control. Route cheaper models to low-complexity queries and reserve frontier-tier models for edge cases — not just to manage latency, but to protect unit economics when your pricing is decoupled from per-call costs.