摆脱 AI 垃圾内容：Atlassian 如何让 AI 队友拥有品味、知识和工作流——与 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: 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: “Adopt 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. 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. 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 as, 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 Sherif 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. While it is perhaps best known for software development tools like Jira, I was surprised to learn that today the majority of its users are actually nontechnical knowledge workers in departments like marketing, HR, and finance. This gives Sherif 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 Sherif'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?”—something 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 Sherif 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.

Finally, we debate the concept of the one-person unicorn, with Sherif 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 Sherif 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 Sherif Mansour, head of AI at Atlassian.

Sherif Mansour, head of AI at Atlassian, welcome to The Cognitive Revolution.

Thank you. Thanks for having me.

I'm excited for this conversation, and I appreciate that we were able to arrange it. I believe we're 16 time zones apart, maybe even 17 hours ahead. You are in Australia, while I'm here in Eastern Time in the United States, so it's amazing what technology can do.

Speaking of technology, Atlassian is obviously a big technology company, but I think a good chunk of the audience doesn't necessarily have direct experience with it. Just as a quick introduction—and I'll let you do a fuller introduction—it's a $40 billion market-cap company, one of the top 100 tech companies in the world by market cap. That puts it ahead, by the way, of household names like eBay, Reddit, SoFi, and Expedia, but it has been historically, and certainly in the products that I've used, very focused on the software industry.

For those who maybe aren't from the software industry and don't have much background with the company, you've been there 16 years. How would you introduce the company? 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. I've been here a long time, and actually, before joining Atlassian, I was a customer myself, 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 worked.

I would describe it pretty simply: we're a product company that builds collaboration tools for teams, and we specialize in different kinds of teams. Historically, we specialized in technical teams, specifically software and IT teams. What do they do? They plan projects, build software, and deploy it. IT teams run service desks and help desks, and provide a service internally.

Today, the vast majority of our user base does similar types of work, just in different departments. I call them people who run projects—marketing projects, finance projects, and so on—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. Today, the majority of our users are actually from nontechnical departments: HR, finance, marketing, legal, and so on. It's really just about helping these teams collaborate with each other to get work done.

I guess the second part of your question is how AI fits into it. We've got close to—I think we're at—3.5 million users of our AI capabilities. The big shift we're seeing in how teams collaborate is that teams are now introducing virtual teammates and bringing them onto the team. I'm not talking just about the personal chat-productivity level; it's about a team working together to get a job done, adding a team agent in their context to help them move that work forward in a collaborative fashion.

I think we're really big on seeing AI as just a new teammate that helps speed up the collaboration process that teams engage in, whether they're technical or nontechnical teams working together.

When you talk about introducing new kinds of teammates, the AI teammate is obviously a little bit ahead of the curve, skating where the puck is going to be, so to speak. 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 benefits of software and inference—the scalability, the copyability, the ability to pay for what you need. It could be available 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 are all these advantages, but there are also rough spots that mean that, in some ways, AI teammates don't quite live up to the same expectations we have for a human teammate. How do you think about, first of all, 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 anthropomorphizing these things in the first place?

Should people be mapping AI onto the idea of a human teammate and creating a fork for their understanding of an AI teammate, or are they so different that people should start with a different base understanding and allow that to evolve independently of their expectations for humans?

That's a topic we're constantly wrestling with. We have this value inside Atlassian called “Build with heart and balance,” which is really about trying to find the fine line in making a decision or balancing 2 trade-offs.

I think most people would agree that nobody wants to talk to something that feels incredibly robotic. At the same time, most people would also agree that nobody wants to talk to something that tries too hard to be human and feels inauthentic. It's this weird balance between the 2.

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?” You have to peel the layers back behind that question, which is, “Why does someone see authenticity as important?” All the way back down, one thing that comes across—especially with our business customers—is the importance of trust, especially in a business context.

If I ask you a question, I want you to be reliable and give me something trustworthy. How do you achieve trust in a business context? For us, a lot of it is transparency. If I give you an answer, I need to give you as many citations as possible.

With our AI, Rovo, we have a whole team dedicated to improving citations, for example, to make sure that the quality of the response is factual and points to the right sources.

But applying it to the agents topic you brought up, the same thing happens here: if I deploy an agent and put it in my workflow, I want to know how it works. I want to see its instructions. I want to see who created it. I want to understand what the last 10 things it's done are. So I think transparency is key to helping build trust, which then helps build authenticity, if that makes sense.

I do agree with you, and it is a fine line. We're certainly not saying, “Oh, yeah, it should just feel like a human teammate.” 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. We want them to feel like collaborators with us. Already, at the personal productivity AI level, people are feeling like it's a personal collaborator. At the team level, it becomes more interesting because there's now a team dynamic here, right?

I always say every team in every company has character. I'm not talking about character in terms of human personality, but 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 are types of language they use, voice and tone. If you're a team serving customers in a bank, you have a very different team character from a team that's working on a marketing campaign for a digital agency for, I don't know, young people or something. It is important for teams to apply some level of character to their virtual teammates; otherwise, you have this weird blend where it just doesn't feel like it's part of our team, or the complete opposite: 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, 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, is something like this: the output is technically correct, but its creativity is lazy—as in, everyone's getting similar results. 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 models, et cetera. One of the biggest techniques to do that is to apply your team's character, your team's soul, if that makes sense. 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? You're effectively prompting your virtual teammate to try to speak your team's language. I think that's critical to teams not just getting standard AI slop. 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 made things scale that didn't previously scale. But when reading about the work you guys are doing to facilitate teamwork, brainstorming, collaboration, and all that kind of stuff with AI, that was the big thing that came to mind for me. So I would love to dig a little deeper into how you do it, I guess, maybe conceptually, but also into the techniques that you're using.

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 it 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 learn from them? Obviously, we know continual learning is not quite at the state that we think it ultimately probably will need to be for the most powerful, transformative agents everyone can envision, but we do have in-context learning. We do have the ability to scroll through the archives and 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 a lot of layers. Maybe the first and foremost layer is, to answer the first part of your question, there's a lot you get out of the box. But the reality is, the real differentiator is applying your team's taste, knowledge, and workflows. I use those 3 ingredients.

Taste, I think we've just talked about, which is: if everyone's typing the same thing, what is your unique thing for your business or your team? You have to apply that. That literally might be a lot of prompting, or it might be a lot of context 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, the same-looking products, and the same-looking services. Humans just aren't going to accept that in the long term.

Knowledge is the second thing, which is where the customer comes in: “Hey, I'm building an agent. What knowledge do I want it to either have access to or be trained on?” And there's a nuanced difference between those 2 things. Often it's like, “Hey, I'm the procurement team.” One of our customers does this a lot. I was talking to him the other day, and they have a bunch of Confluence pages that have all the things they look out for when they review 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. They pull that in, and the agent has access to that knowledge.

