Escaping AI Slop: How Atlassian Gives AI Teammates Taste, Knowledge, & Workflows, w- Sherif Mansour

Hello and welcome back to The Cognitive Revolution. Today, in honor of this week's Gemini 3 release, I'm going to do something that I've only done once before, and that is read an intro essay exactly as it was drafted for me by AI. I've spoken many times about my intro essay workflow. For the last 2 years, going back to Claude 2, I've given the latest Claude model a collection of recent intro essays, plus the transcript of the current episode, and given it a short prompt. Something like, adopting the style, tone, voice, perspective, worldview, values, rhythm, and cadence embodied in the attached intro essays, write a new intro essay for the attached transcript. While I almost always edit its output extensively before recording, Claude has always done the best job of this. And to be honest, no other model from any other provider has come particularly close. That changed this week, though, in a notable way with Gemini 3. While I've not tested it broadly yet, the intro essay that follows immediately jumped out to me as one of the very best drafts I've ever received from an AI. And while there are a few things that I might have said or framed a bit differently, it's clear to me that this model gets me from my writing samples as much and probably more than any other model ever has.

So here goes.

Hello and welcome back to The Cognitive Revolution. Today, I'm excited to share a conversation that bridges the gap between the frontier of AI agents and the reality of enterprise software deployment at massive scale. My guest is Sharif Mansour, Head of AI at Atlassian. For those who might not know, Atlassian is a top 100 global tech company with a $40 billion market cap. And while they are perhaps best known for software development tools like Jira, I was surprised to learn that today the majority of their users are actually non-technical knowledge workers in departments like marketing, HR, and finance. This gives Sharif a unique vantage point. He's not just theorizing about how AI might change work. He is observing how millions of users are actually beginning to adopt AI teammates in the wild. We cover a tremendous amount of ground in this conversation, including Sharif's framework for avoiding AI slop, the generic low-value output that comes from unrefined usage, by injecting 3 specific ingredients. Taste, knowledge, and workflow. We cover the limitations of RAG in complex enterprise environments where permissions are granular and questions are broad, and how Atlassian uses a teamwork graph to answer queries like, what did my team work on last week, which vector search simply can't handle. We touch on the evolving relationship between AI and UI, including my theory that the best interface is no interface. But Sharif pushes back with a compelling historical analogy involving MS-DOS and the command line, arguing that while chat is the universal interface, it is often the worst interface for specific tasks. We also discuss Atlassian's recent acquisition of The Browser Company and the vision for a browser built specifically for the knowledge worker context. And finally, we debate the concept of the one-person unicorn, with Sharif offering a skeptical take, Based on the sheer complexity of business orchestration. I found this conversation particularly valuable because it moves beyond the hype of drop-in agents and gets to the nitty-gritty of process architecture. As Sharif notes, we are moving from a world where we humans are the doers of work to one where we are the architects of how the work gets done. Whether you're an AI engineer trying to solve memory and context window challenges, or a business leader trying to figure out how to actually get your team to adopt these tools, there is a lot of practical wisdom here. So please enjoy this deep dive into the future of the AI-enabled organization with Sharif Mansour, Head of AI at Atlassian.

Sharif Mansour, Head of AI at Atlassian, welcome to The Cognitive Revolution.

Thank you. Thanks for having me, Nathan.

I'm excited for this conversation, and I appreciate that we were able to arrange it, I believe, 16 time zones apart, maybe even 17 hours ahead. You are in Australia, where I'm here in Eastern time in the US. So it's amazing what technology can do. Speaking of technology, Atlassian, obviously a big technology company, but I think probably a good chunk of the audience doesn't have necessarily direct experience with it. So just as a quick introduction, I'll let you do a fuller introduction. $40 billion market cap company, one of the top 100 tech companies in the world by market cap. And that puts it ahead, by the way, of household names like eBay, Reddit, SoFi, and Expedia, but very focused historically and certainly in the, in the products that I've used on the software industry. So for those that maybe aren't from the software industry and don't have so much background with the company, You've been there 16 years. How would you introduce the company? And as we think about the AI future that we're stepping into, how would you describe Atlassian's positive vision for the AI future?

Yeah, that's a good question. Yeah, I've been here a long time. And certainly, actually, before joining Atlassian, I was a customer myself. And so I saw how it transformed. I used to work for a large telco in Australia. And I saw how the software changed how we work. So I would describe it pretty simply as we're a a product company that builds collaboration tools for teams, and we specialize in different kinds of teams. So historically, we were specializing for technical teams, specifically software and IT teams. And what do they do? You know, they plan projects, build software, deploy it. IT teams run service desks and help desks and provide a service internally. But today, the vast majority of our user base are similar types of work. So I call them people who run projects, been in just different departments, marketing projects, finance projects, et cetera, or people who provide a service to another team in the business. The procurement team inside a big organization provides a service to the rest of the business by helping review contracts or whatever it is. And so today, majority of our users are actually from non-technical departments, HR, finance, marketing, legal, and all that. And really just about helping these teams collaborate with each other To get work done. I guess the second part of your question, how does AI fit into it and all that? You know, we've got close to, I think we're 3.5 million users of our AI capabilities. I think what's the big shift we're seeing in the change in how teams collaborate is teams are now introducing their virtual teammates and bringing them to the team. And not just at the, I'm not talking about just the personal chat productivity level. It's about, you know, a team. working together to get a job done, adding a team agent in their context to help them move that work together in a collaborative fashion. So I think we're really big on seeing AI just as a new teammate that helps speed up the collaboration process that teams do, whether they be technical teams or non-technical teams working together.

When you talk about introducing new kinds of teammates, the AI teammate, that is obviously very, I think, like, a little bit ahead of the curve, or skating where the puck is going to be, so to speak, in the sense that I think everybody, including the frontier model companies, has this vision of the drop-in AI knowledge worker, something that you could just deploy with all the sort of benefits of software and inference, of the scalability, the copyability, pay for what you need. could be 24/7, or it could be 5 wide at a given time, but it can also be off when you don't need it. There's all these advantages, but there's also these sort of rough spots that mean that in some ways they don't quite live up to the same expectations that we have for a human teammate. How do you think about, first of all, maybe just what people most need to know about an AI teammate? Where have you seen it done well or not well? in implementation? And how do you think about anthropomorphising these things in the first place? Like, should people be mapping AI? Should they be starting from the idea of a human teammate and kind of creating a fork for their understanding of an AI teammate? Or are they so different that they should maybe start with a different base understanding and kind of allow that to evolve independently of their expectations for humans?

That's a good topic we are constantly wrestling with. We have this value inside Atlassian called Build with Heart and Balance, which is just really about trying to find the fine line in making a decision or balancing 2 trade-offs. I think most people would agree nobody wants to talk to something that feels incredibly robotic. And at the same time, I think most people would also agree that nobody wants to talk to something that tries too hard to be human and feels unauthentic. So it's like this weird balance of the two. You know, I was just speaking at an event last week and the topic was how much does authenticity matter when you're talking to an AI? And, and you have to kind of like pare the layers back behind that question, which is like, why is it, why does someone see authenticity as important and all the way back down? And one thing that comes across, especially with our business customers, is just the importance of trust, especially in a business context. Like if I ask you a question, I want you to be— reliable and give me something trustworthy. And so how do you achieve trust in a business context? For us, a lot of it's transparency. So if I give you an answer, I need to give you as many citations as possible. You know, our AI Rover, we spend— we have a whole team that's just dedicated to focusing on improving citations, for example, to make sure that the quality of the response is, you know, is factual and is pointing to the right sources. But applying it to the agents topic you brought up, the same token happens here, which is if I deploy an agent and put it in my workflow, I want to know how it works. I want to see its instruction. I want to see who created it. I want to understand what are the last 10 things it's done. So I think transparency is key there to help building up trust, which then helps build up authenticity, if that makes sense. But I do agree with you in that it is a fine line. Like, it's— we certainly Not sure I'm like, I'm on the boat of like, oh yeah, it should just feel like a human teammate. We're not suggesting that at all. It feels like a virtual teammate. And I think humans have an understanding of what a virtual teammate can be in a team context and how that would work. I think we want them to feel like collaborators with us. I think already at the personal productivity AI level, people are feeling like it's a personal collaborator. In the team level, it becomes more interesting because there's now a team dynamic here, right? So I always say every team in every company has like character. And I'm not talking about characters in like human personality character, but like there's a set of in-jokes they have and there's a way they show up to the office or virtual office. And there is types of language they use, voice and tone. And if you're a team serving customers in a bank, you have a very different character, team character, to a team that's working on a marketing campaign for a digital agency. for, I don't know, young youth or something. And so it is important for teams to apply some level of character to their virtual teammates. Otherwise, you have this weird blend of like, it just doesn't feel like it's part of our team, and or the complete opposite of like, I just feel like I'm talking to a robot and this is not useful. The other big benefit that teams get out of that is you probably, I'm sure most of your listeners have heard the phrase AI slop. Everywhere. My loose definition of AI slop, because some people say AI slop and they're referring to accuracy of responses and whatever. I think if I define AI slop as something like the output is technically correct, but it's, uh, its creativity is like lazy, like as in it's, yeah, everyone's getting similar results. Let's, you know, let's call that AI slop. Then how do we combat AI slop in a world where everyone has access to the same tools? We all have access to the same large language models, et cetera.

Yeah.

