Why Linear Built an API For Agents

Key Takeaways

All right, we're live for another episode of the New Stack Agents, our podcast about all things AI, AI agents, software development with AI. And this week we've got Andrew, do you pronounce it Militch or Milik? >> Milik. >> Milik, that's what I thought. Andrew Milik from Cursor and Tom from Linear. And the reason we've got both of you on is because there's a partnership between the two that just went live a few weeks ago. So, we really wanted to talk to you about that, but also really about what it's like building with these tools today because I was just I'm you can see it in the background here if you're watching the video. I'm in San Francisco this week. I was at the Workday Conference. Not because I love HR so much. few people do, but it's because I really want to see how people are building with these tools and and some interesting conversations around how you know CTO's, engineers are figuring out how to get the most out of this. And as it turns out, workday is actually a cursor shop. So that works out really well this week. But um before we talk about all of that, let's start with you Andrew because when I saw your name, it looked really familiar and then I realized you had been doing skiff which then got sold to and kind of an email product with some AI built in as well and you sold that to notion. So talk to me a little about that and then we'll talk to Tom about his career a little bit. >> Yeah. Um I spent almost five years working on email products. Skiff was all about privacy and endto-end encryption. the notion uh notion mail uh is a lot more about productivity and AI and then realizing the notion vision of a multi-product notion notion calendar and notion mail uh ecosystem and now cursor is very different direction but I think what ties them together is being very productled you know all the companies skiff grew to a few million users notion obviously announced I think a 100 million user milestone and cursor I think also has really grown almost completely organically for a a long time and now we have great we have customers like workday but um I think all of them I just really enjoyed working on great productled you know very kind of consumer focused products that then hopefully turn into big enterprise businesses >> sure what made you decide to leave well you don't have to go into the details from leave notion but what made you decide that you really wanted to go to to cursor >> yeah I don't think I had a big plan that was like you know now's the right time to go and work at cursor I think you know I was starting to see my peers and myself just adopt cursor so much. And if you walk around the office and you see, you know, hundreds of people who are have cursor on their main monitor, even if they're not an engineer, they're a PM or they're a data scientist, you know, up to our CTO at notion was starting to use and maybe even Ivan, the CEO, using Cursor. And so I think, you know, I loved just the day-to-day of using the product and then also found it really creative where it can let you build things that were inaccessible before or like growing up you try to build a game or a new app or a product and now that's kind of like one prompt. So you know I know you've had conversations on engineer productivity but for me it was not like 10 15 25% it was like 100% 200% you know it was a massive uh change in how I was doing work. >> For sure. Now at cursor you're the head of product engineering correct? So >> yeah, >> what does that mean dayto-day for you what you're doing there? >> Um, well, we still have a pretty small team in general and then a product team. We probably only have 15 to 20 people who are doing like the real engineering work across you know the CLI, the uh IDE and then the async agent product, the background agent product. Um, but I think it means you know uh we have a exciting road map some of which is like the future of coding. So we uh as a little flag we're building kind of more of a planning focus mode into cursor right now and a bunch of users are starting to try that out but then also just you know making the agent give better results um as much as possible. So, as an example, like in the latest version which came out yesterday, we rebuilt like how the agent uses the terminal. And so, it's a lot more reliable and you get a lot better results, but that, you know, leads into this vision of the agent being able to read and use the execution or the output of your program. And that's also really relevant to the background agent work that we've done. >> For sure. For sure. Version 1.6 you're at. I think it exactly everybody's going everybody's going down into the the terminal with their agents it seems right now. >> Yeah. That gives it a lot of power. It definitely you know exposes the like a lot of complexity like running long running scripts and starting your dev server but I think even in the background you could imagine you know the agent can test an API using the terminal or it can you know start your dev server and then open a browser and look at the output of your program so I think it gives us a lot of possibilities >> for sure for sure Tom we don't want to ignore you there >> no internal thing did it did it come out of code act or is it related to that saw the Apple machine learning paper and they talking about how if you uh give the give the agent the the terminal, it's like 30% better just just just through having that, right? >> Interesting. I have to look at look at that. Um I think we've always wanted it to use the terminal. I think it just didn't terminals are really messy. You know, there's like uh Mac, you know, well, first of all, like even on Mac, you might have like zsh bash like you know, multiple different uh shells people are running. And then also like on Windows, you know, there's WSL which is like a Unix based shell and then PowerShell um as well. And so there's a lot of different edge cases. And I think the main motivation was we found that, you know, people are trying to run the same terminal commands like or no matter what platform they're on, but they just had really different reliability even running simple like git commands. So that was the main motivation. And also users do a bunch of weird things. They might have like custom aliases or like custom functions they put in their shell. So, we tried to just make things a lot more simple and reliable. Uh, but yeah, I have to check that out too. Tom, >> I would be remiss if I didn't pluck our episode with Zach from Warp, the other, you know, terminal company from two weeks ago. So, if you haven't listened to that one, you should probably check that one out. But, uh, Tom Linear, you've been there since 2021, so you've really seen the development of this space. And you know maybe also for those who aren't 100% familiar with linear just give us a just a brief rundown. Yeah, sure. >> Does >> I think uh linear started out through the founders frustration with the existing uh issue tracking tools to be frank. Uh things like uh Jira and uh GitHub issues to some extent. Like >> people are frustrated with Jira. I've never heard that before. I mean, yes, you've never heard this line of thinking before, but yeah, they were on like Airbnb and uh Coinbase, which obviously big big users of this, and we're like, "Wow, is this really the best we can do, you know, like uh in terms of our tooling." So, it came out from that just trying to be like a really excellent issue tracking tool. Um was incredibly fast. And I think over the the last five years or so, we've obviously um built on top of that kind of foundation and made a and now have a tool that's a a platform for building products. I want to say kind of end to end. So like ID ideas in one end and hopefully code out the other end to some extent. Um we're not doing every piece of that obviously with integrations with cursor and such but um yeah that's that's the general idea. >> Do does Linear have customers who aren't in the coding software development business or do you even go after those? We do for sure, but the thing is like most companies have some code at this point like you know so we have like car companies we have like boom arrow they're building like supersonic planes they they use linear I I don't know exactly how much of the plane building process is on there versus just the software portion of their their company um >> but yeah primarily our our target is is software companies and building building other products like that yeah >> which makes sense now you als also run another software company on the site. You've got your own little project as well, Outline. Tell us about that for a moment, too. Well, I I think it like helps if I briefly like mention my career, I guess, which is basically I spent my entire 10 years working on like team collaboration, communication software since I kind of came to the came to like the valley in like 2012 and have built like video conferencing, audio conferencing, remote things. um this outline which is a team documentation product uh you could think of it kind of like a confluence competitor if we're going to go and do the the mirror there um that you can you can run it's it's it's actually open source so uh you can go check out the code and run that if it's of interest um then I worked at a company called abstract um for five years and we were we were building version control for uh sketch files primarily but also some of the Adobe files Um, I think there was there was a bet at the time as to which way the industry would go and I think we fell on the wrong side of that bet because uh everything kind of went the Google Docs model and Figma certainly took over that market. Um, and so yeah, from abstract I came across to to linear about four just over four years ago and just kind of continued that trend really. It's like I've always been working on tools which are just for people to communicate and and get and get work done. Feels like >> sounds like your overall mission is to put Atlassian out of business. Is there >> gold? I I'd be happy to take a nice chunk of it. Uh >> there you go. There you go. Now I want to talk about the integration between these two platforms because I think that's that's really interesting and also a trend we're seeing in the industry. I think where you know more of the work is you given to agents maybe in the form of a GitHub issue or on linear or somewhere else. So why don't we talk a bit about how this actually came to be who who introduced who and how did that all happen? I was looking at our team chat trying to figure it out but I I think uh I mean Andrea you could correct me if if you were there I'm not sure but like curs is basically a linear customer so I think we were and then simultaneously we're working on our platform for enabling agents to to be first class citizens inside of linear. So I think there was a very natural we have a shared slack channel um 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 to start that conversation at least. >> Yeah. 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 pain on the side. I think that had a lot of buyin from our team that like we can build something that I think is really good. And um 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 make it pretty good with the original one. And I think we tried that. >> Talk to me about this agent. Actually, before we do that, let's talk about what you can actually do with the integration. And then I want to talk about this agent API because I think that this really interesting. >> Yeah. Yeah. Sure. >> Um yeah, I mean from from our side um our aim was to make it so that like I said agents are first class citizens like the way we see it is is linear as a place where you kind of decide and plan what work gets done. Um so you know like two three years ago that would obviously be 99.9% humans doing the work. On the other side of that, you 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 1%, 10%, 50%. Uh, we 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 of cursor agent were uh only available through the the desktop client, right? And some of the other um things. it was pretty clear that these things were going to get disconnected um and be able to just run autonomously in the background for as long as you need them. >> Um 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. um cursor would get pinged and start the work and then you could then you would have this like dedicated thread to uh continue that conversation and also have cursor feedback all of what it's doing uh you know the files it's looking at like any questions it has um and so forth so you can kind of take it from yeah the the original issue which contains hopefully all the context to uh to a to a pull request >> and of course that only works because curs has the ability to run in the background now and run, you know, not just locally much as in a CLI, but there's more to it now. So, >> yeah, I mean, I think the core technology at Corser 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 um 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 in the cloud or in your infrastructure and now you know taking that work to where you're kind of getting delegated tasks so linear and um we have a slack integration too but um yeah I think it's really exciting and the next step for us I think um is actually if we can kind of you know not make teams change how they work today and so we're experimenting with linear on actually like automatically running on a few issues and I know we've talked to the team about that but I think we don't see that as like you know massively different to how it works today but it's like kind of a behavior shift to say like delegate to an agent and then come back and review its work. Normally you're used to you know delegating to a human and then they kind of get the job done. So I hope that it feels a lot more like that where the agent will take a first pass and then you know maybe you can see if it's automatically solved or it can review itself and then you kind of like stay in your normal flow and give it to a human if um to review or to test. >> For sure. You've it's been in the market for a few weeks now. Is that played out the way you expected it to? Is it working the way you expected it to? Are people using it the way you expected? Yeah, I think we see very very large demand including from massive existing customers to connect these to uh like to connect the background agent to linear and to kind of give their engineers this capability. I think we see uh a lot of enterprises are figuring this out because running on you know running like an async background agent on their infrastructure or on ours is like a bit of a different paradigm actually running you know an IDE is much simpler. It's either running via like an SSH connection that developers already have or it's just running on your file system. So they're definitely moving fast to adopt this, but we're figuring out some of the in between. It's also, I think, a bet on like the future capabilities somewhat too where I think the cursor agent is extremely good and all these coding agents, you know, it's it's quickly become I think um you know, one of the most popular out there, but I think like in a year it will be way better. And so it's very very good at like clearly scoped tasks in linear. So teams that use linear well will get better results from the cursor linear agent. But I think for this to like fully realize and become kind of the primary way teams use AI for coding, it you know, we want to see more of the capabilities develop. >> Same for you, Tom. Is it kind of what you're feeling is? >> Yeah. Yeah. Um I think like the the really nice thing about this integration in particular is that Linear has so much context and the context is what the agents often really need to to do a really good job. Um whether that's like the stack trace that came through from a from a sentry integration, the full context of a support ticket, the conversation that some engineers had to kind of like do some initial debugging. >> Um and then we can pass that all along um to to cursor so it like stands the best chance of actually doing a good job. And we've seen like teams start to kind of get better at writing tickets because they know that they're going to be consumed by AI, right? like, oh, let's let's give it some clues as to where to look and then, you know, it's going to take less passes uh over time. >> Yeah, that's I forget who I talked to about this in the last few days, but having this additional data come in around how did this issue actually arise? What was talked what did people say about it? All these things adds a lot of context. How are you ingesting that context on the on the cursor side? And does that change kind of how you're thinking about context as well as you do? >> Yeah. Okay. Okay. I think a few things. One is the simplest way is just to give a very clear well specified prompt. And so I think that's what's what Tom is talking about like sentry and data dog and others are great examples where that may have more than enough information to get a good result from the agent. The other is like team setup context. So I think either you have or are introducing kind of like more prompting at the team level where you can provide the agent maybe information about your codebase or you know additional instructions. I think the last thing we're seeing some adoption with even in huge you know tens of thousands of engineer customers is MCP where you can connect that to the background agent or the CLI or cursor ID where they may have like an MCP server that hosts their docs or hosts you know other integrations and um that's becoming more common as well and of course like linear also has an MCP server that is uh pretty popular at cursor and like I I use that and it's pretty amazing you know it's it's awesome to see the background agent thing work and We should talk about that. But it's also pretty awesome to be in the IDE and say like what are the linear issues assigned to me and then kind of see them stream in and then you know kind of talk to the agent using that method too. >> Yeah. Talk to me a little bit more about the background agent actually because I I wonder how developers feel about that to some degree right you assign 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? >> 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 can also open it in the IDE and I think we tried to choose an approach that is very developer centric you know not like kind of expecting tasks to always be end to end done. We expect developers to review the output you know and then open it in the IDE or run locally. So um I think you know the core customer of ours is the professional engineer and that's that's a lot of why I join because I think we try to kind of make things that make people work faster but don't expect like you know this to be the main way like tasks are completed without engineers being involved. >> Right. Right. Right. on the linear side, how have you thought about the or how are you thinking about the the user interface for this as well as you know right now I kind of do the at cursor and you know it works for me but >> is that the future? Is that you know >> Yeah, that's a good question. I mean we're already about 10 iterations into the user interface. I think it's it's one of the things that we we kind of feel is our secret source is the ability to to have like very nicely thoughtout user interfaces around things. >> Sure. >> Um 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. Um 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 to differentiate it a little bit. Um if you think about some of the functionality that we started seeing like being able to kind of like fork conversations, be able to kind of like go back in time a little bit and go oh let's let let's 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. Um, I think there's just these these subtle ways that things differ that we can we're starting to build upon. Um, things like structured responses, you know, like one of the things we see from every agent that integrates is the one of the first things they need to do is like find is connect the accounts like who is this I'm talking to, right? So we're introducing like primitives for that and primitives for things like being able to um select repositories and stuff. So like there's a lot of intricacies around the integration of the two platforms. I think that hopefully between us we we try and do a good job of of papering over so that the so that humans don't don't have to deal with it. But that's that's why we have to share Slack channel. >> That's that is the promise. Now, you mentioned the the agent API earlier on and then Andrew also brought up MCP, but it sounds like you decided to set up a specific API for is it for the use of for the agent to use or just to >> work with the agent. What's what are we talking about there? >> Yeah. So, so like that comes back to this like the first version, the second version a little bit. So for the first version it we just had a we had the agents use our existing GraphQL API um which is is very extensive something we've been building for five years now. So you could you could pretty much clone linear on top of our API I think without too much trouble. Um maybe if you let the tokens run for long enough. I'm not I'm not sure but um so we 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. Um 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 um that every agent provider was having to deal with. So we we kind of rethought it and create created um this 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. Um so we wanted to quantify that where when a user mentions you mentions the agent mentions cursor or assigns cursor we send cursor this this like concept of an agent session here's all the context um 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 the user interface for the most part you can still use the full GraphQL API to do anything that that might make sense to though. >> Yeah, you could just use the agents markdown file or something to tell it about how to use an API as well, right? So, there's, you know, some people do that. >> Totally. And we've seen um other agents create like custom CLIs for interacting with Linear too. So, you just do uh through that terminal idea like agents are pretty good at using terminals, right? So, let's give them a bunch of terminal tools and >> always comes down to the terminal. But um Andrew, does did that make life easier for you then to have that API? >> 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 um 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. uh 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 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 like circular dependency thing. >> It's more very ancestrous I found. Yes. But like, no, you're right. Like, we did we had that first version, then we're like, okay, everybody's doing very similar things here. Let's try and make those things easy. Um, and it's a fine balance though, right? Because this is still so early. Like, we didn't want 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. Um, so you know, we have an open communication channel for that and we're we're always adding things and yeah, we're trying to figure it out as we go really. I think everybody is. >> Yeah, I I feel like the I mean, I think like a year ago some of these things were buzzwords, even agents, MCP was definitely a buzzword. I've been surprised at how useful, you know, I don't I don't mean as a joke. I mean actually how useful these are and how widely adopted they've become even with pretty limited documentation you know and resources and like you know support for people are actually like in you know the hundreds of thousands or millions like really turning these things on and getting a lot of value from them and you know even for a normal cursor user at cursor seeing it able to ask for GitHub issues or ask for linear issues then like open a browser and then you know check Sentry all with MCP or in the background is pretty amazing. >> What is it, you know, we're really positive here, but what is it that doesn't work well yet? And either in, you know, the integration or where where are there still issues or is it just the the agent not being able to to do the job sometimes, right? >> Yeah. I'll just admit I think the results from the agent I think we 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 uh improvement area. >> Sure. >> What about from the linear side? >> And I think like a lot of that comes down to some of it comes down to teaching people what these things are capable of right now and what they're not. I I it's not unusual even on our own team to see an issue that has just a title and then someone says at cursor fix this and it's like what did you expect to happen exactly here? Like these things aren't magic. You still need to give it some some idea of of how to do things. Um and I think just spending that one minute like doing the thinking some of the thinking yourself to to give it this head start will goes a long way. And knowing how to kind of like chunk up the work a little bit too. like I find myself when I'm working on these things uh you know okay go and work on the migrations for this here's some ideas how how I want it done okay now let's work on the first two API endpoints for this and like because you know the context can get overwhelmed as as well so it's just a much a learning exercise of of how to deal with agents in general >> totally agree yeah I think the better your team uses linear the better results you'll get from the agents that are also using it. And we have found that too. We've built a bunch of automations about connecting user feedback or internal feedback to linear and sometimes people do exactly the same thing. They say fix this and include a screenshot and actually the agent will read that screenshot but still it may be missing um you know a lot of information. Occasionally things will work magically like wow you actually understood the layout in that screenshot and then sometimes it will just not work at all you know like >> of course >> it's that is the state of the technology >> what's also cool is there are a lot of these like vertical use cases where it's just like a slam dunk use case meaning like updating docs anything dependency related anything like analytics uh or data related you know I think you'll get really good results and sometimes it's a crutch actually it's like I can't you know I don't want to write this query with four joins to understand how you know users are adopting XYZ. It's like take a look at my database schema add this one query to understand you know are people actually connecting their linear account and blah blah blah. So I think those are these you know use cases we want to keep working on. Same with like observability and data and all of that where like a stack trace often you'll get really good investigation results um you know and performance too. So I think we're going to hopefully see more of those use cases where like maybe um teams or like sub teams are starting to adopt it in mass. >> One one pattern I find works quite well is to point the agent to an existing pull request if you're doing something in a similar vein. >> So like we have some stuff internally where we have all of our billing plans kind of defined and it's across like three or four files and there's a bunch of strings and constants and it's just like oh we need a new billing plan. Okay, go and look at this last PR that added a billing plan and I want this one to have this dollar amount and be called this and it'll go like make like the equivalent changes across all those files and kind of use it as a template. Um or like any sort of like refactoring which I guess that sounds similar to as well. >> Yeah. Yeah. I mean one thing we do is we for common things like that I think billing is a great example for us people try experimenting with a lot of new agent tools. Um so agent tools to read docs or search the web and all of that. We have like markdown files that we commit in code and then can reference those in prompt. So it's like open this repository and add a tool to do XYZ. You know there's a lot of manual work to add it to a bunch of constants and files and front end back end all this stuff. And so sometimes these like uh instruction files that live in your codebase can also be really useful and that will you know make that will then kind of pay dividends when you're doing it in all these different surfaces in the IDE or in linear or other stuff. >> Yeah, that's awesome. Now you've you've brought up a couple of best practices here. Are there others when it especially when it comes to thinking about these agents as a as a teammate who's working in the background? Are there best practices you can think of that our audience should know about? >> Uh well with background agent something we you know we 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. um 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 m 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 uh yeah I don't have a clear set. Some teams invest a lot in setting up like a base image and environment and some just like you know are fine with it running like type checks and basic things. >> I think we're we're definitely on the 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're sp we spend a lot of like time on developer experience in general um at Linear like we we try to make our internal development experience really nice and I think that's hopefully started to pay dividends with agents because you you know the the the TypeScript checks run fast, the llinter runs in seconds um and so you can get more iterations in. So I think like investing in those things now just two is 2x what it used to be. So I would definitely uh spend time there as a best practice. >> Talking about investing, what about the cost and how to keep that reasonable? Because when these agents run for three, four, five, six, seven hours, that's a lot of tokens you can burn through. >> Yeah. It compared to, you know, an engineer paralyzing their work, I think it's really inexpensive. I >> I think that's the key, right? And that's why we're seeing such incredible growth in 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 um and at the risk of sounding privileged like I I run the engineering team at linear 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. uh like we'll look occasionally like once a month. Okay, it's still within a reasonable range. Fine. You know, like we're not gonna spend cycles like trying to optimize 10% of our cursor usage or something. >> Yeah. I mean, obviously we feel the same way. There's no constraints on, you know, cursor or token usage, which some 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 oversp specified um agent runs. But I think things hopefully go in that direction. We want every agent run to be high quality. So I think the multiple model thing is more this product of like model innovation is still really fast. So you actually will get different results. But I think eventually, you know, it may cost a dollar 50 cents to run on a linear issue, which is just such a cheap option to fix a bug or save an engineer's time on, you know, a more important problem. >> Yeah, for sure. For sure. No, you did mention Oh, sorry, Tom. No, I was just going to say like we have if I can like we have um part of the product that's built into linear now is this thing called product intelligence um on like our higher tier plans and that literally is an agentic system that runs on every issue that comes into triage. Um so every issue that comes in from support we go and like do the research on it. Basically, it will go and it'll look for similar issues, look for follow the knowledge graph, find who's been working on things um and so forth and it comes back and we can auto apply labels, projects, assignees um and basically >> I'm a user of I'm a pretty heavy user of that. I'm one of the heavier linear users on our team and I think it's great and it also like hopefully gets good results from the cursor part which is I see the little badge to assign to like the product team or like a label with a terminal bug or a chat bug and then it kind of goes and does work >> and but we had this discussion is the reason I bring it up because it's like wow this is actually quite costly as far as infrastructure goes to go and do this for every issue sometimes sometimes it runs for 20 seconds sometimes it runs for like over a minute just just researching you know if it's like a complex thing um and that's we've deced decided that this is we've just baked that into our plans at this point. Um, and we're just going to do it for every single issue because the value is there, especially on bigger teams. It's just such a huge value to have that research done up front. >> And of course, the cost of the models, well, the cost of the models is going down, but they're burning more tokens. So, yeah, hold it equilibrium. It seems >> we're always besting like I feel like the whole thing is is a little bit of a bet on the future. Hopefully, not in like a bubbly way, but it's like, okay, this is great now. like what's it going to be in a year or two? It's obviously going to be better. Um, so and it's going to be cheaper like to to your point like at least for the same level of intelligence, but it's usually just every iteration we decide we want more intelligence instead of cheaper. >> Yeah, it's true. It's true. Now, Andrew, you brought up, you know, running, you know, dozens of agents in the day. What about one thing that I feel like is still a bit unclear how the industry is going to work with this is having those agents interact with each other then and work together on a on a problem or know because I may you know have two agents working on the same codebase but they may not know what they're all doing. How you thinking about that? >> Yeah. Yeah. Well, okay. I think I think that's somewhat inevitable. Like even people in the 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. Um yeah, I think that's the extent of how we're thinking about it today. Um 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 pro you know engineers I find in my experience you know I don't often just think oh I need to do this and 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. So you know in the linear case too that's why we think some of this automatically running and screening issues for a good being a good candidate for cursor is much easier than saying you know change your workflow of the PM engineer designer whoever to you know run cursor on five things and go review five things >> for sure if our attention spans get shorter and shorter we may just >> well I I I have another theory which is like that 22-year-old engineers have a big leg up because you know they've had their attention span like eaten away at by Tik Tok and Instagram everything else. So, it should feel familiar to run, you know, agent after agent and then kind of click between them. >> You you say that like it's a good thing. >> Yeah. I'm not sure yet. The jury will be out. >> judge the younger generation, you know. >> We we'll like at least on linear side, we can try and help with this a little bit. We try and like, you know, we have the the inbox and once you've started a bunch of agents, we'll kind of like surface which ones need attention. Um, so you can kind of go and keep things quite asynchronous. Um, but send a bunch of things off, come back later and go through them uh when you have time is often like a really nice way to work on things. Um from the multi- aent 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 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 Devon will um has an integration that their their entire integration is trying to make sure that an issue is really well speced. So you have like one agent specking the issue, one agent researching the bug, one agent doing the work, one we already have like code review agents which are uh one of the most useful agents out there today in my opinion. Um I've certainly seen them save some terrible bugs from going out the door um personally. So I don't know. I think you guys have seen good growth on on that too, right Cursor? >> Yeah. So, we have a code review product uh called Bugbot that definitely has gotten a lot of adoption and I think it's so helpful internally and I've seen some rumblings on code review from linear Twitter. So, I'm curious how you're you're thinking about that side of things or maybe it's too early to say, >> but that that is u it comes up when I talk to to CTO's a lot. That's that's what they want. That's that's kind of a bottleneck. And as we create more code, we need more tools to review that code, right? So it's kind of pretty straightforward that >> that's an area where these models are really good at too. So sense to to invest there. What else? I >> All right. Fire New York. What can I say? >> There you go. Now I've been waiting for somebody to knock on my hotel door here and trying to clean the rooms. That's just a matter. >> Oh no. >> Um, what was I going to ask you? Interface, the user interface. I asked Tom about this, but also for you, Andrew, like it feels like we're still maybe in the first phase of how we're interacting with all of these tools. Like what's what's next there? How are you thinking about the future of what that's going to look like interacting with these agents? >> Ah, it's a good question. I I think you know that change I mentioned on experimenting with a new layout inside cursor of going from a right sidebar agent which we're starting to see adopted in more products too like actually like the notion agent works this way now where you have kind of like your main work surface and then the sidebar is like kind of the AI pane um with cursor we're experimenting kind of moving that out of the right sidebar and making it more front and center and letting the agent kind of self-direct where you're looking so let it you know open files and you know instead of like you starting at a file and running an agent. It's like you're starting with the agent and then it you terminal as you need. That's a smaller piece of it. Um yeah, I think that I don't know that's probably the main thing we're thinking on the interface right now. And then I mentioned kind of like a more planning focus mode. So, I'm curious if we end up saying like the agents have gotten so good at these minimal tasks that where it's really going to help is like just coming up with a plan and maybe the plan actually lives in a markdown file or something that your team can share and reference and or you're kind of referencing in future chats. So I think that's kind of a little on the horizon of uh something and we already see that where and Tom you probably have engineers on your team who like enjoy making markdown files maybe with AI to kind of scope out a task and so we see that happen a lot and we're wondering if this is where the next uh way people are working with agents is going. I've done it myself. Suddenly speced out a feature fully and then go okay well >> yeah sometimes you don't I don't know I'm curious if it if like you know all this stuff is in between and then you just get the really really good models that are able to kind of come up with great plans without needing more specificity. But there are other times where like a short prompt just genuinely does not have enough specificity like adding a button or you know changing a setting or something where you genuinely kind of want the back and forth like the deep research style of follow up with four questions you know and then go and run off on a task. That may be another thing we're going to try or actually I think we are trying that. My my dream for the for the interface um is is really for things just to be even just far more connected and integrated than they are today. Like I I feel like you know you should be able to to seamlessly have conversations with these things in one context. Move it to to to to Linear. Move it to GitHub for the pull for the review process. And it and it should feel like you're interacting with the same entity. you know, it's it's keeping it's keeping the knowledge. It knows what you said over in Slack. Um, and now it feels still quite disjointed. And so I really hope that we can we can achieve that over time. Yeah, it's a theme too, right? That there's a lot of tooling we're still kind of figuring out to some degree in the back end of how these things are going to work together and how they're going to work themselves and interact with other tools, right? So that's still still early on. What else is top of mind for for both of you in this world of AI right now? What what are you most excited about even outside of your own product? >> No, you're only thinking about your own product. >> Yeah, you got me in my head. >> Any any advances? Any models you're playing with? any any >> the one thing we haven't talked about >> that like we which iron is kind of like ironic in a way is that like we actually don't have a linear agent um but we are kind of working on that right like as you say it's like oh yeah that's kind of a big missing gap there >> so I'm kind of excited for for that and how it changes how you interact with the product >> um and I see like to my point before like I see that as like the personification of linear in hopefully lots of different services Um, and yeah, like we're playing with that internally and it feels really nice and I'm I'm excited to get to get that on there. >> 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 compose with like the first version of tab autocomplete I really liked um yeah I think it's shocking that uh coding feels like it's jumping forward by you know light years every month and then um email still feels like relatively uh you know underserved with AI Yeah. Yeah. And Gmail, you still know it's a smart reply when it's got a exclamation mark at the end for no reason whatsoever. >> I'm guilty of using some of those too. And you know, notion mail, we we have a version of that that we built >> when. >> But yeah, that honestly that that's like a 2022 2023, you know, maybe 2024 high quality with some context stuff. It's not doesn't scratch the itch of like email agent that I still think >> could be done. >> You're hoping for. When when are the home assistants going to get any of this stuff? That's my question. That's what I'm excited about. Like how are we like three, four years into this and like Google Home is still as as dumb as it is. >> Well, it's it's supposed to get the Gemini update around this time, right? It's about to roll out and >> I'm ready for my personal assistant. Let's put it that way. >> Yeah. Same same. you know, with Apple being so far behind all of this. So, >> it feels it feels like the models are capable, but we it's just everything around it that has to happen. >> Yeah, at least Gemini should be able to turn on my lights. Th