The third one is really just how they choose to deploy it in their business workflow. 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 go back and forth with you to then make a proposal for how it should be.”

Those are the 3 ingredients you kind of need in any business. If you want to apply AI and you talk to a customer, you're like, “What are you trying to do?” And they're trying to think of a killer use case. I'm like, “Why don't you just start by telling me what you do today? Pick a team. Pick some tasks that the team does. What do they do?” You often find those 3 ingredients: 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 get the benefits there. So they really need those ingredients.

What we do with Rovo is we give them—obviously, 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 very different results. Nathan gets very different results from Sherif because the data you have access to is totally different. Search in an enterprise context becomes very important. Every percentage better our search engine gets, the better the results get.

The second big thing we have in our portfolio is what we call the Teamwork Graph, which is just a map of all the entities that a customer has worked on. We know their teams, their pull requests, their work items, their Confluence pages, their Trello boards, their ideas, and how that connects to their Figma designs, their Google document proposal with the client, or their Amplitude dashboard where they're tracking metrics. We have the relationships 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. Are you still jumping between multiple tools just to update your website? Framer unifies design, content management, and publishing on one canvas. No handoffs, no hassle, just everything you need to design and publish in one place. Framer already built the fastest way to publish beautiful productionready websites, and it's now redefining how we design for the web. With the recent launch of design pages, a free canvas-based design tool, Framer is more than a site builder. It's a true all-in-one design platform. From social assets to campaign visuals to vectors and icons, all the way to a live site. Framer is where ideas go live start to finish. And now they've added a Framer AI layer to make it all faster and easier than ever. With Wireframe, you can skip the blank canvas and get a responsive page with structure and starter content ready to edit. With Workshop, you can create new visual effects, cookie banners, tabs, and more. No coding needed. And with AI plugins, you can connect top models from OpenAI, Anthropic, and Google to generate images, rewrite text, generate alt text, and more. Ready to design, iterate, and publish allin-one tool. Start creating for free at framer.com/design. And use code cognitive for a free month of Framer Pro. That's framer.com/design. Use promo code cognitive. framer.com/design promo code cognitive rules and restrictions may apply. The worst thing about automation is how often it breaks. You build a structured workflow, carefully map every field from step to step, and it works in testing. But when real data hits or something unexpected happens, the whole thing fails. What started as a timesaver is now a fire you have to put out. Tasklet is different. It's an AI agent that runs 24/7. Just describe what you want in plain English. Send a daily briefing, triage support emails, or update your CRM. And whatever it is, Tasklid figures out how to make it happen. Tasklid connects to more than 3,000 business tools out of the box, plus any API or MCP server. It can even use a computer to handle anything that can't be done programmatically. Unlike Chat GPT, Tasklet actually does the work for you. And unlike traditional automation software, it just works. No flowcharts, no tedious setup, no knowledge silos where only one person understands how it works. Listen to my full interview with Taskllet founder and CEO Andrew Lee. Try Tasklet for free at tasklit.ai and use code cogrev to get 50% off your first month of any paid plan. That's code cogrevlit.ai.

So let’s do maybe one double-click on each of these: taste, knowledge, and workflow levels. If I start with taste, I mean, I don’t know if this is something you guys keep a secret, or how much you want to share, but in my experience, I have found Quan has been the best at capturing my taste.

The main task that I always do, and 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. Basically, I have a big PDF with a bunch of previous essays. We’ll take the transcript of this one, put those two 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 guiding users through the context-creation process? That kind of thing, I find very few people do. The only reason I did it was because I believed it would work, but if I didn’t, it was kind of annoying to go back to 50 different documents. I did that before I had an agent that I could potentially delegate it to, so I had to spend however many minutes on it, 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 the elbow grease 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, nudge, maybe propose whatever ways for them to assemble that context. I’m really curious about what’s working well for you and how you evaluate that, because when you get to something like taste, what makes it so valuable is also probably what makes it, I would think, very hard to subject to a standard eval.

You guys have so many customers and 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. Your example is 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. It’s how your voice and tone, how you think about things, how you write about these shows, and so on. You’ve given it your taste through those two things combined, which is a really good example.

You’ll talk to customers that will just do the prompt and go, “Oh, well, it was okay. It wasn’t that great.” It was just not the thing. I don’t know how much of your example is Claude. I do generally believe that all the models level out, and they’re already 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, as you use our AI tool, most customers start with—you know, I always give them a simple framework of AI maturity. I’m Egyptian, so I always think everything in pyramids.

At the bottom layer, most people just ask a question and get an AI answer. Layer 1, layer 2 is, “Oh, hang on a second. AI can do some work for me,” and they’ll ask it to generate an artifact: “Write a proposal for me. Write the show notes for me. Write the intro for me,” and so on. That’s the next big lightbulb moment in most people’s minds.

Layer 3 is, “Oh, hang on a second. In my team’s context, I can take my knowledge and take my instructions and package that in a repeatable workflow that will help me scale,” and give me either more ideas, improve the quality of something, improve the effectiveness of something, or improve the efficiency of something.

At that bottom layer, when they start with just question-and-answer, you’ll get some customers who’ll be wowed with us doing little work. I’m always curious. I’m like, “Well, hang on a second. Why?” Because you get some customers who get terrible results, and I’m always asking them, “Why are you getting terrible results?”

The ones that happen to be using, for example, Rovo Chat, which is our chat tool, have built-in personal memory. Over time, we start to remember things about you. For me, I like to write with a lot of emoji. That’s just my writing style. It’s a very simple example. So every time I ask Rovo to help me with some writing assistance, it will often prefix my headings with an emoji that best reflects that heading, stuff like that.

It feels more personalized because it’s applying my taste to that world. Personal memory is one big thing that we give customers who happen to be using our products out of the box.

The second big thing we get—and this isn’t talked about a lot, Nathan, in the world of AI, especially in the business context—is that our products are open by default. I have to explain that a little bit. When you create a documentation space in Confluence, a Jira project, or whatever it is, the default is open, and you need to decide who you want to restrict it to.

We’re trying to encourage transparency and fully flowing information. In a business context, you’ll always need very granular permissions, so you can go as far as you like and control everything. But we’ve got over 20 years of history of customers who have been open by default. Many customers who use our products have been using them for a while.

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. It turns out that being open by default is a huge advantage when working with AI.

Let me give you two contrasting examples. Imagine you joined a company tomorrow and 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 starter. You have no access to the Word documents that were just created, or the Google Drive and Google Docs that were just created. You just don’t.

Unless some IT administrator has gone out of their way and changed the default permissions—which is super rare and very unlikely—when someone joins a company and there are some open knowledge bases by default, all of a sudden they’re getting questions answered that would have required them to message 50 people to work out the answer. At least they’re getting pointers to the right person.

That new starter comes with organizational and teamwork knowledge in an open environment. They get a much bigger advantage joining an organization where things are open by default.

