5 Rules for Building AI Agents That Work in Production | Nan Yu & Jacob Shumway

Speaker A: The models are really smart, but we're just not using them enough. If you over prompt these things, you're more likely than not going to make it worse.

Speaker B: Give it as little instruction as possible. Give it the tools to load context. Don't give it context.

Speaker A: Here's all the context. Just figure out what the right thing is, write the issue, and work on it. Linear made the issue took six minutes, and then it gave us a, uh, PR that we clicked through. You have to really break down what is the actual workflow that your users want to do. Computers can do a lot of work for us, so let's get rid of all the work we don't want to do and give it to computers. All right.

Speaker C: Hey, everyone. Today I'm really excited to welcome Nan and Jacob from Linear Do a special episode. We're going to do a, uh, deep dive on how to build a production agent end to end and how it actually works. And we're going to use linear's own agent as an example to keep the discussion concrete and real. So welcome, guys.

Speaker A: Yeah, good to be here.

Speaker C: All right, so why don't we start at the super high level? Can you kind of demystify this whole agent thing? What does the explain, like, I'm fine. Version of what an agent is?

Speaker B: Yeah, sure. I, um, can answer that one. So at a high level, an agent is really just calling an LLM, um, in a loop. Um, normally when you call an LLM, um, you're going to give it one question, you're going to get one answer back. But we want agents to be really autonomous and be able to accomplish more complex tasks. So typically what you'll do is you'll define a goal, some milestone for the agent to hit, and you'll give it tools that allow it to build its own context and then just run it in a loop. Question, answer, question, answer. On each turn, it's going to call tools, pull context in, and eventually it's going to hit a point where it has enough information to consider the goal accomplished.

Speaker C: It'll.

Speaker B: It'll like, synthesize this final response and send it back.

Speaker C: Got it. Okay, that makes sense. Yeah, it's basically a, um, model using tools running on a loop. That's kind of. That's kind of like one line.

Speaker B: Yeah.

Speaker C: Okay, cool. Um, okay, then let's talk about the linear agent. Maybe now you can show us, like, the initial idea behind this thing and then, like, now what it's kind of evolving to.

Speaker A: Yeah, I think it's actually pretty interesting to expand on Jacob's answer a little bit, right? Because we asked the question and I think that that is the correct sort of technical definition. You ask an engineer, that's what they're going to say. Um, but I also think that when we talk about agents colloquially, we think of them as products. It's like a packaging of some sort of, uh, AI loop, plus some other stuff. And I think ultimately these things are like a bunch of different subsystems that are all interacting. And then there's like one facade. It could be a chat bot or something like that that kind of fronts all of it. So even if you think of the desktop agents people use, they have all sorts of stuff built into them, like schedulers, uh, and these other sort of side, uh, tertiary kind of features. They're all kind of part of the agent as a product too, right? So I think we also have to think about it from that perspective.

Speaker B: Perspective.

Speaker C: True, true. Yeah, yeah, true. Do you think about all this when you have the initial idea or like, what is your initial spec?

Speaker A: Yeah, yeah, sure. So I'll show you right now. I was working with Jacob the other day. I'm like, I dug this up. This is a memo I wrote. And if you look, it's like 2H20, uh, 25, right? So it's like not that long ago in human time, but in AI time. It's ancient history. Um, and I think on here you'll see there's a lot of focus that we had on like, computers can do a lot of work for us. So let's get rid of all the work we don't want to do and give it to computers.

Speaker C: Right?

Speaker A: Like that, that's like the central, sort of, central thesis of this thing. And uh, it's, you know, and we kind of structured this idea about, um, you know, before we really had this sort of technical idea in our head, we had this idea about like, there's some kind of triggering event and there's some context that happens and you have instructions and it kind of loops on actions and ends with some kind of result, right? So like we, we, we already had this sort of concept, but I think what we uh, were just. We weren't like, ambitious enough. We did, we didn't think it could do like, really interesting things. We're like, hey, let's give, you know, let's create this agent thing. We call it, you know, we gave it a really like, robotic name. It's like Robotic Program Manager with the idea, right? And we're just give it the boring stuff, right? And I think that. What, what, what's changed, right, about how we think about it today, right. Which, you know, we're in the second half of 2026, so it's literally just a year later, uh, is that we don't think of just giving it the boring stuff. Sure, you're going to give it the boring stuff. But also there's, it opens up a lot of like, the uh, creative possibilities. Right, where you can do it interactively and, uh, it could be a big force augmenter for like, interesting work. Right. Not just, not just the boring stuff.

