Thursday, 4pm, the product and support sync. Someone says lots of customers are hitting the export bug. Someone else heard three onboarding complaints this week, and a founder forwarded the same angry email twice, so it counts double. The ticket that gets written is the one attached to the best story. "Lots of people" is a vibe, not a count, and everyone in the room knows it. The count exists. It is sitting in Intercom, spread across a few thousand conversations from the last quarter, and nobody has read more than the threads they personally answered.
This job has two halves with opposite shapes. The read is enormous: thousands of threads, the same complaint phrased 50 ways, patterns that only show up in aggregate. The write is tiny: a dozen well-evidenced Linear issues, maybe fewer after an honest cut. The fix is to match each half to the tool that fits it. Pull the quarter as local files and let your AI agent read, cluster, and count. You review the ticket list and cut it before anything exists. Then the agent files the survivors through Linear's MCP server, a write small enough that MCP is the right tool for it.
Your options
Reading the inbox by hand
For five escalations, this is the honest answer: zero setup, full nuance, and the judgment is yours the whole way. Intercom will even export selected conversations as PDF or text with the thread intact. The wall is arithmetic. A quarter is thousands of threads, and the CSV export carries conversation metadata but none of the message content, so "export it and skim the spreadsheet" cannot show you what customers actually said. What survives manual reading is whatever was recent and loud. That is the sync problem, recreated at your desk.
Intercom's reporting
Tags, conversation attributes, Tracker tickets, and the AI topic grouping all earn credit. Topics clusters your volume drivers with no tagging work, attributes feed real custom reports, and Tracker tickets link many conversations to one issue, which is the right instinct in miniature. The limits are structural. Topics needs a paid add-on, pauses when Fin is paused, runs a daily pipeline over closed conversations, and by Intercom's own description cannot tell whether a query needs action. Tags rot without a librarian; teams report lists 100 deep that nobody trusts. Reporting tells you where the heat is. It does not draft a ticket, attach the evidence, or put anything in front of engineering.
Forwarding conversations one at a time
Linear's own Intercom integration puts issue creation in the inbox sidebar: a rep links or creates an issue mid-conversation, and an AI option will read the thread and draft the title and description. For a live escalation this is the right move. The customer gets attached to the issue, and the conversation can reopen when the fix ships. The unit is the limit. One conversation becomes one issue, in the words of whoever was on shift, with no view of the other 40 threads about the same bug. Linear ships triage tooling that detects and merges duplicates, and per-conversation intake is exactly the pattern that produces them. Forwarding is intake. It cannot count.
An AI agent on both APIs
Wire an agent to the Intercom and Linear APIs and the whole job is technically reachable, with real judgment in the middle. The cost is the shape of the read. Transcripts come back one conversation at a time: search pages cap at 150 results, and the message bodies arrive only when each conversation is retrieved individually. A 3,000-conversation quarter is 20 search pages plus 3,000 separate retrievals before analysis starts, with rate limits setting the pace. Through an MCP server, every response also lands in the agent's context window, which fills long before the quarter does. A script that saves transcripts to disk solves that, and now the pull step is your project: auth, pagination, retries, backoff.
Scratch on the read, MCP on the write
Scratch pulls the quarter into a folder, one JSON file per conversation with the full thread, and conversations are read-only: there is no write path back to your inbox. The read changes shape. Grep crosses 3,000 files in about a second, a script counts distinct conversations per theme, and the agent judges which differently worded complaints are the same bug. The output is one file: proposed issues, each with a title, a count, and links to the clearest evidence. You cut the list before anything exists in Linear, then the agent creates the survivors through Linear's MCP server. A dozen reviewed writes is the job MCP is good at; the quarter-scale read was the job it was wrong for. The cut is not free: 10 minutes of real reading, because it is your backlog and nobody else should decide it.
| Option | Reads the whole quarter | Counts per theme | List reviewed before filing | Duplicates in Linear |
|---|---|---|---|---|
| Reading by hand | No, a sample | Impressions | You are the list | Few, because you file few |
| Intercom reporting | Closed conversations, daily | Volume, not tickets | There is no list | None, nothing gets filed |
| Forwarding from the inbox | No, one thread at a time | No | No, it files immediately | Many, then triage merges |
| Agent on both APIs | Call by call, slowly | Yes | Only if you build it | Depends on the prompt |
| Scratch read, MCP write | Yes, as local files | Yes, scripted | Yes, you cut it first | One issue per theme |
How the loop works on your inbox
- Scratch pulls the quarter into files. Each conversation lands as its own JSON file: the full thread, participants, timestamps, metadata. 3,000 conversations is 3,000 files in a folder on your laptop. Conversations are read-only in Scratch, so nothing in this project can mark, close, or reply to a customer thread. Your inbox does not know the read happened.
- Your AI clusters, counts, and drafts the ticket list. Point Claude, Codex, Cursor, or Copilot at the folder with the brief. Read every conversation in this folder. Group bug reports and feature requests into themes, count the distinct conversations behind each theme, and drop the one-offs. Draft one proposed Linear issue per surviving theme in a single file: title, description, the count, and links to the five clearest example conversations. Strip customer names, emails, and company names from everything you draft. The agent greps for the obvious phrases, writes a script to score similarity where the wording varies, then applies judgment about what is the same complaint in different words. It does 99% of the work, the reading nobody was ever going to do.
- You cut the list, then the agent files the survivors. The deliverable is one file you can read in 10 minutes: proposed issues, counts, evidence. Cut what engineering already knows about, merge what the clustering split, rewrite a title where the agent's words are not your team's. Nothing exists in Linear yet; that is the point of the order. When the list is yours, the agent creates the approved issues through Linear's MCP server, a handful of small writes after review. The last 1%, deciding what the team actually works on, stays with you.
Run one month before the quarter. If the themes match the conversations you remember answering, the bigger folder is the same brief.
What people use it for
- Walk into the sync with counts. The export bug: 41 conversations this quarter. The onboarding complaint: 6. The loudest anecdote stops winning.
- Run a support-driven backlog review every quarter: top themes, counts, evidence, one cut list.
- Catch the feature request phrased 50 ways. "Export to Excel", "download my data", and "get this into a spreadsheet" cluster into one issue with one count.
- Check a hunch before a roadmap fight, like whether anyone besides the loudest customer ever hit the thing.
- Give engineering receipts: every filed issue cites the conversations behind it, so "users want this" arrives with links.
Questions people ask
Can the agent really read a whole quarter of conversations?
Yes. As local files, reading stops being the bottleneck. Grep finds every thread that mentions a phrase in about a second, a script counts and clusters, and the agent spends its full reads on the threads that matter. One real run put 20,000 conversations through Claude in about 30 minutes: spam pruned, every thread scored, every feature request ranked. The thing no agent can do is read that same quarter through an API at chat speed, one conversation per call.
Why not read the conversations through Intercom's MCP server?
Not at this scale. Intercom's MCP server is real (for US-hosted workspaces) and fine for fetching a handful of specific conversations. A quarter is a different shape: search results come back a page at a time with a cursor, each transcript needs its own retrieval call, and every response lands in the agent's context window, which fills long before the folder would. The mechanics are a long pagination crawl through a context that bloats and throttles. Files skip all of it.
Does Scratch create the Linear issues?
No. Scratch's Linear connector edits issue titles and descriptions and project names and descriptions, nothing else: no status changes, no new issues. Creation happens through your agent and Linear's MCP server, after you have cut the list. If you want issue creation inside Scratch's reviewed-write loop, tell Curtis. That is the kind of ask that moves a feature up the list.
Is the Linear MCP server not the same problem you just described?
No. The problem was read shape, not the protocol. Filing 12 approved issues is 12 calls, nowhere near Linear's API limits, and each call carries a ticket a human already read. Small writes after review are MCP's good case. Reading thousands of records through it was the bad one.
Will this flood Linear with duplicates?
The opposite. Per-conversation intake is what creates duplicates; Linear ships triage tooling that detects and merges them. Here the clustering happens before anything is filed: 41 conversations about the export bug become one issue that says 41, not 41 issues.
Can anything write back to the Intercom inbox?
Nothing. Conversations are read-only in Scratch. There is no write path to the inbox, so the read pass cannot leave a mark on a customer thread, and the agent never needs an Intercom credential; Scratch holds it, and the agent only ever sees files.
What keeps customer names out of the tickets?
The brief, checked at review. The conversation files contain personal details because conversations do. The prompt tells the agent to strip names, emails, and company names from every drafted title and description, and the list review is where you verify it held. The evidence links point back into Intercom, where your workspace permissions still apply.
Does this work for feature requests as well as bugs?
Yes. The clustering does not care what kind of ask it is grouping; requests phrased 50 ways collapse into one theme with one count the same way bug reports do. Your brief decides the split: one list with labels, or separate lists for bugs and requests.
Can Scratch clean up the Linear backlog afterwards?
Yes. The prose side. Scratch's Linear connector pulls issues into local files, the agent standardizes titles and descriptions, and every change comes back as a word-level diff you approve before it writes back. Status, assignees, labels, and cycles stay read-only.
See it on your own inbox
Counts are only convincing when they come out of your own quarter. See it run on your support inbox →, or download Scratch free, pull last quarter tonight, and ask your agent for the top 10 themes by count. It is one prompt.