Building the platform for agent coordination

How do you help engineers keep track of work without making the tracking itself more work? Linear began as an issue tracker, with speed, clarity and reduced friction for individual contributors as its central concerns. Introducing himself as Linear’s engineering lead, Tom Moor describes its evolution into a product development workspace: a place where engineering and product teams coordinate what they build. OpenAI, Ramp and Vercel are among the customers using it for that purpose. Those existing workflows set the standard that its AI features would have to meet.

Linear’s first internal AI experiments focused on summarization, similarity and embeddings. The team had no prior AI experience and learned through experimentation. Moor recalls starting the skunkworks effort in early 2023; his contemporaneous account places its formation that summer. The foundational discovery was straightforward: most useful features first needed to find the relevant information. Summarization and suggestions depended on retrieval, not just on generating good text.

Linear already used Elasticsearch, but Moor recalls finding its vector offering unsuitable at the time. The team evaluated several of the emerging vector databases and encountered trade-offs in each. It ultimately chose OpenAI embeddings stored in pgvector on Google Cloud—a pragmatic use of familiar infrastructure. On that foundation, Similar Issues V1 suggested related issues using simple cosine comparisons between embeddings. It could identify semantic proximity, but its mechanism stopped at comparing vectors.

Other early features kept the AI almost invisible:

• Natural-language filters: “Bugs assigned to me in the last two weeks that are closed” became an issue filter. This was a bounded, one-shot transformation with an immediately useful result.
• Issues from Slack: Creating an issue from a thread produced a composed issue rather than merely copying the message text. The transformation was seamless enough that users could miss that AI was involved.

A general copilot did not clear the same bar. Linear tried building one but never shipped it because the quality was insufficient. Moor attributes that partly to early model capabilities and partly to the team’s own approach. Users instead responded well to the small, practical additions that improved existing tasks without making AI the center of the interface.

Around late 2024, the team began to feel a broader change in what was possible. Moor groups planning and reasoning models such as o3, multimodal APIs, million-token context windows and DeepSeek among the developments that changed its ambitions. This is a retrospective grouping of advances, not a release chronology: o3 became publicly available in April 2025. The practical change was that experiments became less brittle and began to feel capable of handling deeper work.

The first response was to rebuild retrieval again. The embedding store had grown too large to place in Linear’s main database, so pgvector lived separately. During roughly a year and a half with that setup, the team increasingly felt the absence of hybrid search. It moved to turbopuffer and changed from OpenAI to Cohere embeddings after an internal comparison that favored Cohere for Linear’s domain. That preference was specific to their data and task, not a universal ranking of embedding providers.

Moor describes backfilling hundreds of millions of embedding rows, with the rollout finishing only in the two weeks before the talk. Replacing the retrieval foundation therefore involved a substantial data operation, not just selecting a different search service. The long backfill determined when the new foundation was ready for product features.

With the new search foundation in place, Linear was building Product Intelligence, effectively a second version of Similar Issues. Instead of exposing the result of a simple cosine comparison, it introduced a pipeline:

1. Rewrite the query.
2. Retrieve candidates through hybrid search.
3. Rerank the results.
4. Apply deterministic rules.

The output is a map connecting an issue to related issues, including how and why they relate. The distinction matters: a nearby embedding is a candidate relationship; the product needs an explanation that helps someone decide what to do with it.

Those relationships support suggested labels, suggested assignees and possible duplicates. They can also explain why a particular engineer or project is a suitable destination for an issue. The visible suggestion panel places an explanation beside Related and Duplicate controls, making the relationship something a person can inspect in context. For customers receiving thousands of incoming issues, the value lies in routing work into the right engineers’ hands, rather than simply returning more search results.

Customer feedback creates a related problem at a different level. Linear can collect feedback across customer channels, but gathering it does not determine what the team should build. The feedback analysis feature under development would process hundreds or thousands of requests and propose how to divide a project or which features might emerge from it. Moor reports that Linear’s head of product judged the feedback analysis better than 90% of the candidates he interviews. That was an informal judgment, not a controlled benchmark with a supplied rubric or sample size.

Pulse addressed the opposite direction of information flow: understanding what the team had already done. The shipped feature synthesized workspace updates into daily or weekly summaries and also produced an audio version. Someone could catch up on a commute or over breakfast instead of reading through the workspace. At the time, listening required Linear’s mobile or desktop app; Moor wanted an RSS feed, but the audio was not yet a podcast that users could subscribe to in their own player.

A customer’s bug recording contains useful evidence, but an engineer still needs a written description and reproduction steps. Linear’s issue-from-video workflow embeds that conversion in the issue creation process:

1. Drop in the customer’s video.
2. Analyze the recording to infer reproduction steps.
3. Use the analysis to compose the issue.

Moor describes the feature as creating the issue automatically, while the selected demonstration frame shows the populated composer with an embedded recording and a Create issue button—not a confirmed submission. He also cautions that this is not the feature’s strongest example. The useful mechanism is the same as in the Slack integration: turn source material into actionable work without making the user perform the transcription and composition manually.