One of the biggest techniques to do that is to apply your team's character, your team's soul, if that makes sense. Like, what is it we stand for? What are we trying to do? How do we talk around here? How do we think creatively? What are the kinds of things we like and what don't we like? And you kind of, you know, you're effectively prompting your virtual teammate to try to speak to your team's language. And I think that's critical in teams just not getting standard. AI slop at AI. So there is this fine balance of not making it feel like a human, but also representing what the collective group of people are trying to do.

Yeah, I'm really glad you brought up the slop point, because I was finding myself very curious about that in preparing for this. I've done a lot of stuff to build AI features into products and done a lot of workflow automation and making things scale that didn't previously scale. But when reading about the work that you guys are doing to facilitate teamwork and, you know, brainstorming, collaboration, all that kind of stuff with AI, that was the big thing that came to mind for me. So I, I would love to dig a little deeper into how do you do it, I guess, maybe conceptually, but also into the techniques that you're using. Like when you, and I can imagine a lot of different approaches, right? But when I bring one of these virtual teammates onto my team, how much is on me as a customer to set it up? Do I write a brief or give them my employee handbook and say, this is how you're supposed to act? How much do you guys go into my data reservoir and look at the way we talk to each other and try to extract patterns from that and have the thing sort of— obviously, we know continual learning is not quite to the state that we think it ultimately probably will need to be for You know, the most powerful transformative agents everyone can envision. But we do have in-context learning. We do have the ability to go, you know, spelunk through the archives and kind of try to pick up on trends and turn that into a prompt. So how do you think about mechanically making all that happen?

Yeah, it's, it's a lot of layers. Maybe the first and foremost layer is like, you, to answer your first part of the question, there's a lot you get out of the box, but the reality, the real differentiator is applying your team's Taste, knowledge, and workflows. Well, I use those 3 ingredients. Taste, I think we've just talked about, which is just like if everyone's typing the same thing, how do you— what is your unique thing for your business or your team? You have to apply that. That literally just might be a lot of prompting or it might be a lot of context that you give it, but you're applying your taste and your opinion to how something should work. Otherwise, we'll end up with the same looking website and the same looking products and the same looking services. And humans just— that's just not gonna work in the long term. Knowledge is the second thing, which is just, that's where the customer comes in of, hey, I'm building an agent. What knowledge am I gonna, do I want it to either have access to or be trained on? And there's a nuanced difference between those 2 things. But, you know, often it's like, hey, here's my, I am, I'm the procurement team. One of our customers, it just does this a lot. I was talking to 'em the other day and they have a bunch of Confluence pages that have all the things they look out for when they review a, a, a new contract from a vendor. That is their organizational knowledge. They have that documented. They connect their SharePoint. It's got some additional information there as well, and they pull that in, and the agent has access to that knowledge. So the knowledge is the second big ingredient. And the third one's really just how they choose to deploy it in their business workflow. And they might put that into a very rigid workflow, like a Jira ticketing system, where they're just going to go, hey, when a new work item comes in, I want you to review the attached procurement contract and write your first draft response on it and then pass the work item to the human to review and to go back and forth with you to then make a proposal for how it should be. And so you kind of have that taste. I always say like those are the 3 ingredients you kind of need in any business. I wanna apply AI and you talk to a customer and you're like, what are you trying to do? And they're trying to think of a killer use case. And I was like, why don't you just stop by just telling me what you do today? Like pick a team, pick some tasks that the team does. What do they do? And you often find those 3 ingredients of like how they apply their taste to that AI, what knowledge they give it, and where they deploy it in a workflow, some automation tool, Jira or Confluence or whatever it is. It doesn't matter what it is. They just put it in a workflow and they kind of get the benefits there. So they really need those ingredients there. What we do with help is we give them obviously a lot of— we have a lot of investment in our search solution, and that's very important for AI in an enterprise context because everything's permissioned. So when you ask a question and I ask a question, we get 2, you know, Nathan gets very different results to Sharif because the data you have access to is totally different. So search in enterprise context becomes very important. Every percentage better our search engine gets, the better the results get. And the second big thing we have in our portfolio is we call it a teamwork graph, which is just a map of all the entities that a customer has that they've worked on. So they didn't, you know, we know their teams and their, their pull requests or their work items or their conference pages or their Trello board, boards or their ideas and how that connects to their Figma designs or their Google document proposal with the client or their, you know, Amplitude dashboard where they're tracking metrics. And we kind of had the relationship between all of those, which helps us give better results to the user.

Hey, we'll continue our interview in a moment after a word from our sponsors. So let's do maybe one double-click on each of these taste, knowledge, and and workflow levels. If I start with taste, I mean, what— I don't know if this is like something you guys keep a secret, if you know how much you want to share, but in my experience, I have found Claude has been the best at capturing my taste. And the main task that I always do that I kind of use as my own personal benchmark for this is writing the intro essay to this show, which listeners have heard me talk about many times. But basically, I have a big PDF with a bunch of previous essays. We'll take the transcript of this one, put those 2 in there with a relatively simple prompt. It's really the previous examples, of course, that are doing the bulk of the work, and ask it to follow those examples and write me something new. I find that Claude has always done the best job at that for me. Obviously, people's mileage varies. But how do you think about like guiding users through the context creation process? You know, that, that kind of thing I find very few people do. The only reason I did it was because I believed it would work. But, you know, if I didn't, it was kind of annoying to go back to 50 different documents. And I did that before I had an agent, you know, that I could potentially delegate it to. So I had to, you know, it took me however many minutes and it's like, is this worth my time? Well, I believed it would work. I think a lot of people don't even have the confidence that spending, you know, putting the elbow grease in to curate the context will pay off at all. And so they just don't do it. So I imagine you have to guide people or encourage, you know, nudge, maybe propose whatever ways for them to assemble that context. And then I'm really curious about what's working well for you, you know, and how do you evaluate that? Because it's this also, you know, when you get to something like taste, right, what makes it so valuable is also probably what makes it, I would think, very hard to subject to A standard eval. We've got—

Oh, totally.

You guys have so many customers, so many different taste profiles out there. How can this thing adapt to all those taste profiles? How can you even begin to get a handle on measuring that?

Oh, that's a really good question. But your, your example's a great one because you have a prompt and then you have your prior context that you've given it, which is effectively your art. Like it's how your voice and tone, how you think about things, how you write about these shows, et cetera. And so you've given it your taste in between those 2 things combined, which is a really good example. And you'll talk to customers that'll just do the prompt and just go, oh, well, it was okay. It wasn't that great. Like, it was just, you know, another thing. So I don't know how much is, in your example, how much is Claude, how much is— I do generally believe that all the models will level out and they already are kind of getting the same. To answer your question on how much do we need to nudge customers, a lot. But we do have some unique advantages. We're a bit fortunate here. For example, the more you use our— as you use our AI tool, most customers start with— you always give them like, I'm Egyptian, so I always think everything in pyramids. So like a little simple framework of like AI maturity, like bottom layer, most people just ask a question, get an AI for an answer, layer 1. Layer 2 is like, oh, hang on a second, AI can do some work for me. And they'll ask it to generate an artifact, like write a proposal for me, write the show notes for me, write the intro for me, et cetera. That's like the next big light bulb moment in most people's minds. And layer 3 is like, oh, hang on a second. In my team's context, I can take my knowledge and take my instruction and then package that in a repeatable workflow that will help me scale and give me either more ideas or improve the quality of something, improve the effectiveness of something or efficiency of something. At that bottom layer, when they start with just the question and answers, you'll get some customers that'll be wowed with us doing little work. And I'm always curious. I'm like, well, hang on a second, why? 'Cause you get some customers that get terrible results. And then I'm, you know, always tell me, why are you getting terrible results? The ones that happen to be using, for example, Revolut Chat, which is our chat tool in our products, we've got inbuilt personal memory. So over time we start to remember You know, for me, I like to write with a lot of emoji. That's just my writing style, as a very simple example. So every time I ask Rova to help me with some writing assistance, it often will prefix my headings with an emoji that best reflects that heading, stuff like that, right? So I'm now feeling it's more personalized because it's more applying my taste to that world. So that's the personal memory is one big thing that we kind of give customers who already happen to be using our products out of the box. The second big thing we get is, and this isn't talked about a lot, Nathan, in the world of AI, especially in the business context, our products are open by default. And I have to explain that a little bit. When you create a documentation space in Confluence or a Jira project or whatever it is, the default is open and you need to decide who you want to restrict it to. And we're trying to encourage transparency and freely flowing information. Now, in a business context, you'll always need very granular permissions so you can go, you know, as much as you like and control everything. But we have got over like 20 years of history of customers who have been open by default for many customers, right? Like who use our products, have been using it for a while. And so when they, when they're trying to apply taste and judgment and whatever in their AI, they're giving it some context, some documentation spaces, or they're pulling in some extra context. Turns out open by default is a huge advantage when working with AI. Well, let me give you 2, like a contrasting example. Imagine you joined a company tomorrow, you asked AI a question. In most companies where you don't have any open by default tools, you'll probably get very little or no results because you're a new startup. You have no access to the Word documents that were just created or the Google Drive, the Google documents that were just created, whatever. You just don't. Now, unless some IT admin's gone out of their way and changed the default permissions, which is super rare and very unlikely. When someone joins a company and they've got some open knowledge bases by default, all of a sudden they're getting questions answered that would have had to require them to message 50 people to work out the answer to the question, or at least they're getting pointers to the right person. So that new starter there comes with organizational and teamwork knowledge in an open environment. They get a much bigger advantage to joining a an organization where you haven't had that open by default. So just the long answer of saying, like, I think there's a lot of ways we can prefix and bootstrap that context for the customer to make that taste a little bit easier. But in saying all of this, it's only as good as what the user decides to write. Like, at the end of the day, if they're not writing their opinions and their taste and their instruction, whatever, AI can't magically guess that unless you're, again, you're using personal memory, which you are already writing a lot and all that stuff. So, It really comes back down to you have to put in effort to get outcome. And people always use the example of like, oh, 80% was okay, but then to get to the last 20%, it took me another 5, 6 hours. And that's true. Now, sorry, I'll take a long answer, but like to answer your evals question, like, so, so then how do we measure success of this? It's hard. It's like really hard because how one team uses, you know, we have a platform where anyone can create an agent and put in any business workflow. So you're like, What is success there? We have some pretty good signals of success. So you often have, did the user use the output of the agent? Was it successful? We always have thumbs up, thumbs down, and all that kind of stuff as well. And we also have a lot of more nuanced signals, like was there a lot of rephrasing required? You might ask the agent to do something, but you're kind of like, that's not really what I'm after. I'm gonna ask it again in a different way. Or you got that wrong, or that kind of stuff. So like there are other signals that give us that as well. But the reality is agent creators in a business, that, you know, you often take our tools and then apply it and then give it to their teams. They're the ones that are really in the best place to judge success for that. And they usually will give us feedback on which parts are systems, system things that we could improve, or they'll realize that these are things that are knowledge that I need to add or instruction that I need to add. And so it's, you know, either one of those 2 buckets.

