Atlassian Chief AI Officer:
Building Products for Agents and Humans

Tamar Yehoshua: You know, I joined Atlassian right around the time of the SaaSpocalypse, and people are like, wait, what do you mean you're going to a SaaS company? And I just never believed the narrative.

Michael Krigsman: AI agents are real and growing, but where does that leave software and work? Tamar Yehoshua is Atlassian's chief product and AI officer after leading product at Google Search and Slack.

Building products for humans and agents

Tamar Yehoshua: You have to build great products that people love, that agents can work with, and that are valuable. So that thesis of building something that's valuable, understanding the value is the same. I think we started when we were building products with AI of, ooh, this is really cool technology. Let me see what I can do and let me see how I can, what I can improve with the technology. And now people are getting back to the same principles of product management of build a product that is great and that works.

But the new twist is people may be using your product through a coding agent, through Claude Code or Cowork, through Codex, through MCP. So they're not always coming to your site, a human being coming and working with your interface. They might be an agent coming in working with it. So that's an interesting twist. So we have, if you don't mind, I'll take a step back and say kind of our products. So if people are familiar with Atlassian, we do products for teams.

Our mission is to unleash the potential of every team. And now that team includes agents, humans and agents. So for each of our products, take Jira, where you create an issue, you collaborate with your teammates on it. You might want to access that issue from Claude Code or Codex or Cursor or Copilot. And so we want to make sure that if you're working with a coding agent, you can read and write to that issue.

And so that's a big part of making it work for agents, that everything that you can do, you can do. So Confluence, everything that you can do in creating a document, editing a document, adding a table, adding a whiteboard, we've gotten to the point where 95% of everything you can do in the UI, you can do through MCP or a CLI so that you can access that. So that's, that was a very important goal of ours to get to.

And then the stack of what does that mean that you use AI? And so how do you build products with AI is also super interesting and very multifaceted, but I'll pause there.

Michael Krigsman: You described a whole bunch of different aspects as you're thinking about product design for a person versus product design in an agent environment, what's different or what gets overlaid onto traditional product design?

Tamar Yehoshua: An agent needs the context of an organization. An agent doesn't really know, they think of them as somebody coming into your organization with no background whatsoever. Because an agent has access to the intelligence of the foundation models, but doesn't know your organization. So that's a big, big difference of what when you're talking about AI. We think of it as, what are people using AI for? They're using it to accelerate their goals.

You can, it unlocks the ability to do things you couldn't do before, and it enables you to do things faster. So it's a, we think of acceleration as intelligence plus context. So the intelligence comes from the models. So one part is how do you leverage those models?

And so we can talk about that as well as how do you leverage the models, and then how do you give it the context that it needs, but the right context and the context that is for your organization and not too much context that it confuses the foundation model. So that's a really delicate balance. And that's something that's very unique to the agent. And then you have to know when to call it. You need to know how to evaluate it.

And you also want to make it cost effective because you want to make sure that, by when I say you want to understand what context is going to the models, that also impacts your cost. So it's a, and we're learning as we go because as the models get smarter, so the models will use tools and skills to understand how to get their work done for the coding agents and for Cowork and other agents.

So you have to be really smart about what you expose, not just the context, but what tools you expose and how you expose them. So like our MCP and CLIs have over 500 tools from Atlassian that we expose to the agents.

Michael Krigsman: This episode is brought to you by Gartner IT Symposium Expo. Ready to scale agentic AI from pilot to production? Join top CIOs and IT execs this October 19th to 22nd in Orlando, Florida. Over 300 Gartner analyst-led sessions will cover top priorities shaping IT, from AI value, governance, and cybersecurity to cost optimization, IT operating models, and beyond. Get practical insights and connect with peers tackling the same challenges you are.

Secure your spot today at gartner.com/us/symposium. When you talk about context and not having too much, not having too little, first off, what do you mean by that context? Then let's dive into how do you make those judgment calls about what will work best, both for the AI as well as for the person who's the recipient?

The teamwork graph and agent context

Tamar Yehoshua: We have something called the teamwork graph. So the teamwork graph is the context graph that we build for each customer for their organization. And just by using our tools, it builds your graph. And it's something that we've had actually before AI, we were using in our products. And then as AI became more prevalent, we have significantly increased our investment in the teamwork graph.

And so think of it as a map of your organization, of your, all the people in your organization, the knowledge that you have, the data, the structured data, the code that you have, and the communication that you have. So it has all of this information in the graph, and it has it from the Atlassian products, but also products outside of Atlassian. So we can read your Google Docs or your SharePoint docs, your email, your Slack messages, your Teams messages.