It’s a long answer, but I think there are a lot of ways we can prefix and bootstrap that context for the customer to make that taste a little bit easier. In saying all of this, though, it’s only as good as what the user decides to write. At the end of the day, if they’re not writing their opinions, their taste, and their instructions, AI can’t magically guess that—unless, again, they’re using personal memory, which they are already writing a lot into, and all that stuff.

It really comes down to this: you have to put in effort to get an outcome. People always use the example of, “Oh, 80% was okay, but then to get to the last 20%, it took me another 5 or 6 hours,” and that’s true.

Sorry, I take long answers, but to answer your eval question: how do we measure success? It’s hard. It’s really hard, because how one team uses you—we have a platform where anyone can create an agent and put in any business workflow—so what is success there?

We have some pretty good signals of success. Did the user use the output of the agent? Was it successful? We obviously have thumbs-up, thumbs-down, and all that kind of stuff as well. You also have more nuanced signals, like whether a lot of rephrasing was required.

You may ask the agent to do something, but you’re kind of like, “That’s not really what I’m after. I’m going to ask it again in a different way,” or, “You got that wrong,” and that kind of thing. There are other signals that give us insight as well.

The reality is that agent creators in a business—you often take our tools, apply them, and give them to your teams—they’re the ones who are really in the best place to judge success. They usually give us feedback on which parts are system things that we could improve, or they’ll realize that these are things that are knowledge I need to add, or instruction that I need to add. It’s usually one of those 2 buckets.

Yeah. Interesting. So it sounds like, 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, “We have a standard, automated eval suite, and we use an LLM as a judge.” Maybe that’s in there, too, but that didn’t sound like it’s a huge driver of your confidence in what’s working or not.

No, no, we have that, and we use that. To give you an example, we have 20 or 30 out-of-the-box agents that we ship, and they run through the same system. It’s to our advantage to model as many domain-specific examples as possible. But the reality is customers will create their own evals for the agents they create that are very verticalized in their use cases.

The example I gave you about the procurement contract could have an out-of-the-box example and our own evals, and an LLM as a 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. Our agent framework lets people test the agent, see the responses, set up their own eval, that kind of thing, and run through that themselves.

It’s important that, as you deploy an agent into your team, 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. 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. Being an entrepreneur, I can say from personal experience, can be an intimidating and at times lonely experience. There are so many jobs to be done and often nobody to turn to when things go wrong. That's just one of many reasons that founders absolutely must choose their technology platforms carefully. Pick the right one and the technology can play important roles for you. Pick the wrong one and you might find yourself fighting fires alone. In the e-commerce space, of course, there's never been a better platform than Shopify. Shopify is the commerce platform behind millions of businesses around the world and 10% of all e-commerce in the United States. From household names like Mattel and Gym Shark to brands just getting started. With hundreds of readytouse templates, Shopify helps you build a beautiful online store to match your brand's style just as if you had your own design studio. With helpful AI tools that write product descriptions, page headlines, and even enhance your product photography, it's like you have your own content team. And with the ability to easily create email and social media campaigns, you can reach your customers wherever they're scrolling or strolling, just as if you had a full marketing department behind you. Best yet, Shopify is your commerce expert with worldclass expertise in everything from managing inventory to international shipping to processing returns and beyond. If you're ready to sell, you're ready for Shopify. Turn your big business idea into cha-ching with Shopify on your side. Sign up for your $1 per month trial and start selling today at shopify.com/cognitive. Visit shopify.com/cognitive. Once more, that's shopify.com/cognitive. [Music]

I’d love to 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? Everybody has come to the realization that we’ve got context-window working memory, and then we’ve got this baked into the weights: deep memory.

The huge question is what sits between those 2 productively. We’ve got RAG, of course, and all kinds of different experiments and memory structures. Then we’ve got the idea that maybe the context window can just scale to the point where it kind of solves the problem. Then there are maybe new architectures 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? 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, because this is a theory that I have, a lot of times people want to put them into the same thing, and sometimes that’s the right thing to do, but other times a human user can only scroll through maybe the 10 blue links, whereas the LLM user might be able to handle 200 results. By processing a lot more, maybe they can actually do a better job.

Yeah, really good question. Personal memory, I see as just a capability that everyone ends up having over large language models. What’s unique here, and what’s important to call out, is how easy and how organic it is for a user to populate personal memory. The phrase I use is user proximity: how close is the person to the AI when doing it?

For example, a coder is probably chatting with the AI all the time in their IDE, so they’re implicitly populating personal memory, or explicitly as they do it. They have very good workflow proximity in the coding use case. For us, we have a collaboration and documentation tool called Confluence. 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,” that kind of stuff. That’s happening organically, and it’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 2 ways we can be effective with organizational memory. You’ve already touched on RAG. RAG gets incredibly hard in enterprise contexts because everything is permissioned, even at the field level. With Rovo, you can pull in Salesforce, SharePoint, and GitHub. 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.

There’s a very large investment in teams just trying to make sure it has a semantic index behind it, that it’s also permission-aware, that it’s as fast and performant as possible, and all that kind of stuff. That’s the RAG technique.

Then the other technique is 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 it mapped out, and it maps them all out together.

The way the Teamwork Graph works is both organically and inorganically. An example is Jira, which is often seen as a system of record in most organizations. When you get your app approved in the App Store, for example, that goes through a ticketing system. That’s a system of record: where is the app, what stage is it at, what are all the related documents for this app, who’s reviewing it, et cetera.

Typically, systems of record don’t track the work or actually capture the work being done. They track where the work is and the links to the work. If you pick up our billing example, where the call center team is disputing a bill, someone has called up to dispute a billing 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 graph. It’s 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 Rovo.” But it’s also populated organically. As I use Confluence, Jira, or Trello, whatever it is, I’m pasting links and telling you, “Okay, here’s the related design for it,” and pasting a link. As teams work in our products, we populate the graph and understand these nodes and the relationships between them.

When it comes to users building an agent or asking a question, there are sort of 2 or even 3 parts, if you count general knowledge, but let’s put that aside for a second. There are mostly 2 parts. It goes like this: when you say, “Give me a status update about everything my team did last week.”

When you break that down, that’s a pretty loaded statement. “Status update” needs a definition. What do you mean by status update? It might use LLM general knowledge. Maybe in your organization, you’ve already got some documentation somewhere that it has access to that says, “This is how we define what a status update is,” or, “This is what our status updates look like.” So it’ll probably use some of that.

“My team did last week.” My team—okay, how does it know what your team is? There are implicit and explicit signals here. We have a team construct in our portfolio. Millions of customers, on a daily basis, create squads in our system to group work together. We can traverse that: there’s the team relationship, and that team is connected to its members, who that week created these 5 Jira work items, these 4 Confluence pages, these 3 Figma designs, whatever it is. It traverses that tree and could give you a blue-links response. RAG would be a terrible solution to that problem because we’d give you the top 5 documents and then try to summarize the status of those.