Yeah, interesting. So it sounds like it's much more in terms of measurement, it's much more about Presumably you're doing small fraction tests and capturing all these actual feedback signals from users. But what I notably didn't hear there is like, we have a standard automated eval suite and we use an LLM as a judge. Maybe that's in there too, but it didn't sound like that's a huge driver of your confidence in what's working or not.

No, no, we have that. And so we use that to give an example. We have like 20 or 30 out-of-the-box agents that we ship. And so they run through the same system. It's our advantage to model as many domain-specific different examples as possible. But the reality is customers will, will create their own evals for the agents they create that are very verticalized in their use cases. You know, the example I gave you about the procurement contract, we could have an out-of-the-box example and our own evals and LLMs that judge, et cetera, which we do in some of those scenarios. But again, it's really only as good as what the customer sets up. So our agent framework lets people test the agent, see the responses, set up their own evals, that kind of thing, and run through that themselves. So it's important that, you know, as you deploy an agent into your— as you add a new teammate to your team, you define what success looks like for that teammate. Hey, welcome to the team. This is what I expect of you. You know, I think this is a good response. I think this is a bad response. I think that same thing still applies. That doesn't go away when you're trying to apply AI in your team's context.

Hey, we'll continue our interview in a moment after a word from our sponsors. I'd love to maybe get a little bit more into the weeds, a little more technical, if you will, on some of the structures that underlie all of this. Again, this is just such a timely subject, right, where everybody has kind of come to the realisation that we've got context window working memory, and then we've got this baked into the weights deep memory. And the huge question is, What sits between those 2 productively? And we've got RAG, of course, and we've got all kinds of different experiments and memory structures. Then we've got the idea that maybe context window can just scale to the point where it kind of solves the problem. And then there's like, maybe new architectures are needed for continual learning to really solve that problem in a more integrated way. What are you guys doing today? If I can get into my personal memory, is that just a list of observations? Is it something more complicated than that? And similarly, when we go to the knowledge structure that the agents are able to tap into, especially with all this knowledge and history that precedes them, are they using the same search affordances that Human users are using? Or has there been a thought that, like— because this is a theory that I have, is that I think a lot of times people want to put them into the same thing, and sometimes that's the right thing to do. But then other times it's like, a human user can only scroll through maybe the 10 blue links, but the LLM user might be able to handle 200 results. And maybe in processing a lot more, they can actually do, in the end, a better job.

Yeah, really good question. So personal memory, I see as just, you know, I just think it's a capability that everyone just ends up having over the large language models. What's unique here, or what's important to call out, is how easy and how organic is it for a user to populate personal memory? And so the phrase I use is, what user proximity is the person close to the AI to doing it? So for example, a coder coding is probably chatting to the AI all the time in their IDE. And so they're implicitly populating personal memory or explicitly as they do it. So they have very good workflow proximity in the coding use case. You know, for us, we have a collaboration documentation tool called Confluence. So as people are writing and using AI-assisted writing, they're implicitly and explicitly populating personal memory. Make it shorter. No, you're too formal here, et cetera. That kind of stuff that's happening organically. And that's really just at the individual user's preference. Then there's organizational memory. And I think there's a fork here in my mind of like 2 ways we can be effective with organizational memory. You've already touched RAG. RAG gets incredibly hard in an enterprise context because everything's permissioned, even at the field level. You know, with Rovo, you can pull in Salesforce and you can also pull in SharePoint and you could also pull in GitHub. You know, when I pick up a GitHub issue or a Salesforce record, I might be able to see some fields and you might not be able to see other fields. And so there's a very large investment of teams just trying to making sure it has a semantic index behind it and it's also permission aware and all that stuff. And it's as fast and performant as possible and all kinds of stuff. And that's the RAG technique. Then the other technique is really, we have what we call the teamwork graph, which is an understanding of all the users, the teams, their goals, and how the work relates to that. When I say the work, it could be the Figma design, the pull request in GitHub, the page in Notion, whatever it is they've got mapped out, and it maps them all out together. The way the teamwork graph works is both organically and inorganically. So example is Jira is often seen as a system of record in most organizations. When you used to get your app approved in the App Store, as an example, that goes through a ticketing system. And that's a system of record. You know, where is the app, where is it at? What are all the related documentation for this app? Who's reviewing it, et cetera? And typically systems of records don't track the work, don't actually capture the work being done. They track where the work is at and the links to the work. And so if you pick up a, you know, our billing example where the call center team is disputing a bill, Someone's called up to dispute a bill issue that goes through a ticket and the ticket captures the business workflow and all the linked objects related to that workflow that typically happens. And that's the Timo graph. So populated inorganically by customers just saying, hey, I want to connect GitHub and I want to connect Figma and I want to connect whatever it is to their, to Rovo, whatever it is. But it's also populated organically, which is as I use Confluence or Jira or Trello, whatever it is, I'm pasting links and I'm telling you that, you know, oh, okay, here's the related design for it, paste link, et cetera. So we can, as teams work in our products, we populate the graph and understand these nodes and the relationships between them. And so then when it comes to users building an agent or asking a question, there's sort of like, you know, 2 or even 3 paths if you count just the LLM's general knowledge. But let's put that aside for a sec. There are mostly 2 paths it goes when you say, Give me a status update about everything my team did last week. Now, when you break that down, that's a pretty loaded statement. So status update needs cut. What do you mean by status update? Probably might use its LLM general knowledge. Maybe in your organization, you've already got some documentation somewhere it has access to that says, this is how we define what a status update is, or this is where our status updates look like. Okay, so it'll probably use some of that. Well, my team did last week. My team. Okay, how does it know what your team is? There's implicit and explicit signals here. Now, we have a Teams construct in our portfolio. So a lot of millions of customers on a daily basis create squads in our system to group work together. And so we can traverse that. Okay, my team, you know, you, and there's the team relationship, and that team's connected to members in that team that week created these 5 Jira work items, these 4 Confluence pages, these 3 Figma designs, whatever it is. And it kind of traverses that tree. And so it could give you, you know, your blue links response. RAG would be a terrible solution to that problem because it would give you like the top 5 documents and then try to summarize the status of those. In scenarios where you might say, what is my team status update that week? The graph solution is a much better solution for that, where we want to traverse all the objects, give you the— summarize them, you know, et cetera, apply the organizational context. But in scenarios where you might like, What's the process for taking annual leave in my company? RAG's probably a much better solution there if you don't traverse the graph for that. So that, you know, I think really good AI in a business context kind of needs both of a RAG set of techniques, but also a way to traverse very structured information at a much bigger scale.

Yeah, that's great. I, that really reminds me a lot of a project that I studied a while back called HippoRAG, which we did a full episode on. This is maybe the closest thing that I've heard of in the wild to an implementation of that, where you've got on-the-fly or maybe background processing entity recognition. It sounds like if I'm just randomly putting in links, you've got the job to do of figuring out like, what is this in the first place? Those, you know, you've got a lot of different instances where an entity will pop up. So you gotta, you gotta do that disambiguation or reconciliation. Then the process in the background of mapping out all these connections as well. And then when it comes to runtime, what they were doing was pretty still early. It was a research project back in the HippoRAG days, but they would sort of identify through semantic search, like, what are the entities that are relevant? And you may even, in the case of my team, that might just be fully explicit. But then they expanded the search radius through the graph. Like you could expand it one node out or 2 nodes out or 3 nodes out, and then that became the universe in which you would do your semantic matching.

Like if you have that, I always thought that was pretty inspired. Yeah, you can have those single multi-hop travels through there. I think the other thing you overlay on top of that, which gets even better, again, if you happen to be a vendor, again, we're fortunate here like us where we're capturing some collaboration graph as well. So we have a separate graph, which is kind of the collaboration signal. So When Nathan likes my pages or comments on my issues or etc., that could also be used as a weighting depending on your query to lean into some nodes in the graph over other nodes, especially when it comes to understanding people and work relationships. So you would layer any user activity signals of collaboration who worked as well. I shared a page with you, etc. You viewed this content but haven't viewed this other content, so therefore. We're more likely to show you that, I don't know, depending on your query, the content you hadn't viewed if you're asking for something like that. So you, an additional layer you can add on top of that is just those collaboration signals. If you, if you can, it makes a huge difference to the results.

