How to Build an AI Agent for Intercom (2026)
If your support runs on Intercom, an AI agent that reads a conversation, looks up the customer, answers from your help center, and either replies or hands off to a human is the highest-leverage automation you can add. There are two ways to get there: build it against the Intercom API yourself, or connect an agent platform that already speaks Intercom. This guide covers both honestly — the real API path with code, the production work it takes, and the faster route — so you can pick the one that fits your team.
What an Intercom AI agent does
The loop is the same as any support agent, wired to Intercom: a new conversation arrives → the agent reads it and the contact's history → it calls tools (look up the order, search your help center, check a policy) → it posts a reply on the conversation or hands it off to a human. The trick is doing that reliably against real conversations. (New to agents generally? Start with AI agents for customer service.)
Option 1: Build it against the Intercom API
Intercom has a full REST API, so you can build the agent yourself. The pieces:
- Read conversations — the Conversations API to pull a conversation, its parts, and the contact.
- Reply / act — post an admin reply to the conversation, or snooze/close/assign it via the API.
- Trigger on new conversations — an Intercom webhook (topics like
conversation.user.createdandconversation.user.replied) fires your endpoint when a conversation is created or updated.
A reply tool against the real Intercom API looks like this:
import requests
BASE = "https://api.intercom.io"
HEADERS = {
"Authorization": f"Bearer {ACCESS_TOKEN}",
"Intercom-Version": "2.11",
"Content-Type": "application/json",
}
def reply_to_conversation(conversation_id: str, admin_id: str, body: str):
r = requests.post(f"{BASE}/conversations/{conversation_id}/reply",
json={"message_type": "comment", "type": "admin",
"admin_id": admin_id, "body": body},
headers=HEADERS, timeout=10)
r.raise_for_status() # handle 429 rate limits, token refresh
return {"status": "sent"}
Wrap that (and a get_contact, a search_help_center) as tools in an agent loop on the model of your choice — see our from-scratch walkthrough in how to build an AI agent: from scratch vs. platform.
The production part
The API calls are the easy bit. An Intercom agent you'd trust also needs: a webhook endpoint (with signature verification via the X-Hub-Signature header and idempotency so a retried event doesn't double-reply), rate-limit handling (Intercom throttles per app), grounding in your Help Center (embed the articles, keep them fresh), guardrails (escalate refunds, don't leak PII), hosting 24/7, observability, and an eval harness over real historical conversations. That's weeks of work plus upkeep — the undifferentiated infrastructure every support agent needs.
Option 2: Connect Intercom via Macha
If the goal is a working agent on your Intercom — not a project to maintain — a platform that connects natively is far faster. Macha layers on top of Intercom (it's not an Intercom replacement or a Messenger app you install from the App Store — it connects via OAuth and works autonomously):
- One-click connect — authorize Intercom through Macha's native connector and the agent can read conversations and post replies, with a full set of conversation tools ready to use.
- Ground on your Help Center — add your Intercom Help Center as a Source so replies quote real articles.
- Any other system as a tool — Custom Tools turn your order/billing APIs into agent capabilities by describing them.
- Runs and grades — the agent runs in the cloud triggered by new conversations; Agent Analytics show every run, and Studies grade it against real historical conversations before it goes live.
Custom Tools are how you reach the systems the help desk doesn't cover — anything with a REST endpoint becomes an agent capability.
Build vs. connect — for Intercom
| Build on the Intercom API | Connect Macha | |
|---|---|---|
| Read/reply to conversations | You write the API client | Native connector (OAuth) |
| Trigger on new conversations | You build a webhook endpoint | Handled |
| Ground on Help Center | You embed + host a vector store | Add it as a Source |
| Hosting, retries, observability | Your infrastructure | Built in |
| Evaluate before go-live | You build a harness | Studies |
| Time to a live agent | Weeks + ongoing | Same day |
So which should you build?
Build on the API if you need a fully custom runtime, have strict data-residency needs, or the agent is your product. For most Intercom teams who just want conversations resolved, a native connector gets you a measurable agent on your real conversations far faster — and you keep your model of choice. You can start free on Macha, connect Intercom, and test an agent on your own conversations the same day.
FAQ
Is an Intercom AI agent the same as Intercom's own Fin? Not necessarily. Intercom offers built-in AI, but you can also run a model-agnostic agent on top of Intercom (via its API or a platform like Macha) — useful if you want a specific model, custom tools, or to grade the agent your own way.
Do I need to install an Intercom Messenger app? No — Macha connects to Intercom via OAuth and works autonomously; it's an AI layer on top of Intercom, not an App Store app you install into the Messenger.
Can the agent take actions, not just answer? Yes — via the Intercom API (reply, snooze, assign, tag) plus your own systems' APIs as tools (order lookups, refunds), with guardrails on what it can do unattended.
How do I make sure it's accurate before it replies to customers? Ground it in your Help Center and grade it against real historical conversations first (Macha's Studies do this), start in a draft/approve mode, and widen autonomy per conversation type as it earns trust.
Resolve tickets automatically with AI agents
Macha's AI agents work on top of the help desk you already use — no code.
Shopify
Stripe
Slack
Notion
Google Workspace
Confluence

