Why Linear Built an API for Agents  ## Metadata - Author: [[The New Stack Podcast]] - Full Title: Why Linear Built an API for Agents - Category: #podcasts - URL: https://share.snipd.com/episode/7cf8f907-70f2-4248-8469-5a63feb7731e ## Document Notes ## Highlights - **Partnership Started From Customer Relationship** - Linear and Cursor began integration because Cursor was already a Linear customer and both teams collaborated via shared Slack to prototype agent workflows. - The integration evolved once Linear released an agents API that created a first-class agent session for Cursor to use. Transcript: Tom Moor I was looking at our team chat trying to figure it out. But I think, I mean, Andrew, you could correct me if you were there. I'm not sure. But like Cursor is basically a Linear customer. So I think we were, and then simultaneously, we're working on our platform for enabling agents to be first class citizens inside of Linear. So I think that was a very natural, we have a shared Slack channel. Like we have a shared Slack channel with many of our customers to exchange ideas and get bugs and feedback and stuff. So I think it was a pretty natural thing from our point to start that conversation at least. Andrew Milich Yeah i feel like then there was an inflection point when you came out with the agents api which i think all of these things were mostly buildable and we had built a version with the old api But then i know the you know first class agent support with like an agent conversation and you know letting users submit follow-ups and see the agent paint on the side. I think that had a lot of buy-in from our team that, like, we can build something that I think is really good. And yeah, I think that was exciting to see because I'm curious if that becomes, like, what all companies end up building, which is, like, a separate way to interact with their products Using, like, an agent API versus, like, you could probably build the same thing and then make it pretty good with the original one. And I think we tried that. Alex Williams Talk to me about this agent. Actually, before we do that, let's talk about what you can actually do with the integration. Then I want to talk about this agent API because I think that is really interesting. Tom Moor Yeah, sure. Yeah, I mean, from our side, our aim was to make it so that, like I said, agents are first-class citizens. The way we see it is linear as a place where you kind of decide and plan what work gets done. So, you know, like two, three years ago, that would obviously be 99.9% of humans doing the work on the other side of that. You're assigning it to Andrew. He's going to go and work on it for a few days and come back um we we realized that obviously this pattern was coming of like agents being able to do some percentage of the work whether that's One percent ten percent fifty percent uh we'll figure that out um and also of agents kind of like living in the cloud as it were um because like the first versions cursor agent were only Available through the desktop client right and some of the other things but it was pretty clear that these things were going to get disconnected and be able to just run autonomously In the background for as long as you need them so we wanted to make sure that yeah that's something you could do through linear you could just assign an issue to cursor in this case. Cursor would get pinged, start the work, and then you'd have this dedicated thread to continue that conversation and also have cursor feedback all of what it's doing, the files it's Looking at, any questions it has, and so forth. So you can kind of take it from the original issue, which contains hopefully all the context to a pull request. ([Time 0:10:10](https://share.snipd.com/snip/490982e3-4c18-4802-b437-d7f3a46df741)) - **Agent Sessions Simplify Integration** - Linear's agent-specific API framed interactions as an agent session to simplify UI and context handling for agent providers. - That session abstraction reduced repetitive engineering across agents and made conversation and follow-ups easier to manage. Transcript: Andrew Milich I feel like then there was an inflection point when you came out with the agents api which i think all of these things were mostly buildable and we had built a version with the old api but Then i know the you know first class agent support with like an agent conversation and you know letting users submit follow-ups and see the agent paint on the side. I think that had a lot of buy-in from our team that, like, we can build something that I think is really good. And yeah, I think that was exciting to see because I'm curious if that becomes, like, what all companies end up building, which is, like, a separate way to interact with their products Using, like, an agent API versus, like, you could probably build the same thing and then make it pretty good with the original one. And I think we tried that. ([Time 0:10:47](https://share.snipd.com/snip/7e7eece3-4cf7-46ff-a980-53da2f60327d)) - **Coding Agent Runs Locally Or In Cloud** - Cursor's core capability is a coding agent that can run in the IDE, CLI, or cloud as a background worker to clone repos and run tasks. - Moving the agent to the cloud enables long-running autonomous workflows and delegating discrete Linear issues for automated work. Transcript: Andrew Milich I mean, I think the core technology at Cursor is becoming more and more the coding agent, making it more capable, making it able to run for longer, letting you get better results, you Know, the terminal example being one small piece of that. So the main one people are using, you know, many millions of people a day is the main kind of IDE agent, the right sidebar that everyone uses. I think the evolution of that has been, you know, taking the same coding agent and putting it in the cloud so it can run on our infrastructure, like it'll clone your repository and run A task, and then also letting you run it anywhere via the CLI. So that's kind of how we've been taking kind of the same core agent experience, you know, that we are constantly making better. And you can use any model, you know, and we'll work with the model providers to make it excellent, but then like letting you run into cloud or in your infrastructure. And now, you know, taking that work to where you're kind of getting delegated tasks. So linear and we have a Slack integration too, but yeah, I think it's really exciting. And the next step for us, ([Time 0:13:22](https://share.snipd.com/snip/64deeb93-b522-415c-a0ab-efe18f143eae)) - **Provide Clear Context In Tickets** - Write rich, specific tickets because more context yields better agent outcomes when assigning tasks to agents like Cursor. - Include stack traces, support conversations, and links to similar PRs to reduce iteration and improve accuracy. Transcript: Tom Moor Whether that's the stack trace that came through from a Sentry integration, the full context of a support ticket, the conversation that some engineers had to do some initial debugging. And then we can pass that all along to Cursor so it stands the best chance of actually doing a good job. And we've seen teams start to get better at writing tickets because they know they're going to be consumed by AI. Like, oh, let's give it some clues as to where to look. ([Time 0:16:37](https://share.snipd.com/snip/71809bfb-46ee-4106-a73a-7da50a3a8e00)) - **Always Review Agent Work** - Treat background agents like teammates: review their output and iterate rather than expecting perfect end-to-end automation. - Keep engineers involved to run locally or open the IDE for final validation and testing. Transcript: Alex Williams Talk to me a little bit more about the background agent actually, because I wonder how developers feel about that to some degree, right? You sign this, it just goes off, does its thing. How much of a black box is that? How much background information do I get? What's happening there? Andrew Milich Yeah, well, I think it feels a lot like using the cursor IDE. Like on the web, you can see a full conversation. You know, Linear has a similar conversation sidebar where you can see the things it's doing in real time. And then you you can also open it in the IDE. And I think we tried to choose an approach that is very developer-centric, not like kind of expecting tasks to always be end-to done. We expect developers to review the output and then open it in the IDE or run locally. So I think the core customer of ours is the professional engineer. ([Time 0:18:39](https://share.snipd.com/snip/1a87a2ac-965b-4a81-8730-4093be7c9288)) - **Build Agent-Centric Interfaces** - Design UIs that feel like messaging a teammate but add agent-specific controls like forking conversations and structured responses. - Surface primitives for account linking and repo selection to reduce integration complexity for agent providers. Transcript: Tom Moor Sure. So yeah, right now, the first version, we kind of tried to keep it as similar to working with any other teammate as possible. I want to say like we wanted it to feel like as if I was messaging another team member. And I think we've achieved that to some extent. Now we're looking at maybe the places where we should be leaning more into the fact that it's an agent and like actually trying to differentiate it a little bit. If you think about some of the functionality that we start seeing, like being able to kind of like fork conversations, being able to kind of like go back in time a little bit and go, oh, Let's let us redo that or have, you know, 10 conversations going on with different agents at once, things that you probably wouldn't do with, with the human teammates, but make more Sense. ([Time 0:20:08](https://share.snipd.com/snip/aa61ca8d-01a1-4416-ba49-8c337826f7d8)) - **Agent Primitives Reduce Repetition** - Using the full GraphQL API worked but exposed repetitive patterns, so Linear created agent primitives to handle common agent actions and comment threading. - Agents now post updates tied to an agent session ID which abstracts UI concerns and simplifies lifecycle management. Transcript: Tom Moor Yeah. That comes back to the first version and the second version a little bit. So for the first version, we just had the agents use our existing GraphQL API, which is very extensive. It's something we've been building for five years now. So you could pretty much clone Linear on top of our API, I think, without too much trouble. Maybe if you let the tokens run for long enough, I'm not sure. So we kind of did that. But then one of the things we realized is there's actually a lot of surfaces inside of Linear that it would make sense for agents to have access to and be available in. And also there's like a lot of complexities to deal. It doesn't sound complex, but there's a lot of like intricacies to dealing with comments and comment threads and replies that every agent provider was having to deal with. So we kind of rethought it and created this idea of an agent session in our API, which I don't think is like a unique concept. I think most agents have something similar. So we wanted to codify that where when a user mentions you, mentions the agent, mentions cursor or assigns cursor, we send cursor this concept of an agent session. Here's all the context. And then Cursor just has to hit our API with the things it's thinking and its responses with that agent session ID. And it kind of abstracts away the user interface for the most part. You can still use the full GraphQL API to do anything that might make sense to do. ([Time 0:21:57](https://share.snipd.com/snip/38c2cc46-d27b-44dc-abad-77983e4df3f0)) - **Guide Agents With Examples And Docs** - Use small, well-specified prompts and reference existing PRs or spec files to guide agents toward correct code changes. - Store instruction markdown in repos so agents can reference repeatable procedures across IDE and Linear workflows. Transcript: Andrew Milich Yeah, I think I'm curious with the whole set of these like shared interactions agents have, because I think it's normally like one fast reply comment, like we're working on it then, Or like an emoji react. Then maybe that gets updated or like it responds when it's done, or it's like kind of trying to edit and post updates. And then normally like another comment saying this is done um and or like listen to responses on a comment thread to follow up so i imagine that's what you were seeing basically i'm curious If there's some broader set but it also is interesting that then the agent like can use mcp and update linear in reverse which is kind of this weird circular dependency thing. Tom Moor It's more very incestuous, I've found, yes. No, you're right. We had that first version and we're like, okay, everybody's doing very similar things here. Let's try and make those things easy. It's a fine balance though, right? Because this is still so early. We don't want to put restrictions in place that don't make sense and like hold you guys back from interesting things you want to do. So, you know, we have a low-prone communication channel for that and we're always adding things and we're trying to figure it out as we go, really. I think everybody is. ([Time 0:24:01](https://share.snipd.com/snip/dffeb40f-9bcd-4433-9808-392a8e113a77)) - **Code Quality Is The Main Improvement Area** - Current limitations are mainly quality and consistency of generated code; execution-based tools like terminal or browser help improve outcomes. - Multi-model and tool execution strategies can yield divergent results, so product design must orchestrate for reliability. Transcript: Andrew Milich Yeah, I'll just admit, I think the results from the agent, I think we think cursor is a very competitive, you know, I think you'll get the best results from any async agent in cursor. That said, I also think the results from the cursor agent could get better and better and better. You know, I think using program execution like terminal or browser or other stuff, you know, could get better. I think sometimes even using multiple models, so like you could kick off an agent with three models, you may get very different results and then one will work. I think that's kind of a product of this, like in between, you know, this step function we're going through in capabilities. So I will just admit the pure kind of quality of the code that gets generated is our biggest improvement area. ([Time 0:26:24](https://share.snipd.com/snip/64c8940e-5263-40d8-97ea-21d1f198c79b)) - **Optimize Dev Environments For Agents** - Keep dev environments fast and minimal to make agent runs efficient; invest in fast type checks and linting for quick iterations. - Prefer pragmatic base images that run only needed checks rather than heavy full builds for routine agent tasks. Transcript: Andrew Milich With background agent, something we, you know, we have like custom environment support. So you could pick like a custom base image, you know, or we'll give you a default base, you know, Linux machine. We'll install dependencies, like we'll install Python and Java and JavaScript, you know, Node and all this stuff. But there, I think there's still a good amount of setup cost. I'm curious where that goes, where like, you know, if every team has these like dev, remote dev machines that are set up for agents, or like the agents just will install Node via terminal And you'll let them run for three hours. I don't know where that's going to go. I'm curious, Tom, if your team has any tricks there. But yeah, I don't have a clear set. Some teams invest a lot in setting up like a base image environment and some just like, you know, are fine with it running. Tom Moor I think we're definitely on the latter side of that, on the pragmatic, like run as little as you can to hopefully run type checks. And we just try to make those as fast as possible. You know, we spend a lot of like time on developer experience in general at Linear. ([Time 0:31:10](https://share.snipd.com/snip/6ee4c194-6186-42d6-84b2-952ae31f6649)) - **Teams Treat Agent Costs As Worthwhile** - Organizations view agent costs as small compared to salaries and infrastructure; teams trade increased intelligence rather than cheaper runs. - Many firms bake agent research into product tiers because the upfront triage value outweighs model costs. Transcript: Andrew Milich Yeah. Compared to, you know, an engineer paralyzing their work, I think it's really inexpensive. Tom Moor Think that's the key, right? And that's why we're seeing such incredible growth in valuations. And like, these are no longer, we're not, it's not just software, right? It's starting to take budget from other areas a little bit. And at the risk of sounding privileged, like I run the engineering team at Linea, and I don't really think about the cost of these things too much. It's somewhat negligible in comparison to what we pay on GCP and what we pay on salaries. Like, we'll look occasionally, like once a month, okay, it's still within a reasonable range, fine. You know, like, we're not going to spend cycles, like, trying to optimize 10% of our cursor usage or something. Andrew Milich Yeah, I mean, obviously, we feel the same way. There's no constraints on, you know, cursor or token usage, which sometimes means people, you know, I've been guilty of this, run hundreds of background agents a day, you know, like Why not just pick every single model on every single task? I think that's where we are. And so there was a while where we would even have it run on every single linear issue right when it was created with multiple models. I think that was not a cost concern. That was a noise concern where you end up getting these underspecified issues, getting like over-specified agent runs. But I think things hopefully go in that direction. You want every agent run to be high quality. So I think the multiple model thing is more this product of like model innovations is still really fast. So you actually will get different results. ([Time 0:32:46](https://share.snipd.com/snip/2ee142ba-5e4f-413c-99b8-221d3417b8aa)) - **Coordinate Multiple Agents Carefully** - Prevent agents from colliding by restricting simultaneous edits and surfacing active agents to users for oversight. - Provide an inbox or surfacing mechanism so engineers can triage which agent runs need attention asynchronously. Transcript: Andrew Milich Yeah well okay i think i think that's somewhat inevitable like even people in the ide without you know fancy background agent custom environment setups often are running many agents At once. I think the agents are getting better at, like, not running into each other through simple mechanisms, like not editing the same file at the same time, and then complicated ones. Like, AI can do a pretty good job at most merge conflicts, like, especially simple ones. Yeah, I think that's the extent of how we're thinking about it today. And then we're trying other interfaces for like letting people have control over them. So like a new interface and cursor where instead of just being a right sidebar, the agent conversation is like, you know, more front and center. And then, you know, instead of a left sidebar being just files, you would see a list of agents. So I think that gives people a better overview of what they're working on. One limitation we run into is like, people don't by default, like have 30 second attention spans and kick off task after task. Like I think people like, you know, engineers, I find in my experience, you know, I don't often just think, oh, I need to do this, I need to do this, you know, in one minute and kind of kick Off multiple agents. So I think that's something that we feel pretty stuck on today. It's like people don't by default gravitate towards running like 10 agents at once. ([Time 0:36:45](https://share.snipd.com/snip/ce4138e4-b339-4d5f-ba92-f50c54b39822)) - **Multi-Agent Handoffs Are Emerging** - Useful multi-agent patterns already exist: investigative agents (Sentry), specing agents, and work agents can form a handoff pipeline. - Code-review agents are proving high value by catching bugs and improving release quality. Transcript: Tom Moor From the multi-agent point of view, I think like we haven't seen a lot of it yet, but we are thinking of it from like maybe like one step higher, which is this coordination. So, for example, we might have the sentry agent that goes and does the investigatory work and then passes it off to the cursor agent. Or we have like Devin, Will has an integration that their entire integration is trying to make sure that an issue is really well specced. So you have like one agent speccing the issue, one agent researching the bug, one agent doing the work. We already have like code review agents, which are one of the most useful agents out there today, in my opinion. I've certainly seen them save some terrible bugs from going out the door personally. So I don't know. I think you guys have seen good growth on that too, right, Cursor? Yeah. Andrew Milich So we have a code review product called BugBot that definitely has gotten a lot of adoption. ([Time 0:39:22](https://share.snipd.com/snip/46843769-e897-45d3-aff9-26ff704895d1)) - **Email Still Feels Unsolved** - Andrew noted that email remains an unsolved AI problem despite progress in coding agents and productivity tools. - He believes future AI could deliver a far better email assistant than current smart-reply features. Transcript: Andrew Milich Yeah, I think one complaint I have, I still think AI email is not solved at all. Either the replying or whatever agents responding. I think we did a lot with Notion Mail that we got excited about and you'll see that in the product, like, auto-labeling and stuff. But I think it's totally unsolved, you know, and like Gmail smart composed with like the first version of tab autocomplete I really liked. Yeah, I think it's shocking that coding feels like it's jumping forward by, you know, light years every month. And then email still feels like relatively, you know, underserved with AI. Alex Williams Yeah. And Gmail, you still know it's a smart reply when it's got an exclamation at the end for no reason whatsoever. Andrew Milich I'm guilty of using some of those too. And, you know, Notion Mail, we have a version of that that we built. But yeah, honestly, that's like a 2022, 2023, you know, 2024, high quality with some context stuff. It doesn't scratch the itch of email agent that I still think could be done. I'm hoping ([Time 0:45:32](https://share.snipd.com/snip/91215c65-59b6-46ab-a7f1-9b6a53d3c3ee))