Speaker C: I don't want to offend anyone, but I feel like, um, technical program manager is like one of the most boring jobs. Do you literally just like managing spreadsheets, trying to track tickets and stuff? Right. So this is what the agent started with. Right. But now it can do. Now it kind of serves multiple hats, kind of do end to end product development, right?

Speaker A: Yeah, yeah, exactly. And depending on what you use it for and the context that you kind of put into it, it can do all sorts of very creative things that we, at that point we just didn't even think was, uh, a reasonable thing to expect. Right. And things have moved very quickly.

Speaker C: So I'm really curious what your process is. So you wrote this Venmo backing, uh, third quarter, and then, uh, Jacob just built it in a couple days or what was the process? Yeah. What was the next step to actually build this thing, to prototype it or like play with it? Yeah.

Speaker A: Jacob, what was the first version of this that we actually built from here?

Speaker B: The first version was really prototypy. It was like we were calling the LLM from the front end directly and it was just flagged internal. And we, we gave it access. We have our command menu with all our actions, we gave access to those AS tools and we're just like, let's see what this can do. It was really hacky.

Speaker C: This episode is brought to you by Oceanz. I hired someone through Oceanz for podcast post production a few months back and can't imagine running the podcast without his help. He's proactive, picks up new tools fast and uses AI to compound everything that he ships. Oceans doesn't just place assistants, they place operators. The talent is AI fluent and delivers the same output as a senior year as hire at 3 to 5x less cost. They reject 99% of applicants. So the person who lands on your team is already operating from day one. If you're scaling and need marketing, ops, finance or EA help, I highly recommend giving Ocean a try. Check it out. @oceanstalent.com Peter now back to our episode. Right now it can publish code, it can manage tickets, ingest stuff. But what was some of the initial use cases that kind of popped out that you wanted to prioritize first?

Speaker B: I think it was simple things, I think creating issues like it's such a simple thing, but I think that was one that surfaced really early as useful actually writing documents, that sort of thing.

Speaker A: Yeah, I think one of the first like real um, use cases that we knew about that we knew people wanted to do was they would have uh, you know, this is again, this is like maybe even before everyone had uh, you know, automatic note takers for everything, right? Like people were still like handwriting notes and things like that. They were like, hey, I had, I wrote some notes on the sales call. They said a bunch of stuff. Can I just dump this in there and just extract out the issues that we need to build for this or the bugs that were reported or those

Speaker C: kinds of things, right?

Speaker A: So it was, that was the very basic operation that we're like, okay, let's get that. Because I know that's valuable. People have directly asked for that. That's something that we felt in our own workflows. So if we can get something working that can achieve that, that's uh, a reasonable starting point, right. For us. We didn't even know if it was going to be, uh, we're going to have a chat interface, right? There's some place to just dump a bunch of text. Maybe it's just a text field or something like that. And you just hit submit and it goes. So maybe it looks more like that. So I think it was very open ended when we first started, which is also why we don't have a super robust spec for it. We didn't go into this thinking that we knew exactly what we needed to build. We were just like, here's some experiments that some directions we could try and let's just do it.

Speaker C: Yeah, so you launch it on Slack or something for people to use internally.

Speaker A: Yeah. So the first production version of this we launched uh, sort of secretly, right. Without really telling anybody that, uh, because we already had a Slack integration and Slack, you could always mention bots, right? Everyone knows things like donut and things like that where it's all very procedural and they're like these different Slack bots. Uh, so you could mention linear before and it would give you like a form or something like that. And uh, we just silently hooked it up to this, right? We're just like, okay, we're just going to do it. Then if anyone discovers it by mentioning Linear, they can start talking with it and then they can do whatever they want. And uh, a lot of usages for it emerged that we didn't even expect. And that was, we sort of had the inkling that that's what would happen. Right. Is that people would do things and the obvious thing would uh, be something like, hey, Linear, make an issue. And then you would describe it in natural language and it would do it. But people started realizing that because they could read the context, they could just say something like linear, do the right thing or look at what we just did or just something extreme. You can be super lazy. People will be like, oh, I just say at linear and then upwards pointing finger emoji. Right. They do those kinds of things and then linear will just reason through what happened. I know how to create issues. It looks like there's some issues name. So I'm just going to make some issues and then tell the user that I did that. Right. This kind of behavior is actually very emergent and we didn't expect it to be able to do this.