We can, we work with Databricks and Snowflake and Google to get data out of your structured data. So all, and we use Workday to get your people data. So this graph will then know if you ask our products, if you ask Rovo about what are all the projects your team is working on, it will know what your team is because we have the hierarchy. We understand it. We, it will know the projects that are linked to that team because if you created a Jira ticket or an epic, who created that?

Who's working on it? We see the Google Docs that you're working on. So we know who wrote the documents, who collaborated on the documents. So this graph tells us so much rich organization about your enterprise. And it's not just let me use MCP to Google Drive and get all the documents that I have interacted with because that'll be really vast and large.

So if I'm asking what are all the projects that my team worked on, it's much more pointed and it can give you the much more relevant information that you need. And that's why it's so powerful because it does inferences in the graph already that are precomputed and make it faster. So those, that's used inside our products. That's also used by, we have an Agent Studio where you can build agents within Atlassian. So you could build an agent yourself.

You could also attach agents to your automations, and then you can use this information through our teamwork graph, MCP, and CLI in third-party coding agents. So we believe in a very open platform. So we take all this information and we give it to you and make it accessible in whatever way that you want. But this is like the cornerstone of making everything more effective with whatever agent you use. We've done a lot of testing. We've done a lot of A/B testing.

And let's say take Claude Code or Codex and use it just with MCP, not using our teamwork graph, and then using it with our teamwork graph. And we've shown that it's better quality. It finds the right documents. It's, the quality increased by 44%. And very importantly, the token usage went down by 48%. Because you don't have to give as much context to the model, and it's much more directed. And so we can help you use less context in your model. So that's the, our teamwork graph. Does that make sense?

Michael Krigsman: Yes. And you've described quite a lot. So let's start to unpack it. And we have a bunch of questions that have come in on LinkedIn and Twitter. And so, let's go to some questions. And I just want to encourage you guys, ask questions. You can, when else will you have the chance to ask Tamar pretty much whatever you want? Here's a question from Arsalan Khan on Twitter, directly relating to this context issue, set of issues. And he says, should AI agents have some sort of, quote, onboarding by giving access to certain data that provides context?

Tamar Yehoshua: Yeah.

Michael Krigsman: Who, human or other agents, define how context can be driven from what systems?

Tamar Yehoshua: The way that the context works in our products is it's all driven by whatever permissions the human has. So if I'm building an agent in Rovo Studio, it's determined the agent has access to the information that I have access to. So you think of it as an extension of myself. In that it's not going to have access to, if you have a personal, if Michael has a personal conversation with somebody that I can't see, then my agent won't be able to see that. Now, is it building over time?

We have the concept of memory. And so, yes, the, our Rovo product under, starts to understand me. And there's a, it has the memory of what I have listened to and what I have done.

Michael Krigsman: Mm-hmm.

Tamar Yehoshua: in the past, and then that builds up over time. And so you get, it does get smarter and smarter over time as you, as it understands you and what you're doing. And then there's all kinds of agents that you can build that you, we have, to the onboarding question, we have onboarding agents for people. Now, we haven't built an onboarding agent for an agent yet. But I think that the agents, the first time you use them, have access to everything. So just directing them to the right thing for that job has proven effective.

Michael Krigsman: So in essence, then, you could say, would it be correct to say that there's a kind of routing that takes place of the data that's out there? You have this large body of data from various systems, and you need to direct the right data to the right place at the time the question is asked?

Tamar Yehoshua: Yeah, think of it, there's this huge graph. Our teamwork graph has over 200 billion entities in it, and there are links between it. But then when I'm asking something, the graph is specific to me and what I have access to. And so that's a really important part from the access perspective. And then agents can, as I said, use my identity when I build them. And/or if I'm even using a third-party agent, using a coding agent or any kind of agent external to Atlassian, then it calls using my identity.

So that's, and we've built in a lot of safeguards around that.

Michael Krigsman: This episode is brought to you by Gartner IT Symposium Expo. Ready to scale agentic AI from pilot to production? Join top CIOs and IT execs this October 19th to 22nd in Orlando, Florida. Over 300 Gartner analyst-led sessions will cover top priorities shaping IT, from AI value, governance, and cybersecurity to cost optimization, IT operating models, and beyond. Get practical insights and connect with peers tackling the same challenges you are.

Secure your spot today at gartner.com/us/symposium. Let's go to another question, and this is from LinkedIn, from Smail B. And Smail says he'd like to push on this idea that context management for agents must treat data provenance as a first-class constraint, not an afterthought. And he says, in practice, that means auditable data lineage and explicit human-in-the-loop triggers whenever sensitive decisions are involved so accountability isn't outsourced?

Human oversight and agent guardrails