In scenarios where you might ask, “What is my team’s status update for that week?” the graph solution is much better. We want to traverse all the objects, give you the summaries, apply the organizational context, et cetera. But in scenarios where you might ask, “What’s the process for taking annual leave in my company?” RAG is probably much better. You don’t need to traverse the graph for that.

So I think really good AI in a business context needs both: a set of RAG techniques, but also a way to traverse very structured information at a much bigger scale.

Yeah, that’s great. 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. If I’m just randomly putting in links, you’ve got the job of figuring out what this is in the first place. You’ve got a lot of different instances where an entity will pop up, so you’ve got to do that disambiguation or reconciliation.

Then you’ve got the background process of mapping out all these connections as well. At runtime, what they were doing was still pretty early. There was a research project back in the HippoRAG days, but they would identify through semantic search which entities were relevant. In the case of my team, that might just be fully explicit. But then they expanded the search radius through the graph: you could expand it 1 node out, 2 nodes out, or 3 nodes out, and then that became the universe in which you would do your semantic matching.

And you can have that. I always thought that was inspired. You can have those single- and multi-hop traversals 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, we’re fortunate here—is that we’re capturing some collaboration graph as well.

We have a separate graph that’s kind of the collaboration signal. When Nathan likes my pages or comments on my issues, 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. You would layer any user-activity signals of collaboration—who worked with whom, as well. I shared a page with you, you viewed this content but haven’t viewed this other content, and therefore we’re more likely to show you the content you haven’t viewed if you’re asking for something like that.

An additional layer you can add on top of that is just those collaboration signals. If you can use them, they make a huge difference to the results.

Yeah, that’s cool. How do you think about it? It might be too early for this, but one thing I’ve occasionally noticed in products is that sometimes they need to forget as well as remember. If you took my whole work history, you would find that in certain eras I collaborated very closely with certain people. 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.

Most folks who’ve rushed out to build any sort of AI memory system—retrieval or whatever, however far they’ve got—have mostly just tried to get it to work for right now. There hasn’t been much thought about how this evolves over time, as everything always does. How do we know when to let go of things?

Maybe you could get by just saying, “The last interaction with this person was whatever,” and 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 I’m wondering what thought you’ve put into allowing the system to evolve and let go of things that it no longer needs as much.

Yeah. That’s particularly hard for organizations. Again, open by default actually makes this more challenging. You could argue that it makes it better in some ways, but it also makes it more challenging because now you’re getting 20 years of content, and who knows whether that page from 19 years ago is still relevant.

I actually ran into this in the early days of Rovo. I remember doing some testing and playing with things, and I asked it something about rewriting my team’s charter. We were kind of setting a new team charter, and I said, “Rewrite my team’s charter using my goals.” We have a Goals app where you can track goals, OKRs, and all that stuff. It picked up a goal I had from 4 or 5 years ago, in the early days, and I thought, “Wait, where did you get this from? I haven’t worked on that for ages.”

That’s a really good example. The goal was still active, so I hadn’t cleaned up the data to mark it as inactive, and it just assumed that was the case. Since then, we’ve added a bunch of signals. Just to use that as an example, we’ve touched on user activity and collaboration activity being key ones.

There’s a lot of decay for content that might be older, that you may or may not have collaborated on, depending on the context of the query you might ask. But it also highlights the importance of ensuring that the data you connect is useful to some degree.

I had a customer the other day say, “I’m going to connect all my SharePoint to Rovo.” I said, “Sure, go ahead,” but I asked, “How big is your SharePoint?” He said, “Some ridiculous number, like 1 TB.” I said, “Do you even need that?” He said, “I don’t know.”

You could do it, and it’ll try to decay and create gravity over time, depending on what it is. But it does highlight the whole “garbage in, garbage out” motto. There are ways in the system where we try to decay things based on time-based activity, your interactions with objects, et cetera.

There’s also the true definition of the object in the system. In this case, I had a goal that was still active that I hadn’t touched for a while. I probably should have just gone and archived it, and I didn’t, as an example. So there’s a mix of things we try to do, but I also think that as customers connect data to different systems, it’s something for them to think about: Does the system you’re connected to 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.

I think that’s an important aspect for folks to think about as they pick their AI solution.

When it comes to 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 that?

My starting position used to be, “Use the best model available. Don’t worry about cost. Maximize performance and optimize cost and latency from there.” 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.

I think we do now have models that are, for many use cases, overpowered, and that wasn’t the case when I developed that guidance. How do you think about the overall optimization problem of cost, latency, performance, and other intangibles that are maybe also worth considering? I assume that has to start at a value level, but then obviously gets operationalized in detailed ways, too.

Yeah. I could probably answer that in 2 different ways. There’s what we do internally as teams build AI features in our products, and then how that applies to customer applications and customer thinking, if that’s useful.

Internally, it’s very similar to you, especially in the early days: just find fit. Your priorities are to make sure the thing’s useful. If you’re spending more time trying to optimize the cost—and you can manage costs with controlled rollouts and all that kind of stuff—and you haven’t even found fit, you’ve got it the wrong way around.

I always say, “The riskiest-assumptions test—the RAT test: start with your riskiest assumptions first and do whatever you can to debunk that. Then move to your next one, move to your next one.” Most of it is, “Is the feature I’m building valuable?” Go ahead, test it with customers, and whatever. So we’re a bit more liberal in that process. Go ahead and do whatever you need to do.

I will say that, as we’ve developed more AI features, I couldn’t even count the number we have now in our portfolio. It’s kind of rewriting the whole app, assuming AI is now always on at some point. There are probably well over 70 or 80 things across my main apps.

There are some clear patterns that we have learned time and time again where you’re like, “You know, you don’t need this.” The way we solve this internally is that when teams need to build an AI feature, they often get complete free rein in the early days of the discovery process.

At some point, they’ll talk to our ML team. We have an AI gateway, and we have a mix of locally hosted models and models in the cloud. There’s a ridiculous number of models in the AI gateway, which is a proxy, so we can swap models and test different things out.

Depending on the use case, we’ll probably take those workloads—those AI workloads—and run them locally on an open-source model or use a model in the cloud, 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 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 applies there.

The good thing for us is that, as more and more of these AI workloads are used, I guess the cost keeps going down, and we keep passing that value to customers, which is good. 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, 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 our biggest, 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, “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 good instructions.”

They just go and orchestrate a bunch of agents in a business workflow. That one is fascinating because you'll get customers that will probably 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 coming in. There are ways where our orchestration framework—our automation orchestration framework—lets you do some strong, more deterministic comparison of the content of what's in the ticket.

For example, there are 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.” 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.

Some customers will be like, “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 the compute and tokens for that—it’s just not worth it.” You're using something a customer described to me once: “I've got a rocket launcher, and I'm swatting mosquitoes with it.” I was like, “Yeah, that's probably not a good use of AI there.”