Yeah, that's cool. How do you think about, it might be too early for this, but one thing I've occasionally noticed in products is sometimes they need to forget as well as remember. If you took my whole work history, right, you would find that in certain eras, I've collaborated very closely with certain people. And in some cases, those people are no longer at the company. In other cases, they still are, but we're not collaborating as closely as we used to be, whatever. Most folks who've rushed out to build any sort of AI memory system retrieval or whatever, however far they've got, they've mostly just tried to get it to work for right now. And there hasn't been much thought about how does this evolve over time, as everything always does? How do we kind of know when to let go of things? Maybe you could get by by just sort of saying, last interaction with this person was whatever, then let the model handle it at runtime. But I suspect that there's a lot more. I certainly know that my brain is constantly clearing stuff out to make space. So wondering, you know, what thought you've put into, you know, allowing the system to evolve, to let go of things that it no longer needs as much.

Yeah, particularly hard for organizations. Again, open by default actually makes this more challenging. So you could argue it makes it better in some ways, but also makes it more challenging because now you're now getting 20 years of content. And who knows if that, like, that page 19 years ago is still relevant or not, etc. So I think that's even particularly challenging. But also, you know, there's also It's like classic pick any use case and there's probably a pro case and a con case for those. The 2 most obvious, I actually ran into this in the early days of Rovo. I remember doing some testing and we were playing some things and I asked it something about rewriting my, like we were kind of having a new team charter set and I said rewrite my team's charter using my goals. And we have like a goals app and you can track goals, et cetera, and, you know, OKRs and all that stuff. And it picked up a goal I had from like 4 or 5 years ago in the early days. And I'm like, wait, where did you get this from? And I'm like, I haven't worked on that for ages. And you know, that's a really good example there. And the goal was still active. So I hadn't cleaned up the data to mark it as inactive. And so it's just assumed that was the case. Now, since then, we have done a bunch of signals, just use that as an example, touched on user activity and collaboration activity being a key one. That comes up a lot there. So there's a lot of decay on content that might be older that you may or may not have collaborated on, depending on the context query you might ask for as well. But it also highlights the importance of ensuring that the data you connect is useful to some degree. You know, I had a customer the other day, I'm gonna connect all my SharePoint to Rovo. And I'm like, sure, go ahead. But I was like, how big is your SharePoint? It's like some ridiculous, like 1 terabyte.

I'm like, Do you even need that?

He's like, I don't know. You know? So you're like, okay, you could, and it'll decay as, you know, we'll try to decay and create gravity over time depending on what it is. But it does highlight the whole garbage in, garbage out, like, kind of motto. There are ways in the system where we try to decay things based on time-based activity, your interactions with the objects, et cetera. There's also the true definition of the object in the system. You know, in this case, I had a goal that was still active that I hadn't touched for a while. Probably should have just gone and archived it and I didn't as an example. So there's a mix of we try to do stuff, but also I think as customers connect data to different systems, it is something for them to think about, which is, does the system you're connected to, does it have any ways to decay history? Decay history, is that even the right word? You know what I mean? Fade, create some gravity over time for old stuff, but also know when to pull it in if that's the right stuff. So I think that's an important aspect for folks to think about as they They pick their AI solution.

Yeah.

When it comes to kind of brute forcing this stuff and just being willing to pay for compute to do it versus trying to be more efficient, and obviously efficiency and latency relate too, but if you're willing to pay, you can also do a lot of this stuff in the background. How do you guys think about my starting position? I used to always say, Use the best model available, don't worry about cost, maximise performance, and optimise cost and latency from there. And I think that was pretty good guidance for a while. Now, though, maybe not. I don't think you want to use GPT-5 Pro for everything, if only because of latency, right? So it's like, I think we do now have models that are, for many use cases, like, overpowered. And that wasn't the case when I developed that guidance. I guess, how do you think about the overall optimisation problem of cost, latency, performance, other intangibles that are maybe also worth considering? I assume that that's something that has to start at kind of a value level, but then obviously gets operationalised in detailed ways too.

Yeah, I could probably answer that in 2 different ways. There is the What we do internally as teams build AI features in our products, and then what, how that applies for customer application and customer thinking, if that's useful. Internally, very similar to you, especially in the early days, just find fit. Like, your priority is just make sure the thing's useful. If you are spending more time trying to optimize the cost, and even in a, you can manage costs with controlled rollouts and all that kind of stuff, and you haven't even found fit, it's the wrong, you know, I always say, You know, the riskiest assumptions test, the RAT test, like start with your riskiest assumptions first and do whatever you can to debunk that and then move to your next one and move to your next one. And so most of it's like, is this thing, is the feature I'm building valuable? Go ahead, like test it with customers and whatever. So we are a bit more liberal in that process. Go ahead and do whatever you need. I will say, as we've— Yeah, I couldn't even count the number of AI features we have now in our portfolio. It's kind of rewriting the whole app, assuming AI is now always on at some point. Probably over, well over 70, 80 things across my main apps. The, there are some clear patterns that we've learned for time and time again, where you're like, you know, you don't need this. So the way we solve this internally is when teams need to build an AI feature, they'll often, they get complete free rein in the early days in discovery process. At some point, they will talk to our ML team. We have an AI gateway and we have a mix of locally hosted models. Models in the cloud. There's like a ridiculous amount of models in the AI Gateway, which is a proxy so we can swap models and test different things out. And depending on the use case, we'll probably take those workloads, those AI workloads, and run them locally on an open-source model, or depending on what it is that it's doing. You know, a simple summarization feature no longer requires every single bell and whistle in the world. We'll probably offload those workloads locally. The more complicated ones would go to a more sophisticated model. Depending on what it is. So they go through that process at the tail end of their discovery process or whatever that applies there. The good thing for us, it means that more and more of these, I guess, AI, the cost keeps going down and we keep passing that value to customers, which is good. And it's good for us that way. It also means that teams can keep learning as quickly as possible and that doesn't slow them down too much. Now, when customers apply AI in their workflows, so that's probably the biggest thing I see, the explosion of token usage, whether they're using Rovo Dev for coding or they're actually adding an AI agent in a Jira workflow, which is probably the biggest or fastest growing use case of agents in deployment. They just go to their existing workflows. They've already got millions of workflows in Jira and they're like, hey, an agent can help here, an agent can help here. This step here is really just triaging the ticket coming in. An agent could probably do that if we gave it good instructions. And they just go and just orchestrate a bunch of agents in a business workflow. That one is fascinating because you'll get customers that will probably will overuse AI when they don't need to. To give you a very simple example, imagine a ticket comes in and you're reviewing the legal contracts or whatever are coming in. There are ways where our orchestration framework, automation orchestration framework, lets you do some strong, more deterministic comparison of content of what's in the ticket. For example, There's like some string manipulation functions. You can inspect the contents of it. You can say if the Jira ticket has these words in it, then do that. Now, using the out-of-the-box automation nodes that help you build these Lego pieces is a very effective and cost-efficient way to do that. Now, some customers will be like, oh, I'm just going to switch that to an AI. And you're like, okay, cool. That can also get you the same outcome. But geez, the compute and the tokens on that, it's just like, it's not worth it. Like you're using A customer described it to me once as like, I realized after putting this in this workflow, what was her phrase? She said it was like, I've got a rocket launcher and I'm swatting mosquitoes with it. And I was like, yeah, that's probably not a good use of AI there. And so they'll use the more deterministic functions in our orchestration framework that let you do like specific string manipulation or comparison or whatever it is. That's a way better solution there. So from a customer's lens, there is some skills to be learned on building tailored agents and deployment workflows. Is when do you need an agent and when is a large language model appropriate and organizational knowledge appropriate? Or when could you do something a bit more deterministic on the functional side that is much cheaper to execute and run, also more effective from performance perspective as well because it, it only does one job, right? And so that's a skill. that I'm finding many, many organizations are learning as they're deploying these agents. Now, we try to help them with tips and tricks and techniques and content, but I see that as an ongoing journey for a while for a lot of people, because you're like, I could solve everything with AI, and you're like, you don't need AI for that one. That one's just like a simple, just check the contents of, I don't know, some string value and do that and you're done. Yeah.

It's another one of my mantras is anything that can be done with traditional code should probably be done with traditional code, it'll be faster, cheaper, more reliable. Though, even things as simple as like writing a regular expression, you know, nothing makes me feel stupider than writing a regular expression. So it is sometimes tempting to just be like, okay, just have the AI, or the right way to go there is to have the AI write the regular expression for you. But sometimes it's tempting to just, you know, have it do all the work itself.

But that, but on that example real quick, like we do, so our agent framework lets people create skills that the agent have. The skills can be no-code or code skills. And that's just a really good example where you can make sure the agent calls a very deterministic skill, like a function to do math or check the bill details or whatever. And that's very specific and bespoke to the business. So someone writes some Java code or whatever it is they want, and they cook that as a skill for the agent, put that in a business context, and off you go. But it takes— it's a process of discovery for customers. I think people start and go, oh, this is amazing. They're like, wait, sometimes it didn't gimme the right results. But I, you know, in this specific scenario, I wanted to follow this exact 2 steps. And you're like, you're right, Nathan, that's probably better written in code, depending on what it is they're trying to do.

I don't know how specific you want to be in your response to this, but could you give us a breakdown of how many tokens on a relative basis are flowing to which different kinds of models? Like, where are you using proprietary? If you wanted to name brands, I'd certainly be interested to hear that breakdown. So interested in your take and maybe what your customers are signaling to you also that they care about when it comes to what different kinds of models are, you know, from trusted enough sources to be used or not?