Speaker C: Interesting. Okay, so just to understand, you built this thing and kind of get the model, you made the model aware of all the internal APIs that linear has or something stuff people can use the UI for, the model can also do and they just kind of let it loose for people to try.

Speaker A: Yeah, effectively. I think Jake, we could probably talk about like we tried certain techniques at first and then we sort of landed on the version of it that we have now.

Speaker B: We tried to give it essentially just like everything you can do in Linear, which is a lot of different actions, um, across all the different surface. And we ran into just like context issues and hallucination. Uh, we tried things like let's give it our GraphQL schema and see if it can write queries. And that didn't work really well. And we kind of ended up on a uh, skills type of setup where we give it the ability a tool essentially to load skills and then it, based on the request, it'll just load up the different skills that it needs. And that comes with a set of tools and instructions around that.

Speaker C: The skills are defined by you guys like a uh, create ticket skill or like, you know. Mhm.

Speaker B: Because we, we have opinions on how different things work. You know, if you're writing an issue, how do you think about setting a priority and how do you think about writing the description? And so we encode all of that in these skills.

Speaker C: Got it. Okay. That makes sense. Okay.

Speaker A: Yeah, I think that that's, you know, when you. When you have a native agent like this, right? Like, people talk a lot about, like, hey, they build a CLI or they build MCP or something like that, and it comes with a bunch of skills for how to use it. When you build a native agent, you can go buck wild with this, right? You could have hundreds of these things. And because you have dynamic loading and you have control over how everything works, like, you can have a very smooth and opinionated way of how it uses your app. And I think that this is one of the big advantages of having a native agent, right? It's like. It's like you can just treat it like a power user of that. There's no, uh, variance, right, in doing that. So I think that that's. That's where we ended up. And then, because it can just run a loop and decide what tool calls to make and stuff like that. All of this emergent behavior about just being super lazy, when you mention it, it'll just figure out the right thing to do. It just kind of came out.

Speaker C: Can you guys show us, uh, well, the product's pretty polished now, but can you guys show us some examples of tagging Linear in Slack in different channels and see what it does?

Speaker A: This is a conversation we just had. There's some behavior that I'm like, look, this looks a little weird. So here's the pattern. It's very natural. We have a conversation in Slack, and I'm, like, tagging our designer, Jan and Jacob, right? About maybe some suggestions about what we can do here. And we're trading ideas, right? It's not like we have some exact sense of what we want to do right now, right? Like, we're like, hey, like, this feels bad here. Maybe I'll try these things. And then, you know, designer, like, kind of gives his opinion here, and then I try to clarify, right? You were, like, kind of finding where, you know, where the actual problem is. Um, and Jacob, uh, raises, uh, an objection, and I'm like, look, we can just. Here's my way. I want to address that objection. So we're finding the truth, so to speak. And at the end of the day, the message is just like, just do it, right? Like, at linear issue for me, I want to hold on to it. And then now that linear can write code. Just. Just do a pass. Like, I'll take a look at what you did, right? Like, previously, it was just make an issue for me. But here's all the context. Just figure out what the right thing is. Like, we argued about a bunch of stuff. We ended up somewhere. So figure out what somewhere is and then write the issue now. Write the issue and work on it. So then Linear, uh, made the issue, There's a decision, and then, um, it's assignee as Jacob and it delegated to itself. Right. And then, uh, that was 18 minutes ago. It took six minutes. And then it gave us a PR that we can click through on. Right. So this was the whole sort of loop of, here's an idea. And then we talked about it and we figured out hopefully where we got to. And then LINEAR sussed it all out and then made a P.R.

Speaker C: interesting. Uh, and then now you can just go in here and play with it and see if it's actually a good idea or not, right?

Speaker A: Yeah, you can play with it and see if it's a good idea or not. And importantly, because it's part of, like, the LINEAR system, like, this is in Jacob's backlog. Like, it's in his status to do, right? So it's in his personal backlog. Like, he doesn't lose track of it. You know, if it was just stuck in Slack, it would just be like, you know, you would have more chats, and then all of a sudden you just lose track of it. And then, you know, you would kind of cross your fingers with search or hope that someone remembers it or something like that. Right. So, like, the actual tracking aspect of this still matters, right? Because you have it in an organized backlog that's in the right project and everything. So that's the ultimate result.

Speaker C: Right.

Speaker A: When you think about what is linear's goal? Its goal is to put a ticket in the right place and also accomplish the task.

Speaker C: Uh, maybe. This is actually kind of interesting. This is like an interesting product principle. So even though LINEAR actually did work, it's assigned to Jacob. Is it like a principle? Like every agent has to be tied to a human.