They'll use the more deterministic functions in our orchestration framework that let you do specific string manipulation or comparison, or whatever it is. That's a way better solution there. From a customer's lens, there are some skills to be learned in building tailored agents and deploying them in workflows.

The question is: When do you need an agent, when is a large language model and organizational knowledge appropriate, or when could you do something a bit more deterministic on the functional side that's much cheaper to execute and run, and also more effective from a performance perspective because it only does one job, right? That's a skill that I'm finding many, many organizations are learning as they're deploying these agents, and we try to help them with tips, tricks, techniques, and content.

But I see that as an ongoing journey for a while for a lot of them, because you're like, “I can solve everything with AI,” and you're like, “You don't need AI for that one. That's 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: Anything that can be done with traditional code should probably be done with traditional code. It'll be faster, cheaper, and more reliable. Though even things as simple as writing a regular expression—nothing makes me feel stupider than writing a regular expression—can be tempting.

The right way to go there is to have the AI write the regular expression for you. But sometimes it's tempting to just have it do all the work itself.

But on that example, real quick, our agent framework lets people create skills that the agent has. 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, does math, checks the bill details, or whatever. That's very specific and can be bespoke to the business.

So someone writes some Java code, or whatever it is they want, and they code that as a skill for the agent, put that in a business context, and off you go. But it's a process of discovery for customers. I think people start and go, “Oh, this is amazing.” Then they're like, “Wait, sometimes it didn't give me the right results, but in this specific scenario I wanted it to follow these 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? Where are you using proprietary models? If you wanted to name brands, I'd certainly be interested to hear that breakdown.

I'm also interested in your take, and maybe what your customers are signaling to you that they care about when it comes to which kinds of models come from sources trusted enough to be used or not.

Look, I don't—I'm actually just pulling up the dashboard to give you a number. It's in the ridiculous millions, probably billions of tokens. I have no idea. It's a ridiculous number. I remember we used to have a dashboard with all the tokens consumed and created. It's kind of pointless now.

On the model thing, I am seeing a huge trend from a year and a half or 2 years ago—“I want to pick the model. I want to pick the model. I want to pick the model.”—to now, where the care factor just—it’s like, “Oh, I realize it's like me saying I want you to use Postgres, not MySQL.” I mean, all the big expected models are there: ChatGPT, Claude, Anthropic, all that stuff.

I couldn't go into details of all the models; I'd probably get it completely wrong. Name the model, and we're probably using some variant of it in some way. We have a fair bit of transparency with our main AI features. We publish docs on what the feature is, what model it uses, and so on, for the big items.

But everything from GPT, Claude, and Mistral—it's a mix of stuff. Honestly, maybe the takeaway that I have for software vendors or software teams, as I always say, is that it does pay off to build a model gateway or have a solution where you can proxy models.

If you believe that layer is being commoditized, and there are lots of models, and you want to choose the right tool for the job, then, to help you move the fastest, you need to find a way to learn, switch, work out the best use case and cost optimization, and do it that way. So that's certainly something I would recommend to anyone building software. It's paid off by orders of magnitude.

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. I can totally see the use case for verticalization of models—a DNA-sequencing model that's just trained for healthcare purposes, that kind of stuff. I could totally see that.

I just think the average knowledge worker—most of our customers are sitting at a desk, using content to create content, or working in a finance department, HR department, marketing, customer success, whatever it is—the general-purpose models are easily solving 80–90% of the problem. We're seeing that desire for model selection just decline over time, which has been pretty good.

You will see, though, that there is a little nuance here that's important. For those building agents that are setting up their own testing and evals, model stability is important for them. It's like API stability: If you swap the model overnight, you're probably going to get a ton of different results. That's a 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? The answer I came up with is that we build UIs because we need input from the user. We need access to the user's intelligence, taste, as you noted, or 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, if they didn't need anything from the user, then the software in general would run really fast. 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 who have software products and are trying to figure out how to use their AI layer, that the AI can in many cases be sort of a substitute for the human who would otherwise use your software. One kind of true north goal is 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. And so if you can start to abstract those UIs into tasks for the AI to do, sometimes maybe you bundle them or redraw the borders around them for who knows what various reasons.

That seems like a good mental model for people who 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—probably days, weeks. I love to look at history, tech history, and try to find parallels. Nuances are important because some parallels don't apply and some do.

But if I could rewind back to some of your more mature listeners—to the MS-DOS terminal days, before Windows existed, for those of us who remember the terminal, DOS, or whatever, or the Mac terminal—the terminal 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 math, you could type a Word document, you could draw ASCII art if you wanted to, and so on.

But we learned very quickly that it was actually the worst interface for some use cases. Over the years, we built verticalized apps on top of the terminal to do word processing, image generation, spreadsheets, audio, podcast recording, and so on. We're now talking in a dedicated interface that's built on top of the browser and on top of the operating system that solves this problem. The universal interface is still just commands and a terminal, with some higher-level programming language on top of it.

Apply that to AI. I always go with the phrase, “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 was the aha moment: We can predict the next thing. So, let's go with a conversational UI. The best way to get it predicting the next thing is conversation.

Our UI construct for conversation is chat. Just like society and history, it's chat for everything. I do believe—and I would argue that I think we're already seeing it—that chat is not the universal interface to all AI. I think we'll see a spike in a crazy amount of chat usage as the primary way to do anything in a UI.

Over time, as we start building verticalized and more specialist solutions—which are still humans interacting with AIs—they'll be in dedicated experiences on top of chat. That doesn't mean chat will go away. It just means that, like, I use the terminal less and less every day. I don't code anymore, but every now and then I'll open it up to do something. Most of the time, I have a dedicated experience that's far superior for me to solve my particular problem.

I think the same thing will happen with AI. The example I like to tell teams that are building an AI feature for any of our apps is, “What's your AI feature?” I bet nine times out of ten you could build the poor man's version of it in a prompt, without the UX on top of it. Is that true?

They would say, “Actually, yeah, 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 so on. But you can almost fake any AI feature in any product through prompting. It's the worst experience for it.

Then you run into this: If that's the right conclusion, then I reach the conclusion that we're going to build specialist interfaces on top of that. The second thing people often say is, “Okay, but AI will dynamically generate a specialist interface all the time.”

I don't believe that—yes or no. Again, nuance is important here. For form input, potentially, but it has to be a pretty predictable form input. Try filling out a form via a chat interface; it's a disaster. How do you do form validation or conditional form fields? There are a ton of issues there.

Now, could AI dynamically generate something every time? 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. There is some variance in how they learn the tool and how they use it, but they want predictability.

I do believe that there will be lots of specialized user experiences built on top of AI that will effectively be a conversational back end—a user-conversational API back end—because that's the interface to these large language models. But it will be in a dedicated interface.