Look, I don't, I'm actually just pulling up the dashboard to give you a, like, it's in the ridiculous millions, probably billion. I have no idea tokens. It's a ridiculous number. I remember we used to have a dashboard with all the tokens consumed and created. It's, it's kind of pointless now. But on the model thing, I am seeing a huge trend from a year and a half ago, 2 years ago. I wanna pick the model. I wanna pick the model. I wanna pick the model to now, like, like the care factor just, it's like, oh, I realize it's like me saying, I want you to use Postgres, not MySQL. That's the case. I mean, all the big expected ChatGPTs there, Claude, Anthropic's there, all that stuff. So I couldn't go into details of all the, I'll probably get it completely wrong. But name the model, we're probably using some variant of it in some way. We have a fair bit of transparency with our main AI features. They— we publish docs on what the feature is, what model it uses, et cetera, as well for the big items. But everything from GPT, Claude, Mistral, like it's a mix, a mix of stuff. It's a lot to do that. But honestly, maybe the takeaway that I think I have for software vendors or software teams, I always say is It does pay off to build a model gateway or have a solution where you can proxy models. Because if you believe that that layer is being commoditized and there's lots of them and choose the right tool for the job, then to help you move the fastest, you therefore need to find a way to learn, switch, work out the best use case and cost optimization and do that way. So that's certainly something I would recommend to anyone building software. It's paid off Orders of magnitude. Yeah.

So you're on the models will be commoditized side of the will models be commoditized debate.

Little asterisk there. The general purpose models for most general purpose use cases, yes. And I can see the total use case for verticalization of models, like a DNA sequencing model that is just trained in some health— for healthcare purposes on that kind of stuff. I could totally see that. I just think the average knowledge worker that most of our customers, sitting on a desk using content to create content, or like, you know, in finance department, HR department, marketing, customer success, whatever it is, the general purpose models are 80, 90% easily solving the problem. And we're seeing that desire for model selection just decline over time, which has been pretty good. You will see, but there is a little nuance here is important, which is like for those building agents, that are setting up their own testing and evals, whatever, model stability is important for them, right? So it's like API stability, right? Like, if you swap the bottle overnight, you're probably going to get a ton of different results. So that's a little slightly different scenario, but an important thing for people to consider as they're thinking about that.

I've got a few questions on the future of software and also the future of work. Sometimes I ask myself, why do we build UIs? And the answer I came up with is we build UIs because we need input from the user. We need access to the user's intelligence or taste, as you noted, judgment. There's something that only the user of the software can provide that the software can't continue to do its job without. And so I sort of see these UIs as kind of, if it didn't need anything from the user, then the software in general would run really fast. And it's this sort of moment where, okay, we have a stop because we need something from the human. That is when a UI ends up getting created and presented to someone. I sort of think for people that are trying to— who have software products and they're trying to figure out how to use their AI layer, then I think, well, the AI can in many cases be sort of a substitute for the human that would otherwise use your software. And one kind of true north goal is like software you don't have to use as much as possible. People are mostly not waking up in the morning super excited to use whatever SaaS tools they're going to use throughout the day. It's obviously, in most cases, a means to an end. So if you can start to abstract those UIs into tasks for the AI to do, and sometimes maybe you bundle them or kind of redraw the borders around them for who knows what various reasons. That seems like a good mental model for people that are trying to figure out how to bring an AI layer to their software product. But beat that up for me. How would you critique that? How do you think about it differently?

It is such a good topic. We spent hours talking about this. Hours, probably days, weeks. I love to look at history, tech history, and try to find parallels. Now, Nuances are important because some parallels don't apply and some do, et cetera. But if I could rewind back to maybe some of your more mature listeners to the MS-DOS terminal days and back before Windows existed, for those of us that remember, the terminal, DOS or whatever, or Mac terminal, whatever, was the universal interface to the operating system. It was how you interacted with the operating system. It's how you got stuff done. You could do maths, you could type a Word document, you could, you could draw ASCII art if you wanted to, et cetera. But we learned very quickly that it was actually the worst interface for some use cases. And so over the years, we built verticalized apps on top of the terminal to do word processing, image generation, Spreadsheets, audio, podcast recording, et cetera. This is a— we are now, me and you, Nathan, we're talking in a dedicated interface that's built on top of the operating system, on top of the browser, on top of the browser and on top of the operating system that solves this problem. But it's all— the universal interface is still just commands in a terminal with some high-order level of programming language on top of it. Apply that to AI. I always go with the phrase of like, well, what's the universal interface to any large language model? It's conversation. That's what it is. That's how it works today. That's how the models were designed. The transformer model, that was like the big aha moment. We can predict the next thing. So let's go. Conversational UI is the best way to kind of get it predicting the next thing. Our UI construct for conversation is chat. It's just like society and history. It's chat for everything. I do believe, and I would argue, I think we're already seeing it, that chat is not the universal interface to all AI. I think what we'll see is a spike in a lot of crazy amount of chat usage as the primary way to do anything in UI. And over time, as we start building verticalized and more specialist solutions, which is still humans interacting with AIs, they'll be in dedicated experiences on top of chat. Doesn't mean chat will go away. It just means chat— like, I use terminal less and less every day. I don't code anymore, but every now and then I'll open it up to do something. But most of the time I have a dedicated experience that's far superior for me to solve my particular problem to do that, et cetera. So I think the same thing will happen with AI. The example I like to tell teams at Atlassian that are building any, building an AI feature for any of our apps, I always say, what's your AI feature? I bet you 9 times out of 10, you could build the poor man's version of it in a prompt without the UX on top of it. Is that true? And they would, they would be like, actually, yeah, we could. We could just, prompt our way through this, but we can't expect users to type these crazy prompts every time, or we can't get the data in a more structured way and whatever. But you can almost fake any AI feature out in any product through prompting. It's the worst experience for it. And so then you run into this, okay, so if that's the right conclusion, then I reach the conclusion that we're gonna build specialist interfaces on top of that. Then the second thing people often say is, ah, okay, well, but AI will dynamically generate a specialist interface all the time. I don't believe yes or no. Again, nuance is important here. Like, for form input, yeah, potentially, but it has to be a pretty predictable form input. Like, you try filling out a form via a chat interface, it's a disaster. Like, it's still— how do you do form validation, conditional form fields, except like there's a ton of issues there. Now, could AI dynamically generate something every time? Oh, it can, and it probably will over time. Will humans want an interface that keeps changing? No. I think history has told me that as humans interact with software, they want some level of predictability in— there is some variance in how they learn the tool and how they use it. So I do believe that there'll be lots of specialized user experiences built on top of AI that will all effectively be a conversational backend, like user Conversational API backend, because that's the interface to these large language models, but it'll be in a dedicated interface. The example I used last week was my son loves making vibing games and stuff, and he's been geeking out with Leonardo AI. Like, I don't know if you've played with that or not, but you, yeah, to build, to build image sprites for games, to make little characters, predictable characters, and these little tower defense game and stuff and all that. Could you ChatGPT that in a terminal and a chat interface? Totally. Is that the worst interface for doing that? dedicated, predictable UI graphics of slight variants and different sizes and what— yeah, it's terrible. Like, you would rather someone who's thought about the problem deeply design an experience that is still AI native, but it's really around building base-level UI constructs with slight variances. You know, the character moves their hand here or carries another weapon or, you know, whatever it is they're doing. And it's a fairly sophisticated interface, but it's designed For, it's a good example of a vertical user interface that's built just for AI. Long answer of, of saying the chat is the universal interface, but it's the worst interface in the long term. And I do think that the, uh, humans will always be interacting with specialized software on top of that. It's not saying that some of the software won't just, you, you don't need anymore. You can now use it in chat. I think that will happen in all things, but I just think like everything, it's a soft— like we just end up creating more and more software. The explosion of software is only increased with the cloud, and it's even increasing even more with SaaS. So people are just creating better interfaces. And so this is where, like, you end up in this world where design matters, and design ends up being a huge differentiator in any AI future where everyone has access to all the tools.

I wrestle with this question on software, the explosion of software, you know, are we going to see a proliferation of SaaS? So obviously, there's a lot of different reasons people build success software. I think one pretty common one, and I think this sort of applies, I think I've even heard you say that it sort of applies to some of Atlassian's core products, is that the software encodes a way of working that is known to be effective. And so for something like Jira, it's like, yes, it sort of Does these like functional things of it, you know, takes information, it stores information, allows you to search, whatever. But what made that really transformative for so many teams was it kind of guided them to work a different way than they had been working before, right? Instead of the old waterfall model, they were actually able to do agile because the tools they were using were sort of set up for it and naturally steered them in that direction. And so it kind of created habits, reinforced habits, all these sorts of things. If that is right, I wonder, like, to what degree does AI change that? Potentially a lot. When you first apply AI, you think, okay, I have this task of triaging tickets. You know, what are the inputs? What are the outputs? How do we make this decision? Let's get all the examples. You know, let's eval it. Let's do all this stuff. Great. Okay, now we've got an AI that can— triage a ticket. But then, you know, the next level up obviously is like, if we're using AI to answer the tickets, do we even need to triage the tickets? You know, maybe we just answer them all immediately as they come in, right? We don't necessarily need to have that step at all. So we could sort of do the Elon Musk thing of like, best part or best step is no part or step. So I guess I'm wondering how much of the SaaS stuff that we've seen is appropriate for agents? How much should the agents be jumping into all the structured workflows that have been created for humans? And how much should we maybe be thinking, actually, they might ought to work a quite different way from the way we work? And maybe that the SaaS tools that we have actually don't necessarily encode the right way for agents to work.

