A TRACKER REMEMBERS NOTHING. Linear Is Building the Memory Agents Work From

Somebody at Coinbase mentions a bug in Slack. In Linear's published account of the workflow, the remark becomes a structured issue, acquires an owner and enough context to be acted on, goes to Coinbase's own coding agent, and returns to Slack for people to judge. Linear published that account. Coinbase did not publish it independently. Read it as a demonstration, not a census.

Then slow down over the middle of it. The machine at the end is the least surprising part, because coding agents that produce plausible changes are becoming ordinary. The surprising part is that a loose human remark became state precise enough, and bounded enough, for software to act on with nobody standing by to explain what was meant.

That is a harder problem than writing the patch.

In March 2026, Linear published its agent numbers under a banner announcing that its own category was finished: coding agents installed in more than 75 percent of its enterprise workspaces, agent-completed work up fivefold across three months, agents authoring close to a quarter of all new issues. The figures arrive with no denominators and no published methodology. A company reporting its own weather.

Dismiss the numbers and the product releases still point the same way. So does the company's reputation, which rests on something a sceptic can check without asking anyone's permission. An independent technical breakdown of Linear's speed found no magic query and no clever animation: local state, careful synchronisation, caches, rendering discipline, and years of attention to the distance between an intention and a response. No single trick. An accumulation.

Hold onto that breakdown. It is the one clearly independent voice in this story, and it concerns craft rather than strategy.

Speed was the old compression. It is no longer the interesting one.

The classic tracker solved a single economic problem. Engineering time was expensive and finite. A request became a ticket so an organisation could decide which scarce human should receive it, and when. Statuses, estimates, workflows and ceremonies grew up around the waiting, because the waiting was the thing being managed.

The design was not foolish. It described the world it was built in.

That world is moving. Because starting a piece of work became almost free, deciding whether the work should exist became the expensive part. The queue rationed the thing that is turning abundant. It never stored the thing that is turning scarce.

Karri Saarinen, Linear's chief executive, gave the strategy a narrower name in an interview with Every: a focused product-context and product-memory platform that guides Linear's own agent and agents built elsewhere. He drew the boundary himself, and drew it small.

The narrowness is the interesting part.

For about two decades, software companies accumulated value by becoming the place where a recurring job got done. Habit was the moat. You opened the tab, the work happened there, and the switching cost was the muscle memory of a thousand people.

An agent has no muscle memory. It will act through an API, a chat window, a command line or a competitor's product, whichever is cheapest to reach, and it will not feel a thing about the change. A moat built out of habit does not hold against an actor that has none.

What survives is the state an actor has to read before it can safely act, and update when it is finished. Customer complaints. Prior decisions. Rejected ideas. Dependencies, ownership, and the reason a feature exists at all. Those belong to the organisation rather than to any tool, and unlike a model they get more valuable as they age.

The asymmetry is stark once stated. The agent a team runs in March is not the agent it runs in September. The reason that team rejected a feature in March is still the reason in September. The replaceable part is the harness; the accumulated understanding is not.

Linear has begun saying the consequence out loud: that it can remain the system of record even when people reach it through some other application. For a company this admired for its interface, that is a strange thing to want, and the only place the argument can honestly end. The interface can become optional without the record becoming less important.

So the blunt banner turns out to be self-aware. The object does not need to disappear. It needs to stop behaving like a slip of paper waiting for whoever is free.

Linear says a coding session opens with the issue's shared context, and that teammates can follow it, redirect it or take it over, with the result returning to a review surface beside the request that caused it. Loops extend the same shape to recurring work: scheduled and event-driven runs, shared configuration, inspectable history, and governance controls that Linear says are still to come.

Put together, the object becomes an accountability envelope. It records where delegated work came from. It gives a non-human actor a bounded place to begin. It shows an organisation that work is happening when nobody is sitting at an editor. It holds the output and the argument about the output. And it marks the line where authority comes back to a person.

That last job is the one private tooling cannot do. A terminal session knows what it did. It does not know whether it was permitted to, whether someone else is already doing it, or who has to live with the result. When ten pieces of work can start at once, a team needs to know which state is authoritative, which actor owns what, why a choice was made, and whether done means a change was proposed or a useful change survived review. The faster execution gets, the more expensive ambiguity gets.

The volume is not hypothetical. In a second story Linear published, a custom coding agent at Ramp is credited with 60 percent of the company's merged pull requests. A selected example, told by the vendor, with no audited denominator. Whatever governs that flow is not a queue.

