You can turn on an AI agent inside Intercom in an afternoon. Whether it should resolve your hardest tickets, or just your easiest ones, is the decision that actually matters.
Adding an AI agent to Intercom means connecting an AI system that reads incoming conversations, answers customers, and takes actions, then routes the rest to your human team. In 2026 you have two real paths: turn on Intercom's native agent, Fin, or connect a specialist third-party agent that operates inside the same Intercom inbox. This guide walks both, the exact steps to integrate, and how to decide which fits your support operation.
Native Fin is the fastest path: it lives in the Intercom Messenger and inbox with no extra integration work and bills per resolved outcome.
A specialist agent connects to Intercom through the API and webhooks, takes over the conversation, and writes back into the same inbox your human agents already use.
The choice comes down to ticket complexity and regulation: drop-in native AI for FAQ-heavy support, a specialist for multi-step, regulated, or action-taking workflows.
Rollout is the same regardless of vendor: scope a few intents, run in suggestion mode, measure, then expand. Going live on everything at once is the most common failure.
Measure resolution rate, escalation reasons, CSAT on AI-handled conversations, and cost per resolution, not deflection alone.
Last updated: June 2026
Most teams ask "how do I add AI to Intercom" when the real question is "what do I want the AI to do." Answering a billing FAQ from a help center article and resolving a failed transfer that touches a payments processor, a ledger, and a compliance disclosure are different jobs. Intercom's native agent is excellent at the first. The second is where a specialist agent operating inside Intercom earns its place. This guide is buyer-neutral on the easy stuff and opinionated on the hard stuff, because that is where the wrong choice costs you.
Your two options for AI in Intercom
There are two architectures for putting an AI agent into Intercom, and they are not the same product with different logos. They differ in where the AI runs, what it can do, and who owns the resolution.
Option 1: Intercom's native agent (Fin)
Fin is Intercom's built-in AI agent. It is part of the Intercom platform, so it already lives in the Messenger and the inbox with no separate integration to build. It reads your help center and connected sources, answers customer questions, and can take a defined set of actions through Intercom's own tooling. It bills per resolved outcome on top of your Intercom plan.
Fin is a strong default for a large share of support volume. If most of your tickets are answerable from documentation, account-status lookups, and routine how-to questions, native Fin is the fastest way to deflect them, and it is fair to say it does this well. You turn it on, point it at your content, set a few rules, and it starts resolving.
Option 2: A specialist agent operating inside Intercom
A specialist agent is a third-party AI platform that connects to Intercom through its API and webhooks, then handles conversations directly in the Intercom inbox. From your team's point of view the conversation still lives in Intercom, the same conversations list, the same assignment rules, the same handoff to a teammate; the difference is the engine resolving it. The specialist agent receives each inbound message, runs its own reasoning and workflows, executes actions against your systems (a payments processor, a core banking system, a CRM), and writes the reply back into the Intercom conversation. When it cannot resolve, it hands off to a human in the same inbox with full context.
This is the path for support that is multi-step, regulated, or action-heavy. Lorikeet is the specialist example used throughout this guide: an AI customer support platform built for complex and regulated companies (fintech, financial services, healthcare, insurance, gaming) that resolves tickets end-to-end across chat, email, voice, SMS, and WhatsApp, and integrates with Intercom as a ticketing and messaging system rather than replacing it.
Native agent: an AI agent built into the helpdesk itself (Fin in Intercom), requiring no separate integration and billing through the helpdesk vendor.
Specialist agent: a third-party AI platform that connects to the helpdesk via API and resolves conversations inside it, bringing its own workflow engine, integrations, and guardrails.
What a specialist agent actually does inside Intercom
Before the steps, it helps to see what a specialist agent is doing on each conversation, because that is what you are integrating, not just a chat reply.
It resolves, it does not just deflect
A deflection bot answers a question and closes the conversation. A resolution agent finishes the job. For a failed transfer that means diagnosing why it failed, checking the customer's status across systems, reversing a fee if policy allows, and confirming the fix, all inside the Intercom thread. The customer never learns there are two systems involved.
It runs multi-step workflows
Specialist agents combine natural-language workflows (described in plain English) with deterministic structured workflows for steps that must happen in a fixed order. Lorikeet supports both in a single interaction, which matters when a regulated flow needs a scripted disclosure at exactly the right moment but the surrounding conversation is open-ended.
It takes actions against your systems
Through least-privilege scoped tools, the agent can look up an account, update a record, file a dispute, or trigger an outbound message. A team-of-agents pattern lets it dispatch sub-agents to coordinate with third parties, for example emailing a merchant about a disputed charge, while the main conversation continues in Intercom.
It works across channels, not just chat
Intercom is often the chat and email surface, but customers also call. A specialist agent on a single workflow engine can carry the same logic into voice with sub-1-second latency, so a customer who started in Intercom chat and then phones in does not start over. That cross-channel continuity is hard to fake by bolting a separate voice bot onto a chat bot.
It proves its behavior before and after go-live
A specialist built for regulated work runs pre-launch adversarial simulations, checks inbound messages, applies outbound guardrails, and runs automated QA on conversations after the fact. Lorikeet's Coach does 100% post-facto QA ("AI evaluating the AI") and can run standalone. None of this replaces your compliance review, but it supports the obligations your compliance team is accountable for.
How to add Intercom's native agent (Fin)
This is the shorter path. The exact menu labels move around as Intercom ships updates, so treat these as the shape of the process rather than pixel-perfect instructions.
Step 1: Confirm your plan and turn on Fin
Fin is available on Intercom plans that include AI. In your workspace settings, open the AI agent (Fin) section and enable it. You will agree to per-resolution billing as part of turning it on.
Step 2: Connect your knowledge sources
Point Fin at your help center, and add any other supported sources (public URLs, internal articles, snippets). The quality of Fin's answers tracks the quality and coverage of this content, so this step is where most of the work is.
Step 3: Configure actions and guidance
Define the actions Fin is allowed to take and any guidance or guardrails on tone, topics, and when to hand off. Keep the initial scope narrow.
Step 4: Test, then go live in the Messenger
Use the preview to test real questions, then enable Fin on the Messenger for a subset of conversations before opening it to all traffic. Watch the first week of transcripts closely.
How to add a specialist agent inside Intercom
This path is more involved because you are connecting a separate platform, but the platform does most of the heavy lifting. Using Lorikeet as the example, here is the sequence.
Step 1: Connect Intercom as an integration
In the specialist platform, add Intercom as a connected ticketing and messaging system. This uses Intercom's API with scoped credentials so the agent can read incoming conversations and write replies. Lorikeet integrates with Intercom alongside other helpdesks (Zendesk, Front, Kustomer) and connects to your knowledge base (Notion, Confluence, Google Drive, Guru) in the same setup.
Step 2: Connect your systems of record as scoped tools
Wire up the systems the agent needs to take real actions: your payments processor, CRM (Salesforce coexists with the agent), telephony, and any core banking or ledger systems. Each is exposed as a least-privilege tool so the agent can only do what you have explicitly allowed. This is the step that turns a chat responder into a resolution engine.
Step 3: Build workflows in plain English
Describe how each ticket type should be handled. Use natural-language workflows for open-ended reasoning and structured workflows for steps that must be deterministic (identity checks, disclosures, dollar-threshold approvals). With Lorikeet, all configuration is in plain English, so support and compliance leads can read and edit the logic, not just engineers.
Step 4: Set guardrails and run simulations
Before any live traffic, run adversarial simulations against your workflows: red-team the bad paths, confirm the agent declines to act when a guardrail trips, and read the pass/fail report. This is the artifact your compliance team reviews. Add inbound message checks and outbound guardrails (no PII leaks, scripted disclosures, escalation triggers).
Step 5: Run in suggestion mode in the Intercom inbox
Start with the agent drafting replies for human approval inside Intercom rather than sending autonomously. Your team approves or edits, which both protects customers and generates the data you need to trust the agent on its own.
Step 6: Promote to autonomous resolution by intent
As specific intents prove out in the QA data, let the agent resolve those autonomously while keeping the rest in suggestion mode. Expand intent by intent. Coach runs 100% QA on everything it handles so you keep eyes on quality as scope grows.
When to choose native Fin vs a specialist agent
This is the decision the whole guide is built around. Both are legitimate; they fit different operations.
Choose native Fin when
Most of your volume is answerable from documentation, account-status lookups, and routine how-to questions.
You want the fastest possible time-to-value with no separate integration to maintain.
Your actions are simple and covered by Intercom's native tooling.
You are not in a heavily regulated category and do not need pre-launch, provable guardrails or replayable audit trails.
Choose a specialist agent when
Your hard tickets are multi-step and touch multiple systems (a transfer that fails across a processor, a ledger, and a disclosure).
You are regulated (fintech, financial services, healthcare, insurance, gaming) and need provable guardrails, simulation-based validation, and audit trails that support a compliance sign-off.
You need the same agent across chat, email, voice (sub-1s latency), SMS, and WhatsApp, plus outbound re-engagement.
You want defence-in-depth (adversarial simulations to message checks to outbound guardrails to 100% post-facto QA) rather than guardrails as a runtime afterthought.
The honest framing: many teams run both. Native Fin handles the high-volume easy tier; a specialist handles the regulated, multi-step tier where a wrong answer is a regulator-attention event, not a refund. You do not have to pick one forever on day one.
Where each model has limits
Native Fin's limit is depth: it is tied to Intercom's tooling and is not built to be the regulated agent that resolves your hardest fintech or healthcare flows with replayable audit trails. A specialist's limit is setup cost: it is a separate platform to connect and configure, and it is overkill if your support is genuinely FAQ-shaped. Lorikeet is candid about this. If your tickets are simple and you are not regulated, native Fin is likely the right call and a specialist is more than you need.
Rollout: how to launch without breaking trust
The integration is the easy part. The rollout is where deployments succeed or fail. The pattern below works for either option.
Start with a narrow scope
Pick three to five high-volume, lower-risk intents. Resist the urge to launch on everything. A narrow scope you can measure beats broad coverage you cannot trust.
Run in suggestion mode first
Let the agent draft, let humans approve. This is non-negotiable for regulated workflows and smart for everyone else. It builds the evidence base for autonomy.
Validate with simulations before autonomy
For a specialist agent, run the simulation suite and have compliance read the report before you flip any intent to autonomous. For native Fin, test heavily in preview and on a Messenger subset.
Expand intent by intent
Promote one intent to autonomous resolution at a time, watching the QA and CSAT data after each. Roll back fast if an intent underperforms; that is a feature of a careful rollout, not a failure.
How to measure whether it is working
Deflection rate is the metric vendors lead with and the one that tells you the least. Track these instead.
Resolution rate, not deflection rate
Deflection counts conversations the AI ended. Resolution counts conversations the AI actually solved, on your definition. Make sure you, not the vendor, define what counts as resolved. Lorikeet's pricing is built on this: the customer holds the veto on what counts as a resolution, and escalations are not charged.
Escalation reasons
Read why the agent handed off. A rising category of escalations is your roadmap for the next workflow to build, and a signal of where the agent is reaching its limits honestly rather than guessing. Tag escalations by reason (missing tool access, ambiguous policy, customer asked for a human, guardrail tripped) so the pattern is legible. An escalation because a guardrail correctly stopped the agent is a success, not a miss, and your metrics should not punish it.
CSAT on AI-handled conversations
Track CSAT specifically on conversations the AI resolved, separate from human-handled ones. A well-built specialist deployment can match or beat human CSAT on the intents it owns. In one anonymized deployment, a regulated fintech reached roughly 85% automation with equal-or-better CSAT versus its human baseline; treat that as a target to validate in your own data, not a guarantee.
Cost per resolution
Compare the all-in cost per AI resolution against your human baseline of roughly $1.25 to $4 per handled ticket. As a reference point, Lorikeet's per-resolution pricing runs about $0.80 for chat, email, and SMS and about $1.00 for voice, with Coach QA around $0.10 per ticket and escalations not charged. Native Fin bills per resolved outcome on its own schedule. Whichever you choose, the number to watch is cost per resolution on your hard tickets, because those are the ones that move both your budget and your risk.
If your hardest Intercom tickets are multi-step, regulated, or action-heavy, a specialist agent operating inside Intercom resolves them end-to-end with audit trails your compliance team can sign off on. See how Lorikeet works with Intercom.
Conclusion
Adding an AI agent to Intercom is no longer a technical question; both paths are reliable. The real decision is what you want the AI to do. If your support is FAQ-shaped and you are not regulated, turn on native Fin, point it at good content, and roll it out carefully. If your hardest tickets are multi-step, regulated, and action-heavy, connect a specialist agent that resolves them inside Intercom with simulation-based validation, defence-in-depth guardrails, and audit trails, while still handing off cleanly to your team. Many operations end up running both, native AI for the easy tier and a specialist for the regulated tier. Start narrow, run in suggestion mode, measure resolution rather than deflection, and expand one intent at a time.