I would agree with the observation that The way we work is not necessarily the way an agent would work over time, but the way we construct our units of action that an AI can take is usually giving it skills or tools, you know, that it can call at a particular step in its workflow. That's typically what happens. If I were to use Jira as an example, with Jira, the real value of Jira, like, it's funny, like, it's the classic, like, oh, I vibe-coded a to-do, in progress, done app. Okay. I've kind of You might have replaced Jira, it's done. You're like, oh, if that's what you're using Jira for, yeah, sure. Like, you're probably, you know, you won't use— you would, yeah, like, that's what you're better off doing. There's a bunch of other issues with that, like how do you maintain your own software at scale and whatever? There's a bunch of issues. But the real value of the SaaS tools that model, that let a team model some workflow, is the value that the customer has created by modeling it in their world. Jira's value is making I don't know, I'm just picking some random companies here, like Coca-Cola, the teams at Coca-Cola make it theirs. And they make it theirs by actually modeling their taste, how they want their organization to work, because otherwise everyone just ends up with the same organization, their business workflows, how they build products, how they do customer service, how they respond to change and track incidents, how they onboard a new employee, they apply taste in modeling their workflows in some way. In a world where AI agents are helping us do more of our work, the problem of modeling how these agents work in a workflow does not go away. I would argue that employees— employers and employees want even more control to define— if we said at the top of the call, taste is important— to define how they would like the AI to work. So my logical conclusion there is therefore agent orchestration with human workflows becomes a pivotal thing that every business needs to do at some point. And so, okay, what does that look like? Humans need to decide what they would like to do and what they would like their agents to do and how they would like them to do them and what they will do and what the agent will do and what their other colleagues will do, et cetera. That problem definition space of applying AI to a business workflow I don't prescribe to that world where, well, you'll just give it to AI, it'll work out everything. Because then in that world, and I can't reason with that world because you end up in the AI slop world. You're like, okay, well, that's basically everyone has the same thing all the time, every time. And everyone's company works exactly the same thing, which by definition isn't true because everyone's company builds different products and different services. And so you're like, well, I just can't follow. I can see how people follow that reasoning. But the reality is— the most valuable thing that a business needs to do is give their human teammates and their virtual teammates tools to do their jobs and design the workflows in which they would like to do that. And everyone goes from doing the thing to architecting the thing. I think that becomes more important in that world. And in that world, will they use different sets of SaaS services? Oh, totally. Maybe they were using some SaaS service yesterday and they use a different one tomorrow. That'll change. That'll always change. And that has changed for the last— you know, as many years as I've been doing this for. But I think what doesn't change is the need for specialist tooling where humans will do work with AI. I don't think that goes away in the SaaS world. I would argue that only increases if we're already— if you believe that chat is not the only— isn't it gonna be the interface to all interfaces and it like that won't work. I just, I can't see that world. Given the amount of crazy specializations there are in the world, it's just unbelievable, right? Like, you look at the crazy explosion of legal AI tooling. It's so specialist. My brother's an M&A lawyer, and watching him use his tools, I'm like, it is just fairly sophisticated UI tooling on citations of previous court cases related, like, legislation by country, by geo. And it's just like, Could he type a prompt and try to solve similar problems? Potentially, but it's a disaster. Try to build any business that does that job at scale, you're going to need specialist tooling. I just, I can't see that world. And then the only other counterargument to my argument is like, I always challenge myself of like, oh, but AI could dynamically generate that interface. I'm like, sure, but at some point, like, that needs to be predictable and scalable for employees and people to work with. And then you end up building a verticalised SaaS software. Like, you end up getting to the same outcome of a verticalised solution on top of the conversational interface.

You know, what predictions would we make from that? It seems like there's this Silicon Valley notion of the one-person unicorn, which we haven't seen happen yet. You know, we're starting to see some interesting, you know, very small teams with, like, you know, pretty notable Scaling success, but no one-person unicorns yet, to my knowledge. But I think the one-person unicorn is sort of premised on an idea that obviously the AIs are going to continue to get better. It probably isn't the case you could build a one-person unicorn with today's models, but maybe the next generation or the next generation, it starts to become— at least people think that it becomes more realistic. Maybe you think like, nah, that's just never going to happen. But I would not be comfortable putting a cap on how far the AI capabilities curve will go before it bends over. I always say it might be an S-curve, but the top of the S-curve can still be superhuman. And that is probably my best guess. There's also the possibility of intelligence explosion. That's a whole other thing. But it seems safe to me to believe that, like, We're going to get to something that is genuinely better than people at almost everything almost all the time. But then, yeah, I guess I just wonder, like, enterprises want control. That's a deep value or a deep reflex. But does that set us up for a world where, you know, does that work against the enterprise at some point? If they're like, you know, we can, we put these agents into these boxes and we have these workflows and we like, We need them to do these sort of point things in these prescribed ways. And meanwhile, with maybe Gemini 4 or whatever, some kid is out there that's like, I'm just going to provide light guidance and a bit of genius. But other than that, the AIs are going to just do all this sort of stuff, and I'm going to kind of let them figure it out. There's also this notion of, in human teams, Obviously, we're all different, right? And so I heard a previous interview where you said that the hardest thing about scaling a company is scaling product teams, because communication, trust, process, and rituals all break down. And so I think, again, that's kind of like one of the reasons we have all this software is because people can't keep all that structure in their heads. They can't just have like a shared mental model of it. So they need some more lasting instantiation that kind of says, this is the way we work. But the AIs are also going to be like clones of themselves, right? They can potentially collaborate with a lot fewer guardrails and kind of constraints and all these sorts of things in place. And I just wonder if that could be something that could really sneak up on the incumbents.

There's a lot there, dude. Let's do the first part. The first part of just the one-person unicorn, I think, is a good test, right? I was talking to a 5-person startup who's kind of doing like a sales AI vertical. The work that they do is the same work that I just described to you. To give you a specific example, they have AI agents in their Jira workflow that automatically publish content to their WordPress or whatever their blog is on a regular basis, thought leadership content based on a bunch of inputs that they have given it in a regular job. And humans in the loop review the content and You know, try to critique it and give it feedback, etc. So they got this content creation machine that's just popping out content to do that. So first point is even those one-person unicorns, they're orchestrating AI agents in a workflow to get stuff done, I think is my first point. Like, I don't think it's just an enterprise thing. I think the ones that are getting high leverage are not just manually typing in a prompt all the time. They put it in some sort of frequent automation orchestration rule. And are doing it there. The second big thing there is like those when you talk to those people, at least when I talk to them, they're the bottleneck, and they they have a constant need to hire more people. Can they do more with what they have? Oh, absolutely they can. But the ones that are truly growing, like we have more like we have more ideas of what we want to build than people to build it and agents to help us build it. Like Like, unless they're happy to stay stable and not grow, they're still like, hey, I'll hire, I can just get more with what I have, but I'm also still hiring. You hear that story all the time. So that one-person unicorn, I've read just lots of references to that thing. I'm like, sure, if that one person is happy to just remain as they are and be the bottleneck, like, if they're running a smart business, like, they would realize that talent is a scarcity and they'd probably wanna grow at some point.

Yeah.

Doesn't mean that each person can't do a lot more than they ever could before. So that's probably the second point there. Third one's really just around, often gets excluded, but not a major talking point, but like there are so many regulations and industries and compliance that just needs to happen. So like, you know, there is a whole cohort of the market that like literally cannot move without some sort of intervention there from a domain expertise human stuff. Even with AI stuff, I'm sure there'll be— there are regulatory implications. The last one I keep coming back to, Nathan, is like, I just still don't believe that one-person unicorn is some guy or girl typing a handful of minor prompts into things and not getting slop. Even when AI gets better, when again, my definition of slop is it produces something good, but just lacks any creative diversity. So like, Everyone's getting similar things because that's how these models are designed to do. And you can do it today. You can go type the same prompt in 7 different tabs of different AI tools and you're getting 80% the same. So therefore, for that person to actually become a unicorn, maybe they just get to the most— they capitalize on their slop the first, but then the second unicorn will look too similar. So they'll have to put in a lot more effort in avoiding that slop. And how do you do that? It's really just about the human process of just making AI yours. Like, I, I don't see a solve for that, like, other than just making it yours in some way. How do you make it yours? There's a million things of voice and tone, taste, content, context, et cetera. I just don't see that going away at all. Like, I think that's what makes us human, and that's what makes us crave different things and like different things because of how we think and how we feel and how we interact with things. Anyway, those are my thoughts on that topic.

You've mentioned this kind of core skill throughout the conversation, like figuring out how to build workflows, basically. You might, in other contexts, call that systems thinking or system architecture, process design, process architecture. I have found that skill is like very natural to some people and very unnatural to other people. What have you learned about how to teach that skill? How should people practice it? What can we be, you know, if this is the thing, right, where we're gonna be going from doers of things to architects of how things get done?

