Linear uses LLMs and vector embeddings to surface similar and duplicate issues
Large engineering teams face a persistent duplicate-issue problem where, at worst, multiple engineers unknowingly fix the same bug; support teams also waste time manually aggregating related customer messages across tools.
Initial experiments storing vector embeddings as blobs in the primary database worked for prototyping but posed performance risks; several dedicated vector databases were rejected due to scaling downtime, cost, or ops complexity; naive similarity queries without indexing regularly timed out on tens of millions of issues.
The Similar Issues feature was rolled out to all Linear workspaces and has already helped the customer experience team consolidate support issues in Intercom with less manual aggregation time, with early community feedback confirming improved backlog management.
Frequently asked questions
What did this team achieve with this AI workflow?
The Similar Issues feature was rolled out to all Linear workspaces and has already helped the customer experience team consolidate support issues in Intercom with less manual aggregation time, with early community fee…
What tools did this team use?
LLMs, pgvector, PostgreSQL, ElasticSearch, Intercom, Google Cloud.
What results were reported?
Manual support message aggregation time: less time spent manually aggregating messages; Backlog management quality: helping folks better manage their backlogs (source-reported, not independently verified).
What failed first in this deployment?
Initial experiments storing vector embeddings as blobs in the primary database worked for prototyping but posed performance risks; several dedicated vector databases were rejected due to scaling downtime, cost, or ops…
How is this ticket triage AI workflow structured?
Issue creation trigger → LLM embedding generation → Cosine similarity search → Similar issues surfaced → Triage duplicate marking.