Practitioners are already improvising the envelope. In Linear's small community, builders describe using issues and dependency edges as resumable memory for coding agents. One wrote a thinner command-line interface to cut the context cost of tool calls and to fail closed when an agent points at the wrong organisation or team. Another found that more developer throughput simply moved the bottleneck into triage, planning and dependency management.

A handful of self-selected builders is not adoption research. It is something more useful this early: the shape of the next problem. Once an actor can execute, the hard part is handing it the right state cheaply, and proving afterwards what it was given.

The anxiety about Slack makes the layering easier to see. Slack's own agent-first thesis is a strong argument rather than a weak one: people already talk there, organisational history already piles up there, and agents should meet workers where they are. Block has open-sourced Buzz, an explicit shared environment for humans and agents to converse inside.

It is tempting to turn this into a contest over the next interface for work. That is probably the wrong altitude.

Conversation is excellent at starting things and at interpreting them. Someone reports a bug, asks for status, notices that a customer is unhappy. Conversation is a poor final form for durable state, because a decision arrives mixed with jokes, corrections, half-context and the passage of time. People can usually reconstruct the thread. An actor that has to act needs those pieces made explicit and connected, with permissions attached.

In the Coinbase account, conversation stays in Slack while structured work and agent context move through Linear. Linear's documentation shows the ordinary version of the same arrangement: a request can start in Slack without turning every requester into a Linear user. The thread stays synchronised. The work picks up a team, a status, permissions and customer context.

Nothing in that requires anybody to lose. The plausible near arrangement is a division of labour: conversation where people express intent, structure where the organisation preserves it, harnesses where execution happens, and review where authority returns.

Which is where the bill arrives, and it arrives on one desk. Somebody now reads changes they did not write, at a volume set by actors that never tire. Linear's own account of reviewing code in the agent era describes the scarce human contribution moving upward: away from line-level correctness, toward usefulness, architecture, risk and taste.

The question stops being whether the change is correct. Correct is getting cheap. The question becomes whether the change deserves to exist, and that is a question about intent, which is exactly what the queue never stored.

Any incumbent can add an agent button. Fewer can explain why an agent should begin its work there rather than somewhere else.

Linear can, because its first product was already a structured map of product development: issues, projects, cycles, initiatives, customer requests, ownership, dependencies, and the arguments around all of it. The opinionated design lowered the cost of keeping that map current, which is the only reason such maps ever stay current.

That is the continuity between the old product and the new one, and it is not a pivot dressed up as a philosophy. The craft was never cosmetic. Speed made it plausible that people would keep shared state accurate instead of retreating into side documents and private memory, and a record nobody updates is worth nothing to an agent at all.

Now look at the shape of the evidence in this piece. Linear supplied the adoption figures. Linear selected the customers. Linear published the essays about how review should work. The one clearly independent source concerns rendering performance. Reporting on a company this early always looks like this. It still leaves the verdict at directional rather than proven.

The direction is credible without reliability, governance or broad adoption being solved. Linear says governance controls are still coming. A practitioner reports a Codex session that opens its thread and then never starts. Another describes discarding metadata to move off Jira because Linear deliberately resists custom fields. The large migrations are real and also chosen by the vendor telling the story.

The alternatives stay strong. GitHub Issues remains right for a small team whose context already lives in the repository and in three people's heads. Configurable trackers remain right where compliance structure or a complicated organisation model is worth the overhead. Slack may absorb more structured state than its critics expect. And agent platforms may learn to reconstruct enough context from code, conversation and data that no separate memory layer is needed, which is the falsifier that would end this argument fastest.

A sharper question sits underneath that falsifier, and the public record does not answer it. If the record is the moat, it is made out of the customer's own institutional memory. Linear has been explicit that the interface can become optional. On whether the record itself can travel, it has been quieter.

The metadata that practitioner discarded to move off Jira shows the cost in miniature, and they were only moving in. What a team would lose moving out is the part no vendor volunteers. The incentives point the wrong way as well, because every export path Linear builds makes its own moat shallower. Which way the company resolves that is worth watching, since a memory an organisation cannot carry is one it will eventually resent.

Every organisation already runs on a memory it never wrote down. Why the billing code is untouchable. Which customer left over which decision. The argument settled three years ago that nobody wants to reopen. That memory lived in people, travelled at the speed of lunch, and left when they did.

The workers arriving now cannot be told these things over lunch. They will know exactly what the record contains and nothing else, which makes the record the boundary of what a company is still able to know about itself.

A tracker was somewhere to wait for work. What is being built is somewhere to keep the reason the work existed. That difference used to be a matter of hygiene. When part of the workforce is software, it becomes the difference between an organisation that can explain itself and one that merely runs.