Tamar Yehoshua: We have a product called Guard in our enterprise offering that does a whole data sensitivity layer. And so you can put rules in there saying if these are certain types of data, always exclude them or always have checks and balances. So there is a product that we have that does a lot more, I think, on the data provenance side and make sure. And the human in the loop is really up to you in what your in how you configure the agent.

So you can configure agents in Rovo Studio, and you determine how to invoke those. So if you, a lot of people use them in our automation. So if people don't know, our products like Jira and Jira Service Management and Confluence have automations built into it that they've always had. We run millions of automations every month. And there are automations like when a bug comes in of this type, then do this with it. So it's kind of, it's workflows for the organization. So a lot of those workflows call agents.

And you can easily have a step in that workflow call the agent, and then a human needs to evaluate it. So it's really up to the person writing the workflow, or you automatically go through. But you do have accountability and observability. And as I said, you do have the ability to identify and determine sensitive data and make sure that the agent is not working with that.

Michael Krigsman: That's a really important point, this issue of human-in-the-loop. And so, it sounds like you're providing a great deal of flexibility to the user of when to invoke stop points where a human needs to get involved. But, many users don't know. You know, they're not sure. Either they're not sure what to do, or they may be tempted to just press the auto button because the LLM seems to know everything and seems to, quote-unquote, always be right. And so how do you provide guidance to users on when they need to put in stop points?

Tamar Yehoshua: So a couple of things. So one, you're right, and a lot of people don't really know what the best way to build the agents is. So we have templates out of the box saying, here are some, you know, examples of how you should be using them. We also, in our Agent Studio, give you the ability to put in eval data. So you can say, you can actually eval it within Agent Studio to say, is this doing the right thing?

And we have as part of Atlassian, you can work with FDE or technical SE to help you build what you need. So we try and educate people on what they're going for. But the biggest thing is observability. So your admin can see all the agents that are built, and they can also give access to who they want.

So some companies really want to control it because to your point, they're not sure if everybody understands how to build the right agents so they can say, here's a group of people in IT or in engineering who are going to build the agents for the rest of the company because they're trained, we trust them, and then we're going to expand. Or you can say anybody in the company can do it and we're going to watch it. We're going to see what the token spend is.

We're going to see what the value is that's accrued. So what we like to do is, again, be an open platform, be flexible, but give you the controls that you as an enterprise need to be able to turn the spigot on or off.

Michael Krigsman: Yeah, I guess you, as the software vendor, need to be capable of handling all kinds of the many different use cases of which you can't possibly know what they will all be in the future.

Tamar Yehoshua: And we want people to build stuff that we've never imagined. And so we want to start with, here's some things that we see everyone using, and these are really effective. So, let me give you an example just to ground it, of an example of an agent that's built on our platform. So take Mercedes-Benz. Mercedes-Benz has been a customer of the Atlassian suite for over a decade, and they use Jira on their, when they're testing new cars. Testing new cars, a defect comes in, the test engineer puts a ticket in Jira.

Well, as you can imagine, there's a lot of duplicate tickets, and there's a lot of tickets that may not have all the information that they need. So what they did is they built a Rovo agent that takes in all of those tickets and auto-triages them, removes the duplicates, knows who to assign them to, and just gives all the details that you need. And so that triaging agent reduced the manual work for engineers to triage the bugs by 85%.

And so that's a great example, just to make it concrete, of how people are using Rovo agents, with the information from Jira to improve a workflow.

Moving fast versus getting it right

Michael Krigsman: The whole context and the graph that you're building, it's really fascinating. Okay, let's go to another question. This is from Ricardo Anklan, and this is on LinkedIn. And Ricardo says, how do you see leaders balancing the urgency to implement AI agents with the need to thoughtfully assess which tasks are truly suited for them? Seems like a tough call to make without rushing into mistakes.

Tamar Yehoshua: I get this question internally all the time for us and what we're doing internally, this balance of moving fast versus actually getting it right. You have to start with what problem you're trying to solve and what your goals are for that problem. We have seen organizations just say, go forth and just use AI. And then people are just prototyping and they're learning. So in some ways, it's very important to do that so people can understand the boundaries of what AI can and can't do because it's a new technology.

So people don't really understand it, but you have to make sure that you're measuring it. So at Atlassian, for example, we've been running a ton of experiments. Now, this is internally, not building our products. This is how we use AI internally. And we've set up more structured experiments of goals for each department, for engineering, for finance, for sales. These are processes that we want to automate. And then we run with a team, an internal team, obviously using our tools built on top of Rovo.

But there's a good report that we put out on that we're the day, the zero-day customer. So that's, I think, a really important point of what you're trying to achieve as opposed to just go forth and do anything that you want. And we ask people to think about what are the processes where you think you can get a 10x improvement. So this isn't where you want just an incremental 10 to 20% improvement. Yeah. Like the Mercedes-Benz example.