Also, the next logical question that people love, spicy, you probably hear this all the time, I'm sure, is, well, does that mean I don't need as many junior staff anymore? Because I like, it's just the senior staff that get the architecture stuff, right? So, I think that that's also related to that question I find that comes up a lot. We always forget how good of a teacher AI is. It's arguably the best teacher of all time. You know, I always, even I just think about, like, after the product management craft at Atlassian, as an example, you know, we've deliberately changed our hiring profiles of like which seniority and which people. Yeah, I'll make the joke of like those kids that are cheating in college and university, we want more of them. And they're coming in as AI native. need a better phrase for that. But the reality is they are the ones that are already starting to think how they can use AI to advantage them the most, even though they have less domain industry experience. The ones that are doing, that are using it in their personal lives or their, you know, as they, as they, it feels native to them. My son, if I observe him, he's gone from, he's 11 years old, he's gone from Scratch coding, which is like a visual coding language, Straight to vibing, and like he hasn't had that middle section of like learning about syntax and code constructs or whatever. You know, he geeks out with them every now and then, but he hasn't yet had that. But he's already, you know, his Roblox got upgraded the other day. He's like he's got this Roblox like IDE where he codes stuff, and he's like, "Dad, dad, that AI thing just appeared in Roblox," and he runs in my room. I'm like, "What are you doing?" And he's just typing and vibing away and doing stuff. So he's that that's becoming. The skill he's learning is how to instruct AI to get what he wants. And if he doesn't, it doesn't get what he wants, he's learning how to instruct AI to teach him to explain what he's after. I will say this whole doing, being the architect of the thing, one logical conclusion that's incorrect, I would say, is people say, therefore, I only hire or focus on senior staff. No, I would argue behavioral change is really hard. I would argue a lot of senior staff actually probably still doing things the old way because it's the quickest and easiest. I struggle with this. Like when I get a new task, I could do it the way I currently do it, or I could try this new way of doing it, which may or may not work, which may require more time or may fail, but I might get a better outcome. That behavioral change is really hard. Where is it in our workforce that we're easiest and best placed to instill behavior change when someone's new to any role? It's great there. So I will say the biggest thing to be aware of is just AI as a teacher is an excellent tool to help with there. And the second thing is, yes, we see more people go to being the architect of the thing, but also there's an equivalent amount of people in the workforce that are reviewing the thing who aren't yet architecting the thing that are also building knowledge to then become architects of the thing, right? So the person architecting the workflow for that procurement team I gave you as an example of, that's usually one person that sets that up and decides how it works. The humans are still reviewing the contracts and the proposals from the AI, but they're also building domain knowledge and skill of what's good and what's bad taste. And in doing so, they're also becoming architects over time. So, I think their growth still continues even as people who are reviewing the results of AI there.

Speaking of new teammates, Atlassian bought a browser company, and it's literally the browser company. So, Kind of a 2-parter on this one. One, the goal, as I understand it, is to build the browser for knowledge workers. I'd love to hear a little bit more about like what the vision is for that, you know, what you imagine that ultimately looking and feeling like. And then I'd be interested in your advice for businesses that are thinking about acquiring an AI startup in their space. How should they be thinking about the value drivers? Classically, you have, like, team, tech, and traction. And, you know, but this is such an uncertain world for so many reasons, right? Like, is the tech that some startup has built today, you know, gonna endure in the way that we might have been confident it would in past eras? Is the traction even right? I mean, you know, we see these, like, super fast, basically vertical revenue expansion stories, but then we also kind of wonder, like— Yeah, what happens to Cursor, for example, if Anthropic decides that they're going to only allow their next model to be used in Claude code for a few months when it first comes out? So I just feel like to so many companies, the feeling is like, it would be really nice to be able to acquire our way into this a bit, but are we comfortable paying what we would normally pay for the sort of traction that we see? It can be really hard, I think, for people to think about that.

Awesome. Browser for Knowledge Workers, amazing team. Josh and team have done an incredible job. Maybe just as analogy to help that I kind of use in my head, like, we're not trying to compete against your everyday browser and your consumers browsing the web, doing shopping, whatever it is, planning their next trip, buying some dress or something. When you reset the assumptions on which you're building software, you get a very different outcome. I keep telling the teams inside Atlassian that are building our apps, I'm like, hey, we need to build assuming AI is always on and available, and you'll get a very different Jira to what you did back then, right? Like, that's our mental model. Now, in this particular example, early messenger days as a parallel example, AOL Messenger, ICQ, I still remember my ICQ number. They were messaging tools that were largely used in a consumer context. Now, we did, the industry, we as in we the industry, did apply some of those messenger tools in a work context, and they worked okay, but they weren't great. They didn't take off well, et cetera. When we reset the assumptions of, hey, in a business context, how is messaging different? We ended up with a very different solution. Like, we ended up with channels as a way to reflect org and team structure. We ended up with integrations as a way to integrate with different systems, business workflows modeled in MS Teams channels or Slack channels, et cetera. Permissions and control became more important. So we actually end up with very different products to the consumer messaging products. And still, I would argue today, consumer messaging products still look very different to business products. Like, and so we believe the same thing's happening in the browser context for work. If you reset the assumptions on how people work every day with a wide variety of different SaaS tools, why do they go to the different SaaS tools to do what tasks, then there's a bunch of different things we need to do to get to that outcome. So that's like a bit of an analogy of like, hey, like we generally believe that there will be a different work construct for using AI in a work context and you'll still need a personal context and it'll be quite different. And I think the same is applying a little bit with just personal AI and work AI as well. You're seeing more and more of that. Like, You know, the personal AI productivity in a personal world is quite different to a work one. I think the browser company's already thinking about, Josh and team's thinking about like, hey, in a world where the browser has access to the tools that you have access to, permissioned per user, it's a fairly complicated world. In a world where the browser has access to the organizational knowledge and the graph that we talked to you about, how might we— solve the similar problems that, but in a work context, we end up with quite a different interface, quite a different experience that ends up happening there. So I think the opportunity there and the vision there is really just around envisioning teams working in that collaborative context with their virtual teammates across many SaaS tools. We believe what the browser looks like today will look quite different to what it looks like tomorrow for knowledge workers. So stay tuned there. That's a Exciting and moving space, but also just a fun space. As someone who's been in tech for a long time, you're like, when assumptions reset, it's such a clean slate to like start thinking again. We went through this with e-commerce days, the cloud days, et cetera, mobile. So it's always fun.

So that sounds like mostly team is what I heard largely there. Any thoughts about tech and traction if you're thinking about buying an AI startup?

Oh yeah. So your second part of your question, look, there's the mix of like, there's an AI fog of like investors and companies are struggling with like, oh look, how much of this is like reproducible overnight? How much of it's not, et cetera? Like that exists. I will say on that particular topic and bucket, what has stood the test of long-term AI, long-term, I always tell teams define long-term as 12 months here in the world of AI. Understand the trajectory and define what long-term means, because otherwise you don't make a decision. You're an information paralysis. You go, oh, but the trajectory is here. And so be like, okay, let's agree for the next 12 months, what's the most valuable step you can take as a business, as a team, whatever it is, to get to 80% of something to 100% of something that's a market-specific vertical domain niche is a massive investment. And I think that is certainly, again, depending on What your listeners are thinking about, whatever. That's certainly something we're like, okay, if it's a vertical and I can see that the team's put in effort to get to that, what I could do with a general model gets me 80% of what I could do with a general AI tool. But what I get to here is that 20%. Businesses are willing to pay if that's high value to get to that extra 20%. And that's where most of the value is. That's one big thing to take away. The second big thing to ask your team, your teams is, I use the phrase workflow proximity. There's user workflow proximity and buyer proximity. Those 2 things are pretty important for thinking about these things. User workflow proximity and asking is, do we have a right to win in terms of how users work every day? And this is more for the PLG style of discussion. For example, I could go build some AI tool to help with calendar AI automatic scheduling tomorrow as me as a random individual. Who's probably gonna win that space? People that already have people that are using calendars. So I would either, you know, build to get acquired or build to the hope that I could somehow steal market share and then start with a new calendaring system. That seems like an epic, too big hops to take, right? So asking workflow proximity is where do the users exist today? I always, and then say for that job to be done, draw Maslow's hierarchy of needs for that job to be done. And you want to be as close to the bottom of that pyramid as possible for that vertical because that player is in best position to move to the next layer of the stack and to the next layer of the stack. So the calendaring example, you're like, you can't— I really want to own calendaring and scheduling to do that. Or you feel like your niche on top of that calendar will be a niche that those big vendors won't go after for a while and you can earn some big bucks doing that and whatever. And that's fine. So I always think user User and buyer workflow proximity. Is that also a good thing for these companies to have in mind when you're thinking about these things? Do they help us? Do they give us more users workflow or more buyer workflow? And then where are they in this stack of that job to be done? Are they at the top? Once I've done these four things, I need to do this fifth thing. Then that's a dangerous spot to be in, but it might be good if again it's so nuanced depending on the market's big enough. You think what you're doing is so specialized they won't go after that, etc. There's a bunch of. Things to think about there. Hopefully that's useful.

Yeah, a couple of good frameworks there for sure. On the future of software, one mental model I have for, like, are we going to see a software explosion? Or might we, 5 years from now, have fewer professional developers than we have today because AI is doing a lot of the work? Is to ask, and I'll give you a spectrum, right? How much more of this would I buy if it were functionally free? On the low end is like dental work. Like I would buy no more dental work even if it were free, right? I, I don't want it.

You don't enjoy it?

You don't enjoy it? I'd like to avoid it, you know? And accounting is like less painful than dental work, but it's like still, I would probably pretty much buy whatever I'm required to have and probably not much more. And some people might, you know, buy a little more, but I think most people have roughly that attitude. On the other hand, like massages, if they were freely available all the time, I'd probably consume like 100 times more than I currently consume, maybe even more than that. Where is software on that spectrum? I find quite hard to figure out. And I would definitely separate software for the purposes of this from AI inference generally. How much more do we need? What is the limiting factor on how much we can use? Is it our time? Is it something else? But what's your intuition? Because I do think it's gonna get a lot cheaper. And then in terms of like the future of the industry, it seems like I just don't know how elastic demand really is.