Speaker A: The vast majority of them are. Right. There's going to be situations where, um, it's really, you know, the system effectively invokes itself. Right. If, like, you know, if you're. If you instrumented like a datadog or something like that, there was an alarm that tripped and it threw a, you know, put a bug into the system and then LINEAR tried to solve it. Like, there's not. No one really touches it until the very end. So at that point, you're relying on the agent to figure out who should review the code.

Speaker C: Right.

Speaker A: It's all the way there. But this Is, you know, for something like this, like someone made a decision to like do this, right. In this case it was Jacob who's like, okay, cool, I think we have enough information now. Let's work on this. Right. So that way he has a handle to it and it's attributed to him.

Speaker C: Got it. Okay. What kind of information and context can this agent access? Uh, obviously all the tickets in Linear can read the Slack and stuff, or you can hook up to Gone and everything else.

Speaker A: Yeah. So this context was just from Slack, from this thread. Right. So it can read Slack. And I think a lot of the, a lot of the benefit comes from stitching all this together. Right? Like Slack by itself isn't enough. But if you combine Slack with the ability to read your code base, with the ability to read your project description and your other tickets and stuff like that, then all of a sudden you can do something. Because what could have happened here was, uh, we made the issue and said, oh, looks like I found someone else who actually did this already. Right. There's actually an open PR that exists in the system. It would have told us that that's what happened. Right. So because it has access to all that stuff, it doesn't just like, you know, bulldoze its way through this. It like it knows it's aware of everything else in the system.

Speaker C: Got it. Okay, so let's just go back to the early. Like when you stealth launched this agent in Slack, right. Like, so people probably started using it and started getting some feedback. The product was just like a simple basic prompt and some tools. That was the problem. Very complicated back then or is it pretty simple? How do you improve it?

Speaker B: Um, at that point was it technically had the ability to do a lot of different things, but it wasn't really good at it yet. I don't think we'd arrived on our skill architecture yet, which unlocked a lot of things. The, um, primary thing people were using it for was just creating issues. Um, so we actually optimized pretty heavily around that. We created a small little router and for 80% of these use case, we routed to a specific sub prompt that was just for creating issues. Like highly optimized for that. Um, so that's what most of our usage was in the really early days.

Speaker C: So the structure of the product was like just like a main prompt that maybe tells the agent what it can do and stuff and then it kind of routes to like sub prompts.

Speaker A: Right.

Speaker C: Is that it?

Speaker B: Yeah, yeah, yeah. Or there's a really small model that runs a router and that will send it to either this, like, big model main prompt that can do anything and has access to all these tools or these specific use cases, like creating an issue.

Speaker C: Oh, interesting. Okay, so there's a best practice saying that when you're prototyping an agent, you should use the best model available just to see what it's capable of. But it sounds like you guys actually use a mix of different models for different tasks.

Speaker B: We do, but I would say we follow that best practice for the most part. Uh, we tend to throw the biggest model on it until we know that it's working well. We build out some evals, we have a good idea of what success criteria looks like, and then you can start to optimize the model down because you have a really good framework in place to like, make sure it's still. Ideally, you want to use the smallest model for the job, right?

Speaker A: Yeah.

Speaker C: Because.

Speaker B: Yeah.

Speaker C: You want to save. Save money, right? You know? Yeah. Okay, so. So then, um, it's like very iterative. Like in the beginning, you probably don't have a ton of evals set up, like automated evals and stuff. Yeah, yeah, got it. Just to make this pretty concrete, like, uh, let's take the create a ticket thing, right? You probably have some evals for. Did you actually create a ticket or not? Or like, is the ticket useful? Or how do you evaluate how good it is?

Speaker B: Yeah, um, I mean, yeah, pretty much. We have evals. A lot of it comes from just iterating and using it. So a user will use it in a way that isn't as expected. We'll add that to our data set for our evals, and then they grow over time through that. Um, but we try to have a mix of like, objective and then more subjective measures.

Speaker C: Objective and. Okay, so objective is like, uh, deterministically do this thing or not.

Speaker B: Yeah, exactly. If the user says in progress, make sure it always adds the status in progress. That's really deterministic. And then there's more subjective of things. Like, did you structure the description in a. In a good way? Did you extract the. The right information that should be the title into the title field?

Speaker C: How do you evaluate? Like, is that like a yes, no thing or is it like a scoring.

Speaker B: Yeah, it's. It. It's LLM as a judge. So we'll.