So what we did, like in R&D, we're using obviously coding agents for everything, but that only gets you so much improvement. So you wanted to see around what you're doing. So we gave, there was one team working on Confluence slides, and we said, how can you reimagine all of the workflows, and what would you do? And I'm going to give one example.

There's, I've taught, there's like 10 different things that they did in that example, but one of them was they took the designs from Figma and then the code and said, where are the deltas between the designs and the code? And they used Figma's MCP to automate that gap and coding agents to automatically fix them. So they fixed 14 bugs in an hour, which it would have taken days.

So that's just giving the, again, the concrete example of there was a task and a goal you gave to a team to achieve something. And then it's amazing what they do as opposed to saying just, you know, just use the tools. And to the person's question, I think it was Ricardo, you have to be careful that if you're not measuring what the value was, then you might be going too fast and not being able to see the value.

But I think if you set the goals and then you turn and you come back to them, whatever the timeline is, month or quarter, it's, you're going to see which teams made good use and you're also going to learn from the teams that didn't hit their goals.

Michael Krigsman: Yeah.

Tamar Yehoshua: Okay, this is what we needed and why.

Efficiency first, then new capabilities

Michael Krigsman: To what extent do you see people using agents to drive efficiencies, faster, cheaper, versus using agents to accomplish things that they could not otherwise do? Really, so efficiency versus innovation.

Tamar Yehoshua: It starts with efficiency. So if you take mobile, when mobile came around, all of the first apps on mobile were websites just put on the phone. And then people started taking advantage of signals like Uber being able to have the map and your location. So we're in that same phase. So it first starts with, here's a process and we're just going to make it more efficient. But let's take another example from Confluence.

So Confluence launched Remix with Rovo, where you can take on a page, you can highlight some text and use our Rovo AI to remix it into a new format. Well, that's something you could just never do before. So what we're seeing now is new examples of things that they built that with AI in a way that they couldn't have. So they got much more efficient in how they built it, and they took it from taking months to taking weeks to do it.

They had to eval it in a whole new way, invent new ways of evaling. But then they produced a product that customers could use that they couldn't do before, something that they couldn't do before. And those kind of things really resonate with customers. So I would say we're more in the early innings of seeing those. And even though, if you take the foundation models, they're so powerful.

And even though I think there's a lot of power in the foundation models to do more of that, I think organizations haven't quite caught up yet. And they're starting with, you know, they started with chatting. That's just kind of the basics and finding information and chatting. And now they're starting to really change their workflows in a way that's completely different than what they would have done.

Michael Krigsman: Large companies definitely tend to be risk-averse, and their incentives are designed to continue doing what has worked well in the past. There is that discontinuity relative to, oh, we have this new suite of capability and we should just apply it. No, they're going to think it through and plan it out.

Tamar Yehoshua: While that's true, I'm finding this technological transformation different in that every customer I meet with is like, what are you doing at Atlassian? How are you using AI to transform your work. And they really see the potential of big change. And it's partly fear-driven because they see their competitors doing it and moving faster. And they see everyone launching faster and moving faster. And so there is a desire. Now, they don't always have the ability, but I'm meeting with more AI transformation leaders inside very large companies who are blazing forward.

And they're, we're putting out how you can change and use AI in legal, in marketing, in addition to R&D. And we're seeing, I'm seeing a much faster uptick, which is really interesting. And also, like we had in the beginning, people didn't want to turn on our AI because of all the things you're saying, risk, this, that. But we showed that, you know, we are enterprise ready, and we have things like zero data retention that are really important. And now we're like, we have a huge uptick in usage.

Michael Krigsman: Among our guests coming up, we have the Chief AI Officer of Occidental Petroleum, and we have the Vice Chair of Deloitte. I mean, separate episodes. And, we haven't scheduled yet, but we're about to schedule the Chief AI Officer of Bank of America. So, this would be an excellent time to subscribe to the CXOTalk newsletter so we can notify you, and you can join us, and you can ask questions of all of these people, too. So, go to CXOTalk.com and subscribe. Do that now. Okay.

So, let's take another question, and this is from Michael Beelar on LinkedIn who says, how do you look at your budget in terms of SaaS licenses versus tokens?

Tokens, vibe coding, and SaaS survival

Tamar Yehoshua: Value-driven. Where are we getting the value and making sure that as we increase our budget for tokens, that we are seeing the output. Now, this is a question in the industry in general. Everyone is asking, how do you measure AI? So the thing that we look at is especially in most of the cost for us internally is in engineering. We are using tokens in departments outside of engineering. It's just the usage is small compared to engineering. And so we look at PRs deployed per engineer.