These embedded features have a limit: Linear cannot anticipate every team’s structure or build every workflow into the product. The Linear for Agents platform, launched roughly two weeks before the talk, makes the workspace extensible through agents. Moor frames them as cloud-based teammates that can scale beyond a human team’s capacity. The coordination logic follows from the existing product: if Linear already holds the work and communication for people, agents should participate in that same context.

Codegen demonstrates the coding workflow. A user assigns it an issue or mentions it in Linear; the agent produces a plan and then a pull request. Moor says the sped-up Codegen demonstration represented four minutes of work, not twenty seconds. The resulting PR is still a reviewable artifact: a human examines it as they would a teammate’s contribution.

The agent is not confined to Linear’s interface. A user can initiate work through Slack or another communication tool, provide the Linear issue as context, and have the agent connect the work across systems. The same model allows a user to interrupt it partway through. Linear supplies shared work context; the agent operates beyond any one window into that context.

Bucket, the feature-flagging product now represented by a Reflag-branded companion article, shows an operational workflow. Mentioning the agent can create a feature flag, roll it out or check its status from within Linear. Moor’s example combines flag creation with a requested rollout to 30% of users; that percentage is an illustrative target, not a reported rollout result. Combining the steps in one request avoids making the user drive each command separately.

Charlie shows investigation before implementation. In the example, a Linear issue has a Sentry issue attached. A user mentions Charlie and asks it to research the problem; with repository access, it can inspect recent commits and the codebase to identify possible causes and reasons for a regression. An engineer then arrives at an issue containing an initial investigation rather than starting from scratch. The claimed time saving is qualitative: the demonstration does not establish a measured reduction in debugging time.

The integrations shown so far live primarily in issue comments. Linear was also developing a dedicated surface where agents could expose observations and tool calls, and where users could interrupt their work. That would make activity inspectable through a consistent workspace interface across coding agents and product-management agents, instead of asking each integration to invent its own presentation inside a comment stream.

Intercom’s Fin integration, still under development, would extend that coordination into customer follow-through. The proposed Fin request asks it to reply to the 100 customers who reported a now-fixed bug; no completed outreach is demonstrated. The issue would connect the engineering fix to the people waiting for it. Moor expected the new agent interface within a couple of weeks of the talk, making this a description of intended behavior rather than an already delivered interface.

That leads to a broader proposed change in backlog management. Instead of accepting a permanent accumulation of bugs, a team could assign every outstanding issue to an agent for a first pass. Moor speculates that perhaps 50% of backlog issues could be fixed by the end of a week; this is a forecast, not a measured result. The underlying expectation is that removing repetitive investigation and implementation work could let teams build more, improve quality and deliver faster.

The platform architecture makes agents first-class users with identities, histories and an audit trail of their actions. Installation happens through OAuth, after which team administrators can manage the agent and its access. Linear’s GraphQL API supplies the product operations, constrained by granular scopes. In Moor’s description, that API gives agents access to essentially the same range of product actions available to humans.

Agent-specific webhooks provide the other half of the interaction: knowing when to act. They notify an integration when its agent is triggered on an issue or receives a reply. Additional opt-in scopes determine whether the agent can be mentioned or assigned work.

The combination separates action permissions from event delivery: an agent needs both authority to perform work and a signal that work has been requested.

The demonstrated integrations were already possible through the existing API, but developers had to assemble more of the interaction themselves. Linear planned an SDK convenience layer to launch alongside the dedicated agent interface. This is the initial platform model shown in the recording; the later Agent Interaction SDK evolved toward agent sessions, and current documentation uses delegation while retaining human ownership. Those later concepts should not be read back into the original assignment and webhook demonstration.

The closing integration practices come from months of work with partners in an ecosystem still taking shape. The first is to separate immediate acknowledgment from confirmation of intent. An emoji reaction can quickly signal that a mention reached the agent. A precise response should then establish what it understood: when asked to handle an issue, Codegen should confirm that it will produce a PR for the particular requested change. Acknowledgment answers whether the request arrived; confirmation lets the user catch a misunderstanding before work proceeds.

An agent may live in the cloud and interact through several products, but each interaction should follow the conventions of its host. Linear is a structured window into the agent’s behavior, with useful work context attached. Inside that window, use Linear’s language and workflow: refer to an issue as an issue, move it to In Progress when work begins, and leave activity visible. If someone replies in an existing agent thread, the agent should respond without requiring another @mention. These are ordinary expectations of a teammate, and they make the integration understandable without teaching users a separate conversational protocol.

Before taking action, communicate a plan and get clarification on it. Moor warns against trying to be clever through overconfident one-shot execution; a plan gives the user a chance to resolve intent before the agent commits to work. The final communication standard is equally practical: do not dump verbose model output into comments, issues or other collaboration tools. Be concise and useful. Ask what a good human teammate would contribute in the same situation, and make the agent’s output earn its place in the shared workspace.