# Escalate tagged Intercom bugs into Linear without duplicates > When support tags a conversation as a bug, an AI agent files it in Linear, checks it is not a duplicate first, and tells engineering. - Workflow type: agent - Services: Intercom, Linear, Slack Bot - Categories: Customer Support, Engineering - Published: 2026-08-04 ## What it does - Watches for a tag of your choosing on your Intercom conversations, like bug or escalate, and kicks off the moment a teammate applies it. - Reads the whole conversation and writes up the reproduction steps, the affected customer, and whether they are completely stuck. - Checks your existing Linear issues first, so a second report of a known bug gets added as a comment on the open issue instead of becoming a duplicate. - Posts the Linear link to your engineering channel in Slack and drops the same link back on the Intercom thread as an internal note. ## What you'll need - An Intercom workspace where your support team already tags conversations, plus permission to connect it. - A Linear workspace, and the team you want bug reports filed against. - A Slack workspace and the engineering channel where escalations should land. ## Prompt I want an agent that escalates tagged Intercom conversations into Linear bugs, without filing a duplicate every time a second customer reports the same thing. Trigger this on a webhook from Intercom when a tag is applied to a conversation (the conversation_part.tag.created topic). Make the tag name a configurable input that defaults to "bug", so a team can point it at "escalate", "needs-eng", or whatever they already use. If the tag that fired does not match the configured name, stop immediately and do nothing. When a matching tag fires, use the Intercom operation Retrieve a Conversation to pull the entire thread, including all of its conversation parts. Read the whole exchange and work out: the reproduction steps, what the customer expected versus what actually happened, any error messages, IDs, or URLs they mentioned, which customer and company reported it, and whether they are fully blocked or have a workaround. Support threads are messy and out of order, so reconstruct the actual sequence of events rather than quoting the customer verbatim. Before creating anything, use the Linear operation Search Issues to look for an existing open issue describing the same symptoms. Search on the distinctive technical terms from the report rather than the customer's exact phrasing, and try a second and third wording if the first search comes back empty. Only treat a result as a match if it genuinely describes the same underlying bug, not merely the same feature area. Ignore issues that are already closed, archived, or shipped. If you find a confident match, use the Linear operation Add Comment to Issue to append this report to the existing issue instead of filing a duplicate. The comment should name the customer and company, note whether they are blocked and since when, add anything new this thread reveals that the issue does not already capture, and link back to the Intercom conversation. Do not restate what is already in the issue. If nothing matches, use the Linear operation Create Issue to file a new one on the right team. Write a title that describes the symptom concisely, and a description containing the reproduction steps, expected versus actual behaviour, the affected customer and company, and a link to the Intercom conversation. Set the priority yourself based on how many customers are affected and how badly they are blocked: urgent when a customer is fully blocked with no workaround or several customers have already hit it, high when it blocks a core task but a workaround exists, normal for everything else. State in the description why you chose that priority so an engineer can overrule you. Either way, post to the engineering channel using the Slack Bot operation Send a Message. Say clearly whether this was a newly filed issue or another report on an existing one, and include the Linear link, the customer name, the priority, and a one or two sentence summary of the bug. Make the channel a configurable input. Finally, write the Linear URL back onto the Intercom thread using the Intercom operation Reply to a Conversation, as an admin note rather than a customer-visible reply, so the support rep who applied the tag can follow the issue without leaving the inbox. Note whether it was newly filed or added to an existing issue. One guard: if the conversation has already been escalated, meaning the thread already contains an admin note with a Linear link, do not file or comment again. Post a short note to Slack saying it was already escalated and stop there. ## How to customize - The tag that triggers everything: keep it as bug, or point it at escalate, needs-eng, or whatever your team already uses. - The Linear team bugs get filed to, and how strict the agent should be before it calls something a duplicate. - The Slack channel that gets notified, and how much detail the message carries. ## FAQ ### Will it create duplicate issues if several customers report the same bug? No, that is the main thing it is built to avoid. Before filing anything it searches your open Linear issues for the same symptoms, and when it finds a genuine match it adds the new customer as another report on that issue instead of opening a second one. ### Does the customer see anything? No. The link it writes back onto the Intercom conversation is an internal note, visible only to your team inside the inbox. Nothing is sent to the customer. ### Can I use a tag other than bug? Yes. The tag name is a setting, so you can use escalate, needs-eng, or any tag your team already applies. Only conversations carrying that exact tag are picked up, and everything else is ignored. ### How does it decide the priority? It reads the conversation for how badly the customer is stuck and whether others have reported the same thing. Someone fully blocked with no workaround gets urgent, a broken core task with a workaround gets high, and everything else lands at normal. It also explains its reasoning in the issue so an engineer can overrule it. ### What happens if it matches the wrong issue? Everything it does is visible and reversible. The Slack message states whether it filed a new issue or commented on an existing one and links straight to it, so an engineer can move or reopen anything that landed in the wrong place. Use this prompt in General Input: https://www.generalinput.com/prompts/escalate-tagged-intercom-bugs-into-linear-without-duplicates