An observation

After hitting 1,000 Linear tickets working on our website and tools, I noticed that the AI seemed to be remembering details that it (and I) had forgotten. So, I decided to investigate.

A ticket shows where work stands and can preserve the constraints, attempts, and decisions behind it. Illustrative example. Created with Codex for Renaissance Solutions.

A hypothesis

After a coding agent finishes a stretch of work, the useful bits often live only in the chat. Constraints. Failed approaches. The quiet “don’t do X because Y.” The next session — or the next person — starts thinner than the last one ended.

Without a durable home, the team relearns the same lessons. Negative knowledge (what we tried that failed, and why) is usually the first thing to vanish.

What tickets used to be

Before coding agents were in the room, tickets were mostly project-management artifacts: status, assignee, a short ask. Humans wrote sparse tickets. The durable record of why and what failed lived in people’s heads, in meeting notes, or nowhere.

We should not romanticize the old tickets. Often they were thinner than we like to remember.

What we’re seeing after roughly a thousand issues

We started using a ticketing system to track work. After roughly 1,000 issues, another benefit became increasingly visible: tickets appear to function as durable, shared context for our AI coding agents.

That is an observation, not a proven causal claim. Our tools, prompts, codebase, and agent-working practices are all improving at the same time. We are still learning.

Here’s what we are seeing:

  • Later sessions seem to get more of the small constraints, oddities, prior decisions, and gotchas when work is grounded in tickets.
  • We let AI generate many of our tickets. They are typically far more detailed than the human tickets we used to write.
  • Those tickets often capture requirements, constraints, acceptance criteria, dependencies, implementation notes, and discoveries made during the work.
  • Retries, failed approaches, test failures, and corrections that flash past in agent logs become organizational knowledge when they land in a ticket or a retrospective.
  • Retrospectives surface details we missed in the moment or had already forgotten — including negative knowledge: not only “this worked,” but “we tried this and it failed for this reason.”

A ticket can be a small, persistent packet shared between humans and agents. It can answer: what are we doing, why, what we learned, what didn’t work, what must not change, which edge cases showed up, and how we know we’re done. AI helps write that history. Future agents can consume it.

Ticketing may be becoming part of the context architecture for agentic development — how we store and share the context humans and agents reuse.

The product is not the thesis. The workflow is. Systems like Linear and GitHub Issues can both support this kind of shared context. We are not crowning one tool.

We also do not claim AI-written tickets contain exactly “what agents need.” They carry substantially more machine-produced context than our historical human tickets. We suspect that richer shared context helps later work. We have not proved it.

Tickets can carry decisions, failed approaches, and open questions into later work. People must review and maintain that record. The benefit described here remains an observation. Created with Codex for Renaissance Solutions.

The catch: ticket hygiene

Bad external memory is still memory.

A stale assumption, an ambiguous requirement, a misnamed system, or an obsolete instruction becomes input to future automated work. We have already seen unintended consequences from unclear tickets. Keeping tickets clean is becoming a human responsibility alongside code, tests, and docs.

We are still exploring the practical questions. Should completed tickets be summarized? Should discoveries be pushed back into the original issue instead of left in ephemeral chats?

Should assumptions be labeled explicitly? How should superseded decisions be marked so agents don’t reconcile old and new instructions incorrectly? When should a retrospective update the durable ticket?

One line we keep coming back to: Ticket hygiene may be becoming part of code hygiene.

Humans own the cleanliness of the shared home.

How we might learn more

Next, we will be gathering stronger evidence without risking live work. Of course we must avoid degrading production tickets by using completed historical issues and isolated repo states. The process will look something like:

  • One light sketch: a planning-only shadow.
  • Give fresh agent sessions different context: the original ask only; the ticket as it existed when work began; a cleaned version of that ticket; or the ticket plus retrospective knowledge available today.
  • Ask each for a plan, risks, likely files, tests, and open questions.
  • Compare those plans to what actually happened. Nothing merges.

Later we can replay selected completed issues on disposable branches and ask a sharper question: if a ticket records that approach X failed because of Y, does the next agent avoid X while an agent without that history repeats the failure? That would be one sign of organizational learning transferring between sessions.

Those are ways we might learn more. This article does not promise results. If useful evidence shows up later, we can update the piece then.

Close

Give the work a durable home. Let humans and agents learn there together. And keep that home clean.