We look at features developed, and we've seen a huge uptick in PRs and features developed. Our OKRs, are we meeting our OKRs? And then the value that that's bringing to customers. We also have a product called DX. We acquired them last fall, and they measure AI adoption in engineering teams and look at all of these metrics, and they help you measure it. And they also do survey-based of like, are engineers feeling more productive? And so that's a tool that engineering leaders can use to measure the output.

But this is what we're looking at. Again, each company, it's early days trying to figure this out, but working with the CFO to say, well, we're delivering more value. Our products are being deployed faster, so we are able to bring more value to our customers.

Michael Krigsman: You're trying to assign quantifiable value metrics to licenses versus, or to token usage against the benefit that arises from using these tokens. It sounds like it's,

Tamar Yehoshua: 100%. And it's not, I don't think of it as tokens versus SaaS. Like, we have a lot of SaaS products we use, like Databricks and Salesforce, and like those we need for whatever purposes we're using. Now we are using their AI as well, their AI capabilities. But do you still have a need? So that I don't feel like it's a trade-off between the two, because if you have a need for those products, those needs don't go away. At least we haven't found that any of those needs go away.

Now, there are constantly new products in the AI realm that we are evaluating. So my team also runs Corp Dev and Atlassian Ventures. And so we are constantly looking at what is new in the industry to make sure that we can stay up to date, not only for building our products, but things that we might want to use.

Michael Krigsman: So like, Atlassian Ventures might come across a startup doing something new and cool that. Do you ever have the temptation to look at some product that you subscribe to, some SaaS product, and say, you know, we only need a few of these features and we can just code this, vibe code this ourselves, and have a smaller scaled-down version that's just perfect for us? We don't even have to pay that cost anymore.

Tamar Yehoshua: I think that works for small companies. I don't think it works for large companies. So once you're a company of like thousands of people or even hundreds of people, if you vibe code something, you got to support it. And if you have all these customers internally, then your job becomes a software vendor. You can't vibe code it and put it out there and not support it. Like internally, if somebody in my team would vibe code something to be used instead of one of the SaaS products.

So if you're a really small company, you have just fewer users, you have fewer needs. But what I'm seeing in the industry is, oh, I could just vibe code Slack. I could just vibe code Jira. These just don't last because the people in the company are doing it to just get underwater. And then how do you deal with data protection? And how do you deal with SSO? And how do you do, as you grow, there are just so many demands. We spend a lot of our engineering resources on enterprise readiness.

Yeah. And your vibe-coded stuff, it's just not secure. It's not enterprise ready. So no, internally at Atlassian, we don't see that at all. We do see a lot of agents being built to automate parts of your job. So we see like agents built for the sales team to help them prepare for sales calls, to help them get approvals and automate them. We see like the finance team agents to close the books. We see in engineering like tons of the most agents are in engineering.

I gave you the Figma one, but there's so many examples of PMs are now no longer writing weekly updates. They use agents to write those weekly updates. So that's where we see, and people vibe code whole apps to do things. So we see a ton of vibe coding internally to help people do their jobs, but they're not instead of large SaaS vendors that we buy their software.

Michael Krigsman: I take it you are not a believer in the SaaSpocalypse where agents are going to destroy software.

Tamar Yehoshua: You know, I joined Atlassian right around the time of the SaaSpocalypse, and people are like, wait, what do you mean you're going to a SaaS company? And I just never believed the narrative, partially for what I said. And we are so embedded. We have 370,000 customers. We are in 85% of the Fortune 500. People run their tier 0 workflows on Atlassian. That's just, you can't substitute that. And we are AI-ifying everything that we do.

So all our products, we are, you know, as I said, we're talking with agents, making sure we can write to agents, we can read to agents, making sure that we have AI-native workflows for all of the workflows that go through Atlassian. So we're helping our customers move to being AI-native. We say that we're like the bridge to helping them become AI-native because we're already embedded there. Now, if we did nothing, and didn't introduce AI into our products, I would be worried.

But I met, I spent a lot of time with the team at Atlassian before I joined. And it's, they built so much infrastructure and so many pieces of layers of the stack to make sure that they would be relevant for the AI era, which is why I was never worried.

Agent accountability and the software lifecycle

Michael Krigsman: I totally agree. I just don't see people tearing out their enterprise systems. Anyway, let's take some more questions. Okay. So, this is a very interesting one from Swami Vaidyanathan on LinkedIn, and he says, as agents start chaining into other agents, how does that model hold up when no human is realistically reviewing every intermediate step? And who's accountable when that chain breaks? How do you approach this challenge as a product design principle?