Speaker A: We'll.

Speaker B: Yeah. Again, it's. We build out this data set over time. Then we just have a, A scoring type of LLM that's like, did this extract the right information? This is what it should be. Pretty Much.

Speaker C: And then, and then I don't know, I don't have time experience doing this stuff. But like I feel like you have to, you have this element of jug which sounds very fancy but you have to look at the judge and be like, hey, is this actually judging it correctly or not? It's actually pretty manual.

Speaker B: Yeah. And we actually try to use those less often for that reason. I think, I think evals are the most successful when you're ensuring consistency somewhere that consistency is in important but consistency is not always important for agents. They can have a lot of variance in how they respond to things. Um, and you really don't want to have too many evals around that because then it just false signals.

Speaker C: Okay, interesting. Okay, so you started with uh, creating Imagine tickets and then um, what are some other use cases that you decided to support before? I don't remember when the thing was first launched but like before the first launch.

Speaker A: So I think the way that you should think about this is like there's uh, because it's especially because it's like um, very purpose specific. There's like this power law of use cases, right. Like if you think about like what the purpose of linear is, it's like you're trying to structure uh, the intention of the, of the company, right. Like you have ideas, you have meetings, you have slack conversations, you have whatever, right. Discussions. And uh, at some point you make a decision and we're, you know, we were originally like a system of record to codify those decisions. So if you just look at the distribution, the vast majority of um, how people use linear, the agent is codified decisions. I had this free form conversation with a customer. They complained about a few things. Let's extract what those things are and figure out what to do with them. Or um, the thing that we demoed uh, or even hey, we changed our opinion about something, we had a big meeting about something, just pull the notes and we changed so many opinions about uh, the spec of this project or something like that. Just go and update all this so that all the marketers and stuff like that don't get false information. So those are the motions that are fairly common. But ultimately this is powered by Frontier LLMs, right? You can do anything that you want, right. And I've used different things like being an interview grader. We have like a document in one of our uh, teams that's like here's the criteria for you know, how we want to evaluate someone's like interview process or whatever it is. And because I have the granola mcp connected to my Linear Agent. Right. I can just be like, hey, that last interview I just had, can you just quickly give me a score on how we go against this rubric? Right. So I don't have to like read through all the notes and remember. And so it's like a starting point. So there's like a lot of things that you can uh, you can utilize it for as long as you have uh, the context somewhere.

Speaker C: Got it. Okay. When you guys launched Linear Agent, it wasn't like, uh, here's the use cases that actually pass all the evals. So let's focus on those use cases in the marketing. But like, I guess the user can do other things too if they want to because it's just like a LLM, right?

Speaker A: Is that kind of idea? I think the way to think about it is it's almost like what's the biggest problem in applied AI right now? Right? The biggest problem is not the agents aren't smart enough. Right. The problem is not the models are not advanced enough. The problem is, uh, there's like, you know, people talk about a capability overhang or like a capacity, uh, overhang or something like that, which is like the models are really smart, but we're just not using them enough. And so like where we're, all the evals that we have are focused on, they're focused on like, are you uh, almost like, you know, when the user says something they actually want to accomplish a task. Did you, did you figure that out? Right? Because you could, here's a, here's an opportunity. You can really help them accomplish something. Like, you know, or did you, did you understand that that's what they wanted you to do? Or like, were you a little bit too eager and you went on and did something like that was way too expensive and annoying when the user didn't want that.

Speaker C: Right.

Speaker A: Like, so, so we, we have things where, um, you know, for example in the Slack integration, when like you're having a conversation with the agent and you ask a follow up question and the agent thinks it can answer it, there's a whole internal process that goes through. Like I think I can answer this question. Should I interject? And so the evals are really focused around those kinds of ergonomic type of uh, moments.

Speaker C: And after the product is live or even during dogfooding, uh, is there some sort of feedback loop after the agent responds? I can do a thumbs up, the thumbs down or some feedback. So you can get constant feedback.

Speaker A: Yeah, totally. And that's been very useful. Right? A Lot of our evals are effectively derived from. From those moments where someone goes like this, behaved in a weird way or a stupid way, like, let me tell you why. And then. And then eventually that itself becomes an eval. Um, Jacob, you probably know like a couple of these, like the funnier earlier ones, right?

Speaker B: Yeah, yeah, we've had. We've had a ton of these. Like, we had. We had a user, like, call the agent dude once, and then the agent was like, okay, I'm not going to respond to you because that was like, you're not being formal with me. Um, so we've had a lot of interesting use cases where we've had to really just dial these things into a really narrow zone.

