Escaping AI Slop: How Atlassian Gives AI Teammates Taste, Knowledge, & Workflows, w- Sherif Mansour
Sherif Mansour, Head of AI at Atlassian, discusses integrating AI into enterprise software for non-technical users. He shares a framework to avoid "AI Slop" using Taste, Knowledge, and Workflow, and explains Atlassian's "Teamwork Graph" for complex queries.
Watch Episode Here
Listen to Episode Here
Show Notes
Sherif Mansour, Head of AI at Atlassian, discusses bridging AI agents with massive-scale enterprise software deployment, drawing insights from Atlassian's millions of non-technical users. He shares his framework for avoiding "AI Slop" using Taste, Knowledge, and Workflow, and explains Atlassian's "Teamwork Graph" for complex enterprise queries beyond RAG. The conversation also explores the evolving relationship between AI and UI, and the shift from humans as workers to architects of AI-driven processes. This episode offers practical wisdom for both AI engineers and business leaders navigating the future of AI-enabled organizations.
Sponsors:
Framer:
Framer is the all-in-one tool to design, iterate, and publish stunning websites with powerful AI features. Start creating for free and use code COGNITIVE to get one free month of Framer Pro at https://framer.com/design
Tasklet:
Tasklet is an AI agent that automates your work 24/7; just describe what you want in plain English and it gets the job done. Try it for free and use code COGREV for 50% off your first month at https://tasklet.ai
Shopify:
Shopify powers millions of businesses worldwide, handling 10% of U.S. e-commerce. With hundreds of templates, AI tools for product descriptions, and seamless marketing campaign creation, it's like having a design studio and marketing team in one. Start your $1/month trial today at https://shopify.com/cognitive
PRODUCED BY:
CHAPTERS:
(00:00) About the Episode
(03:56) Atlassian's AI Vision
(08:27) Trust, Authenticity, and Slop
(14:10) Taste, Knowledge, and Workflow (Part 1)
(17:33) Sponsors: Framer | Tasklet
(20:14) Taste, Knowledge, and Workflow (Part 2) (Part 1)
(29:51) Sponsor: Shopify
(31:47) Taste, Knowledge, and Workflow (Part 2) (Part 2)
(31:48) Technicals: RAG vs. Graphs
(40:48) Forgetting, Cost, and Optimization
(52:28) The Model Commoditization Debate
(55:12) The Future of AI Interfaces
(01:02:44) How AI Changes SaaS
(01:09:43) Debating the One-Person Unicorn
(01:16:17) Becoming a Workflow Architect
(01:21:39) The Browser for Work
(01:33:23) How Leaders Drive Adoption
(01:39:26) Conclusion: Just Go Tinker
(01:40:08) Outro
SOCIAL LINKS:
Website: https://www.cognitiverevolution.ai
Twitter (Podcast): https://x.com/cogrev_podcast
Twitter (Nathan): https://x.com/labenz
LinkedIn: https://linkedin.com/in/nathanlabenz/
Youtube: https://youtube.com/@CognitiveRevolutionPodcast
Spotify: https://open.spotify.com/show/6yHyok3M3BjqzR0VB5MSyk
Transcript
Introduction
Hello, and welcome back to the Cognitive Revolution!
Today, in honor of this week's Gemini 3 release, I'm going to do something that I've only done once before, and that is: read an intro essay exactly as it was drafted for me by AI. I've spoken many times about my intro essay workflow â for the last 2 years, going back to Claude 2 â I've given the latest Claude model a collection of recent intro essays, plus the transcript of the current episode, and given it a short prompt â "adopting the style, tone, voice, perspective, worldview, values, rhythm, and cadence embodied in the attached intro essays, write a new intro essay for the attached transcript." While I almost always edit its output extensively before recording, Claude has always done the best job with this, and to be honest no other model from any other provider has come particularly close.
That changed in a notable way with Gemini 3 â while I haven't tested broadly yet, the intro essay that follows immediately jumped out to me as one of the very best drafts I've ever received from an AI, and while there are a few things I might have said or framed a bit differently, it's clear to me that this model "gets me" from my writing samples as much and probably more than any other model ever has.
So, here goes!
***
Hello, and welcome back to the Cognitive Revolution!
Today Iâm excited to share a conversation that bridges the gap between the frontier of AI agents and the reality of enterprise software deployment at massive scale.
My guest is 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, and while they are perhaps best known for software development tools like Jira, I was surprised to learn that today, the majority of their users are actually non-technical knowledge workers in departments like marketing, HR, and finance.
This gives Sherif a unique vantage point: he isn't 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 three specific ingredients: Taste, Knowledge, and Workflow.
- 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?" that vector search simply can't handle.
- The evolving relationship between AI and UI. We discuss my theory that the "best interface is no interface," and 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.
- And 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 into the nitty-gritty of "process architecture." As Sherif notes, we are moving from a world where we humans are the doers of the work, to one where we are the architects of how the work gets done.
Whether you are 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.
Main Episode
Nathan Labenz: Sharif Mansour, head of AI at Atlassian. Welcome to the Cognitive Revolution. Thank you. Thanks for having me, Nathan. I'm excited for this conversation, and I appreciate that we were able to arrange it, I believe, 16 time zones apart, maybe even 17 hours ahead. You are in Australia, where I'm here in Eastern time in the US. So it's amazing what technology can do. Speaking of technology, Atlassian, obviously a big technology company, but I think probably a good chunk of the audience doesn't have necessarily direct experience with it. So just as a quick introduction, I'll let you do a fuller introduction. $40 billion market cap company, one of the top 100 tech companies in the world by market cap. And that puts it ahead, by the way, of household names like eBay, Reddit, SoFi and Expedia. But very focused historically and certainly in the products that I've used on the software industry. So for those that maybe aren't from the software industry and don't have so much background with the company, you've been there 16 years. How would you introduce the company? And as we think about the AI future that we're stepping into, how would you describe Atlassian's positive vision for the AI future? Yeah, that's a good question. Yeah, I've been here a long time. And certainly, actually, before joining Atlassian, I was a customer myself. And so I saw how it transformed. I used to work for a large telco in Australia, and I saw how the software changed how we work. So I would describe it pretty simply as we're a product company that builds collaboration tools for teams, and we specialize in different kinds of teams.
Sherif Mansour: So historically, we're specializing for technical teams, specifically software and IT teams. And what do they do? You know, they plan projects, build software, deploy it. IT teams run service desks and help desks and provide a service internally. But today, the vast majority of our user base are similar types of work. So I call them people who run projects, but in just different departments, marketing projects, finance projects, et cetera, or people who provide a service to another team in the business. The procurement team inside a big organization provides a service to the rest of the business by helping review contracts or whatever it is. And so today, majority of our users are actually from non-technical departments, HR, finance, marketing, legal, and all that. And really just how about helping these teams. collaborate with each other to get work done. I guess the second part of your question, how does AI fit into it and all that? You know, we've got close to, I think we're three and a half million users of our AI capabilities. I think what's the big shift we're seeing in the change in how teams collaborate is teams are now introducing their virtual teammates and bringing them to the team. And not just at the, I'm not talking about just the personal chat productivity level. It's about you know, a team working together to get a job done, adding a team agent in their context to help them move that work together in a collaborative fashion. So I think we're really big on seeing AI just as a new teammate that helps speed up the collaboration process that teams do, whether they be technical teams or non-technical teams working together.
Nathan Labenz: When you talk about introducing new kinds of teammates, the AI teammate, that is obviously very I think like, you know, a little bit ahead of the curve or, you know, skating where the puck is going to be, so to speak, in the sense that I think everybody, including the frontier model companies, has this vision of the drop in AI knowledge worker, something that you could just deploy, you know, with all the sort of benefits of software and inference of the scalability, the copyability, the, you know, pay for what you need. It's, you know, could be 24/7 or it could be, you know, five wide at a given time, but it can also be off when you don't need it. There's all these advantages. But there's also these sort of rough spots that mean that in some ways they don't quite live up to the same expectations that we have for a human teammate. How do you think about, first of all, maybe just what people most need to know about an AI teammate? You know, 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? Like, should people be mapping AI? Should they be starting from the idea of a human teammate and kind of, you know, creating a fork for their understanding of an AI teammate? Or are they so different that they should maybe, you know, start with a different base understanding and kind of allow that to evolve independently of their expectations for humans.
Sherif Mansour: That's a good topic we are constantly wrestling with. We have this value inside Atlassian called build with heart and balance, which is just really about trying to find the fine line in making a decision or balancing two trade-offs. I think most people would agree nobody wants to talk to something that feels incredibly robotic. And at the same time, I think most people would also agree that nobody wants to talk something that tries too hard to be human and feels unauthentic. So it's like this weird balance of the two. You know, I was just speaking at an event last week and the topic was how much does authenticity matter when you're talking to an AI? And you have to kind of pare the layers back behind that question, which is like, why does someone see authenticity as important and all the way back down? And one thing that comes across, especially with our business customers, is just the importance of trust, especially in a business context. Like if I ask you a question, I want you to be reliable and give me something trustworthy. And so how do you achieve trust in a business context? For us, a lot of it's transparency. If I give you an answer, I need to give you as many citations as possible. RAI, Rovo, we have a whole team that's just dedicated to focusing on improving citations, for example, to ensure that the quality of the response is factual and is pointing to the right sources. But applying it to the agent's topic you brought up, the same token happens here, which is if I deploy an agent and put in my workflow, I want to know how it works. I want to see its instruction. I want to see Who created it? I want to understand what are the last 10 things it's done. So I think transparency is key there to help building up trust, which then helps builds up authenticity, if that makes sense. But I do agree with you in that it is a fine line. We're certainly not sure I'm on the boat of like, oh, yeah, it should just feel like a human teammate. We're not suggesting that at all. It feels like a virtual teammate. And I think humans have an understanding of what a virtual teammate can be in a team context and how that would work. I think we want them to feel like collaborators with us. I think already at the personal productivity, AI level, people are feeling like it's a personal collaborator. In the team level, it becomes more interesting because there's now a team dynamic here, right? So I always say, Every team in every company has like character. And I'm not talking about characters in like human personality character, but like there's a set of in-jokes they have and there's a way they show up to the office or virtual office. And there is types of language they use, voice and tone. And if you're a team serving customers in a bank, you have a very different character, team character, to a team that's working on a marketing campaign for a digital agency for, I don't know, young youth or something. And so it is important for teams to apply some level of character to their virtual teammates. Otherwise you have this weird blend of like, it just doesn't feel like it's part of our team and, or the complete opposite of like, I'm just feel like I'm talking to a robot and this is not useful. The other big benefit that teams get out of that is you probably, I'm sure most of your listeners have heard the phrase AI slop. everywhere. My loose definition of AI slop, because some people say AI slop and they're referring to accuracy of responses and whatever. I think if I define AI slop as something like the output is technically correct, but it's, it's creativity is like lazy, like as in it's, yeah, everyone's getting similar results. Let's, you know, let's call that AI slop. Then how do we combat AI slop in a world where everyone has access to the same tools? We all have access to the same large, large running 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. Like, what is it we stand for? What are we trying to do? How do we talk around here? How do we think creatively? What are the kinds of things we like and what don't we like? And you're effectively prompting your virtual teammate. to try to speak to your team's language. And I think that's critical in teams just not getting standard AI slop at AI. So there is this fine balance of not making it feel like a human, but also representing what the collective group of people are trying to do.
Nathan Labenz: 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 like workflow automation and, you know, making things scale that didn't previously scale. But when reading about the work that you guys are doing to facilitate teamwork and, you know, brainstorming, collaboration, all that kind of stuff with AI, that was the big thing that came to mind for me. So I would love to dig a little deeper into how do you do it, I guess maybe conceptually, but also into the techniques that you're using, like when you And I can imagine a lot of different approaches. But when I bring one of these virtual teammates onto my team, how much is on me as a customer to set it up? Do I write a brief or give them my employee handbook and say, this is how you're supposed to act? How much do you guys go into my data reservoir and look at the way we talk to each other and try to extract patterns from that and have the things sort of-- obviously, we know continual learning is not quite to the state that we think it ultimately probably will need to be for like the most powerful transformative agents everyone can envision. But we do have in-context learning. We do have the ability to go spooling through the archives and kind of try to pick up on trends and turn that into a prompt. So how do you think about mechanically making all that happen?
Sherif Mansour: Yeah, it's a lot of layers. Maybe the first and foremost layer is like-- to answer your first question. There's a lot you get out-of-the-box, but the real differentiator is applying your team's taste, knowledge, and workflows. Well, I use those three ingredients. Taste, I think we've just talked about, which is just like, 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 just might be a lot of prompting or it might be a lot of context that you give it, but you're applying your taste and your opinion to how something should work. Otherwise, we'll end up with the same looking website and the same looking products and the same looking services. And humans, that's just not going to work in the long term. Knowledge is the second thing, which is just, that's where the customer comes in of, Hey, I'm building an agent. What knowledge do I want it to either have access to or be trained on? And there's a nuanced difference between those two things. But often it's like, Hey, I'm the procurement team. One of our customers just does this a lot. I was talking to them 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, and they pull that in, and the agent has access to that knowledge. So the knowledge is the second big ingredient. And the third one's really just how they choose to deploy it in their business workflow. And they might put that into a very rigid workflow, like a Jira ticketing system, where they just go, Hey, when a new work item comes in, I want you to review the attached procurement contract and write your first draft response on it, and then pass the work item to the human to review and to go back and forth with you to then make a proposal for how it should be. And so you kind of have that taste. I always say, like, those are the three ingredients you kind of need in any business. I want to apply AI. And you talk to a customer and you're like, what are you trying to do? And they're trying to think of a killer use case. And I was like, why don't you just stop by just telling me what you do today? Like pick a team, pick some tasks that the team does. What do they do? And you often find those three ingredients of how they apply their taste to that AI, what knowledge they give it, and whether they deploy it in a workflow, some automation tool, Jira or Confluence or whatever it is. It doesn't matter what it is. They just put it in a workflow and they kind of get the benefits there. So they really need those ingredients there. What we do with help is we give them, obviously, 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, Nathan gets very different results to Sharif because the data you have access to is totally different. So search and enterprise context becomes very important. Every percentage better our search engine gets, the better the results get. And the second big thing we have in our portfolio is we call it a teamwork graph, which is just a map of all the entities that a customer has that they've worked on. So we know their teams and their pull requests, or their work items, or their conference pages, or their Trello boards, or their ideas, and how that connects to their Figma designs, or their Google document proposal with a client, or their Amplitude dashboard where they're tracking metrics. And we kind of have the relationship between all of those, which helps us give better results to the user.
Nathan Labenz: So let's do maybe one double click on each of these taste, knowledge, and workflow levels. I start with taste. I mean, what I don't know if this is like something you guys keep a secret if you know how much you want to share. But in my experience, I have found Claude has been the best at capturing my taste. And the main task that I always do that I kind of use as my own personal benchmark for this is writing the intro essay to this show, which listeners have heard me talk about many times. But basically, I have a big PDF with a bunch of previous essays. We'll take the transcript of this one, put those 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, you know, follow those examples and write me something new. I find that Claude has always done the best job at that for me. Obviously, you know, people's mileage varies. But how do you think about, like, 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 it was kind of annoying to go back to 50 different documents. And I did that before I had an agent that I could potentially delegate it to. So it took me however many minutes. And it's like, is this worth my time? Well, I believed it would work. I think a lot of people don't even have the confidence that putting the elbow grease in to curate the context will pay off at all, and so they just don't do it. So I imagine you have to guide people or encourage, nudge, maybe propose whatever ways for them to assemble that context. And then I'm really curious about what's working well for you, and how do you evaluate that? 'Cause this also, 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. We've got so many customers, so many different taste profiles out there. How can this thing adapt to all those taste profiles? How can you even begin to get a handle on measuring that?
Sherif Mansour: That's a really good question. But your example is a great line 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, etc. And so you've given it your taste in between those two things combined. which is a really good example. And you'll talk to customers that will just do the prompt and just go, oh, well, it was okay. It wasn't that great. It was just another thing. So I don't know how much is, in your example, how much is Claude? I do generally believe that all the models will level out and they already are kind of getting the same. To answer your question on how much do we need to nudge customers, a lot. But we do have some unique advantages. We're a bit fortunate here, for example, The more you use our, as you use our AI tool, most customers start with, you always give them like, I'm Egyptian, so I always think everything in pyramids. So like a little simple framework of like AI maturity, like bottom layer. Most people just ask a question, get an AI from an answer. Layer one. Layer two is like, oh, hang on a second. AI can do some work for me and they'll ask it to generate an artifact, like write a proposal for me, write the show notes for me, right? write the intro for me, et cetera. That's like the next big light bulb moment in most people's minds. And layer three is like, oh, hang on a second. In my team's context, I can take my knowledge and take my instruction and then package that in a repeatable workflow that will help me scale and give me either more ideas or improve the quality of something, improve the effectiveness of something or efficiency of something. At that bottom layer, when they start with just the question answers, you'll get some customers that'll be wowed with us doing little work. And I'm always curious. I'm like, well, hang on a second. Why? Because you get some customers that get terrible results. And then I'm always telling me, why are you getting terrible results? The ones that happen to be using, for example, RovoChat, which is our chat tool and our products, we've got in-built personal memory. So over time, we start to remember For me, I like to write with a lot of emoji. That's just my writing styles, a very simple example. So every time I ask Rover to help me with some writing assistance, it often will prefix my headings with an emoji that best reflects that heading, stuff like that. So I'm still feeling it's more personalized because it's more applying my taste to that world. So the personal memory is one big thing that we give customers who already happen to be using our products out-of-the-box. The second big thing we get is And this isn't talked about a lot, Nathan, in the world of AI, especially in the business context, our products are open by default. And I have to explain that a little bit. When you create a documentation space in Confluence or a Jira project or whatever it is, the default is open and you need to decide who you want to restrict it to. And we're trying to encourage transparency and fully flowing information. Now, in a business context, you'll always need very granular permission so you can go as much as you like and control everything. But we have got over like 20 years of history of customers who have been open by default for many customers, right? Like who use our products, have been using it for a while. And so when they, when they're trying to apply taste and judgment and whatever in their AI, they're giving it some context, some documentation spaces, or they're pulling in some extra context. Turns out open by default is a huge advantage when working with AI. Well, let me give you two, like a contrasting example. Imagine you joined a company tomorrow. you asked AI question. In most companies where you don't have any open by default tools, you'll probably get very little or no results because you're a new startup. You have no access to the Word documents that were just created or the Google documents that were just created, whatever. You just don't. Now, unless some IT admin's gone out of their way and changed the default permissions, which is super rare and very unlikely. When someone joins a company and they've got some open knowledge bases by default, all of a sudden they're getting questions answered that would've had to require them to message 50 people to work out the answer to the question, or at least they're getting pointers to the right person. So that new starter there comes with organizational and teamwork knowledge in an open environment. They get a much bigger advantage to joining an organization where you haven't had that open by default. So just a long answer of saying, like, I think there's a lot of ways we can prefix and bootstrap that context for the customer to make that taste a little bit easier. But in saying all of this, it's only as good as what the user decides to write. Like at the end of the day, if they're not writing their opinions and their taste and their instruction, whatever, AI can't magically guess that unless you're, again, you're using personal memory, which you are already writing a lot and all that stuff. So it really comes back down to you have to put in effort to get outcome. And people always use the example of like, oh, 80% was okay, but then to get to the last 20%, it took me another five, six hours. And that's true. Now, sorry, I take a long answer, but to answer your evals question, so then how do we measure success of this? It's hard. It's really hard because how one team uses You know, we have a platform where anyone can create an agent and put in any business workflow. So you're like, what is success there? We have some pretty good signals of success. So you often have, did the user use the output of the agent? Was it successful? We obviously have thumbs up, thumbs down and that kind of stuff as well. And you also have a lot of more nuanced signals, like was there a lot of rephrasing 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 or that kind of stuff. So like there are other signals that give us that as well. But the reality is agent creators in a business that you often take our tools and then apply it and then give it to their teams. They're the ones that really in the best place to judge success for that. And they usually will give us feedback on which parts are system things that we could approve. Or they'll realize that these are things that are knowledge that I need to add or instruction that I need to add. And so it's either one of those two buckets.
Nathan Labenz: Yeah, interesting. So it sounds like it's much more, in terms of measurement, it's much more about, presumably you're doing like small fraction tests and capturing all these like actual feedback signals from users. But what I notably didn't hear there is like, we have a standard, you know, automated eval suite and we use, you know, an LLM as a judge. Maybe that's in there too, but it doesn't sound like that's a huge driver of your confidence in what's working or not.
Sherif Mansour: No, no, we have that. And so we use that to give an example. We have like 20 or 30 out-of-the-box agents that we ship. And so they run through the same system. It's our advantage to model as many domain-specific different examples as possible. But the reality is customers will 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, we could have an out-of-the-box example and our own evals and LLMs, et cetera, which we do in some of those scenarios. But again, it's really only as good as what the customer sets up. So our agent framework lets people test the agent, see the responses, set up their own eval, that kind of thing, and run through that themselves. So it's important that as you deploy an agent, 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.
Nathan Labenz: Maybe get a little bit more into the weeds, a little more technical, if you will, on some of the structures that underlie all of this. Again, this is just such a timely subject, right? Where there's, everybody has kind of come to the realization that we've got context window, working memory, and then we've got this like baked into the weights, you know, deep memory. And the huge question is, what sits between those two productively? And we've got, you know, RAG, of course, and we've got all kinds of different experiments in memory structures. Then we've got the idea that like maybe context window can just scale to the point where it kind of solves the problem. And then there's like, you know, maybe new architectures are needed for continual learning to really solve that problem in a more, you know, integrated way. What are you guys doing today? You know, if I can get into like my personal memory Is that, you know, just a list of observations? Is it something more complicated than that? And similarly, when we go to like the knowledge structure that the agents are able to tap into, you know, especially with all this, you know, knowledge and history that precedes them, are you, are they using like the same search affordances that human users are using? Or has there been, you know, a thought that like, Because this is a theory that I have is that I think a lot of times people want to put them into the same thing, and sometimes that's the right thing to do. But then other times it's like a human user can only scroll through maybe the 10 blue links, but the LLM user might be able to handle 200 results. And maybe in processing a lot more, they can actually do, in the end, a better job.
Sherif Mansour: Yeah, really good question. So personal memory I see is just... I just think it's a capability that everyone just ends up having over the large language models. What's unique here, what's important to call out is how easy and how organic is it for a user to populate personal memory? And so the phrase I use is, what user proximity is the person close to the AI to doing it? So for example, a coder coding is probably chatting to their AI all the time in their IDE. And so they're implicitly populating personal memory or explicitly as they do it. So they have very good workflow proximity in the coding use case. We have a collaboration documentation tool called Confluence. So as people are writing and using AI assisted writing, they're implicitly and explicitly popular in personal memory. Make it shorter. No, you're too formal here, et cetera, that kind of stuff. That's happening organically. And that's really just at the individual user's preference. Then there's organizational memory. And I think there's a fork here in my mind of like two ways we can be effective with organizational memory. You've already touched RAG. RAG gets incredibly hard in an enterprise context because everything is permissioned even at the field level. With Robo, you can pull in Salesforce and you can also pull in SharePoint and you can also pull in GitHub. When I pick up GitHub issue or Salesforce record, I might be able to see some fields and you might not be able to see other fields. And so there's a very large investment of teams just trying to making, making sure it has a semantic index behind it, and it's also permission aware and all that stuff, and it's as fast as performant as possible and all kind of stuff. And that's the RAG technique. Then the other technique is really we have what we call the teamwork graph, which is an understanding of all the users, the teams, their goals, and how the work relates to that. When I say the work, it could be the Figma design, the pull request in GitHub, the page in Notion, whatever it is they're, they've got mapped out and it maps them all out together. The way the team at Graph works is both organically and inorganically. So example is Jira is often seen as a system of record in most organizations when you when you used to get your app approved in the app store as an example that goes through a ticketing system. And that's a system of record. You know, where is the app? Where is it at? What are all the related documentation for this app? Who's reviewing it, et cetera. And typically systems of records don't track the work, don't actually capture the work being done. They track where the work is at and the links to the work. And so if you pick up our billing example where the call center team is disputing a bill, someone's called up to dispute a bill issue, that goes through a ticket, and the ticket captures the business workflow and all the linked objects related to that workflow. That typically happens, and that's the Timo graph. So populated inorganically by customers just saying, hey, I want to connect GitHub, and I want to connect Figma, and I want to connect whatever it is to Rovo, whatever it is, but it's also populated organically, which is as I use Confluence or Jira or, or Trello, whatever it is, I'm pasting links and I'm telling you that, you know, okay, here's the related design for it, paste link, et cetera. So we can, as teams work in our products, we populate the graph and understand these nodes and the relationships between them. And so then when it comes to users building an agent or asking a question, they're sort of like, you know, Two or even three paths if you count just to LLM's general knowledge. But let's put that aside for a sec. And mostly two paths it goes when you say, give me a status update about everything my team did last week. Now when you break that down, that's a pretty loaded statement. So status update, what do you mean by status update? Probably might use it's LLM general knowledge. Maybe in your organization you've already got some documentation somewhere it has access to that says. This is how we define what a status update is, or this is where our status updates look like. Okay, so it'll probably use some of that. Well, my team did last week, my team, okay, how does it know what your team is? There's implicit and explicit signals here. Now we have a team's construct in our portfolio. So a lot of millions of customers on a daily basis create squads in our system to group work together. And so we can traverse that, okay, my team, you and there's the team relationship and that team's connected to Members in that team that week created these five Jira work items, these four conference pages, these three Figma designs, whatever it is, and it kind of traverses that tree. And so it could give you your blue links response. RAG would be a terrible solution to that problem because we'd give you the top five documents and then try to summarize the status of those. In scenarios where you might say, what is my team status update that week? The graph solution is a much better solution for that, where we want to traverse all the objects, give you the, summarize them, you know, et cetera, apply the organizational context. But in scenarios where you might like, what's the process for taking annual leave in my company? RAG's probably a much better solution in there. We don't traverse the graph for that. So that, you know, I think really good AI in a business context kind of needs both of a RAG set of techniques, but also a way to traverse very structured information at a much bigger scale.
Nathan Labenz: Yeah, that's great. I that really reminds me a lot of, uh, project that I studied a while back called Hippo Rag, which we did a full episode on. This is maybe the closest thing that I've heard of in the wild to a implementation of that, where you've got on the fly or maybe background processing entity recognition, it sounds like. If I'm just randomly putting in links, you've got the job to do of figuring out, like, what is this in the first place? Those... you've got a lot of different instances where an entity will pop up. So you got to do that disambiguation or reconciliation. And then, you know, the process in the background of mapping out all these connections as well. And then when it comes to runtime, what they were doing was pretty still early. There was a research project back in the hippo rag days, but they would sort of identify through like a semantic search, like what are the entities that are relevant? And you may even, in the case of my team, that might just be fully explicit. But then they expanded the search radius through the graph. You could expand it one node out or two nodes out or three nodes out, and then that became the universe in which you would do your semantic matching. I always thought that was really inspired.
Sherif Mansour: Yeah, you can have those single multi-hop travels through there. I think the other thing you overlay on top of that, which gets even better, again, if you happen to be a vendor, again, we're fortunate here, like us, we're capturing some collaboration graph as well. So we have a separate graph, which is kind of the collaboration signal. So when Nathan likes my pages or comments on my issues or et cetera, that could also be used as a weighting, depending on your query, to lean into some nodes in the graph of other nodes, especially when it comes to understanding people and work relationships. So you would layer any user activity signals of collaboration, who worked with, well, I shared a page with you, et cetera. You viewed this content, but haven't viewed this other content. So therefore we're more likely to show you, depending on your query, the content you hadn't viewed if you're asking for something like that. So an additional layer you can add on top of that is just those collaboration signals. If you can, it makes a huge difference to the results.
Nathan Labenz: Yeah, that's cool. How do you think about It might be too early for this, but one thing I've occasionally noticed in products is sometimes they need to forget as well as remember. If you took my whole work history, right, you would find that in certain eras, I've collaborated very closely with certain people, and in some cases, those people are no longer at the company. In other cases, they still are, but we're not collaborating as closely as we used to be, whatever. Most folks who've rushed out to build any sort of AI memory system, you know, retrieval or whatever, however far they've got, they've mostly just tried to get it to work for like right now. And there hasn't been much thought about how does this evolve over time as everything always does? How do we kind of know when to let go of things? You know, maybe you could get by by just sort of saying last interaction with this person was whatever, and let the, you know, let the model handle it at runtime. But I suspect that there's like 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 to let go of things that it no longer needs as much?
Sherif Mansour: Yeah, particularly hard for organizations. Again, open by default actually makes this more challenging. So you could argue it makes it better in some ways, but obviously it makes it more challenges because now you're now getting 20 years of content and who knows if that page 19 years ago is still relevant or not, et cetera. So I think that's even particularly challenging. But also, it's like classic pick any use case and there's probably a pro case and a con case for those. The two most obvious, I actually ran into this in the early days of Rover. I remember doing some testing and we're playing some things and I asked it something about rewriting my, like we're kind of having a new team charter set and I said to rewrite my team's charter using my goals. And we have like a goals app and you can track goals, et cetera, and OKRs and all that stuff. And it picked up a goal I had from like four or five years ago in the early days. And I'm like, Wait, where did you get this from? And I'm like, I haven't worked on that for ages. And that's a really good example there. And the goal was still active. So I hadn't cleaned up the data to mark it as inactive. And so it's just assumed that was the case. Now, since then, we've done a bunch of signals, just use that as an example, touched on user activity and collaboration activity being a key one that comes up a lot there. So there's a lot of decay on content that might be older that you may or may not have collaborated on, depending on the context query you might ask for as well. But it also highlights the importance of ensuring that the data you connect is useful to some degree. I had a customer the other day, I'm going to connect all my SharePoint to Rover. And I'm like, sure, go ahead. But I was like, how big is your SharePoint? It's like some ridiculous, like one terabyte. I'm like, Do you even need that? He's like, I don't know. So you're like, okay, you could and it'll decay as, you know, try to decay and create gravity over time depending on what it is. But it does highlight the whole garbage in, garbage out like kind of motto. There are ways in the system where we try to decay things based on time-based activity, your interactions with 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, probably should have just gone and archive it and I didn't as an example. So there's a mix of we try to do stuff, but also I think as customers connect data to different systems, it is something for them to think about, which is, does the system you're connected to, does it have any ways to Decay history. Decay history is that even the right word? You know what I mean? Fade cranks some gravity over time for old stuff, but also know when to pull it in if that's the right stuff. So I think that's an important aspect for folks to think about as they, they pick their AI solution. Yeah.
Nathan Labenz: When it comes to kind of brute forcing this stuff and just being willing to pay for compute to do it versus trying to be more efficient, and obviously efficiency and latency relate too, but if you're willing to pay, you can also do a lot of this stuff in the background. How do you guys think about my starting position? I used to always say, use the best model available. Don't worry about cost, maximize performance and optimize cost and latency from there. And I think that was pretty good guidance for a while. Now, though, maybe not. You know, I don't think you want to use GPT-5 Pro for everything, if only because of latency, right? So it's like, I think we do now have models that are for many use cases, like overpowered. And that wasn't the case when I developed that guidance. I guess, how do you think about like the overall optimization problem of cost, latency, performance? other intangibles that are maybe also worth considering. I assume that that's something that has to start at kind of a value level, but then obviously it gets operationalized in detailed ways too.
Sherif Mansour: Yeah, I could probably answer that in two different ways. There is the what we do internally as teams build AI features in our products and then how that applies for customer application and customer thinking, if that's useful. Internally, very similar to you. Especially in the early days, just find fit. Your priorities, just 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, it's the wrong, I always say, the riskiest assumptions test, the RAT test, start with your riskiest assumptions first and do whatever you can to debunk that, and then move to your next one, move to your next one. And so most of it's like, Is the feature I'm building valuable? Go ahead, test it with customers and whatever. We are a bit more liberal in that process. Go ahead and do whatever you need. I will say, as we've, yeah, I couldn't even count the number of AI features we have now in our portfolio. It's kind of rewriting the whole app, assuming AI is now always on at some point, probably over well over 70, 80 things across my main apps. There are some clear patterns. that we've learned for time and time again, where you don't need this. So the way we solve this internally is when teams need to build an AI feature, they'll often get complete free reign in the early days in discovery process. At some point, they will talk to our ML team. We have an AI gateway, and we have a mix of locally hosted models, models in the cloud. There's like a ridiculous amount of models in the AI gateway, which is a proxy, so we can swap models and test different things out. And depending on the use case, we'll probably take those workloads, those AI workloads and and run them locally on an open source model or depending on what it is that it's doing. A simple summarization feature no longer requires every single bell and whistle in the world. We'd probably offload those workloads locally. The more complicated ones would go to a more sophisticated model depending on what it is. So they'd go through that process at the tail end of their discovery process or whatever that applies there. The good thing for us means that More and more of these, I guess, AI, the cost keeps going down and we keep passing that value to customers, which is good. And it's good for us that way. It also means that teams can keep learning as quickly as possible and that doesn't slow them down too much. Now, when customers apply AI in their workflows, so that's probably the biggest thing. I see the explosion of token usage, whether they're using RevoDev for coding or they're actually adding an AI agent in a Jira workflow, which is probably the biggest, our fastest growing use case of agents and deployment, they just go to their existing workflows. They've already got millions of workflows in Jira and they're like, hey, an agent can help here, an agent can help here. This step here is really just triaging the ticket coming in. An agent could probably do that if we gave a good instructions and they just go and just orchestrate a bunch of agents in a business workflow. That one is fascinating because you'll get customers that will probably will overuse AI when they don't need to. To give you a very simple example, imagine a ticket comes in and you're reviewing the legal contracts or whatever coming in. There are ways where our orchestration framework, automation orchestration framework, lets you do some strong, more deterministic comparison of content of what's in the ticket. For example, there's like some string manipulation functions. You can inspect the contents of it. You can say, If the Jira ticket has these words in it, then do that. Now, using the out-of-the-box automation nodes that help you build these Lego pieces is a very effective and cost efficient way to do that. Now, some customers will be like, oh, I'm just gonna switch that to an AI. And you're like, okay, cool. That can also get you the same outcome. But geez, the compute and the tokens on that, it's not worth it. A customer described it to me once as like, I realized after putting this in this workflow, what was her phrase? She said, I've got a rocket launcher and I'm swatting mosquitoes with it. And I was like, yeah, that's, that's probably not a good use of AI there. And so they'll use the more deterministic functions in our orchestration framework that let you do like specific string manipulation or comparison or whatever it is. That's a way better solution there. So from a customer's lens, there is some skills to be learned on building tailored agents and deployment workflows is when do you need an agent and when is a large language model appropriate and organizational large appropriate? Or when could you do something a bit more deterministic on the functional side that is much cheaper to execute and run, also more effective from a performance perspective as well, because it only does one job, right? And so that's a skill that I'm finding many, many organizations are learning as they're deploying these agents. Now we try to help them with tips and tricks and techniques and content, but I see that as an ongoing journey for a while for a lot of people, because you're like, I could solve everything with AI. You don't need AI for that one. That one's just a simple, just check the contents of some string value and do that, and you're done. Another
Nathan Labenz: one of my mantras is anything that can be done with traditional code should probably be done with traditional code. It'll be faster, cheaper, more reliable. Though, even things as simple as writing a regular expression, nothing makes me feel stupider than writing a regular expression. So it is sometimes tempting to just be like, OK, just have the AI. 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.
Sherif Mansour: But on that example real quick, so our agent framework lets people create skills that the agent have. The skills can be no code or code skills. And that's just a really good example where you can make sure the agent calls a very deterministic skill, like a function to do math or check the bill details or whatever. And that's very specific and bespoke to the business. So someone writes some Java code or whatever it is they want. And they cook that as a skill for the agent, put that in a business context and off you go. But it's a process of discovery for customers. I think people start and go, oh, this is amazing. They're like, wait, sometimes it didn't give me the right results. But in this specific scenario, I wanted to follow this exact two 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.
Nathan Labenz: I don't know how specific you want to be in your response to this, but Could you give us a breakdown of how many tokens on a relative basis are flowing to which different kinds of models? Like, you know, where are you using proprietary? If you wanted to name brands, I'd certainly be interested to hear that breakdown. So interested in your take and maybe what your customers are signaling to you also that they care about when it comes to what different kinds of models are from trusted enough sources to be used or not.
Sherif Mansour: Look, I don't, I'm actually pulling up the dashboard to give you a, like it's in the ridiculous millions, probably billion, I have no idea, tokens. It's a ridiculous number. I remember we used to have a dashboard with all the tokens consumed and created. It's kind of pointless now. But on the model thing, I am seeing a huge trend from a year and a half ago, two years ago. I want to pick the model. I want to pick the model. I want to pick the model to now like the care factor. It's like, oh, I realized it's like me saying, I want you to use Postgres, not MySQL. That's the case. I mean, all the big expected ChatGPTs there, Claude, Anthropics there, all that stuff. So I couldn't go into details of all the, I'll probably get it completely wrong. But name the model, we're probably using some variant of it in some way. We have a fair bit of transparency with our main AI features. We publish docs on what the feature is, what model it uses, et cetera, as well for the big items. But everything from GTP, Claude, Mistral, it's a mix of stuff. It's a lot to do that. But honestly, maybe the takeaway that I think I have for software vendors or software teams, I always say is it does pay off to build a model gateway. or have a solution where you can proxy models because if you believe that that layer is being commoditized and there's lots of them and choose the right tool for the job, then to help you move the fastest, you therefore need to find a way to learn, switch, work out the best use case and cost optimization and do that way. So that's certainly something I would recommend to anyone building software. It's paid off orders of magnitude, yeah.
Nathan Labenz: So you're on the models will be commoditized side of the will models be commoditized debate.
Sherif Mansour: Little asterisks there. The general purpose models for most general purpose use cases, yes. And I can see the total use case for verticalization of models, you know, like DNA sequencing model that was just trained in some health for healthcare purposes on that kind of stuff. I could totally see that. I just think the average knowledge worker that most of our customers sitting on a desk using content to create content or like, you know, in, in finance department, HR department, marketing, customer success, whatever it is, the general purpose models are 80, 90% easily solving the problem. And we're seeing that desire for model selection just decline over time, which is, which has been pretty good. You will see, but there is a little nuance here is important, which is like for those building agents, that are setting up their own testing and evals, whatever, model stability is important for them, right? So it's like API stability, right? Like if you swap the bottle overnight, you're probably gonna get a ton of different results. So that's a little slightly different scenario, but an important thing for people to consider as they're thinking about that.
Nathan Labenz: How about a few questions on the future of software and also the future of work? Sometimes I ask myself, why do we build UIs? And the answer I came up with is we build UIs because We need input from the user. We need access to the user's intelligence or taste, as you noted, judgment. There's something that only the user of the software can provide that the software can't continue to do its job without. And so I sort of see these UIs as kind of, you know, if it didn't need anything from the user, then the software in general would run really fast. And it's this sort of moment where, okay, we have a stop because we need something from the human that is when a UI ends up getting created and presented to someone. I sort of think, for people who have software products, and they're trying to figure out how to use their AI layer, then I think, well, the AI can in many cases be sort of a substitute for the human that would otherwise use your software. And one kind of true north goal is like, software you don't have to use. as much as possible. You know, people are mostly not like waking up in the morning super excited to use whatever SaaS tools they're going to use throughout the day. It's obviously like in most cases a means to an end. So if you can start to abstract those UIs into tasks for the AI to do, and you know, sometimes maybe you bundle them or kind of redraw the borders around them for who knows what various reasons, that seems like a good mental model for people that are trying to figure out how to bring an AI layer to their software product. But beat that up for me. How would you critique that? How do you think about it differently?
Sherif Mansour: It is such a good topic. We talk, we spend hours talking about this, hours, probably days, weeks. I love to look at history, tech history, and try to find parallels. Now, nuances are important because some parallels then apply and some do, et cetera. But if I could rebank, rewind back to maybe some of your more mature listeners to to the MS-DOS terminal days and back before Windows existed, for those of us that remember, the terminal DOS or whatever, or Mac terminal, whatever, was the universal interface to the operating system. It was how you interacted with the operating system. It's how you got stuff done. You could do maths, you could do type a Word document, you could draw ASCII art if you wanted to, et cetera. But we learned very quickly that it was actually the worst interface for some use cases. And so over the years, we built verticalized apps on top of the terminal to do word processing, image generation, spreadsheets, audio, podcast recording, et cetera. We are now, me and you, Nathan, we're talking in a dedicated interface that's built on top of the operating system, on top of the browser and on top of the operating system that solves this problem. But it's all, the universal interface is still just commands in a terminal with some high order level of programming language on top of it. Apply that to AI. I always go with the phrase of like, well, what's the universal interface to any large language model? It's conversation. That's what it is. That's how it works today. That's how the models were designed. The transformer model that was like the big aha moment. We can predict the next thing. So let's go. Conversational UI is the best way to kind of get it predicting the next thing. Our UI construct for conversation is chat. It's just like society and history, it's chat for everything. I do believe, and I would argue, I think we're already seeing it, that chat is not the universal interface to all AI. I think what we'll see is a spike in a lot of crazy amount of chat usage as the primary way to do anything in UI. And over time, as we start building verticalized and more specialist solutions, which is still humans interacting with AIs, they'll be in dedicated experiences on top of chat. Doesn't mean chat will go away. It just means chat. I use terminal less and less every day. I don't code anymore, but every now and then I'll open it up to do something. But most of the time I have a dedicated experience that's far superior for me to solve my particular problem, to do that, et cetera. So I think the same thing will happen with AI. The example I like to tell teams at Atlassian that are building an AI feature for any of our apps, I always say, What's your AI feature? I bet you nine times out of 10, you could build the poor man's version of it in a prompt without the UX on top of it. Is that true? And they would like, actually, yeah, we could. We could just prompt our way through this, but we can't expect users to type these crazy prompts every time, or we can't get the data in a more structured way and whatever. But you can almost fake any AI feature out in any product through prompting. It's the worst experience for it. And so then you run into this. Okay, so if that's the right conclusion, then I reach the conclusion that we're going to build specialist interfaces on top of that. Then the second thing people often say is, okay, well, but AI will dynamically generate a specialist interface all the time. I don't believe yes or no. Again, nuance is important here. Like for form input, yeah, potentially, but it has to be a pretty predictable form input. Like you try filling out a form via a chat interface, it's a disaster. Like let's do, how do you do form validation, conditional form fields, et cetera. Like there's a ton of issues there. Now, could AI dynamically generate something every time? Oh, it can and it probably will over time. Will humans want an interface that keeps changing? No. I think history has told me that as humans interact with software, they want some level of predictability in, well, you know, there is some variance in how they learn the tool and how they use it. So I do believe that there'll be lots of specialized user experiences built on top of AI that will effectively be a conversational backend, like use a conversational API backend, because that's the interface of these live download models, but it'll be in a dedicated interface. The example I used last week was my son loves making vibing games and stuff, and he's been geeking out with Leonardo AI. I don't know if you've played with that or not, but to build image sprites for games, to make little characters, predictable characters, and these little tower defense game and stuff and all that. Could you ChatGPT that in a terminal and a chat interface? Totally. Is that the worst interface for doing dedicated, predictable UI graphics of slight variance and different sizes and whatever? Yeah, it's terrible. Like you would rather someone who's thought about the problem deeply design an experience that is still AI native, but it's really around building a base level UI constructs with slight variances. You know, the character moves their hand here or carries another weapon or, you know, whatever it is they're doing. And it's a fairly sophisticated interface, but it's designed for, it's a good example of a vertical user interface that's built just for AI. Long answer of saying the chat is the universal interface, but it's the worst interface in the long term. And I do think that humans will always be interacting with specialized software on top of that. It's not saying that some of the software, you don't need anymore, you can now use a chat. I think that will happen in all things. But I just think like everything, we just end up creating more and more software. The explosion of software is only, increased with cloud and it's even increasing even more with SaaS. So people are just creating better interfaces. And so this is where you end up in this world where design matters and design ends up being a huge differentiator in any AI future where everyone has access to all the tools.
Nathan Labenz: I wrestle with this question on software, the explosion of software. Are we going to see a proliferation of SaaS? So obviously there's a lot of different reasons people build SaaS software. I think one pretty common one, and I think this sort of applies, I think I've even heard you say that it sort of applies to some of Atlassian's core products, is that the software encodes a way of working that is known to be effective. And so for something like, you know, Jira, it's like, yes, it sort of does these like functional things of it, you know, takes information, it stores information, allows you to search, whatever, but what made that really transformative for so many teams was it kind of guided them to work a different way than they had been working before, right? Instead of the old waterfall model, they were actually able to do agile because the tools they were using were sort of set up for it and naturally steered them in that direction. And so it kind of created habits, reinforced habits, all these sorts of things. If that is right, I wonder, like, to what degree does AI change that Potentially a lot. When you first apply AI, you think, okay, I have this task of triaging tickets. What are the inputs? What are the outputs? How do we make this decision? Let's get all the examples. Let's eval it. Let's do all this stuff. Great. Okay, now we've got an AI that can triage a ticket. But then the next level up, obviously, is like, 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 can do the Elon Musk thing of best part or best step is no part or step. So I guess I'm wondering, how much of the SaaS stuff that we've seen is appropriate for agents? How much should the agents be like, jumping into all the structured workflows that have been created for humans? And how much should we maybe be thinking like, actually, they might ought to work a quite different way from the way we work. And maybe that, you know, the SaaS tools that we have actually don't necessarily encode the right way for agents to work.
Sherif Mansour: I would agree with the observation that like, the way we work is not necessarily the way an agent would work over time, but the way we construct our units of action that an AI can take is usually giving it skills or tools, you know, that it can call at a particular step in its workflow. That's typically what happens. If I were to use Jira as an example, with Jira, the real value of Jira, like, it's funny, like, it's the classic, like, oh, I vibe coded a to do in progress done app. Okay, I've kind of, it might, I've replaced Jira, it's done. You're like, Oh, if that's what you're using Jira for, yeah, sure. Like you're probably, that's what you're better off doing. There's a bunch of other issues with that. Like how do you maintain your own software at scale and whatever, there's a bunch of issues. But the real value of the SaaS tools that let a team model some workflow is the value that the customer has created by modeling it in their world. Jira's value is making, I'm just picking some random companies here. the Coca-Cola, the teams at Coca-Cola make it theirs, and they make it theirs by actually modeling their taste, how they want their organization to work, because otherwise everyone just ends up with the same organization, their business workflows, how they're, how they build products, how they do customer service, how they respond to change and track incidents, how they onboard a new employee. They apply taste in modeling their workflows in some way. In a world where AI agents are are helping us do more of our work, the problem of modeling how these agents work in a workflow does not go away. I would argue that employees, employers and employees want even more control to define, if we said at the top of the call, taste is important, to define how they would like the AI to work. So my logical conclusion there is therefore, agent orchestration with human workflows is becomes a pivotal thing that every business needs to do. And so, okay, what does that look like? Humans need to decide what they would like to do and what they would like their agents to do and how they would like them to do them and what they will do and what the agent will do and what their other colleagues will do, et cetera. That problem definition space of applying AI to a business workflow, I don't prescribe to that world where well, you'll just give it to AI, it'll work out everything. I can't reason with that world because you end up in the AI slop world. You're like, okay, well, that's basically everyone has the same thing all the time, every time. And everyone's company works exactly the same thing, which by definition isn't true because everyone's company builds different products and different services. And so you're like, well, I just can't follow. I can see how people follow that reasoning. But the reality is the most valuable thing that a business needs to do is give their human teammates and their virtual teammates tools to 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'll always change. And that has changed for the last as many years as I've been doing this for. But I think what doesn't change is the the need for specialist tooling where humans will do work with AI. I don't think that goes away in the SaaS world. I would argue that only increases if we're already, if you believe that chat is not the only, isn't it gonna be the interface to all interfaces and it like that won't work. I just, I can't see that world. Given the amount of crazy specializations there are in the world, it's just unbelievable, right? Like you look at the crazy explosion of legal AI tooling. It's so specialist. My brother's a M&A lawyer and watching him use his tools, I'm like, it is just fairly sophisticated UI tooling on citations of previous court cases related like legislation by country, by geo. And it's just like, could he type a prompt and try to solve similar problems potentially, but it's a disaster. Try to build any business that does that job at scale, you're going to need specialist tooling. I can't see that world. And then the only other counter argument to my argument is I always challenge myself of like, oh, but AI could generate the interface. I'm like, sure. But at some point, that needs to be predictable and scalable for employees and people to work with. And then you end up building a verticalized SaaS software. You end up getting to the same outcome of a verticalized solution on top of the conversational interface. Nice.
Nathan Labenz: You know, what predictions would we make from that? It seems like there's this Silicon Valley notion of the one person unicorn, which we haven't seen happen yet. You know, we're starting to see some interesting, you know, very small teams with like, you know, pretty notable scaling success, but no one person unicorns yet to my knowledge. But I think the one person unicorn is sort of premised on an idea that obviously the AIs are going to continue to get better. You know, it probably isn't the case. You could build a one person unicorn with today's models, but, you know, the next generation or the next generation, it starts to become, at least people think that it becomes more realistic. Maybe you think like, nah, that's just never going to happen. But I would not be comfortable putting a cap on, you know, how far the AI capabilities curve will go before it bends over. I always say, it might be an S-curve, but the top of the S-curve can still be superhuman. And that is probably my best guess. There's also the possibility of intelligence explosion. That's a whole other thing. But it seems safe to me to believe that we're going to get to something that is genuinely better than people at almost everything, almost all the time. But then, yeah, I guess I just wonder, enterprises want control. That's a deep value or a deep reflex. But does that set us up for a world where, does that work against the enterprise at some point? If they're like, we can, we put these agents into these boxes and we have these workflows and we like, we need them to do these sort of point things in these prescribed ways. And meanwhile, with maybe Gemini 4 or whatever, some kid is out there that's like, I'm just gonna... Yeah. Provide like light guidance and, you know, a bit of genius. But other than that, you know, the AIs are going to just do all this sort of stuff and I'm going to kind of let them figure it out. There's also this notion of, you know, in human teams, obviously we're all different, right? And so I heard a previous interview where you said that the hardest thing about scaling a company is scaling product teams because communication, trust, process, and rituals all break down. And so I think, again, that's kind of like, one of the reasons we have all this software is because people can't keep all that structure in their heads. You know, they can't just have like a shared mental model of it. So they need some more, you know, 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, you know, with a lot fewer guardrails and kind of constraints and all these sorts of things in place. And I just wonder if that could be you know, something that could really sneak up on the incumbents.
Sherif Mansour: There's a lot there, dude. Let's do the first part. The first part of just the one person unicorn, I think is a good test, right? I was talking to a five person startup is to kind of doing like a sales AI vertical. The work that they do is the same work that I just described to you. To give you a specific example, they have AI agents in their Jira workflow that automatically publish content to their WordPress or whatever their blog is on a regular basis, thought leadership content based on a bunch of inputs that they have given it in a regular job and humans in the loop review the content and try to critique it and give it feedback, et cetera. So they got this content creation machine that's just pumping out content to do that. So first point is even those one person unicorns, they're orchestrating AI agents in a workflow to get stuff done, I think is my first point. 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 they were is like those when you talk to those people, at least when I talk to them, they're the bottleneck and they they have a constant need to hire more people. Can they do more with what they have? Oh, absolutely. They can. But the ones that are truly growing, 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, that one person is happy to just remain as they are and be the bottleneck. If you're running a smart business, they would realize that talent is a scarcity and they probably want to grow at some point. Doesn't mean that each person can't do a lot more than they ever could before. So that's probably the second point there. So everyone's really just around, often gets excluded, but not a major talking point, but there are so many regulations and industries and compliance that just needs to happen. So like, you know, there is a whole cohort of the market that like literally cannot move without some sort of intervention there from a domain expertise human stuff. Even with AI stuff, I'm sure there'll be, there are like legatory implications. The last one I keep coming back to, Nathan, is like, I just still don't believe that one person unicorn is some guy or girl typing a handful of minor prompts into things. and not getting slop, even when AI gets better. When again, my definition of slop is it produces something good, but just lacks any creative diversity. So like everyone's getting similar things because that's how these models are designed to do. And you can do it today. You can go type the same prompt in seven different tabs of like different AI tools and you're getting 80% the same. So therefore, for that person to actually become a unicorn, maybe they just get to the most They capitalize on their slop the first, but then the second unicorn will look too similar. So they'll have to put in a lot more effort in avoiding that slop. And how do you do that? It's really just about the human process of just making AI yours. I don't see a solve for that other than just making it yours in some way. How do you make it yours? There's a million things of voice and tone, taste, content, context, et cetera. I just don't see that. going away at all. I think that's what makes us human and that's what makes us crave different things and like different things because of how we think and how we feel and how we interact with things. Anyway, those are my thoughts on that topic.
Nathan Labenz: You've mentioned this kind of core skill throughout the conversation, like figuring out how to build workflows, basically. You might, in other contexts, call that systems thinking or system architecture, process design, process architecture. I have found that skill is like very natural to some people and very unnatural to other people. What have you learned about how to teach that skill? How should people practice it? If this is the thing, where we're going to be going from doers of things to architects of how things get done.
Sherif Mansour: Also, the next logical question that people love is spicy. You probably hear this all the time, sure. Well, does that mean I don't need as many junior staff anymore? Because it's just the senior stuff that get the architecture stuff. So I think that's also related to that question I find that comes up a lot. We always forget how good of a teacher AI is. It's arguably the best teacher of all time. Even I just think about it after the product management craft at Atlassian as an example. We've deliberately changed our hiring profiles of which seniority and which people. I'll make the joke of like, those kids that are cheating in college and university, we want more of them. And they're coming in as AI native need a better phrase for that. But the reality is, They're the ones that are already starting to think how they can use AI to advantage them the most. Even though they have less domain industry experience, the ones that are doing, that are using it in their personal lives or their, you know, as it feels native to them. My son, if I observe him, he's gone from, he's 11 years old, he's gone from scratch coding, which is like a visual coding language, straight to vibing. And 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, but he's already, his Roblox got upgraded the other day. He's got this Roblox IDE where he codes stuff. And he's like, Dad, that AI thing just appeared in Roblox. And he runs into my room and I'm like, What are you doing? And he's just typing and vibing away and doing stuff. So that's becoming the skill he's learning is how to instruct AI to get what he wants. And if it doesn't get what he wants, he's learning how to instruct AI to teach him to explain what he's after. I will say this whole being the architect of the thing, one logical conclusion that's incorrect, I would say, is people say, therefore I only hire or focus on senior staff. No, I would argue behavioral change is really hard. I would argue a lot of senior staff actually probably still doing things the old way because it's the quickest and I struggle with this, like when I get a new task, I could do it. the way I currently do it, or I could try this new way of doing it, which may or may not work, which may require more time or may fail, but I might get a better outcome. That behavioral change is really hard. Where is it in our workforce that we're easiest and best placed to instill behavior change when someone's new to any role is great there. So I will say the biggest thing to be aware of is just AI as a teacher is an excellent tool to help with there. And the second thing is, yes, we say more people go to being the architect of the thing, But also there's an equivalent amount of people in the workforce that are reviewing the thing, who aren't yet architecting the thing, that are also building knowledge to then become architects of the thing, right? So the person architecting the workflow for that procurement team I gave you as an example of, that's usually one person that sets that up and decides how it works. The humans are still reviewing the contracts, the proposals from the AI, but they're also building domain knowledge and skill of what's good and what's bad taste, and in doing so, they're also becoming architects over time. So I think their growth still continues, even as people who are viewing the results of AI there.
Nathan Labenz: Speaking of new teammates, Atlassian bought a browser company, and it's literally the browser company. So kind of a two-parter on this one. One, the goal, as I understand it, is to build the browser for knowledge workers. I'd love to hear a little bit more about what the vision is for that, what you imagine that ultimately looking and feeling like. And then I'd be interested in your advice for businesses that are thinking about acquiring an AI startup in their space. How should they be thinking about the value drivers? Classically, you have like team tech and traction and You know, but this is such an uncertain world for so many reasons, right? Like, is the tech that some startup has built today, you know, going to endure in the way that we might have been confident it would in past eras? Is the traction even, right? I mean, you know, we see these like super fast, basically vertical revenue expansion stories, but then we also kind of wonder, like, yeah, what happens, you know, to Cursor, for example, if, you know, Anthropic decides that they're going to only allow their next model to be used in Claude code for a few months when it first comes out. So I just feel like, to so many companies, the feeling is like, it would be really nice to be able to acquire our way into this a bit, but, you know, 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.
Sherif Mansour: Awesome. Browser for Knowledge Workers, amazing team. Josh and team have done an incredible job. Maybe just as an analogy to help that I kind of use in my head. We're not trying to compete against your everyday browser and your consumers browsing the web, doing shopping, whatever it is, planning their next trip, buying some dress or something. When you reset the assumptions on which you're building software, you get a very different outcome. I keep telling teams inside Atlassian that are building our apps, I'm like, Hey, we need to build assuming AI is always on and available, and you'll get a very different JIRA to what you did back then, right? That's our mental model. Now, in this particular example, early Messenger days as a parallel example, AOL Messenger, ICQ, I still remember my ICQ number. They were messaging tools that were largely used in a consumer context. Now we did, the industry, we as in we, the industry, did apply some of those Messenger tools in a work context and they worked okay, but they weren't great. They didn't take off well, et cetera. When we reset the assumptions of hey, in a business context, how is messaging different? We end up with a very different solution. Like we ended up with channels as a way to reflect org and team structure. We ended up with integrations as a way to integrate with different systems. Business workflows modeled in Ms. Teams channels or Slack channels, et cetera. Permissions and control became more important. So we actually end up with very different products. to the consumer messaging products. And still, I would argue today, consumer messaging products still look very different to business products. And so we believe the same thing's happening in the browser context for work. If you reset the assumptions on how people work every day with a wide variety of different SaaS tools, why do they go to the different SaaS tools to do what tasks? Then there's a bunch of different things we need to do to get to that outcome. So that's like a bit of an analogy of like, hey, Like we generally believe that there will be a different work construct for using AI in the work context and you'll still need a personal context and it'll be quite different. And I think the same is applying a little bit with just personal AI and work AI as well. You're seeing more and more of that, like the personal AI productivity in a personal world is quite different to a work one. I think the browser companies are already thinking about, Josh and team thinking about like, hey, in a world where the browser has access to The tools that you have access to permissioned per user, it's a fairly complicated world. In a world where the browser has access to the organizational knowledge and the graph that we talked to you about. How might we solve the similar problems that, but in a work context? We end up with quite a different interface, quite a different experience that ends up happening there. So I think the opportunity there and the vision there is really just around envisioning teams working in that collaborative context with their virtual teammates across many SaaS tools. We believe what the browser looks like today will look quite different to what it looks like tomorrow for knowledge workers. So stay tuned there. That's a exciting and moving space, but also just a fun space as someone who's been in tech for a long time, you're like, when assumptions reset, it's such a clean slate to like start thinking again. We went through this with e-commerce days, the cloud days, et cetera, mobile. So it's always fun.
Nathan Labenz: So that sounds like mostly team is what I heard largely there. Any thoughts about tech and traction if you're thinking about buying an AI startup?
Sherif Mansour: Oh, yeah. So your second part of your question, look, there's there's the mix of like there's there's an AI fog of like investors and companies are struggling with like, oh, look, how much of this is like reproducible overnight? How much of it's not, et cetera, like that that exists. I will say on that particular topic and bucket, What has standards the test of long-term AI, long-term? I always tell teams, define long-term as 12 months here in the world of AI. Understand the trajectory and define what long-term means, because otherwise you don't make a decision. You're an information paralysis. You go, oh, but the trajectory is here. And so 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 to 80% of something to 100% of something that's a market-specific vertical domain niche. is a massive investment. And I think that is certainly, again, depending on what your listeners are thinking about, whatever, that's certainly something we're like, okay, if it's a vertical and I can see that the teams put an 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 to hear is that 20% businesses are willing to pay if that's high value to get to that extra 20%. And that's where most of the value is. That's one big thing to take away. The second big thing to ask your team, your teams is, I use the phrase, Workflow proximity. There's user workflow proximity and bio proximity. Those two things are pretty important for thinking about these things. User workflow proximity and asking is, do we have a right to win in terms of how users work every day? And this is more for the PLG style of discussion. For example, I could go build a some AI tool to help with calendar AI automatic scheduling tomorrow as me as a random individual. Who's probably gonna win that space? People that already have people that are using calendars. So I would either, you know, build to get acquired or build through the hope that I could somehow steal market share and then start with a new calendaring system. That seems like an epic, two big hops to take, right? So asking workflow proximities, where do the users exist today? I always, and then say, for that job to be done, draw Maslow's hierarchy of needs for that job to be done. And you want to be as close to the bottom of that pyramid as possible for that vertical, because that player is in best position to move to the next layer of the stack and to the next layer of the stack. So the calendar example, you like, you kind of really want to own calendaring and scheduling to do that. Or you feel like your niche on top of that calendar will be a niche that those big vendors won't go after for a while and you can... earn some big bucks doing that and whatever, and that's fine. So I always think user and 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 users workflow or more buyer workflow? And then where are they in this stack of that job to be done? Are they at the top? Once I've done these four things, I need to do this fifth thing, then that's a dangerous spot to be in. But it might be good if, again, it's so nuanced depending on The market's big enough. You think what you're doing is so specialized, they won't go after that, et cetera. There's a bunch of things to think about there. Hopefully that's useful.
Nathan Labenz: Yeah, a couple of good frameworks there for sure. On the future of software, one mental model I have for like, are we going to see a software explosion or, you know, might we five years from now have like fewer professional developers than we have today because AI is doing a lot of the work is to ask, And I'll give you a spectrum, right? How much more of this would I buy if it were functionally free? On the low end is like dental work. Like I would buy no more dental work even if it were free, right? I don't want it. You don't enjoy it? I'd like to avoid it. And accounting is like less painful than dental work, but it's like still, I would probably pretty much buy whatever I'm required to have. and probably not much more. And some people might, you know, buy a little more, but I think most people have roughly that attitude. On the other hand, like massages, if they were, you know, freely available all the time, I'd probably consume like a hundred times more than I currently consume, maybe even more than that. Where is software on that spectrum, I find quite hard to figure out. And I would definitely separate software for the purposes of this from like AI inference generally. How much more do we need? What is the limiting factor on how much we can use? Is it our time? Is it something else? But what's your intuition? Because I do think it's going to get a lot cheaper. And then in terms of the future of the industry, it seems like I just don't know how elastic demand really is.
Sherif Mansour: I would totally take the massages one, by the way. Such a good one. Look, I feel like the only way to have a fruitful discussion is to be more nuanced on the category of software. And we could so many ways we could slice this. So let's just say we slice it in B2B and consumer. Okay, well, consumer. Well, that honestly feels like a massive pool. Look at our lives of entertainment, leisure, home renovations, like whatever, cooking, etc.. I feel like that continues to grow and especially And sadly, so there's also the business for attention, which exists, but it's, it's what it is. So I just can't see that shrinking in the world of AI. I think in the world of AI, we have to ask ourselves, society is like, what do we want it to become in the consumer space? The trajectory we're on is, is extremely highly fabricated. content and the blend between reality and real is getting blurry. But again, arguably you could go, okay, applying a photo filter to my phone five years ago was already somewhat AI, right? Like that was like already that. Anyway, I just can't see that shrinking. And the business, again, if you go business by specific vertical, et cetera. But the general thing, again, I go, okay, well, AI looks better with the more tools it has access to, tools being Tools that humans need to build or tell AI to build. I don't think that goes away to build those tools for it to have access to. So 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 stop. 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. You know, if I build an app tomorrow, let's use the calendaring app to, you know, as an example, the app to a human, that's one tool. The calendaring app to an AI is like, that's like 50 tools. It's like. You know, find time between Shrif and Nathan that works in this time zone is probably one tool that you give it. Find, you know, time between two people. Block busy time is another tool. Public, you know, get public holidays. And like there's so many ways you could slice and dice that. So I would argue that in that world, designing software for AI is incredibly more sophisticated and more complicated in terms of the quantity of, and the granularity. of which we need to design things to get a better outcome than it is for humans. And so I reached the conclusion of like, I just can't see that shrinking anytime soon. Now, could a vendor's world change so that they go from building a UI to building a set of tools that the AI calls? Yeah, it will, and it is changing, and the business model will change over time. If I look at the app store as an example, Apple's got a big push right now with their app vendors of like, hey, spend time focusing on building app intents over UIs. App intents is sort of their skills and framework. If your app kind of does these things, then yeah, then I guess Siri or whatever the new AI ends up being can use that as a tool. And there's still value exchange done in that tool, but it depends on what the use case is and how that works. So I just see the software continue to explode, but maybe the more useful discussion is having it by market, by domain, because then you could see, okay, you know, how automated software might be totally different to software for reviewing and tracking official document signage or compliance or something like that. That might change. Yeah, it might be different by, by the actual market there.
Nathan Labenz: Last question, leadership. What do you think companies are not doing enough as they try to lead a process of encouraging their people to adopt AI. Things I've said in the past, which I think are like, okay, but maybe getting a little stale are like, leaders should lead by example. Make sure everyone gets hands on. Highlight your individual creativity and success stories. Make AI adoption a part of performance reviews and evaluations is maybe like as spicy as I've got with it. What's the next level up from that in terms of, you know, the best ideas that you've seen for you know, making especially bigger organizations really rally and catch this wave.
Sherif Mansour: Look, they're all good points. I think the nuance comes in the tactical implication of how they apply them. Like leadership modeling behavior is a great example, right? The leaders that do it well and inspire are the ones that can share stories that are more than I used AI to summarize this document and draft this e-mail for me. That's the thing you need to unlock. And so, okay, how do we help? Folks, unlock that. I'm a firm believer, when I again look at tech history, when a technology wave came, when we used it in our personal lives, it ended up impacting our work lives a lot stronger. When we started buying stuff online in e-commerce, it's 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 would say, look at your days as a leader, to be very specific, You might be renovating, I'm just going to run through my use cases, like you might be landscaping your backyard and you could use AI to give you a bunch of ideas, visualize it for you, critique the different plants and the environment you're in, etc. Like 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 that doesn't give away the answer, but knows the school curriculum for his grade and year. And he talks to it and it helps walk through an answer and it's very personalized. We put some Fortnite jokes in there and stuff like that that he likes to do. My daughter, she loves creativity and she geeks out with AI music all the time and makes her own prompts. and all that kind of stuff. So using it personally for the model behavior, I think is the important thing that leaders miss. They go, oh, look, I pressed summarize or I wrote an e-mail. And you're like, that's a great start, but just fine. I actually love asking this question in job interviews. I mean, you personally use AI and you'll see things from planned a trip to redoing a whole house renovation with it, and it's basically running like the show for me. I recently just did a sporting injury to my MCL. And I'm thinking and a physiotherapist, but I've also got an AI assistant that reminds me every day of the exercises I should do. And it checks in on me and I will ask also what I ate and will tell me like, is that good or bad? Like I've spent time prompting it to say like, are you helping me heal as quickly as possible and doing that kind of stuff. The second thing on like you're mandating or now getting others to do it, like I always feel like we've got to show the examples ourselves. Creating a safe space is the hardest thing people will need to do. What is safe? I don't believe mandating is safe. I think that sends a message of do or get out of here. Just generally, if I hear the mandate message, I'm like, okay, it might help some people for motivation, but I think the vast majority of your workforce probably see that as a threat. But again, the nuance in these conversations, I think is where all the value, Nathan is. Fine. We, you know, we just ran a AI builders week, a thousand product managers, designers, engineering leaders, researchers. We blocked time off synchronously across the crafts. So it was no longer in some team, some person is taking a few days to tinker with this thing. That person feels guilty if they come back with a failed project. If they, if they feel like they're blocking the team when the team's asking them questions on their day jobs and they're like over here trying to explore the new thing. So I always say like, okay, find times where multiple people that work together can block their times, so they're not dependent on each other. But what you're celebrating is the learnings, not the actual outcome. The outcome is the learning, not a product outcome. And because tinkering is the most important thing they need to be doing. And then applying AI in their business workflows, like whatever that may means in their department, is something for that team to go through the process of discovery themselves. That's the best way they'll be able to do that. So often say to teams, you'll get customers that will want a high-touch meeting and we'll meet with them, whatever. And they're sitting there exploring and trying to discover this killer use case. And they'll pull in someone who tries to imagine use cases. And I'll often say, who in your company is doing some step of that or that today? No one. And I'll be like, forget that. Just throw it in the bin. Throw it in the bin yesterday. Find me a team of what they're doing today and let's write down exactly what they're doing. And let's walk through, I always say, just write down for any specific task, write down the steps for each task. And then within each step, what are the specific knowledge, instruction, and actions the human takes to solve that step? And then we'll be able to identify opportunities in a more effective way and actually get to a proof of concept super quickly by you guys building your own agents, deploying them in a much more effective way. I think your advice, Nathan, high level tech, I think where everyone struggles is the next click down. I couldn't tell you of any other killer advice other than saying the next click down is often what's missing, which is to help me actually do the model behavior. Help me actually apply to a team. What does that look like? We have players in our playbook. People can go look up and try to open source some of these frameworks for how people can apply on their teams. But definitely go and and do that.
Nathan Labenz: This has been great. I really appreciate all the time and many thorough answers. Anything that we didn't touch on or anything you want to leave people with before we break for today.
Sherif Mansour: No, my only my encouragement is just look at your days outside work and and just play and try things. I think that's what will change your behavior. And that's probably will also change your behavior in your workplace over time, you'll find, because you'll start to use that level of thinking when you get to your work. So that'll be my biggest encouragement is ignore all the buzzwords and all that stuff and just try it when you're fixing your tap next and you need to take a photo and understand which washer is what washer or whatever it is or how that works or whatever it is, just find a way to tinker. But yeah, thank you for your time, Nathan. Really appreciate it.
Nathan Labenz: Sharif Mansour, thank you for being part of the Cognitive Revolution.
Sherif Mansour: See ya.
Read next