Tamar Yehoshua: I don't think anybody has figured out the answer to this. So I'm not going to claim to have figured it out. But I can say the principles to your question, the principles are whoever built the agent that starts is still accountable. There always has to be a human accountable. You can't say that there isn't because I just don't think it works if there isn't.

So the human needs to understand that there's going to be a chain of agents that are called and should put in the checks and balances to make sure it's not veering off course. I do worry about that. And, you know, we've seen in the industry how this can go wrong. But that's where I think you have to build safeguards. And I also think that what's going to happen is agents are going to be putting in guardrails for other agents. So you're going to see agents being the defensive.

And you're going to see agents. So let's say you have an agent that's chaining a lot of steps. You're going to have agents verifying each step as well. And we already do that. We use LLM as a judge. So as we're testing new features, we use LLMs to test the features of the LLMs. And we've been using that in the industry for a while. So I think you're going to just see a lot more of the LLMs teach testing LLMs, and people will learn where to put the safeguards on.

But I think of that person, that individual always has to be responsible. And I also think that we as software providers need to, and this goes back to your question earlier on, need to help companies figure out how to do that and help tell them, here's where you got to put the safeguards in. And as the models get stronger and smarter, we're all learning what that's going to look like.

Every new model we test thoroughly, and we learn what it's capable of, and we change our harnesses, and we change how we're calling the models based on that.

Michael Krigsman: Last week on CXOTalk, we had the head of engineering for Snap that makes Snapchat, and they use, they're huge users of agents, very sophisticated internally. And he said that half of their engineering goes into the engineering itself with the agents, and then half of their investment is setting up the guardrails and ensuring accountability and processes for accountability.

Tamar Yehoshua: 100%. So, if you think of pre-AI, if you think of the software development lifecycle, about approximately 20% of your time was spent coding. And you had left of code and you have right of code. And so all of that has, the coding has shrunk with agents, but the left of code and the right of code has gotten more substantial and is a lot more, it's a lot more complicated. As the head of engineering at Snap said, there's more guardrails that you need to do.

So if you think about the number of incidents you would have per PR, let's just assume that that is the same. But now you have so many more PRs, so you're going to have a lot more incidents, and you have to make sure that that code is quality. So one of the things that we've been doing is we've been investing tools in left of code and right of code. So I'll take you through a little bit of that.

On the left of code is, we just launched what we call the AI Planner. So the AI Planner is what you would do to identify what goes into the coding agent. So we take, we start from the prompt of what you want to build, and then we work on top of our context graph. So we understand the code that's existed before. We understand all your design docs, all the people involved. And what we do is we take that Mm-hmm.

All that information from the prompt, we create the spec, then we create the technical document, then we automatically create the work items. And it's a nice collaborative environment where you can put in your teammates for that. And then that's what goes to the coding. Then after that, on the right of code, we have the AI reviewer, which uses LLMs again, but we have the context of all of your previous incidents. So we can look at and say, this code had these kind of issues before because they're documented in Jira.

So make sure to test for those and to look for those in your AI reviewer, look for those type of incidents. So to the person's point from Snap, it gets a lot more complicated to do the AI reviews, to do the reviews for AI code that's generated. And you want to make sure that you're looking at all of the context and previous code and issues. So we have an AI reviewer.

And then likewise, as you deploy, the AI SRE will look at what are the issues and the incidents that you may have had previously in production. So we try and look at the full lifecycle from the idea through to the deployment and use LLMs across every aspect of that on top of the context in order to get the best results.

Simpler interfaces and visualizing agent work

Michael Krigsman: This is from Eldad Postan-Koren who says, we spent 20 years designing SaaS around the human user. If agents become users too, what part of today's SaaS product architecture becomes obsolete first?

Tamar Yehoshua: Obviously, parts of the UI that were very human-centric, but I think you still will have people logging in, but you might have them logging in for different purposes. So I keep on using Jira as an example, but Jira, you had to go in and fill out these complicated forms of each thing that whoever the program manager set up Jira or your Jira admin said that you had to fill out. Well, now with AI, you don't have to do that anymore.

So that's how AI is making the user interface for humans easier. But that's the same for agents. So agents don't have to go in and you're not going to simulate the forms. You're going to have a much easier way of inputting the data, which will then transform to users as well to make it easier. So I, again, I don't think the UIs are going to go away, but I think they're going to get simpler. And then on the flip side, humans want to see what agents are doing.

So the transformation of SaaS has to be that you have visibility into what all the agents are doing. So how do you visualize when a project used to take 10 people, 50 people, and now you have agents and you may have hundreds, maybe thousands of agents running on something. So the whole concept of how you visualize software for agents instead of just humans, that's going to change as well. And I'm really excited about what that is going to be.

