How to Build an Intercom AI Agent

Intercom's position inside the product is what makes its agents valuable and what makes them risky. A customer opening the messenger is usually mid-task and already blocked, which means a good answer saves a support contact and a churn risk, and a wrong one compounds their frustration at the worst moment. This guide covers building an Intercom agent that helps rather than obstructs, drawing on FISTA Solutions' AI agents delivery in SaaS support. It complements how to build an ai customer service agent and ai in b2b saas.

How does integration work?

Through the REST API and webhooks. Webhooks deliver conversation and message events; the API provides conversation history, contact and company records with their custom attributes, and the ability to reply, add internal notes, apply tags, and assign to a team.

The agent typically runs as its own admin or bot identity so its messages are attributable and its actions auditable. Conversation state should be held in the agent's own store keyed by conversation identifier rather than reconstructed from message history each time, which keeps context assembly bounded and consistent.

Why is live account data the differentiator?

Because in-product questions are rarely about the product in general. A customer asking why their import failed wants to know about their import, not about imports. An agent with access to their plan, feature entitlements, recent activity, error events, and open issues can answer specifically; one with only help articles can only describe the general case.

Context source	What it enables
Help centre content	Correct general explanation with a link
Plan and entitlements	Whether the feature is even available to them
Recent activity and errors	Why their specific attempt failed
Account and billing status	Answering billing questions without handover
Open tickets and history	Avoiding repetition and recognising escalation
Product configuration	Explaining behaviour specific to their setup

The engineering consequence is that the agent needs read access to product data alongside Intercom, scoped to the requesting customer's own records, which is an entitlement boundary rather than a convenience.

How should answers be grounded?

In published help centre content, with a link the customer can open. Two reasons: the link lets the customer verify and read further, which builds trust rather than requiring it, and it makes wrong answers traceable to a specific article that can be fixed.

Answers generated from the model's general knowledge about software drift from what your product actually does, particularly after releases, and they are the primary source of support errors that damage trust. Where the help centre lacks an answer, the correct behaviour is to say so and hand over, not to improvise.

What does good handover look like?

Fast and complete. Triggers should include explicit request, repeated failure, frustration language, billing disputes, anything touching cancellation, and any question the agent cannot ground.

The teammate should see the conversation, the account context the agent assembled, what it attempted, which articles it offered, and why it handed over, as an internal note on the conversation. The customer should never be asked to re-explain. Handover that loses context is worse than no agent, because the customer has now spent time twice.

Which questions should it handle first?

The top ten by volume, not broad coverage. In most products these cluster tightly: setup and configuration, a small number of common errors, billing and plan questions, how to do a specific frequent task, and integration questions.

Narrow, accurate coverage of those produces measurable resolution and builds the evidence to expand. Broad shallow coverage produces an agent that answers everything mediocrely, which customers learn to bypass within a week.

How is it measured?

Resolution, confirmed by the customer or inferred from the absence of a follow-up on the same issue, is the primary metric. Containment rate is not: it rises when customers give up, which is the opposite of the intended outcome.

Alongside it: satisfaction on AI-handled conversations measured separately from human-handled ones, handover rate and handover quality, time to resolution, and the volume of conversations the agent declined to handle, which indicates coverage gaps worth closing.

How does the feedback loop work?

Through the support team. Teammates who pick up handed-over conversations see exactly where the agent failed, and giving them a one-click way to flag a bad answer, with the case flowing into the evaluation set, is what keeps quality improving after launch.

Help centre gaps surface the same way. Conversations the agent could not ground are a prioritised content backlog, which is one of the more valuable by-products of deploying it.

What does the build sequence look like?

Two weeks building an evaluation set from real conversations, including the ones that went badly. Four to six weeks building retrieval over help content, account data access with entitlement scoping, conversation handling, and handover. Two weeks in internal or beta mode where teammates see proposed answers before customers do. Then live for the top question types, expanding as resolution evidence accumulates.

What goes wrong?

Broad coverage before accuracy. Answers without links. No live account data, so answers are generic. Handover without context. Containment reported as success. Help content left unowned. And launching to all customers rather than to a segment where problems are recoverable.

How does this differ from a ticket-queue agent?

In tempo and in stakes. A ticket arrives after the customer has already given up on solving the problem themselves and accepted a wait. A messenger conversation happens while they are still trying, which means the response must arrive in seconds rather than minutes and must be right, because a wrong answer sends them back into a broken workflow with more confidence than before.

The practical consequences are a tighter latency budget, a stronger bias toward saying nothing rather than guessing, and a lower tolerance for answers that are technically correct but do not address the customer's actual configuration. It also means the agent should recognise repeat visits: a customer returning to the messenger for the third time in an hour needs a person, regardless of what they are asking.

How should the agent handle product changes?

Deliberately, because in-product agents go stale faster than anything else in support. A release that changes a screen, renames a setting, or alters a limit makes every answer about it subtly wrong, and the customers who notice first are the ones adopting the new feature.

The mechanism that works ties help content updates to the release process rather than treating them as a follow-up task, and re-runs the evaluation set after each significant release so regressions are caught before customers find them. Teams that skip this see accuracy decline in a sawtooth pattern, dropping at each release and recovering slowly as content catches up.

How FISTA Solutions helps

FISTA Solutions builds Intercom agents grounded in help content with verifiable links, connected to entitlement-scoped account data so answers are specific, with fast context-carrying handover and a correction loop the support team uses, measured on resolution rather than containment, through AI enablement, AI agents, and forward deployed engineers. The record behind the approach is 150+ projects for 50+ companies with 99.9% uptime.

To help customers in-product without frustrating them, message FISTA on WhatsApp, or read ai in b2b saas.