Speaker C: I feel like, um, you don't have to show the prompt, but I feel like when you write the prompts and the skills, you gotta be a little bit. Maybe it's more aligned around principles and how you should think versus. Hey, you should make sure that this is 140 characters long or very specific kind of. You don't want to restrict it too much, right? In terms of what it can do.

Speaker B: Yeah, totally. And you also just want to give it as little instruction as possible, to be honest. Give it the tools to load context. Don't give it context, I think is like a principle we found important.

Speaker C: Interesting. Because if you just give it too many instructions, I'll just like overfit on stuff or.

Speaker B: Yeah. And it may not need that. And then it may overemphasize on certain things that actually aren't important for that task. Um, they're just smart enough to get what they need if you give it a really good defined goal.

Speaker C: Oh, because they can just like do searches and stuff and figure out.

Speaker B: Yeah, give it tools to load skills. Give it tools to load guidance, you know, different things like that. And it can build its own content context.

Speaker C: Got it. Interesting. It's kind of funny, like, it's kind of. Because you probably get a bunch of feedback about the agent and then you probably have something the agent ingests the feedback and synthesizes. It's almost like the agent's improving itself.

Speaker A: Right.

Speaker C: It's like a loop.

Speaker A: Yeah.

Speaker B: We have a mechanism where the agent can report, um, essentially functionality it can't do. So if the user asks it to do something, it doesn't have a tool for it. It's going to call a tool and report that back to us. And then we auto ingest that into, you know, go check if there's already an issue for this. If so, add it there, if not create a new issue. So we have like a constantly streaming, nice set of issues coming in around what we can do.

Speaker C: Dude, do you remember like, offhand, like, what's the craziest thing the user, like a user asks agent to do crazy things.

Speaker B: I, I think in general, like, we're actually okay with the user asking, you know, as long as there's not like safety concerns or like that sort of thing, we're okay with. If you want the agent to write you a poem, that's fine. Let it write you a poem. So we, we give it quite a bit of freedom in that regard. Um, I think trying to lock it down too much can, can end up in a frustrating situation.

Speaker C: Got it. Okay.

Speaker A: I think when it comes to like, you know, the, the range of things that people ask Linear Agent to do, it's, it's interesting, right, because, because it's like explicitly like for work, right? It's associated with your, with your workspace and your, your development team and stuff like that. Like, people don't tend to go on wild adventures, but there are things which surprise us, right? Like, uh, a lot of people use it for translation, so they'll, they'll get feedback from customers or something like that in a language they don't speak and they'll just, they'll just straight up just ask it for translation or even set up an automation to be like if something ever, you know, we have, we have a lot of customers in France, so if we ever get a, ah, intercom ticket that comes in, in French, just translate it for me before you. When you file an issue against it or something like that. Right. So like, there's a lot of those sorts of creative, uh, sort of use cases that are very on topic, you know, but like, we never thought that that would be a thing that people would do necessarily. Right. Like that, that was, they didn't even cross our minds that that was uh, a possible, uh, a possible thing.

Speaker C: Got it. Okay. Yeah, yeah, yeah. I think just like put the product in people's hands and then they'll figure out like, new use cases will appear. They can figure out which part to improve. Yeah. All right, well, let me ask you some product questions about the agent then. So I think before, uh, Linear Agent came out, Linear was a platform for. You can tag cursor agent and some other agents on here.

Speaker A: Right.

Speaker C: What was the philosophy behind actually kind of going off and building your own agent?

Speaker A: Yeah, I think the, um, assigning issues to agents was kind of what you're referring to, right? And then you can mention them in comments and stuff like that. Uh, and I think that we wanted to be able to support the entire software development lifecycle end to end. Like ultimately that's what, you know, that's where we saw our own sort of expertise. Right. In terms of how we can have very good opinions that you can adopt for your team. Um, uh, and having intelligence and having an AI system, uh, there to take action was a way to actually uh, execute on those things. Right. Because before, if you think about the olden days, we would write guides, we'd write something, the linear method about how you ought to think about your software development process. And uh, so a lot of what we saw, uh, uh, with models, capabilities is basically the ability for us to be like, actually you don't just have to read it and then execute on this playbook that we're giving you. You can just have Linear itself execute the playbook. So I think ultimately that's where we saw so specific agents that we add to the system, they'll do parts of that, they'll write the code or maybe they'll do the root, uh, cause analysis or something like that for bug reports. Uh, but none of them really took the whole process end to end like we wanted to.