We're investing a lot in design because we, this might be a contrarian view, but we actually feel that the design of products is going to become so important of how do you understand and observe what's going on. And so I don't think it's going to go away. I think it's going to become a differentiator.

Michael Krigsman: Sounds like there's a certain amount of experimentation that you're doing on an ongoing basis because the capabilities are evolving so rapidly.

Tamar Yehoshua: It's amazing how fast it's going. And so we have our teamwork graph that really is invisible to users. It's, agents can call it, our products can call it, but we made a website called teamworkgraph.com so that people could visualize it. So you can go and put, you can log in and you can see your teamwork graph. You can see who you're connected to, how you're connected to it, because we thought it was important as people rely on this concept to be able to visualize it.

So that was really, it's kind of an example of humans need to see it. And so we, that's how we don't think it's going away. But agents can be so much more powerful and don't need all those layers, and they can just go slurp up a lot more data without having to visualize every single thing.

How AI reshapes leadership and hierarchy

Michael Krigsman: Let's jump to a question from Tim Crawford. He's a big-time CIO influencer. He's been a guest on CXOTalk a number of times. Tim says, it's impressive to hear how Tamar and team are thinking about efficiency opportunities. He's curious how this is driving toward deriving insights and potentially greater value opportunities.

Tamar Yehoshua: Sometimes we have them upfront, we say, okay, we're going to be able to launch this faster or take this presence and make it better. And sometimes things surprise us in that you see it as you're going. So what are some of the insights? Some of the insights is I believe how information is flowing in organizations is going to change how organizations work. So if you think pre-AI, information flowed through hierarchies. But now with things like Rovo, any person in the company can say, what's the status of an OKR?

Can say, what are all the issues that happened? If there's an outage, what was the outage and why? It doesn't have to flow through hierarchy anymore. And the people whose job it was just to pass information back and forth, they can now work on higher leverage activities. So that's one insight that I've had from watching all of this transform. I, for example, no longer have monthly OKR meetings.

I have an agent that runs, that gives me the updated OKRs, goes through, looks at all the Confluence docs, the Jira tickets, the Slack messages, and then says these are green or these are red. And then I can say, oh, I want a meeting to discuss that one that's red. I'm concerned about it. Let's dive into it. But it just, to me, it just unlocks so much that I'm not waiting for information to come up through the hierarchy. And I'm also not wasting people's time to ask them all these questions.

I can just find all the information myself. So I think that's one, how hierarchies work. And I think all leaders need to change how they're thinking about how they run organizations and where their points of leverage are. It's a very interesting topic for me of how leaders need to change how they lead in the era of AI. And I think if they don't, then their organizations will not see efficiencies and speedups. Then it'll be just micro improvements.

And it has to be not only at the top, but all the way through. We are launching so much faster than I've ever seen in my career. And so you have to empower people to do things without approvals and then have a culture where they will escalate when they need. That's my one insight. I'm sure there are lots more.

Michael Krigsman: We've had a number of guests on this show recently talk about the importance of senior leaders, senior business leaders having a very solid, I was going to say deep, but let's say extremely solid understanding of AI and agents because you need that understanding in order to know how to take best advantage of the capabilities.

Tamar Yehoshua: I couldn't agree more. Our CEO, Mike Cannon-Brookes, when OpenClaw came out, got super pilled on OpenClaw and was building agents to run his personal life and still does. But that depth challenged all of us. And he came back and said to the executive team, you all need to implement OpenClaw just so that you can see what everyone's talking about. And that depth really influences how we think about what products we're doing and it, and we're building and it sets a bar for the executive team all the way through.

That we need to keep up with it, and we need to make sure that we're playing with it. And if you're not, then you don't really understand how this is going to change your teams and how they work. And not every team is moving forward as fast as others. So we measure that, we look at it, we're using the carrot, not the stick. But at some point, maybe that transition. So one thing I didn't talk about yet is how are we transforming internally our organization?

One of the tools that's been the most effective for us is something we called AI Builders Week. So small companies can say we're only going to hire AI-native people. If you're a large company, you got a lot of great people that you want to train them. So once a quarter, we take a week out of everything that everyone's doing in product and design, and we train them on a subject. So it might be prototyping or evals or agent building or coding.

And so we give training, and then we have them do a project, and then they showcase the project, kind of like a Demo Days. But then we're finding that those projects that are built during AI Builders Week, people continue to use them. 70% of what's built during Builders Week actually gets used later. So this is a very effective tool that we have on how we're upleveling our organization.

And it's really important that you don't just tell people to use AI, but you help them along the path and you give them the time and the space. So that's one of the biggest complaints I've heard from people is like, I'm so overworked. I don't have time to learn how to use the tools. You've got to give them that space, and people are so appreciative of that time and space.

