AI Support Agents: Intercom Conversation Triage and Suggested Help Articles

A support team loses time in two places. The first is triage: opening each conversation, understanding what it is about, finding the customer's context, checking whether the answer exists somewhere. The second is quieter: the same questions come back week after week, and nobody has time to write the help article that would make them disappear. These are two reading and synthesis tasks, well suited to an autonomous AI agent, as long as it is never given the floor in front of the customer.

The inspiration: prepare the reply, do not give it

User stories of autonomous agents describe a cautious use: the agent reads the support inbox, prepares the ground and lets the human answer. The benefit is not automating the conversation with the customer, it is that the person who replies opens a conversation already tagged, summarized and accompanied by a proposal. Atako keeps that split: the agents read, tag and write internally, the human talks to the customer.

What the agents do

The scenario deploys two agents, each on its own rhythm.

The support triager reads the open conversations in Intercom. For each one, it picks one of your categories and an urgency level, based on the urgent cases you gave, then tags it, reusing your existing tags. It finally adds an internal note starting with "[Triage]": a two-line summary, the customer's context, what they expect, the sources used (help articles, similar past conversations) and a suggested reply in your brand tone. It comes back every hour on working days, from 9 am to 6 pm, and does not retriage an already annotated conversation unless the customer wrote again.

The documentation miner works by the week. It reads the conversations of the last seven days, groups them by underlying question rather than wording, counts each group and compares with your existing help articles. For the three to five most frequent questions without a good article, it drafts a page in the wiki: a short answer first, then the steps, then what to do if it still fails. It attaches the number of conversations and their ids as evidence, without customer names, and every Friday at 4 pm it writes the "Weekly docs review" page.

What the agents do not do

The limits are part of the design. No agent answers a customer, closes a conversation or assigns it: they have no tool to do so. The miner publishes no article; its drafts stay in the wiki until a human copies them into Intercom. None promises a date, a refund or a fix in a suggested reply. And they invent nothing: when the documentation or the history does not give the answer, the note says so, and a draft carries a clearly marked "to confirm" gap. That is the principle of a human-in-the-loop design.

How to set it up in Atako

Deployment takes four steps.

1. Connect Intercom. Paste an Intercom access token when Atako asks. The connection is checked before anything is created.
2. Fill in your context. Describe your brand tone, list your request categories (up to eight) and, if you wish, what must be flagged as urgent.
3. Deploy. One action creates the two agents and the "Support triage and docs" project. The agents are provisioned and receive their first instructions on their own.
4. First triage, then a regular rhythm. The fifteen most recent conversations are triaged when the first run ends. The triager then schedules an hourly run, and the miner a review every Friday at 4 pm.

If you do not have an account yet, creating one starts your trial and the scenario is configured right after.

Where to see the results

You follow the work in three places. In Intercom, each triaged conversation carries its tag and an internal "[Triage]" note visible to the team, never to the customer. In the project wiki, the "Triage log" page gives the counts, and the "Draft article" and "Weekly docs review" pages hold the miner's work. On the floor, each agent shows its current activity.

You can also talk to them in the chat: add a category, tighten the tone, ask for a review right now or have them explain why a conversation was classed urgent.

Guardrails

Access to Intercom is deliberately narrow: eight tools, only two of which write, the tag and the internal note. The tools to reply, close, assign and publish an article are not granted, which makes the limit structural rather than a mere instruction. Human validation sits where it matters: the suggested reply is a proposal, and your team is the one talking to the customer.

What to expect

Expect notes that are mostly useful for saving the first minute of each conversation: no more rereading a long thread to understand where things stand. The suggested reply will often be right for usage questions and more cautious for special cases, where the agent prefers to say it does not know. On the documentation side, the benefit comes from repetition: after a few weeks, the articles published from the drafts reduce the questions that came back most. Plan for a short tuning period for categories and tone, and correct them in the chat when a note seems off: the agents remember it for the following conversations.

One practical point: the suggested replies are only as good as the tone description you give. A sentence such as "first names, short sentences, never promise a date" changes the output more than a long style guide, so start short and refine from the notes you actually read.

Finally, the triage tags are yours: if your team already uses a tagging scheme in Intercom, give the same names as categories and the agent reuses them instead of creating a parallel set.