Tom Moor: Give coding agents the product context that code cannot show

Tom Moor of Linear introduces a talk about agent context beyond the immediate coding loop. As teams move from manually driving a local agent toward orchestrating longer-running agents, he argues, they need systems that preserve context throughout the work.

Linear began as an issue tracker built out of frustration with slow, difficult software. Moor says the company still cares about building high-quality products, even as software development tools have changed rapidly since its founding.

He traces the shift from AI-assisted completion to coding agents and increasingly autonomous cloud workflows. He expects cost and task duration to keep changing, while acknowledging uncertainty about how much long-running agent output actually ships.

In his view, the problem is not merely generating code. A product must remain coherent: consistency, restraint and many small tradeoffs need to reinforce one another rather than accumulate as disconnected features.

A coding agent can read the repository but may miss the original intent, user need, prior tradeoffs, visual expectations and concurrent work. It may also miss who owns the decision or why a related change was reverted.

Moor proposes carrying that context from the first idea through planning, implementation and review. He uses Linear’s systems as examples but says the same principles can be implemented elsewhere.

The first stage is intake. Ideas and reports arrive from support, chat, customer conversations, social media, internal teams and monitoring alerts; Linear feeds them into a triage process.

A triage agent labels and assigns work, groups related requests, closes duplicates, routes issues to teams and identifies decisions requiring clarification. It also investigates and leaves its findings on the issue.

The enriched issue may contain who requested the change, customer context, frequency, stack traces, monitoring logs, internal account information, related issues and the decisions attached to earlier work.

In one example, the triage agent investigated video captions that kept switching on. It reproduced the problem and found an automatic browser action being interpreted as user intent; that finding helped the subsequent fix.

In another example, the research checked existing code and similar shipped work, gathered related customers and located a likely starting point in the codebase. Moor presents this as a richer input for the coding agent.

Small bugs may be fixed automatically after triage, while other changes can be started manually, locally or in the cloud. Moor says the ability to verify changes and feed CI failures back to the agent is essential.

He turns to review, where a code-only agent may catch logical errors but miss broader context. Linear makes the original issue and its enriched context available to a separate review agent.

The review agent also considers product history: prior decisions, incidents, regressions and reverts in the affected area. Once it knows the changed code, it can refine the search for related issues and overlapping work.

The full coding-agent session can reveal decisions made during implementation. Ownership identifies who should make a product tradeoff and where review coverage may be missing, including non-engineering leaders.

The question becomes not only whether the code is correct, but whether the change is right for the product. Moor illustrates this with recent examples from Linear’s own review workflow.

One review surfaced changes from six and seven months earlier and flagged an incident risk involving a database transaction held open. Moor says the historical context helped the review find a concern that another review did not catch.

Another review found that a proposed interface change would reintroduce iconography previously removed as too busy. The earlier product decision was not necessarily visible in the current code.

A further example concerned the order of workspace and team labels. A prior revert and related issue exposed a product convention that might not be obvious from any one place in the repository.

Linear built a review interface to guide human reviewers through changes and surface decisions requiring judgment. Moor says other review products can support the same objective.

The final stage is distilling feedback. Issues, pull requests, merged changes and review comments accumulate context, and the goal is to make human corrections useful beyond the immediate change.

A daily automation examines merged work, review comments and reverts, extracts actionable lessons and adds them to AGENTS.md or related documentation. The interval can vary with the organization’s pull-request volume.

Moor cautions that prompts and accumulated instructions require experimentation and curation. An instruction file should not grow indefinitely simply because each individual lesson once seemed useful.

He summarizes the intended effect: better intent at intake, prior conventions during implementation and related work during review can reduce wrong-problem fixes, conflicts and rework.

The distillation loop then carries human judgment into the next cycle. Moor’s premise is that as code becomes cheaper to produce, deciding what to build and preserving product coherence matter more.