Speaker C: Yeah, that makes sense. I always think the AI handles the middle 80% and then humans in the first 10% and last 10%. And maybe we're almost at, or maybe we're already at a point where we can tell linear agent, here's some user problems, here's a high level idea of a solution. Go figure it out and then go put a PR up and then I'll review it even for bigger features.

Speaker A: Right? Yeah. I mean you're talking about, I've heard people say something like AI is um, not an end to end solution, it's a middle to middle solution. Right. It's kind of what you're, what you're talking about. And right now maybe humans handle the first 10%, last 10%, but at some point maybe it's the first 0.1% and the last touch. Right. It's like the middle, it's going to get bigger until it basically reaches the limits of the edges. So that's kind of what we're also seeing. Uh, we're assuming that that's going to happen. So we want to build a system that facilitates that.

Speaker C: I don't know. So Jacob, have you been following discourse around loops and goals and stuff like that? Are you doing all that stuff? Are you just letting it run?

Speaker B: Yeah, we're definitely experimenting with that internally. I mean there's definitely cost trade offs. You have to consider once you get into these long running agents. Um, but I think models are getting really close to where that's a really interesting thing.

Speaker C: Yeah. On one hand, like, not exactly like I said, if you upload the linear method in the markdown file and then the agent will actually read through it and actually try to follow it. Right. But on the other hand, I feel like it's so good at producing markdown files and all this stuff by itself and then usually it's pretty long. Sometimes I don't even read it anymore. Okay, you made a plan. Go for it. Just do it. And then I look at the final output and I'm really paranoid that it'll just end up as more and more agent, uh, produced markdown files end up in the repo and I don't read any of it. The whole report turns a slop.

Speaker A: Dude.

Speaker C: That's what happened.

Speaker A: Yeah. And I think as people use AI systems, they start feeling these things as well. And then a lot of times, well, you know, skill issue or something like that, they were like, well, you should just read your things. You should tell us not to produce slap. It's like, yes. But it comes back to the main problem of what are the defaults. And I think one of the opportunities we saw for introducing AI into linear as a system because there's an alternate way of the universe where we just say we have an mcp, uh, we have MCP server and they just use whatever to connect to linear and then that's it. Right. We don't have a native agent doing anything. Um, but I think having a native agent lets us, uh, imbue our opinions about what good product management looks like. And what it looks like is not producing endless markdown documents that are unreadable and full of extraneous detail. We can make some determinations about how the process ought to run in the best case.

Speaker C: I see that's a really good. Yeah, because if you just build an mcp, it's just a bunch of tools that people can use, then they might go off the rails. But the agent actually has a bunch of skills and instructions to kind of imbue linear's values and product process. Right?

Speaker A: Yeah, exactly.

Speaker C: That makes sense. Yeah. Cool. When did you guys decide this thing was ready to ship? Like Kari has high bar. Right. So when you guys and this thing, like people are using it for all kinds of stuff. So how did you decide if this thing is ready to go?

Speaker A: What Was it like from the engineering side, Jacob? I could talk about the product side, but what was the uh, what did it look like from the, from the back end?

Speaker B: Uh, it felt like we released it early, not too early, but I think we kind of leaned on the side of like, it's pretty good. Let's put it out there and get more data for how to improve it more. I think we could have worked on it internally forever, honestly, to make it perfect. Um, with something subjective like this, it's, it's harder to get to that like, perfect spot. And so I think we hit a point where like, we just need to ship it.

Speaker C: Yeah, got it. How about you? Not from the product side.

Speaker A: Yeah, I think from the product side, if you think about shipping products that have a ui, the UI effectively limits what you can do with it. It's like a very UI driven feature or whatever. And uh, so you can have some definition of quality that's based on eliminating everything that you didn't intend in the first place. I think for something like this, we had core hero use cases that were like, these are the things we're going to demo. These are the things we think are going to add a lot of value and they're a good first way for people to use the agent. Right. And if we make those rock solid, then the other stuff, it's like, look, there's going to be a variance in reliability and things like that. Because this is the nature of uh, this kind of tool and this kind of technology and we're okay with that. Right? But as long as the hot paths, uh, that we're advocating for are, you know, are solid and we believe in them, then I think that that's the bar for quality that we're looking at.

Speaker C: Okay. The stuff like, you know, like creative ticket, manage ticket, creative pr, like that kind of stuff like that, you highlight the market, marketing. As long as those are good.

