---
title: "Your Coding Agent Has a Context Problem"
speakers:
  - name: Tom Moor
    affiliation: Linear
room: "McCarthy Room (Riverside Suite)"
starts_at: "2026-10-14T11:05:00-04:00"
ends_at: "2026-10-14T11:23:00-04:00"
format: "talk"
recording: "2026-10-14_1104_Linear"
duration: "21m 54s"
source: "qwen3-asr-1.7b"
---

# Your Coding Agent Has a Context Problem

> Transcribed by qwen3-asr-1.7b with a schedule prompt. Possible prompt artifacts, names heard more often here than in the unprompted Voice Memos transcript (Qwen vs Voice Memos): Linear (7 vs 3). Check them against the audio before quoting.

### 00:00:00 — Opening and Linear's Craftsmanship Roots

Remember devices. We really appreciate it. A good idea. Voila. I'm silencing it. Jesus. Do we have anybody standing in the hallway, watching? Yeah. Yep. Does the door stay open? I do. Yeah. Yeah, I was saying I'm glad I don't have audience interaction. I can't see anything. My confidence.

Hey everybody, I'm Tom. I run the engineering team at Linear. Thanks for, thanks for turning up to a talk about agents and context. I, you know, I didn't think these were keywords that would really hit today. I'm sure it will be the last, the last time you hear about it, but I'm going to try and kind of get out of the inner loop a little bit and think more about the outer loop stages. Excuse me if it feels a little off topic at times, but we'll get that.

So yeah, I work at a company called Linear. Start with just a quick intro for those in the room that might not be familiar. Linear started life as an issue tracker. It was born out of the frustrations with the existing products in the space, how poor quality they were, kind of slow, hard to use, buggy, slow. I won't name any specific products, but you may have used other products in the space. So you know the founders very selfishly wanted to work with great tools. The best craftspeople always invest in the highest quality tools they can afford, and we felt that at the time, you know, engineers had a distinct lack of good tools.

Now this was around 2019. This is when Linear was founded. And you might say that the world has changed a lot since then. Some things have happened since 2019, since 2020. But as you know, as a company, we're still striving to build high quality software and build systems that enable that for everybody else.

### 00:02:20 — From Tab Completion to Long-Running Agents

So, what changed? I hope you guys will just humor me for a second here. This is not new information to you, but I want to just like bask in how fast this stuff moves for a split second, like, we've had a complete reinvention of software engineering in the time that our company exists and is only half a decade old. It's not that long ago that tab completion came out, at least AI assisted. How did we get to like a copilot in twenty one? Coding agents did not exist in any functional sense until two years ago. The first coding agents came out in 2024. These were really early. They were not that great, and you definitely had to be kind of cutting edge to use them.

So, coding agents themselves are both like long in the tooth as like super early right now. I'm assuming that if you're in this room, you're probably using a coding agent as the primary way to work. Right now, that is the assumption of this talk. If not, come to me afterwards. I'm intrigued in what you're doing. You may have you may have moved to a world beyond this, and definitely come and talk to me then. So you know we hear a lot of talk about software factory now. I don't know if that's the right terminology. You're also going to see our co-founder did a talk a couple of weeks ago about how we shouldn't call it a factory. I'm not going to hop on that particular piece, but I do think that we are — you know, one of the important pieces here is that we're kind of quickly moving from a world where you're hand driving an agent on your local device, to orchestrating more agents, or having them run in the cloud automatically, things like that. And so that does change how — it does change how you use the context, what context you need.

Yeah, and if we look forward like this, this is just the beginning, right? Like that speed that we've seen, it's — we're still at the very, very beginnings. There's a lot of folks on Twitter that are like naysayers, saying that all the free rides over, it's all gonna go up from here. Like they were just obsessed. I don't believe that at all. The cost is going to keep dropping. Like this, this graph is — it's an example of, you know, three years ago what the intelligence that would have cost you a hundred dollars now costs you five cents. So it's is you can extrapolate that into the future and kind of get very interesting results in a few years, like ultra-fast folding camera, you'll snap your fingers, and the future's worth it. And then on top of that, like Task Horizon is like exponential too, so excuse the graph pitch. It's just great software, but it doesn't not let you, doesn't not let you do an exponential access. But it makes it look more impressive.

So, you know the important thing here is we are now leaving these coding agents running longer and longer. So think back for two thousand and twenty-four, you had a coding agent, but you were definitely kind of very in the loop, tight loop there, right? And now these things can run for hours, days. You hear you hear folks leaving things running over the weekend, having success with it. I don't know how much truth there is in that — that code actually ships, but no doubt it's increasing, and we'll continue to do so. So, why am I mentioning all this? Like, what's this got to do with agent context? I think one of the main reasons is that the context kind of moves out of that inner loop and largely into the outer loop. If we have like super fast systems completing tasks for cents and running for hours or days, you're not going to have humans manually doing like eating and starting and stopping them. So we need to start building systems to manage this chaos and manage the context.