The example I used last week was my son. He loves vibe-coding games and stuff, and he's been geeking out with Leonardo AI. I don't know if you've played with that, but he uses it to build image sprites for games, to make little characters for these little tower-defense games and stuff like that.

Could you ChatGPT that in a terminal and a chat interface? Totally. Is that the worst interface for doing dedicated, predictable UI graphics of sprite variants, different sizes, and so on? Yeah, it's terrible. You would rather have someone who has thought about the problem deeply design an experience that is still AI-native but is really around building basic-level UI constructs with slight variances: the character moves their hand here, or carries another weapon, or whatever it is they're doing.

It's a fairly sophisticated interface, but it's designed for that. It's a good example of a vertical user interface that's built just for AI.

That's a long answer saying that chat is the universal interface, but it's the worst interface in the long term. I do think that humans will always be interacting with specialized software on top of that. It's not to say that some of the software won't just disappear—you don't need it anymore because you can now use it in chat. I think that will happen in all things.

But I think we just end up creating more and more software. The explosion of software has only increased with the cloud, and it's increasing even more with SaaS. People are just creating better interfaces. So we 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 the explosion of software. Are we going to see a proliferation of SaaS? Obviously, there are a lot of different reasons people build SaaS software. I think one pretty common one—and I think this applies to some of Atlassian's core products—is that the software encodes a way of working that is known to be effective.

For something like Jira, it does these functional things: it takes information, stores information, allows you to search, and so on. But what made that really transformative for so many teams was that it guided them to work a different way than they had been working before. Instead of the old waterfall model, they were actually able to do agile because the tools they were using were set up for it and naturally steered them in that direction. It created habits, reinforced habits, and all these sorts of things.

If that is right, I wonder to what degree AI changes that—potentially, a lot. When you first apply AI, you think, “Okay, I have this task of triaging tickets. What are the inputs? What are the outputs? How do we make this decision? Let's get all the examples. Let's evaluate. Let's do all this stuff.” Great. Now we've got an AI that can triage a ticket.

But the next level up is, obviously, if we're using AI to answer the tickets, do we even need to triage the tickets? Maybe we just answer them all immediately as they come in. We don't necessarily need to have that step at all. So we could do the Elon Musk thing: The best part is no part; the best step is no step.

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? How much should we instead be thinking, “Actually, they might ought to work a quite different way from the way we work,” and maybe the SaaS tools that we have 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 by giving it skills or tools 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, the real value of Jira is—it's funny, it's the classic, “Oh, I vibe-coded a to-do, in-progress, done app. Okay, I've replaced Jira. It's done.” You're like, “If that's what you're using Jira for, yeah, sure. You probably weren't using Jira. That's what you're better off doing.” There are a bunch of other issues with that, like how you maintain your own software and scale it, but there are a bunch of issues.

The real value of the SaaS tools that model a workflow is the value that the customer has created by modeling it in their world. Jira's value is in making it theirs. 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.

Otherwise, everyone just ends up with the same organization. They model their business workflows: how they build products, how they do customer service, how they respond to change and track incidents, and 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 employers and employees want even more control to define how they would like the AI to work. As we said at the top of the call, taste is important.

So my logical conclusion there is that agent orchestration with human workflows becomes a pivotal thing that every business needs to do at some point. What does that look like? Humans need to decide what they would like to do, what they would like their agents to do, how they would like them to do it, and what they will do, what the agent will do, what their other colleagues will do, et cetera.

That problem-definition space of applying AI to a business workflow—I don't subscribe to that world where you'll just give it to AI and it'll work out everything, because then you end up in the AI slop world. You're like, “Okay, well, basically everyone has the same thing all the time, every time, and everyone's company works exactly the same way.” Which, by definition, isn't true, because everyone's company builds different products and different services.

I can see how people follow that reasoning, but the reality is that the most valuable thing a business needs to do is give its human teammates and its virtual teammates tools to do their jobs and design the workflows in which they would like to do that. 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 will always change, and that has changed for as many years as I've been doing this.

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 you believe that chat is the only interface to all interfaces, that won't work. I just can't see that world, given the amount of crazy specialization there is in the world.

It's just unbelievable, right? You look at the crazy explosion of legal AI tooling. It's so specialized. 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 to legislation by country, by geo. Could he type a prompt and try to solve similar problems? Potentially, but it's a disaster. To try to build any business that does that job at scale, you're going to need specialist tooling. I just can't see that world.

The only other counterargument to my argument is that I always challenge myself with, “Oh, but AI could dynamically generate that interface.” I'm like, sure, but at some point that needs to be predictable and scalable for employees and people to work with. Then you end up building verticalized SaaS software. You end up getting to the same outcome of a verticalized 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. We're starting to see some interesting, very small teams with pretty notable scaling success, but no one-person unicorns yet, to my knowledge.

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 that you could build a one-person unicorn with today's models, but the next generation or the generation after that, it starts to become at least something people think is more realistic. Maybe you think, “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 I kind of think that is probably my best guess. There's also the possibility of an intelligence explosion. That's a whole other thing. But it seems safe to me to believe that we're going to get to something that is genuinely better than people at almost everything, almost all the time.

But then I guess I just wonder: enterprises want control. That's a deep value or a deep reflex, but does that set us up for a world where that works against the enterprise at some point? If they're like, “Can we put these agents into these boxes and have these workflows? We need them to do these sort of point things in these prescribed ways,” 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 that, in human teams, obviously we're all different, right? 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 the way down.

And so I think, again, that's kind of one of the reasons we have all this software: because people can't keep all that structure in their heads. They can't just have 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 constraints and all these sorts of things in place. 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. I was talking to a five-person startup doing 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. It's 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 try to critique it and give it feedback, et cetera. So they have this content-creation machine that's just pumping out content to do that.

The first point is that even those one-person unicorns are orchestrating AI agents in a workflow to get stuff done. I think that's my first point: 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, when you talk to those people—at least when I talk to them—they're the bottleneck, and 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 are like, “We have more ideas of what we want to build than people to build it and agents to help us build it.”

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 remain as they are and be the bottleneck.

If they're running a smart business, they would realize that talent is a scarcity, and they probably want to grow at some point. It doesn't mean each person can't do a lot more than they ever could before. So that's probably the second point there.

The third one is really around something that often gets excluded—not a major talking point—but there are so many regulations and industries where compliance just needs to happen. There is a whole cohort of the market that literally cannot move without some sort of intervention there from a domain-expertise human. Even with AI stuff, I'm sure there'll be regulatory implications.

The last one I keep coming back to, Nathan, is that I just still don't believe that a 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. Again, my definition of slop is that it produces something good but just lacks any creative diversity. So everyone's getting similar things, because that's how these models are designed to work.