I would totally take the massages one, by the way. That's such a good one. Look, I feel like the only way to have a fruitful discussion is to be more nuanced on the category of software. And we could, so many ways we could slice this. So let's just say we slice it in B2B and consumer. Okay, well, consumer, well, that honestly feels like a massive pool. Look at our lives of entertainment, leisure, home renovations, like whatever, pick, pick cooking, etc. I feel like that continues to grow, especially and sadly. So there's also the business for attention, which exists, but it's what it is. So I just can't see that shrinking in the world of AI. I think in the world of AI, we have to ask ourselves, societies, like, what do we want it to become in the consumer space? The trajectory we're on is extremely highly fabricated content, and the blend between reality and real is getting blurry. But again, arguably, you could go, okay, applying a photo filter to my phone 5 years ago was already somewhat AI, right? Like, that was like already that. Anyway, I just can't see that shrinking. In the business, again, we could go business by specific vertical, etc. But the general thing, again, I go, okay, well, AI looks better with the more tools it has access to. Tools being tools that humans need to build or tell AI to build. I don't think that goes away to build those tools for it to have access to. So developers, as an example, are still going to need to build tools for AI to have access to. or review or be involved in some architectural step of that stuff. And so in the business context, I don't know why that would shrink. I still think that would continue to grow. If anything, the granularity of tools explodes. If I build an app tomorrow, let's use the calendaring app as an example. The app to a human, that's one tool. The calendaring app to an AI is like, that's like 50 tools. It's like, you know, find time between Sharif and Nathan that works in this time zone is probably one tool that you give it. Find, you know, time between 2 people. Block busy times, another tool. Public, you know, get public holidays. And like, there's so many ways you could slice and dice that. So I would argue that in that world, designing software for AI is incredibly more sophisticated and more complicated in terms of the quantity. of then the granularity of which we need to design things to get a better outcome than it is for humans. And so I reached the conclusion of like, I just can't see that shrinking anytime soon. Now, could a vendor's world change so that they go from building a UI to building a set of tools that the AI calls? Yeah, it will. And it is changing and the business model will change over time. You know, if I look at the App Store as an example, you know, Apple's got a big push right now with their app vendors of like, hey, spend time focusing on building App Intents over UIs. If your— App Intents is their sort of their skills and framework. If your app kind of does these things, then yeah, then I guess Siri or whatever the new AI ends up being can use that as a tool. And there's still value exchange done in that tool, but it depends on what the use case is and how that works. So I just see the software continue to explode, but maybe the more useful discussion is having it by market, by domain. 'Cause then you could see, okay, you know, how automated software might be totally different to software for reviewing and tracking official document signage or compliance or something like that. That might change. Yeah, it might be different by the actual market there.

Last question, leadership. What do you think companies are not doing enough as they try to lead a process of encouraging their people to adopt AI. Things I've said in the past, which I think are like, okay, but maybe getting a little stale, are like, leaders should lead by example, make sure everyone gets hands-on, highlight your individual creativity and success stories, make AI adoption a part of performance reviews and evaluations. This is maybe like as spicy as I've got with it. What's the next level up from that in terms of the best ideas that you've seen? For, you know, making especially bigger organizations really rally and catch this wave?

Look, they're all good points. I think the nuance comes in the tactical implication of how they apply them. Like leadership modeling behavior is a great example, right? The leaders that do it well and inspire are the ones that can share stories that are more than, I used AI to summarize this document and draft this email for me. That's the thing you need to unlock. And so, okay, how do we help folks unlock that? I'm a firm believer when I again look at tech history, when a technology wave came, when we used it in our personal lives, it ended up impacting our work lives a lot stronger. When we started buying stuff online in e-commerce, it ended up changing how we exchanged software and bought software. When we started using mobile phones personally, it changed how we use mobile for work. And so I always say, look at your days as a leader to be very specific. You might be renovating. I'm just gonna run through my use cases. Like, you might be landscaping your backyard, and you could use AI to give you a bunch of ideas, visualize it for you, critique the different plants and the environment you're in, et cetera. Like, actually use it aggressively there. If you have children, oh boy, my use cases explode here. Like, I use— I have an agent that Helps my son with his math homework that doesn't give away the answer, but knows the school curriculum for his grade and year. And he talks to it and it helps, you know, walk through an answer. It's very personalized. We put some Fortnite jokes in there and stuff like that that he likes to do. My daughter, she loves creativity and she geeks out with AI music all the time and makes her own prompts and all that kind of stuff. So using it personally, For the model behavior, I think is the important thing that leaders miss. They go, oh, look, I pressed summarize or I wrote an email. And you're like, that's a great start, but just find— I actually love asking this question in job interviews. How many of you personally use AI? And you'll see things from planned a trip to redoing a whole house renovation with it. And it's basically running the show for me. I recently just did a sporting injury. Tore my MCL. And I'm thinking, you know, and a physiotherapist, but I've also got an AI assistant that reminds me every day of the exercises I should do. And it checks in on me and I will— it asks also what I ate and it will tell me like, is that good or bad? Like I've spent time prompting it to say like, are you helping me heal as quickly as possible? And doing that kind of stuff. The second thing on like, you know, mandating or now getting others to do it, like I always feel like we've got to show the examples ourselves. Creating a safe space is the hardest thing people will need to do. What is safe? I don't believe mandating is safe. I think that sends a message of like, do or like get out of here. I just generally, I just, if I hear the mandate message, I'm like, okay, it might help some people for motivation, but I think the vast majority of your workforce probably see that as a threat. But I would, again, the nuance in these conversations, I think is where all the value, Nathan, is. So like I always say, Find, we, you know, we just ran AI Builders Week, 1,000 product managers, designers, engineering leaders, researchers. We blocked time off synchronously across the crafts. So it was no longer in some team, some person is taking a few days to tinker with this thing. That person feels guilty if they come back with a failed project. If they feel like they're blocking the team when the team's asking them questions on their day jobs and they're like, Over here trying to explore the new thing. So I always say like, okay, find times where multiple people that work together can block their times so they're not dependent on each other. But what you're celebrating is the learnings, not the actual outcome. The outcome is the learning, not a product outcome. And because tinkering is the most important thing they need to be doing. And then applying AI in their business workflows, like whatever that may mean in their department, is something for that team to go through the process of discovery themselves. That's the best way they'll be able to do that. So I often say to teams, don't go— you'll get customers that will want a high-touch meeting and we'll meet with them, whatever. And they're sitting there exploring and trying to discover this killer use case. And they'll pull in someone who tries to imagine use cases. And I'm like, and I'll often say, who in your company is doing some step of that or that today? No one. And I'll be like, forget that. Just throw it in the bin. Throw it in the bin yesterday. Find me a team of what they're doing today, and let's write down exactly what they're doing. And let's walk through. I always say, just write down for any specific task, write down the steps for each task. And then within each step, what are the specific knowledge, instruction, and actions the human takes to solve that step? And then we'll be able to identify opportunities in a more effective way and actually get to a proof of concept. super quickly by you guys building your own agents, deploying them in a much more effective way. So I think your advice, Nathan, like high-level tech, I think where everyone struggles is the next click down. I couldn't tell you of any other killer advice other than saying the next click down is often what's missing, which is to help me actually do the model behavior, help me actually apply it to a team. What does that look like? We have plays in our playbook. People can go look up or try to open source some of these frameworks for how people can apply it in their teams. But definitely go and do that.

This has been great. I really appreciate all the time and many thorough answers. Anything that we didn't touch on or anything you want to leave people with before we break for today?

No, only my encouragement is just look at your days outside work and just play and try things. I think that's what will change your behavior, and that probably will also change your behavior in your workplace over time. find because you'll start to use that level of thinking when you get to your work. So that'll be my, just my biggest encouragement is like ignore all the buzzwords and all that stuff and just try to try it when you're fixing your tap next and you need to take a photo and understand which washer is what washer or whatever it is or how that works. So like whatever it is, just find a way to tinker. But yeah, thank you. Thank you for your time, Nathan. Really appreciate it.

Sharif Mansour, thank you for being part of the Cognitive Revolution.

See ya.

If you're finding value in the show, we'd appreciate it if you'd take a moment to share it with friends, post online, write a review on Apple Podcasts or Spotify, or just leave us a comment on YouTube. Of course, we always welcome your feedback, guest and topic suggestions, and sponsorship inquiries, either via our website cognitiverevolution.ai or by DMing me on your favorite social network. The Cognitive Revolution is part of the Turpentine Network, a network of podcasts where experts talk technology, business, economics, geopolitics, culture, and more, which is now a part of a16z. We're produced by AI Podcasting. If you're looking for podcast production help for everything from the moment you stop recording to the moment your audience starts listening, check them out and see my endorsement at aipodcast.ing. And finally, I encourage you to take a moment to check out our new and improved show notes, which were created automatically by Notion's AI meeting notes. AI Meeting Notes captures every detail and breaks down complex concepts so no idea gets lost. And because AI Meeting Notes lives right in Notion, everything you capture, whether that's meetings, podcasts, interviews, or conversations, lives exactly where you plan, build, and get things done. No switching, no slowdown. Check out Notion's AI Meeting Notes if you want perfect notes that write themselves. And head to the link in our show notes to try Notion's AI Meeting Notes free for 30 days.