### 00:06:18 — Why Product Coherence Needs More Than Code

So yeah, this sounds great, right? Like we're gonna have tons of code produced. It's gonna be really cheap. We're gonna build software factories. We're going to pump it out, like features coming out left, right, and center. I think, like, to be a little trite, like, code is not the bottleneck now. Implementation is not the bottleneck now. The failure mode here isn't an inability to build. The failure mode is like an inability to maintain coherence, to have a product that makes sense as a whole.

What makes a product great is something we care about a lot, and it's something that we are trying to build — a product that helps you build great products too. So it's a free meta. But what makes a product great is consistency, restraints, trade-offs, and like lots of tiny decisions that reinforce one another. This is a Codex-generated image of a settings page that's gone a bit crazy. Don't look too closely. But it's a good example, right? Like, just add another setting. I'm gonna do.

So you know a coding a coding agent today we'll read the code, but it can still — and that's great, like that, there is a lot of value in the code, obviously — they can still miss a lot of the context behind it. So some examples would be like the intent. The intent. What problem are we solving here? Why does this matter? Why does this matter to the end user? Which decisions were made previously? What were the trade-offs that resulted in this design or in this feature? You know, how should this look like visually, outside of the code?

How should this feel like in the product? Maybe things like: Is there other work underway in other parts of the organization, and like who is the decision maker on this? Who's leading this project? Who is ultimately responsible for the decisions that happen here? And then, are there any like additional risks? Like, you can see some things from the right, but you can't always see, oh, like a revert happened two weeks ago in this area of the codebase, may not be immediately. So the idea here is that we carry this — we carried this context through from the initial idea, through planning, implementation, and review.

### 00:08:47 — Automated Intake and the Triage Agent

So I'll talk a little bit about our system for doing that. Most of this is in production in some form, and most of this in production in a way that other people can use too. This isn't a linear add. You can use linear methods, of course, but the principles apply broadly, and you can you build this into any system that you're using, and it's — it's agents all the way down. I'm afraid this is one of the reasons I'm bullish on AI as a whole. Like, every time you deeply dive into a problem, the solution is more AI, and it's definitely the case here.

So the first thing we did is ultimate is ultimate intake. You have, you know, if you're developing a product, you have ideas coming in from Zendesk, Slack, Team Dong, Twitter, your internal product team, your CEO. All of these ideas kind of need to be collected. We feed it into this concept called triage, date dog alerts. Like, there's so many things. I this is like one fifth of it.

Then we have something called Triage Agent. It labels, assigns, and groups the incoming work into themes. It closes duplicates. It routes things to the correct people and the correct teams, and its services decisions when more input might be needed to clarify the problem. It also investigates the — this is this is part of like the investigation that it does. And when the investigation is done, is left on the issue — in our case, issues are kind of the centre of our world still — and it's left us detailed context for the next human agent to use. So by the end of that investigation, we have, you know, the problem that came in, all the idea that came in, who requested it. It's been enriched with the customer information. Hey, this is a high value customer, this is the third time they've requested this in a month. Any stack traces, maybe if it's a bug, logs from DataDog that are associated. It's hooked up to your internal and MCPs, so you can have like internal account IDs and things like that.

And then also related things that previously touched this area, related issues and decisions that were made on those. This is all surfaced on the on the issues of the kind of forms the space context. So you can have something very simple that comes in like this crashes in this scenario, and then by the time the triage agent is done, you have a really a really build out context.

A few examples of where this was useful for us recently. You probably found me. This doesn't matter too much. But you know, this is an example where the video captions kept getting turned — yeah, kept getting turned on. And here, like our triage agent went beyond finding just the setting or something like that. It actually reproduced the bug and discovered that there was an automatic browser action that was being mistaken for user intent. This level of detail left on the on the issue context, it was heave in success of like automatically fixing the issue, but at this point.

Here's another example where the research checked the different codebase. It found some similar shifts to work, make sure it wasn't a regression. In this case, is this a missing feature? Is this a bug? It found all the customers that are associated with this request and realized it's high value. It also found a likely point in the codebase to get started. So as you can imagine, this is just like a really great starting point for your covering agent at this point. It massively increases the chances of success.

### 00:12:47 — Implementation Loops and Agent Verification Skills

So yeah, we have a pretty nice base context. The next step is to build, either automatically from the triage agent deciding to the second that the issue is quick enough. In our case, we have a — if the bug is small enough, we automatically fix it, but you could do this manually. It could be locally via MCP, or it could be remotely in a cloud.