And you can do it today. You can type the same prompt in 7 different tabs of different AI tools, and you're getting 80% the same. Therefore, for that person to actually become a unicorn, maybe they just get to the market and capitalize on their slop first, but then the second unicorn will look too similar. So they'll have to put in a lot more effort into avoiding that slop.

How do you do that? It's really just about the human process of making AI yours. I don't see a solve for that. Other than just making it yours in some way, how do you make it yours? There are a million things: voice and tone, taste, content, context, et cetera. I just don't see that going away at all.

I think that’s what makes us human and what makes us crave different things and like different things because of how we think, 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: figuring out how to build workflows, basically. You might, in other contexts, call that systems thinking or system architecture, process design, or process architecture. I have found that skill is very natural to some people and very unnatural to others. What have you learned about how to teach that skill? How should people practice it?

What can we be—if this is the thing, right, where we’re going to be going from doers of things to architects of how things get done? The next logical question that people love—it’s spicy, and you probably hear this all the time—is, “Well, does that mean I don’t need as many junior staff anymore? It’s just the senior staff who get the architecture stuff, right?” I think that’s also related to a question I find comes up a lot.

We always forget how good of a teacher AI is. It’s arguably the best teacher of all time. I always think about the product management craft at Atlassian as an example. We’ve deliberately changed our hiring profiles in terms of which seniority and which people.

I make the joke that those kids who are cheating in college and university—we want more of them. They’re coming in as AI-native; I need a better phrase for that. But the reality is, they’re the ones already starting to think about how they can use AI to their advantage the most, even though they have less domain and industry experience. The ones who are doing that are using it in their personal lives, and it feels native to them.

My son, if I observe him—he’s 11 years old—has gone from Scratch coding, which is a visual coding language, straight to vibing. He hasn’t had that middle section of learning about syntax and code constructs, whatever. He geeks out every now and then, but he hasn’t yet had that.

His Roblox got upgraded the other day. He’s got this Roblox Studio where he codes stuff, and he’s like, “Dad, Dad, that AI thing just appeared in Roblox.” He runs into my room, and I’m like, “What are you doing?” He’s just typing and vibing away and doing stuff.

That’s becoming the skill he’s learning: how to instruct AI to get what he wants. If it doesn’t get what he wants, he’s learning how to instruct AI to teach him to explain what it is he’s after.

I will say this: this whole doing or being the architect of the thing—one logical conclusion that’s incorrect, I would say, is that 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 are probably still doing things the old way because it’s the quickest and easiest.

I struggle with this. 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, may require more time, or may fail, but I may get a better outcome. That behavior change is really hard. Where in our workforce are we easiest and best placed to instill behavior change? When someone’s new to any role, that’s a great place to do it.

The biggest thing to be aware of is that AI, as a teacher, is an excellent tool to help with that. The second thing is, yes, we say more people go to being the architect of the thing, but there’s also an equivalent number of people in the workforce who are reviewing the thing—who aren’t yet architecting the thing but are also building knowledge to then become architects of the thing.

Right? The person architecting the workflow for that procurement team I gave you as an example is usually one person who sets that up and decides how it works. The humans are still reviewing the contract proposals from the AI, but they’re also building domain knowledge and a sense of what’s good and what’s bad taste. In doing so, they’re also becoming architects over time. I think their growth still continues, even as people who are reviewing the results of AI.

Speaking of new teammates, Atlassian bought a browser company, and it’s literally The Browser Company. Kind of a 2-parter around this one: 1, the goal, as I understand it, is to build the browser for knowledge workers. I’d love to hear a little bit more about what the vision is for that—what you imagine that ultimately looking and feeling like.

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 team, tech, and traction, but this is such an uncertain world for so many reasons. Is the tech that some startup has built today going to endure in the way that we might have been confident it would in past eras? Is the traction even right?

I mean, we see these super-fast, basically vertical revenue-expansion stories, but then we also wonder, what happens to Cursor, for example, if Anthropic decides that they’re going to allow their next model to be used only in Claude Code for a few months when it first comes out?

I just feel like, to so many companies, the feeling is, “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 an analogy to help with that, one that I kind of use in my head: we’re not trying to compete against your everyday browser for consumers browsing the web, doing shopping, planning their next trip, buying some dress, or whatever it is.

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, “Hey, we need to build assuming AI is always on and available, and you’ll get a very different Jira from what you did back then, right?” That’s our mental model.

In this particular example, early messenger days are a parallel example: AOL Instant Messenger, ICQ—I still remember my ICQ number. There were messaging tools that were largely used in a consumer context. Now, we—the industry, meaning we as 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. We ended up with channels as a way to reflect organizational and team structure. We ended up with integrations as a way to integrate with different systems, and business workflows modeled in Microsoft Teams channels or Slack channels, et cetera.

Permissions and control became more important, so we actually ended up with very different products from the consumer messaging products. Still, I would argue today that consumer messaging products look very different from business products.

We believe the same thing is happening in the browser context for work. If you reset the assumptions about how people work every day with a wide variety of different SaaS tools—why do they go to the different SaaS tools, and what tasks do they do?—then there are a bunch of different things we need to do to get to that outcome.

That’s a bit of an analogy that I use. 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, which will be quite different. I think the same is applying a little bit with personal AI and work AI as well. You’re seeing more and more of that: personal AI productivity in a personal world is quite different from a work one.

I think The Browser Company is already thinking about this—Josh and Tim are thinking about, 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 similar problems, but in a work context?

We end up with quite a different interface and quite a different experience. I think the opportunity and the vision there are really about 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 from what it looks like tomorrow for knowledge workers.

That’s an exciting and moving space, but it’s also just a fun space. As someone who’s been in tech for a long time, when assumptions reset, it’s such a clean slate to start thinking again. We went through this with the e-commerce days, the cloud days, et cetera, and mobile. So it’s always fun.

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 the question: look, there’s a mix of that. There’s an AI fog—investors and companies are struggling with, “Oh, look, how much of this is reproducible overnight? How much of it is not?” 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 in analysis paralysis. You go, “But the trajectory is here,” and so you're 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 from 80% of something to 100% of something?”

To get from 80% of something to 100% of something that's market-specific, vertical, domain, or niche is a massive investment. And I think that is certainly, again, depending on what your listeners are thinking about, something where you're like, “Okay, if it's a vertical and I can see that the team has put in effort to get to that, what I could do with a general model gets me 80%; what I could do with a general AI tool—but what I get 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 teams is—I use the phrase “workflow proximity.” There's user workflow proximity and buyer workflow proximity. Those 2 things are pretty important for thinking about these things: user workflow proximity and buyer workflow proximity. Asking, do we have a right to win in terms of how users work every day? This is more for the PLG-style discussion.

For example, I could go build some AI tool to help with calendar AI, automatic scheduling, tomorrow, as a random individual. Who's probably going to win that space? People that already have people using calendars. So, I would either build to get acquired or build with the hope that I could somehow steal market share and then start with a new calendaring system. That seems like 2 epic, big hops to take, right?