Michael Krigsman: This is from David Peles on LinkedIn. He says, can Rovo agents access the metadata in Atlassian's database of all the projects in Jira?

Tamar Yehoshua: Can Rovo cross-project? Yes, as long as the agent has the access to them. As I said before, if I built the agent, if I had access to those projects, then yes.

Reimagining processes and the Forge ecosystem

Michael Krigsman: This is from Babul Kamireddy. Babul says, how do you reimagine entire business processes rather than one process at a time so that, as a company, you know strategically where you're going?

Tamar Yehoshua: You have to start by gaining the skills. And so you may start by one business process. So I think that's okay that you start that, that people understand what AI can do. And then you have to really go back to your strategy. What is your strategy as a company? What is your North Star? What are your differentiators? Where are you going to be successful? So we put together our strategy and the pillars of our strategy, and then you need to ladder up to that.

So get the company comfortable with it and then set ambitious North Stars and say, okay, how are you going to get there in a way that people might not be able to see initially that they can achieve them, but they can.

Michael Krigsman: That's not really an AI issue, is it? That's really one of organizational dynamics and change that,

Tamar Yehoshua: But that was kind of my point in the beginning is that AI gives you a tool to do this. And that's why you have to learn. You have to first do the business processes that you transform so that you understand what the capabilities are. So one issue I think people do is they go too large with AI. I'm going to transform everything, and those usually fail. That's the boil of the ocean. So you got to do the steps leading up, and then you will get to the bigger prize, I believe.

But yeah, the bigger prize is just management, leadership.

Michael Krigsman: Here's a question from Puneet Patwari on LinkedIn. And she says, or he, asking as an Atlassian employee, what would be your future direction for ecosystem and Forge and its potential for users?

Tamar Yehoshua: I think for, so Forge, for people who don't know, it's our marketplace. It's where people build apps on top of Atlassian products. I think it's so critical in the age of AI to enable our third parties and our partners to use the functionality within Atlassian so that they can build AI workflows for customers and expand our ecosystem. But if you're building on Forge, you can use LLMs through our AI gateway, and you can use our agents. We're already seeing partners do that.

I think it's a really, really critical and important piece of our strategy to enable our partners to use AI on our platform.

Advice for CIOs and managing AI costs

Michael Krigsman: Can you offer advice to CIOs in large organizations who are just looking at this swirl of agentic AI and tokens and investments and budgets and just trying to map a pathway through?

Tamar Yehoshua: Understanding what you're trying to achieve, but push the boundaries. I was meeting with a leader at Atlassian the other day that they have automated so many of their processes that they didn't believe that they could automate before, and they did it so fast. And so just make Be ambitious in what you're setting, but understand the tools yourself as we were describing because you don't want to set a goal of something that the tools really aren't capable of.

But I just think that these tools can do more than what people are using. And we see once people build on our ecosystem that they're amazed. They're like, wow, this works so much better than I anticipated. There's so much more that I can do. So be ambitious, but be educated. That's, I would say that combination.

Michael Krigsman: So then, there's this combination of understanding the capabilities and being willing to push the envelope around what could be possible, essentially.

Tamar Yehoshua: Exactly. That's what I would say.

Michael Krigsman: You touched on this whole issue of tokenomics and the increasing cost of AI usage. How does that affect your thinking about product design?

Tamar Yehoshua: So one of the things that we invest a lot of time into is something called the AI gateway. So we do not use one model in our products. We use a gateway that then routes to the model that's the most appropriate model for the job that takes into account quality, latency, and cost. And so what we found is that our investment in the AI gateway has been so important so that we can optimize and not get locked into one model, but optimize our costs.

And so there's tons of things where we don't need the most expensive model by default. We can use a lesser model. So that's what, and I also believe, I mean, the prices keep coming down. Like the frontier model may stay really expensive, but there's so much that we can do in our tools for the previous generation model. So I want to leverage the frontier model so that we can give our customers much more advanced functionality.

So I'm super excited when they come out with more functionality, and we implement it very fast. And if people are getting the value, we want them to be able to get that value through our product. But we also then want to make sure that we're optimizing for costs on the things that don't need that. So we've put a lot of energy and effort into this.

Michael Krigsman: Okay. And with that, Tamar Yehoshua, thank you so much for taking time to join us.

Tamar Yehoshua: I'm very grateful to Thank you for having me.

Michael Krigsman: And, everybody who's watching and you guys who ask such great questions, thank you! Before you go, go to CXOTalk.com. Subscribe to our newsletter so we can notify you of upcoming shows. We want you to participate!