I'm not going to hop on this slide too much. I'm sorry if this is where you expected most of the talk to be, but in my experience, this is kind of a solved problem today. The most important thing here, apart from the base input context that we just created, is the ability to verify and the ability to AI failures to feedback into the agent. So between those two pieces, I see a lot of success. Between the base, the base context, being able to verify and being able to see failures, we see a massive amount of success in our team. Lauren at XAI — he was probably a potato on Twitter — she has a great set of skills you can use to generate the verification skill of your copy agent, really makes a huge difference.

### 00:14:07 — Context-Aware Review Agents and Product History

So the next place where context matters and — I think it's still ill-considered — is in review. And it's also where it gets quite interesting. Like, if you think about your setup today, what does it look like? Do you do you just have codecs running? What are they considering when they review your code? It's likely that they're getting all of their context from the co-occurrence and mostly focusing on logical correctness. That's okay, that's good. The coding agents, the review agents, are really great. They catch a lot of bugs.

But, at this point, we make internally we make much more context available than just the co base. We dispatched another agent. We have a review agent. It starts with that original issue and that base context that we created with the customers, the original intent, and then it goes and looks for product history, so things like previous decisions, reverts, regressions and incidents in the same area. Now we have codes to compare against too, right? So we know which code has been touched, and we know the intent of the PR. We can we can further and enhance the context with this. We also need to refine related issues.

So we now we now have the code context. This might be weeks later, it might be minutes later, but it might be a long time later too. We also want to catch overlapping and conflicting changes, and we just have the full agent session, all the decisions that were made in that. Maybe it was a water shop. Maybe somebody went round and round, and made some critical decisions along the way. And finally, ownership, Tulsa's who should make the product trade-off and where review coverage may be missing. You know, it's not always that are in the companies. It could be your product lead. It could be the CEO, company that product that used to be into. So now we're thinking like less about is this code correct and more about, is this the right change for the product?

So I have a couple of concrete examples of this. These are all within the last few weeks of our products. In this case, our review agent found several relevant changes from six months ago and seven months ago where this was marked as an incident risk due to holding a DBT transaction open. This is actually really great. Like you know, a review agent, a standard review agent, may able to find that potentially, but in this case the extra context really helped. Context did not find it.

This is a pretty visceral example where we surface decisions made one year ago, where we some UI because it was busy. This is the kind of decision we make a lot in a product, right? Like, this — this doesn't feel right. This doesn't feel good enough. How do you get that back into the coding agents context? In this case, like a PR attempted to re-add that same iconography that had been rejected multiple times before. We were able to surface that, and then of course these review comments get fed straight back into the coding agent as additional context. And one more here: we have the concept of team and workspace labels in our product as a hierarchy, and in this case, it looked like the workspace labels were being displayed below the team labels. I don't think a code review tool would generally pick that up. But in this case, yeah, we had a previous reverse issue related to this, and the service that.

So this is where it's able to like maintain that sense of coherence. There's no place in the code that defines that. So many places the labels are listed, for example.

We also built a UI around this that will guide a human reviewer through the change set, and acts as a place to surface those decisions and places where the judgment calls are needed. You can use any review product for this, of course. But you know we want to build tools. We're a big fan of like handcrafted tools, and we wanted to make the best because so we've got the surface.

### 00:18:47 — Compounding Judgment Through Daily Feedback Distillation

And the final stage is like distilling that feedback. So, along the way, these comments have been stored on issues, on PRs. Changes have been merged into the codebase. A lot of context has built up. This is like multiplied at the organizational level, not just in the code. This gives like the human correct active influence beyond the current change. Hopefully, we spend less time making the same correction twice.

And then on top of those changes that end up back in the code, end up in the issue tracker, end up in the progress, we also have a specific loop setup. This is an automation that runs once a day, but it could, could be less or more depending on your PR volume, that will crawl through all of the code that has been merged in that day. It will find actionable lessons, places where these types of comments happened in the PRs, and changes were made, or reverse happened, extract learnings, and then inject them back into the codebase, either in the agents.md or in the related documentation, just to make sure that those learnings are continuously compounding. The exact prompt is something you just have to experiment with, and obviously these changes aren't something you want to build up forever. You don't want your agents empty to end up — this is something that you have to iterate on.

This is this is a linear automation, but you could use any automation product. I think every product has some sort of automation trigger at this point.

So, what does carrying the context through the whole workflow bias? Hopefully, I kind of described it, right, like, fewer changes that solve the wrong problems, to begin with. An intake, understanding the intent helps us with that. During implementation, the product history and conventions help us build on decisions that we've made before. At review, seeing the related work helps us capture complex in the product and with ongoing work — any given example of that — and decides like whether the change like the product as a whole. The aim here is for to is for fewer avoidable mistakes, less rework, and with that, we get faster iteration. Faster iteration.

And then at that final distillation loop, that final automation, human judgment that happened during this whole process becomes context for the next loop around. You know, our judgment matters more as code gets cheaper. That's it.