It is 9:14 AM. Tomás opens Linear. There are eleven issues in triage, most of them filed overnight by Sentry alerts, a couple from the Slack integration, one from a teammate outside his squad. Each one needs a priority, a label, an assignee, and a cycle. He knows the answers to maybe half of them on sight. The other half require reading a description, checking whether a similar issue already exists, and making a judgment call he will probably second-guess.
This is not a Linear problem. It is a triage problem, and it is endemic to every team that ships software.
What triage is actually for
Triage in Linear is a special inbox for your team. When an issue is created by an integration or by a workspace member not belonging to your specific team, it lands there. The intent is to review, update, and prioritize issues before they enter the actual workflow.
That framing is useful. Triage is not where work happens-it is the loading dock. Without it, Linear becomes a dumping ground. With it, the team gets a daily forcing function to decide what is real and what is noise.
The catch is that the forcing function costs time. Research shows that three dimensions capture the full range of friction developers experience in review workflows: feedback loops, cognitive load, and flow state. Pull requests and triage touch all three. The time spent waiting or deciding affects feedback loops. The complexity of descriptions and context affects cognitive load. The interruptions affect flow state.
Where it breaks down
Linear's built-in automation rules handle the mechanical cases well: auto-assign when a state changes, auto-close when a PR merges. But the rules hit a ceiling fast.
Linear's automations can't help with the judgment layer. Auto-assign based on label only works if the label is already set, and setting the label is half the triage work. Auto-prioritize based on title keywords catches maybe 15% of cases. The rest require reading the description, understanding the context, and making a judgment call.
So Tomás reads. He cross-references. He may or may not remember that a nearly identical issue was filed six weeks ago and quietly resolved in a PR nobody linked back to the board. One team noticed they were filing roughly the same bug every two weeks. Each instance was a separate issue. Each one got triaged, investigated, and patched individually. Nobody connected them because Linear doesn't surface "this looks like the same bug you fixed 13 days ago."
That is the deeper cost: not the nine minutes, but the pattern those nine minutes never reveal.
What Linear has built into the workflow now
Linear's response to this is Triage Intelligence, which has been expanding steadily since its launch. It uses a combination of search, ranking, and LLM-based reasoning to make suggestions as new issues come in-drawing on the existing backlog as a dataset to understand how similar work has been organized. It can flag duplicates, link related issues, and recommend properties like labels or assignees, with a brief explanation so teams can triage quickly and consistently.
The design choice worth noting: Linear built Triage Intelligence around a few core principles. First, trust-if you are going to act on AI-generated suggestions, you need to see where they came from and believe their accuracy. Second, transparency-making the model's reasoning visible so teams can validate its output and improve it over time.
That shows up in the UI in a concrete way. Properties that have been automatically applied are clearly marked in the suggestions header. You can hover over them to review the reasoning or to make changes.
More recently, Linear shipped Triage Automations via Linear Agent, which go further than static rules. Automations let you define how Linear should respond to issues entering triage using flexible, open-ended instructions. Triage combines deterministic rules that apply predefined actions, Triage Intelligence for routing and property-setting, and Automations that extend into more complex, open-ended behavior. That means an instruction like "if this issue mentions a payment timeout, attach the relevant runbook and add a comment linking the last three related incidents" is now expressible without code.
Triage Automations use Linear Agent to carry out flexible, instruction-based actions on issues in triage. They are useful for solving complex workflows-like automated language translation, relevant document attachment, or comments made with additional information-that go beyond fixed rules or issue analysis.
The gap that still sits in Slack
Here is what none of this solves on its own: the issue that never makes it into Linear at all.
A bug surfaces in a Slack thread. A customer mentions a reproducible edge case in a support message. An engineer says "I'll file that later" and does not. The workflow that works is: bug report comes in via Slack, then in Linear: Cmd+K → "Create issue" → paste text → AI extracts title and description → assign → done. Total time: 15 seconds. But someone has to decide to do that. The issue has to make it out of Slack.
Linear's agent for Slack can help: mention Linear in a conversation and it can automatically create issues based on the discussion. A teammate like Beagle can also bridge this gap-surfacing a thread that looks like an unlogged bug and asking whether it should become a Linear issue before the context evaporates.
The real shape of the problem
The daily triage ritual is not about Linear being slow or hard to use. Linear uses a local-first architecture that stores your active issue database in the browser and syncs in the background. The result is sub-50ms response times for most actions, compared to 800ms-3,000ms for Jira. For developers interacting with their issue tracker 50+ times a day, that gap compounds quickly.
The friction is cognitive, not mechanical. It comes from having to hold the context of the whole backlog in your head to make a good routing decision on a single incoming issue. That is exactly the kind of task where a well-calibrated model-one that has read your last six months of issue history-earns its keep.
Triage Intelligence aims to make tribal knowledge actionable, uncovering the implicit patterns in your issue history and applying them to what comes next.
Whether it does that reliably enough to trust depends on the density of your workspace history and how consistently your team has labeled things in the past. Teams that have been sloppy with labels will get sloppy suggestions back. The system reflects the data it was trained on-which is another way of saying that investing in clean triage now pays compound interest.
Tomás closes the triage queue at 9:23. Nine minutes, which is actually pretty good.