Scaling an Autonomous AI Customer Support Agent from Demo to Production

intercom · Tech · 2023 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Autonomous AI customer support agent in production

Intercom needed to move Finn from impressive controlled demos to a customer-facing support agent that could answer safely, avoid hallucinations and brand failures, and improve resolution rates across tens of thousands of customers.

Constraints:

• GPT-3.5 prototypes could not be safeguarded well enough for production.
• Customer support agents must avoid wrong answers, hallucinations, inappropriate opinions, competitor recommendations, and brand-voice failures.
• Hard edge cases matter more than easy questions for measuring agent readiness.
• Production behavior improves through continuous iteration on architecture, prompts, retrieval, reranking, and observed failures.
• The answer model is only one part of a larger multi-process agent subsystem.

Architecture

Finn evolved into a multi-component support-agent subsystem rather than a single LLM call. GPT-4 and Claude-class models sit behind a torture-test-driven release process, while Intercom's architecture includes disambiguation, chunking, reranking, summarization, bespoke RAG, bespoke ranker, prompt engineering, answer generation, and continuous production learning from customer conversations.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  A["Customer conversation interface"] --> B["Finn orchestration subsystem"]
  B --> C["Disambiguation process"]
  B --> D["Bespoke RAG engine"]
  D --> E["Bespoke ranker"]
  E --> F["Answer generation model"]
  F --> A
  G["Torture test suite"] --> F
  H["Production feedback loop"] --> B
  H --> G

Components

Data flow

A support question enters Finn, is disambiguated, chunked, retrieved against support knowledge, reranked, summarized, and passed into the final answer-generation step. Torture tests and production feedback expose failures, which feed prompt, architecture, RAG, and ranker iterations that raise the autonomous resolution rate over time.

Why this architecture

Intercom learned that model capability unlocks production readiness, but resolution gains come mainly from the agent architecture and surrounding retrieval/ranking systems rather than raw model swaps alone.

Models used: GPT-3.5 · GPT-4 · Claude · DeepSeek · open-source models

Scale

• Finn runs across approximately 30,000 customers.
  “we have like 30,000 customers, so if there's edges or wrinkles in Finn, they're going to find it.”transcript, stated
• Finn improved from about 25% support conversation resolution at launch to about 58-59%.
  “when we launched Finn, it I think it was resolving maybe 25% of our customers support conversations. Today it's doing about 58 59%.”transcript, stated
• The agent subsystem contains about 15 processes.
  “It's a subsystem of about 15 different uh processes.”transcript, stated

Alternatives considered (roads not taken)

Ship the GPT-3.5 prototype

Rejected because: It worked only in controlled demos and could not be safeguarded against hallucinations.

Measure easy questions

Rejected because: Easy questions do not distinguish production readiness; hard edge cases are where support automation earns value.

Rely on the foundation model as the main improvement lever

Rejected because: Model swaps produced smaller gains than architecture, prompts, RAG, and ranker work.

Patterns

rag-retrieval (retrieval)

Finn relies on bespoke RAG and ranking before answer generation.

eval-driven-development (evaluation)

The torture test codifies failure modes and hard support questions before release.

tool-use-orchestration (agent-architecture)

Finn coordinates many processes around retrieval, reranking, summarization, and answer generation.

safety-policy-enforcement (governance)

Torture testing explicitly checks hallucinations, wrong answers, inappropriate opinions, competitor recommendations, and brand tone.

Tradeoffs

Production launch model

Chose GPT-4/Claude-class model after torture testing over GPT-3.5 demo-era prototype.

Rationale: The earlier model could not be safeguarded enough against hallucinations.

Agent implementation

Chose 15-process subsystem over single-shot LLM answer.

Rationale: Support automation required disambiguation, retrieval, ranking, summarization, and answer generation.

Gotchas (what bit them)

Demo quality did not imply production readiness.

Root cause: GPT-3.5 could perform well only when Intercom controlled the user input.

Resolution: Wait for GPT-4-class reliability and torture-test the agent before production deployment.

Easy eval questions hide failure modes.

Root cause: Real customer support breaks on hard, adversarial, security, or documentation-gap cases.

Resolution: Build torture tests from last hard questions, common questions, prompt injection, sales, and escalation cases.

Raw model improvements have limited leverage after production hardening.

Root cause: The agent's behavior depends on retrieval, ranker, architecture, prompts, and orchestration.

Resolution: Iterate on the multi-process architecture and bespoke peripheral systems.

Evaluation

Intercom evaluates Finn with torture tests, hard support questions, security/prompt-injection cases, common questions, A/B tests, and production resolution-rate tracking.

Metrics: autonomous resolution rate · hard-question pass rate · hallucination avoidance · wrong-answer avoidance · prompt-injection resistance · A/B test results

Outcomes

• Finn moved from non-production GPT-3.5 demos to a fully autonomous support agent.
• Resolution rate increased from about 25% at launch to about 58-59%.
• The system reached approximately 30,000 customers.
• Intercom is on its third major Finn architecture and continues improving from production feedback.

Finn runs in production support workflows for roughly 30,000 Intercom customers and is evaluated against hard support and safety cases rather than only easy questions.