Speaker A: Yeah, yeah, exactly. Because those are things that are like, like those are, you know, those have, those are in the warranty, so to speak. Right?

Speaker C: Yeah, got it. Okay, that makes sense. Okay, so I guess just to like kind of wrap up a little bit. I'm sure a lot of companies are thinking through this right now. Should they just build like an MCP or should they build a native agent or like, you know, if you build all this stuff, then people don't even use your website anymore. Then like, what do you do? Like, do you have any advice for, uh, builders or companies or think about whether to even build their own agent or not?

Speaker A: Yeah, I mean my advice is like you have to really break down what is the actual workflow that your users uh, want uh, to do, right? Like and a lot of times it's like super multi step, right? Like no one like sits down at their desk and one shots their whole job. M. That's not, that doesn't happen.

Speaker C: Right.

Speaker A: So it's an entire process that goes into end. And then where are the natural places where uh, you want to hook into that? Where it makes sense to uh, hook into that. And I think that that's really where um, like we said like linear agent of as a collection of subsystems, right. A lot of them are about figuring out where the right entry points are. Because the most obvious thing is like look, there's a, there's an in app chatbot. You can have a chatbot, right? And then people will point at that, be like oh, that's the agent. Like well that's, that's, that's one way to interact with the agent. It's necessary because if you want to do any kind of like follow ups or you want to do any sort of like multi turn processes, you have to have some surface to do that. But that's not where the entry points are. The entry points are in the discussion that you're having in Slack or in your meeting debrief or when you're writing a project update and you're trying to do the research. Right. Those are the, those are the on ramps to utilize the intelligence. So if you give people good on ramps, right. The sort of interactive chat, that's the follow up. Right. And that covers the long tail of things that people want to do. So I think that's what you kind of have to do um, for domain specific agents, right? Because otherwise you're dealing with this problem which is like why wouldn't I use quad or chatgpt or something like that for this uh, instead of your sort of native agent.

Speaker C: Yeah. I think an agent is almost like employee. And then employee doesn't only work in one app, right. You should talk to them from Slack or wherever you guys work.

Speaker A: Yeah, I think everyone's kind of moving that direction now, right. Especially with the latest releases, uh, that everyone's kind of putting out.

Speaker C: Do you think Kari has a tear when um, if everyone is using linear through the agent or the MCP instead of all the beautiful buttons and the UI that exists?

Speaker A: Honestly no, I don't think he minds at all. I think linear is also very um, naturally a multiplayer system. So different players are going to use it in different ways. We have, for example, a lot of, uh, customer support agents, people who are doing customer support will, um, use linear by escalating things out of Zendesk or Intercom. Right. And that's their entire linear surface usage. Um, there's some controls in the plugin in Intercom for the than to escalate and pick a template or describe the issue or whatever it is. Right. And that's it. That's their linear usage. But it's very valuable because that's the input stream for everyone else to actually do their work.

Speaker C: Yeah, that's a good point. Yeah. So I guess because Kyrie talks about being opinionated about the product. Right. But I guess you need to let people use it from whatever workflow or service they want. You can't be too opinionated.

Speaker A: Yeah, yeah, yeah. Exactly.

Speaker C: Yeah. Cool. All right, guys. Well, I mean, uh, I guess what's next for Linear AA agent? And we're people learn more about it.

Speaker A: Uh, what's next is, you know, I think we're definitely introducing some aspects of proactivity and sort of longer running memory. Right. Those are the two areas that we're really kind of focused on. Um, if you think about like, ah, let's say you're building like a project at your company and that project can last. It could be a very short project over in a few days, or it could like last a whole quarter. And, you know, the agent should be very well aware of everything that happened throughout the lifetime of that project and be able to kind of naturally push it forward. Right. There's a lot of different moments where you have to coordinate people, you have to make sure that documents are kept up to date and all those kinds of things. And that's where we want that to just be something you can take for granted. Yeah. Like I run a project in linear. I can take for granted that it's well run. Right. Like, that's the goal that we're looking for.

Speaker C: That makes sense. Yeah. Whenever I have like a long slack thread with an engineer and then they're like, okay, let's go up to the prd. I'm like, I'm just too lazy to update prd. I don't update prd. So, yeah, just being able to assign it to linear, that'll be super useful. Yeah. Cool. All right, guys, well, thanks so much, man. Thanks for giving us an inside look at how linear aging works. And, um, yeah, I wish you guys the best of luck. I think it's a very interesting problem to solve.

Speaker A: Thanks, Peter.

Speaker C: Thanks.