So, asking about workflow proximity is asking, where do the users exist today? I then always say, for that job to be done, draw Maslow's hierarchy of needs for that job to be done. You want to be as close to the bottom of that pyramid as possible for that vertical, because that player is in the best position to move to the next layer of the stack and to the next layer of the stack.

In the calendar example, you're like, “Do 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. That's fine. So, I always think: user, user, user. Buyer workflow proximity is 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 user workflow or more buyer workflow? And then where are they in the stack of that job to be done? Are they at the top? Once I've done these 4 things, I need to do this 5th thing. That's a dangerous spot to be in.

But it might be good if, again, it's so nuanced. Depending on if the market's big enough, you might think what you're doing is so specialized that they might 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 whether we're going to see a software explosion—or whether we might, 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 give you a spectrum: how much more of this would I buy if it were functionally free?

On the low end is dental work. I would buy no more dental work even if it were free, right? I don't want it. You don't enjoy it. I'd like to avoid it, you know. And accounting is less painful than dental work, but I would probably pretty much buy whatever I'm required to have and probably not much more. Some people might buy a little more, but I think most people have roughly that attitude.

On the other hand, massages—if they were freely available all the time, I'd probably consume 100 times more than I currently consume. Maybe even more than that. Where software is on that spectrum, I find quite hard to figure out. 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? What's your intuition? Because I do think it's going to get a lot cheaper, and in terms of the future of the industry, it seems like I just don't know how elastic demand really is.

Totally. The massage is 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. We could slice this so many ways, so let's just say we slice it into B2B and consumer. Consumer honestly feels like a massive pool. Look at our lives: entertainment, leisure, home renovations, whatever, cooking, and so on. I feel like that continues to grow.

Especially—and sadly so—there's also the business for attention, which exists, but it is what it is. I just can't see that shrinking in the world of AI. I think in the world of AI we have to ask ourselves, as a society, 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 the unreal 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?” That was already AI. I just can't see that shrinking in the business. Again, if you go business by specific vertical, etc., but the general thing, I go, “Okay, well, AI looks better with the more tools it has access to.” Tools are things that humans need to build or tell AI to build. I don't think that goes away. We need to build those tools for it to have access to.

The 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 stack. 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 is 1 tool. The calendaring app to an AI is like 50 tools. Find time between Sherif and Nathan that works in this time zone is probably 1 tool that you give it. Find time between 2 people and block busy time is another tool. Get public holidays is another tool. There are 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 and granularity with which we need to design things to get a better outcome than it is for humans. And so I reached the conclusion that 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 AI calls? Yeah, it will, and it is changing, and the business model will change over time. If I look at the App Store as an example, Apple's got a big push right now with their app vendors of, “Hey, spend time focusing on building App Intents over UIs.” App Intents is their sort of skills and framework. If your app kind of does these things, then I guess Siri, or whatever the new AI ends up being, can use that as a tool. 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 software continue to explode. But maybe the more useful discussion is having it by market, by domain, because then you could see, okay, automotive software might be totally different from software for reviewing and tracking official document signing or compliance or something like that. That might change. 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 okay but maybe getting a little stale, are: leaders should lead by example; make sure everyone gets hands-on; highlight individual creativity and success stories; make AI adoption a part of performance reviews and evaluations. That's maybe 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 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. 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 look at tech history that when a technology wave came, when we used it in our personal lives, it ended up impacting our work lives much more strongly. 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 your—I'm just going to run through my use cases. 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, and so on.

Actually use it aggressively there. If you have children, oh boy, my use cases explode here. I have an agent that helps my son with his math homework. It doesn't give away the answer, but it knows the school curriculum for his grade and year, and he talks to it while it helps him walk through an answer in a very personalized way. We put some Fortnite jokes in there and stuff like that that he likes to do.

My daughter 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, “Look, I pressed summarize or I wrote an email,” and you're like, “That's a great start.” I actually love asking this question in job interviews.

Some of you personally use AI, and you'll see things ranging from planning a trip to redoing a whole-house renovation with it. It's basically running the show for me. I recently had a sporting injury to my MCL, and I'm seeing a physiotherapist, but I've also got an AI assistant that reminds me every day of the exercises I should do. It checks in on me and also asks what I ate, and it will tell me, “Is that good or bad?” I've spent time prompting it to ask, “Are you helping me heal as quickly as possible?” and doing that kind of stuff.

The second thing, on mandating or getting others to do it, is that 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, “Do or die, or get out of here.” I generally think that if I hear the mandate message, it might help some people with motivation, but the vast majority of your workforce probably sees that as a threat.

But again, the nuance in these conversations is where all the value is, Nathan. We just ran an AI Builder Week with 1,000 product managers, designers, engineering leaders, and researchers. We blocked time off synchronously across the crafts, so it was no longer some person on some team taking a few days to tinker with this thing.

That person feels guilty if they come back with a failed project. They feel like they're blocking the team when the team is asking them questions about their day jobs, while they're over here trying to explore the new thing. So I always say, find times where multiple people who work together can block their time so they're not dependent on each other. What you're celebrating is the learnings, not the actual outcome. The outcome is the learning, not a product outcome.

Tinkering is the most important thing they need to be doing. Applying AI in their business workflows, whatever that may mean in their department, is something for that team to go through the process of discovering themselves. That's the best way they'll be able to do that.

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,” or whatever, while you're sitting there exploring and trying to discover this killer use case. They'll pull in someone who tries to imagine use cases. I'll often say, “Who in your company is doing some step of that today?” No one. I'll be like, “Forget that. Just throw it in the bin. Throw it in the bin yesterday.”

Find me a team and what they're doing today. Let's write down exactly what they're doing, and let's walk through it. I always say, for any specific task, write down the steps for each task. Then, within each step, what are the specific knowledge, instructions, and actions the human takes to solve that step? 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 and deploying them in a much more effective way.

I think your advice, Nathan, at a high level on tech is great. I think where everyone struggles is the next click down. I couldn't tell you any other killer advice other than saying that the next click down is often what's missing: “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 that people can look up. We try to open-source some of these frameworks for how people can apply in their teams. But definitely go and do that.

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

No. My only encouragement is to just look at your days outside work and play and try things. I think that's what will change your behavior, and that will probably also change your behavior in your workplace over time. You'll find that you'll start to use that level of thinking when you get to your work.

That would be my biggest encouragement: ignore all the buzzwords and all that stuff, and just try. When you're fixing your tap next and you need to take a photo to understand which washer is which, or whatever it is and how that works, just find a way to tinker.

Thank you. Thank you for your time, Nathan. I really appreciate it.

Sherif Mansour, thank you for being part of The Cognitive Revolution. See you. 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, cognitive revolution.ai, or by DMing me on your favorite social network. The Cognitive Revolution is part of the Tarpentine 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. 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.