For Q&A, we will take questions live from the audience as well as via the webcast for those that are joining virtually. As a reminder, we're in quiet period, and we won't be discussing or taking any questions about current business trends or the quarter results. Lastly, this event is being recorded, and a replay will be available on the IR website. Now, before we get started, I do need to mention our typical legal disclaimers. This session may include forward-looking statements and may include a discussion of non-GAAP financial measures. Information about risks involving forward-looking statements and limitations regarding the use of non-GAAP measures is discussed on this slide. Please take a moment to review this information. All right. Please join me in welcoming Mike to the stage for a Rovo demonstration. Hi, everyone. Rovo would have given you a great summary of that legal disclaimer, but I think you can probably all repeat it off the top of your heads by now. Martin doesn't often ask me to do demos for investors, so I was like, sure, why not? Let's have some fun. I wanted to recap. I know there's a lot of people watching online who maybe didn't get to attend the keynote or anything, so we've got a few small repeats. I can talk to them in a slightly different way, probably, and a couple of new ones in here. Probably trigger some conversations. I figured there'd be at least one or two questions on AI, so Martin's probably in a very smart place as to what we should demo. Quick recap on our portfolio slide, because it's quite interesting to look at it this way. Rovo is at the center. We're really placing it at the heart, the jewel in the crown, if you might say, the heart of the Atlassian platform. It's both visually there and strategically, that's really important to us. You saw that it's a part of the platform. New products, the strategy collection over there on the right, focus, talent, AI native from day one by being built on the platform, on the Teamwork Graph, on Rovo. All of those features just appear from day one with new products, so that's part of the platform. A few demos of Rovo capabilities. A quick demo of search. You may have seen this one earlier. Rovo search is available via the app, also via the browser extension on the mobile, et cetera. Importantly, we have more than 50 different connectors now. You can see those on the right-hand side here, or a handful of them. All of the major SaaS products, all of the products that our customers have asked for over the last 12 months. We continue to make those and work with partners to make those, I would say. You can see that we get results from all of the different applications threaded together. We spent a lot of time on relevance, ranking, and search quality. We have an amazing search team at the moment. That is very, very difficult. It's very, very hard. It requires the teamwork graph. It requires the social signals from how work happens to get good results and ranking in the enterprise. We feel really confident about where we are in terms of search. Search is important because search is at the core of everything. The teamwork graph, search, chat, think of them as different interfaces to the same data set that we have underneath. That's a really valuable data set. In chat, obviously, we see two things in the deep research demo that I think are interesting. Firstly, it's showing the teamwork graph and all that information in a totally different way. Secondly, it's taking the best of AI models that are available. In this case, planning and reasoning models, things that do multi-turn, take between 5-10 minutes to actually generate this report in actual clock time. Both of those are actually using what's inside. Here, the data from the teamwork graph, the deep research mode for chat, instead of saying, I'm going to give you an answer back in, say, 15 seconds, it will take a much longer period of time and go off and do much more deep calculations. Here, it's telling you we're doing our research planning. It's going to get information from Confluence, Slack, and Google Drive, other places. It'll come back and write you a much bigger report. Again, sometimes you know you want more information. It'll go and do it. All a different modality of the same teamwork graph and data that we have underneath. What's important for us is then to take that human and AI collaboration. You'll hear that from us a lot. The idea that AI, you hit a button, magical things happen, and we're done, I think it's kind of fanciful. It makes for a really nice demo. The reality is we're going to go off and do a lot of research. We're going to take all the historical information that an organization has. We're going to bring that back into a report. We're going to take that report into Confluence, share that with colleagues, and they're going to comment on it, say, this is really good, this paragraph is bullshit, whatever they're going to say. That's great. That's exactly what we want, right? AI's done a bunch of the work. Humans are going to come in, and it's going to be an iterative process between the two. Hence why everything ends in one of our collaboration apps as well. Agents. Out of the box, we have a whole series of different agents. We've showcased a bunch of new ones at Team 25. One of the ones that is perhaps more visual, a little bit different than some of the agents that we otherwise showed. Meeting Insights agent is a good example where it reads meeting transcripts, meeting recordings, and gives you insights, but it's very textual. The Diagram Creator is a little bit different. It starts from a whiteboard, so it takes the information from various places in the teamwork graph. The whiteboard is full of different ideas. This one actually is plotting out an email campaign. You can think about it as drawing like a flow chart from the information you have. It's not just drawing the flow chart. It's actually drawing it and taking different sorts of information to put it into the flow chart. Again, it's generating you a flow chart of an email campaign and thinking through who the audience would be based on information you have in your teamwork graph. The point is it's generated a visual artifact here, but these are just whiteboard objects. Now people can come in. They can move them around. They can add new ones, delete them, et cetera. Again, we're trying to get to that human-AI iterative improvement where at the same time the AI is helping you get started, helping you give you a lot of ideas, and moving you forward, all based on grounded in the data that your organization already has. Probably some questions on software, just guessing. A little bit of a deeper look at the Rovo Dev agents and how they work. Using the same teamwork graph, we'll use that in all of our demonstrations. We know that people plan their work in Jira. Again, the magical demo where you hit a button and just everything's finished doesn't actually exist in the real world. This is a very real-world example. We have a whole bunch of customers using this. Again, we use this hundreds and hundreds of times at Atlassian. You talk down at the booth, they'll tell you all the examples of things that we built with this. The first thing this is going to do is actually link work items. This is much more of a simple teamwork graph demo at the start. It's finding out what work do we have that's linked to here. Similarly, what related documents do we have to here? Actually going to build a piece of software. The hardest thing is prompting the software agents nowadays to give you the right things. We have, in this case, linked work items, linked documents, and written a description of the issue from all of that. Again, there would likely be humans in this flow as well, but all of this is running code. You have a much more full-fledged issue. The next thing you need to do with that issue is turn it into some sort of a plan. It is not just going to go and write code for you. It is going to take that task assigned to a developer. Again, they probably make edits. They make changes. It is not exactly what I want you to do. I want you to do more like this, more like that. It will go and make what is called a code plan. This is telling the developer, here is what I think I am going to go do. Here are the files I found. I found code repositories. I found related things. I'm going to go and modify these files up here. I'm going to modify some tests. Here we're showing off that it can use different languages. This is Go. And it'll generate that and tell you what it's about to do. Again, this can be edited. You can say, no, this code plan is wrong. I want you to do this. All of these steps are there. Partly also, I would say for customers, it's very scary to do 25 steps at once. Breaking it down into a series of sections we've learned over the last 12 months is really helpful for them because they might want to use a few of them. They're scared by some. They want to use some. They want to walk through it. Babysit it on the way through. Totally fine. Obviously, it'll then go and you can actually turn that into running code. Point here is that it generates some code. It'll go off and write the code. Where do we review the code? We review the code in our pull request, which is over here. Oops. I should say also, we didn't go into some detail. You can give it your engineering standards and your existing code base, and obviously all in the teamwork graph, no matter where you store your code. That is really important because it generates pull requests that are close to what your human developers would do in terms of your personal standards and your existing either strict standards or not. Importantly, though, what it will do is create a pull request here. Oh, no, we didn't see the pull request in this demo. Sorry. It'll make a pull request in Bitbucket, and then other agents can come in and modify it as can human beings. Again, pushing the standard that we think that humans and AI are going to work together in lots of different ways, in different processes, maybe more AI in different processes, more humans. We're trying to make sure all our parts can be compiled in those sequences. Finally, the last demo here we've showed off in various places. This is actually an internal agent that we've built for ourselves. You can think of this as a demo of what you can build with Studio. This is a code-driven agent. It's written with code and prompts. It is written inside. We have more and more customers writing their own agents. They generally start with the no-code agents, prompt-driven. They'll combine them with automation, and then they move into code-driven as they get more familiar with all of the technology. This one's called Customer 360. It uses all the data in our teamwork graph and lots of different internal systems that we have. There are lots of systems that we can't get to. In the teamwork graph and in search, we have a bring your own data connector. You can write your own connectors to put data into the system. In this case, we're showing off an agent that can use that data. You can ask to get a brief overview of the customer. I did actually think if we could do this with some of your banks, but Martin said that wouldn't be a good idea. Apparently, we can show you directly your own data. If anyone wants a demo later, maybe you can get it. In this case, we're using VitaFleet again. This gives you an overview of VitaFleet. Now, this has gone off to sales force, Databricks, and our internal billing system to pull back the data. A good example of multiple systems coming back, giving you a single answer. It goes off and asks about CSAT. I want a satisfaction. I just want sales data. I want CSAT. This goes to a purely internal system to get CSAT. Interactions goes to service desk. I think some other place, which I've forgotten. I apologize for that. It goes and generates a Confluence page with all the things that I've just generated. I have prompted it. I've gone back and forth. I've gotten the data I need. Out comes a Confluence page. I can share this with a team, et cetera. A great example because we used to have people generate these for me all the time. I go to sit down with a customer, a bunch of customer meetings every single week. I get a customer brief before I walk in with all this detail. I want to ask a question. I have got a fixed document. I cannot at this point. I use this. Maybe not every day. Let's call it three to four days a week, realistically, but almost every single day do I use this agent to go look up a customer and do things. I am very familiar with our internal customer systems. It is really handy. I can just say, give me a brief, and then I can share it with someone or vice versa. It just saves time for people internally. Super brief demo of what we can do with the teamwork graph. Hope that was helpful. Probably spurred some questions. Let's go to Q&A. Ten minutes. Close button. Ten and a half. All right. Come on. You're good. Oh, we want to get the chairs. All right. As I mentioned earlier, joining Mike is going to be President Anu Bharadwaj and our Chief Revenue Officer, Brian Duffy. Just as a reminder, we are in quiet period, so we won't be taking any questions about business trends or any financial performance since our last earnings call. I have a second from the front. No, I think you're here. We're in this order. Thanks. It's just reversed. For live attendees, raise your hand. We have some mic runners around the room. As well as you can scan this QR code and submit it via the platform, I can answer questions here. Also, for those watching virtually, you can submit questions and we can take your questions. All right. Let's start in the front. Keith. Thank you very much. Appreciate you guys doing this. I know it's sort of an awkward time for you, Martin. So appreciate doing this. I wanted to ask one of the, I thought, larger, more interesting announcements was Rovo's now for free. And I just wanted to try to understand the puts and takes associated with that, making that decision. It was a pretty $20 to free is a pretty significant change, but maybe just walk through the logic of that. I also thought, I'll just ask the second question, is I thought your diagram was really interesting where Rovo's now at the center of everything. As I think about that, was just hoping maybe you could elaborate a little bit on how that might pull some of the other things, particularly JSM, and how you think that it may differentiate JSM from ServiceNow having Rovo on the front end of that. Thank you very much. Oh, sorry. Keith Bachman from Bank of Montreal. Sure, Keith. I can take that. A few things on both sides. Puts and takes is maybe a good way of explaining it. Firstly, what have we learned over the last 12 months? Rovo is super popular. You heard that if you're in the room today, right? People are really excited. It's super popular. It's got amazing customer reception, which is awesome. Secondly, it's ever more essential to our platform, actually. When you think about it, you kind of can't have a piece of your platform that's off to the side. We've been really trying to get it closer and closer to the core of the platform, and then we can build amazing features in all applications. The put and take there is obviously we think it's better for us to have it in the platform as a part of every application. The net gain from that is higher in terms of going wall to wall in companies and more seats of whatever it is that Rovo's inside rather than Rovo by itself. Thirdly, the pieces of Rovo also are really essential, even when broken apart, right? Just the great search that we have makes a difference to every single customer. You start to get into a system where you're like, you know what? We should put it in the middle and we should work hard to get there. The last part on the opposite side of the ledger is we know a lot more about running Rovo now at large scale. I think 12, 18 months ago, people were much more afraid of the costs of these types of things and not only have the costs come down externally in various different forms, I would say. Some features are running like three orders of magnitude cheaper than we were 18 months ago. Not only have the costs come down, we're much better at running it at scale. We understand what our usage costs are likely to be. We're obviously very capital efficient and very careful with that sort of thing. It's probably a combination of these factors. We feel we're doing really well in this space, right? We have an advantage. We have a very thoughtful graph. We have a very thoughtful platform. We have a very coherent story, and we have a product in the market out there usable by customers today with customers actually testing. We want to press that advantage. We think it can make a big deal with customers. It's only been a few hours, but they've been super excited. Obviously, we had the enterprise customers here on Monday and Tuesday, but they were really, really excited about its potential and possibility. Thanks for some time on JSM. Anything specifically on JSM? Yeah. For JSM and AI, we've had that in early access program for a while now. We see more data, and it's performed really well. Like we talked about in the keynote this morning, we've had several customers deploy our virtual agents in a service management scenario. That is one of those places where there is a natural evolution to be able to use AI. There we see it in HR service management, customer service management, IT support, a lot of the traditional use cases, et cetera. I think that is a particularly interesting market for us because it really plays to our strengths. With the investment we've made in Rovo and the platform, it really enables us to punch above our weight and be able to deliver for customers things that we would not have been able to deliver a couple of years ago. Now with the combination of Rovo plus JSM, we see customers use it in a lot more expansive and creative ways. This stuff, I will say, just to zoom out of the JSM space in general, is very expensive and hard, right? You're always asking, I think you've asked probably a number of times over the years, where does all the R&D go? Right? This is not an uncommon question. This is a good example, right? There's no doubt we're investing very heavily in the search space, in the graph space, in all of the underlying platform components. We want to distribute that across as many of our products as possible. There's sort of a logical distribution of the sort of CapEx spend, if you like, on the R&D there. If you don't have a world-class R&D team, this is not as easy as just getting some model off the internet and plugging it into data. It takes a lot of learning and a lot of iteration and a lot of continuous improvement that we feel we're doing better than a lot of other people out there at the actual R&D and the quality of the product. We hear that back from customers as well when they go and compare our results to other people's, whether that's in virtual service agents or in just sheer search ranking or anything else. That has come from a lot of hard work and grift and an amazing engineering team. Good follow-on question that's come in from Michael Turrin from Wells Fargo attached to kind of Keith's question is, how do you factor in potential surge usage on Rovo? Are there usage-based components of pricing to mitigate the surge in costs? Hi, Michael. Yes, there are. We put it up online. There's definitely some consumption-based pricing aspects to the billing, which is there. Again, surge is probably a good word as used in the question, right? The goal is to have that as, I guess at the moment, a constraint or a limiter on overuse or excessive use, much like our pricing on things like storage have been in the past. We're long familiar with that model. You want the vast majority of customers to not have to think about it. When they do have to think about it, it's really like they have an extreme use case and they see value in that extreme use case. We do have that consumption-based billing aspect in there. It's a little different between the different mixes of products and other things. We have tried to be pretty clear about how we put that up for customers. On the Rovo and AI side strictly, think of that as the agents or AI usage. We then also have the consumption-based pricing on Forge and automation rules. You have automation rules as sort of one stack. You have Forge or sort of cloud services that are underneath Forge from databases, all the other sets of Forge services. You have AI. Think of them as three different credit stacks. From a studio perspective, it depends on how you remix stuff. The more customers build on the platform, yeah, we want them to be really clear on what they're paying for that. We'll go with Adam in the front. Good job. Thanks, Martin. Adam Tindle, Raymond James. Mike, one of the other announcements here at Team '25 was the Teamwork Collection. I thought it was particularly interesting in the $15 bundle of Jira, Confluence, and Loom, and I guess theoretically Rovo into that as well. Reminded me a little bit of Atlassian Together that you announced a couple of years ago. I wonder for the question, some observations since you launched Atlassian Together a couple of years ago. As you kind of think about this Teamwork Collection, the risk from potential headwinds of the existing SKUs are priced much higher than this. Does it introduce some level of existing customers maybe moving to this bundle and saving money and hurt growth? The reward would be, I would theoretically think this could lead to more wall-to-wall adoption at customers. As you kind of weigh the risk-reward of bundling those products together and what it might introduce, just touch on that. Was that a question or a question and answer? You did a great job answering your question there. Yes, sure. No, there's no doubt that's the case. Look, we've learned a lot over the years about how to put things together. We've always said, if you've listened to me for probably the last 10 years, packaging and repackaging and changing pricing structures to adapt to the market and what is the expectation of what's included. We have defragmented our pricing continually over the last 20 years, in fact. See this as just a continual evolution of that, firstly. Secondly, it certainly has much more attractive economics for customers that are going wall-to-wall, which we see, and obviously we want to encourage. It's a really good thing, and we believe it has amazing value as both a platform and then a set of platform apps and the core collaboration apps. That set together is amazing value, and we've always looked to have amazing price-value ratio among those things. There's no doubt that the goal there is to go wall-to-wall. I don't think that's a bad thing at all. Secondly, it also has a fixed edition structure and a fixed seat structure. There is a trade for the customer to always think about there, which is really good in the case of things like Loom or other things where often they might think, "Oh, I'll just get it for 100 people," and you're like, "Actually, you know what? I'll get it for everybody because you've got one seat count across the Teamwork Collection." That tends to be a good thing, and we're certainly using all the learnings we have from past history. Yeah, just as a data point of that, we recently concluded our early access program for Teamwork Collection, and there are plenty of customers who proactively come to us and say, "We want to displace other tools across the organization and standardize." This is a great way for us to get a foothold and do that at one shot and standardize on the platform. That has been particularly effective for our larger customers. Let's go with Alex in the front. Hey, guys. Alex Zukin with Wolfe Research. Maybe another variant of probably a question you're going to get a lot today on Rovo. If you think about just the transition to free in terms of getting it really unlocking the potential, getting into the hands of as many people to play with it and try it and use it, and how do we think about the monetization of that functionality? I think there's a lot of anxiety from some people in the investor community of like, "This stuff's just going to basically be built into most of the enterprise software vendors' basic or premium functionality." Gee, there's a whole lot of CapEx being spent on something that makes the product better, increases retention, maybe drives premium functionality. At a basic level, kind of how have you thought through the equivalency of that initial per-user pricing with consumption ramping, use cases getting used, agents being deployed, particularly some of the ones that you demoed? How are you guys thinking of kind of 12 months from now when we're thinking about how much either AI-adjacent or consumption revenue you guys are starting to drive? How do we start thinking about those equations? Look, I think you can believe in a series of future worlds, right? If all this stuff becomes free and included with everything, we want to have the best thing, and we want to make sure we get there as soon as possible. If that is the future world that you believe in, this is probably a really good move for that because we know we've built something really good. The general jobs that people hire us for in broad collaboration and project management and communications and all this are still going to be jobs many years in the future. The best thing for us is to get as much wall-to-wall penetration and as many customers as possible with the highest sort of value ratio of our products. That is all good. If the usage turns out to be, again, much higher than we anticipated, we do have the consumption billing for any sort of overage. Obviously, the ability to move those levers around in time as we learn about potentially consumption levels that we cannot expect right now. I still think even in that world, though, customers are going to look for really great products. It has to start with something that is really, really good. It is very easy to make AI demos. It is very hard to make large-scale shipping enterprise products that deliver value to the customers in a way that they can describe. We spend as much time on the design and the implementation and the quality of the results. The team, I'll tell you, the search team, the graph team, the conversational AI team, all the teams we have are week in, week out trying to measure their progress with real customers and make their answers better and their quality better and applying across all those weapons. That is, it's really, really hard to do. We do think it's something that we can deliver to the customers, unique answers, unique both in the data sets we have and the interfaces we have that they already play in, but also unique in the quality of what we can give them back on top of that data and that knowledge, which will hopefully gain us more data and more knowledge from that company. There is an ability to stay ahead in that. I do believe in that, that we can stay ahead in this race because it will be very hard for other people to catch up or keep up. We're certainly trying to run that as hard as we can. Maybe a supplemental perspective on that is it's very early. Consumption-based pricing is going to be an important component for us, for sure. It's too early to predict exactly how that's going to pan out. To his point around, it's easy to build demos, hard to build real products. I think we will find out a lot over the coming quarters. We will find out from enterprise customers which are the patterns that light up. Where are the places where consumption-based pricing makes the most sense? Where are the places where we need to go figure out what kind of customization customers want, etc.? I think we will go through a learning loop over the coming quarters. Maybe one thing to add, Alex, is within my organization, then there's the opportunity to get closer to our enterprise customers to understand the challenges that they have. Rather than introducing barriers to AI, we're actually doing the opposite. Embedding teams that are going to be able to partner with our customers to understand where those use cases are that then are going to lead to expansion. Not only within our four walls, also working with the ecosystem. Earlier this week, we had them together on Monday. We will over the next couple of weeks in terms of enabling them so that we can actually partner further with our customers. Maybe just a follow-up, Brian, for you. Welcome to the organization. Just, I guess, maybe what are you seeing the kind of, I would not say low-hanging fruit, but the most earnest opportunities? The team's done a great job of painting the picture of how much enterprise dollars are available within the current configuration of the customer base. When you think about applying your previous experience at SAP here, kind of how do we, what are you finding as getting you really excited incrementally from when you started? Firstly, the journey that Atlassian has had has been amazing. With all of the customers that we have and how they all came through effectively the same door. In 90 days in the company now, approximately, meeting with customers, seeing how mission-critical we are to their organizations is a great, strong position to be in. At the same time, also seeing the very healthy, positive relationship that we have with customers and users is very refreshing for me personally. At the same time, we have an opportunity now to really lean into the customer-centric selling motion. To move away from products, to build out the organization more so we have more feet on the street, but also more of a VAT team to really understand what are the problems that our customers are facing and how are we going to best serve them. At the same time, a big opportunity is around customer success. Back to my earlier point around how we embed teams to really help them adopt solutions. I also believe there's low-hanging fruit internally within our four walls in terms of building best practices from a rhythm cadence perspective associated with a sales organization. We have a really healthy and thriving ecosystem, which has played a huge part in getting us to this point. We can get closer and closer with them, for sure. I would say the other low-hanging fruit in time that we can go after is new markets where, quite frankly, we're not there yet. There are a lot of new markets as we roll into fiscal year 2026 and 2027 that we'll be looking to see how much business we can take from those markets. Arjun, you had your hand up earlier. Thank you. Maybe I'll touch on private cloud and Government Cloud, or sorry, Isolated Cloud and Government Cloud, which were interesting announcements. What role do you see those playing as you kind of look to migrate DC customers off into the cloud and maybe capture more share in the enterprise? From a product perspective, feature parity perspective, should we think of that as equal to existing commercial cloud, or are there going to be differences in product development and feature parity? Thank you. Maybe I'll go backward to forward there. There's definitely some differences with the government cloud and the isolated cloud. Government cloud has already got early access customers running on it, so it's probably a year or two ahead of the isolated cloud. Obviously, they share a lot of architectural primitives. The important part for customers is they're all running on the fundamental cloud code base, which is really important for them so that the innovations we deliver, by and large, will be delivered to all clouds unless there's obviously an exception that requires it to be eliminated for some particular reason, which is a vastly different architectural model. Secondly, we've spent a lot of time, as maybe you would expect, Arjun, you've been with us for a while, making sure that we have the engineering capacity to run this at scale. We've spent a lot of time on both the isolated cloud offering and the government cloud offering to make sure that we can do that in an efficient manner, continually re-architecting the base levels of our cloud built on some of the fundamentals we built for data residency and just continuing to push that. We do believe that there'll be more opportunities, let's call them, in that world. There's no doubt government cloud is a big space we haven't really gotten into yet, so it's just getting started. Isolated cloud for some of the gnarliest complex data center type customers that have that offering. Obviously, they have different pricing schedules and things for both of those and a set of requirements. The reason we've spoken about this before, philosophically, the world is going to have, I think, a lot more regulations and compliance rules that are in a lot more variance around different geographies or areas. That is the reason we keep investing in the architecture so much to make sure that we can keep up with that and use that as a strength. I think we're really in a good spot to do that. Itai. Thanks, Itai Kidron from Oppenheimer. A couple from me. First of all, are we at a point where customers, or how close are we to a point where customers can no longer buy the product without actually using Rovo extensively in their daily usage? Is there a point in time when that happens, number one? Number two, regarding the agents, you gave a couple of examples of multiple agents in different areas. It seems like some of them are perhaps overlapping with what other vendors would think is their area of expertise, Customer 360, for example. Why are you a natural place to do all of this? Are there agents where you'd say these are use cases where it's more natural to run it through us rather than to run it through a CRM system, for example, or somewhere else? Help me think why you are the gravitational point for that. I mean, two different questions. When we say our customer is going to use Rovo, I would expect that in 12 months' time, yes. Most users use Rovo every single day. Let's not forget that search is a part of Rovo. Even if you're just using Confluence, you're using search quite a bit to find stuff, you're going to be technically using Rovo. You'll get better search results. Maybe on that spectrum, that's not quite what you're asking. Technically, that I think would be the answer. The agents and the chat functionality, etc., we want that to be a very natural progression. There are more and more places in the products that will drive you to get a chat-based answer, which you can then interact back with. Even from search, there are paths into chat. Part of what we want to do is build a fabric where they kind of disappear. Yes, you're moving between apps, but you're not really thinking about that. You're trying to find an answer, and you're getting your answer. There'll be modalities where people think chat is more sensible and not. I can tell you inside Atlassian, there are a lot of people who live with the chat sidebar open. I don't. I open it when I need it, and I close it again. There are a lot of people who just seem to like it sitting there all the time. It's like a constant companion that they're using. There'll probably be different work patterns. I think we're all learning about how these work patterns emerge. Agentically, look, we have a great framework for building our model of agents. We have a pretty clear definition of what an agent is. I would say other people have a very vague definition of what an agent is. If you fit our clear definition, and we have a very fulsome technology stack today, I heard that from a number of customers over the last two days, especially in the enterprise, largely based on our heritage in Forge and in other extensibility mechanisms. You can build a very, very full-fledged agent today that is not just a chat responder. It actually does a lot of things. It can take a lot of actions. It can be combined into automation rules in various ways. It can manipulate and appear in the UI at lots of different spots. This is very fulsome as a framework. That is one reason you would choose us, if that makes sense. Second, we have a lot of interfaces, which may be a starting point for your agent journey. Obviously, if you're doing anything with projects, to do with documents, to do with data, we have a lot of reasons to be there. I think customers will build their own agents that serve their own purposes. We built Customer 360 because it leverages our data in Salesforce, but it also leverages our data in our internal cost repository and billing systems and customer service and various other systems that we have. That's maybe a case where we are a consumer of a series of different products. Because of the way our agents interact with each other and with human beings, there's no reason also they can't interact with agents from other agent frameworks if the customer wants them to do that. I don't have any examples off the top of my head of customers, but I suspect six months and 12 months from now, I'll be able to give you lots of examples where people are doing that. I think that's totally natural for any new sort of technology progress. There's nothing exclusive about them not being able to interact or share data with other services. I think the why are you the natural place for us to build this? Three clear reasons. I just came out of a customer meeting with a large chip company that's trying to do this with us on Rovo, and they're really excited about three reasons. One, as AI-native development becomes more prevalent, user personas that used to do traditional tasks before will do a lot more. Where do you call Customer 360 from? Is it really your salesperson that's calling that agent, or is it everybody else in the arc, any customer-facing person? It'll be a lot more the latter. The work surface area, I think we have a very broad work surface area. That's a big advantage. This is why they want to build our agents. Second, the teamwork graph connects to 50 different connectors and has programmability built in. We have a heritage of programmability. Customers already have plenty of custom apps. Building custom agents just got even easier. From Forge, we are now down to a point where you can do non-coding. Third, really, it's about the agent building is translating into every single team across your company. Because the things that we're doing in the virtual cycle around Teamwork Collection, making sure that knowledge workers have wall-to-wall access to our products, etc., it's a virtuous loop of it's only going to get better and broader and easier. We see a lot of customers want to get a head start on that and build agents alongside. I suspect in 12 months, there will likely be overlaps of agents. I think it's going to be very important to say, how easy is it to build the agent, and how easy is it to use it without asking you to retrain your entire workforce and make them do unnatural things? I have a question from online that I think is good to change gears on. How do you think about the competitive set in CSM, and how has success with JSM and ITSM informed the decision to extend to CSM, and do you see further expansion opportunity? Yeah. In CSM, today, 25% of our JSM customers already use JSM for customer service workflows. There is a lot of pull from our customers in this particular area. The way we think about that, our right to win in this space is twofold. One, AI disruption is really completely changing the space. It is really creating an opportunity for new players to come in and redefine the game. Because of our massive investment in Rovo and the teamwork graph and the platform that we have built for several years, this places us in pole position to really operate in a new market, to Brian's point. Second, the fact that your developer teams, ops teams, are already on our platform and placing customer support teams on the same platform really gives the same ability of breaking down silos that we have seen very successfully work in the JSM space. We bring the same advantages to the CSM space. Across those two, we believe that we have a clear right to win in that space, and that's why we're excited to roll out the beta of the CSM app. What was the second part of the question? Do you see further expansion opportunities? Yeah. I think with the whole collection and system of work, as we've spoken about extensively before, our fundamental thesis is that we want to expand beyond our traditional sets of customers that we address to the non-technical teams, to teams that have no technical backgrounds necessarily, but are adjacent with other technical teams. Technology-driven organizations that have business teams that interact with technical teams. Customer support is very much in that definition. We are very bullish on being able to address that market. I'd say we also showed off the HRSM stuff. That is a slightly different space, again, an internal use case driven by a lot of people using Jira Service Management in HR. Now we have dedicated templates and connections to Workday and all sorts of other things that is different. Lastly, for those students of history, I forget the percentage of Jira usage that was serviced before we had Service Desk in the first place, but it was somewhere around that 25%-30% mark. That's right. It was around. People were using Jira back then for service use cases before we even had a queue or an SLA to speak of. It is a traditional sort of follow your customer, and that's worked out pretty well so far. Maybe to add to that, in terms of maximizing on the opportunity, we have a specialized Salesforce in certain areas of the business. JSM is one of those areas. As Anu said, CSM directly relating to it gives us the focus that we need from a go-to-market perspective to go after the potential in that particular space. Rob, up front over here. Thanks, Martin. Rob Oliver from Baird. My question's for you, Brian. Since you've only been here three months, just be curious. Atlassian built a really unique and world-class partner network that I think is the envy of most growth software companies. Following the company a long time, we've seen a lot of these partners grow from really small to being able to rent out Disney for their customers last night. I'd be curious to hear, with a lot of talk of platform and clearly a move to enterprise, what your philosophy is on how to manage that both opportunity and potential for conflict as bigger partners start to come in and what your view is on that opportunity at enterprise. Thanks. Yeah. Thanks for the question. Firstly, I think, as you said, we do have a great ecosystem, and they have done very well by partnering with us. We now have an opportunity to invest further in our partners. We've taken some initiatives already in terms of rolling out some tools to assist in terms of migrations to help them. In addition, we now need to move our partners away from the traditional transactional selling and instead to look at new models whereby we're going to be focused on moving our customers to the cloud, rewarding them for services engagements as opposed to traditional rebates potentially. At the same time, we need to enable our partners more, let's say, better. I think there is, back to Alex's earlier question, there's low-hanging fruit around that space as well. I think from the 90 days that I've been in so far, it's very clear that our customers are hungry. The ecosystem is very hungry as well for further investment from us and direction. Finally, I would just say we have an opportunity, like I said earlier, to look at new markets and where we can actually partner with some partners. One of the things that I've gone out of my way to stress to the partners that I have met with is we don't have a plan to roll out a large-scale services organization, which would cannibalize their business, which obviously they're relieved to hear that's the plan. However, we will have a small advisory services team that we'll reserve for our largest customers so that we can put some hands on keyboards to help in terms of migrations. One thing I will say I've heard—sorry, maybe we didn't get all much piling on—but I've heard three times in the last, once yesterday and then a couple of times last week with different partners. Our scale as a platform is enabling them to start doing things that they couldn't do beforehand. By that, I mean the maturity of Forge databases was a big step for them. They can build real applications now on top of the Atlassian platform, which they couldn't have done 12 months ago. The movements in Forge and also the excitement around AI and agents is letting them go in and sell services to our customers to really solve unique use cases entirely on top of the Atlassian platform that wasn't really possible, certainly in the cloud, 24 months ago. I'm really excited to see how they do that, right? We've long had a history of not just partners going in and selling software, but solving problems for customers by building unique things, by taking Jira and adding stuff on top and solving a customer problem. To hear them say that cloud has reached a point that they feel like they can do that, supercharged by AI coming in, obviously customers asking them, "Hey, can you solve this problem for me?" Giving them Rovo plus Forge plus all the other things, really excited to see the things that they can build for customers, which is only going to benefit us in the long term too. Greg, up front. Hi. It's Greg Moskowitz from Mizuho. I wanted to get back to Atlassian Isolated Cloud. I think it's a pretty exciting development. That said, our understanding is that Isolated Cloud, at least initially, is only available to your very largest data center customers. If that is correct, I guess why restrict Isolated Cloud so significantly? Why not appeal a little bit more broadly to your population of DC customers that feel like they just can't pull the trigger on moving to the cloud today? And then just a quick follow-up for you, Brian. Very helpful to sort of hear your perspective on the business. I think a lot of us look at Atlassian just being so successful over the years, 300,000 customers. And so there's, I think, many who just look at this and kind of say, "Well, it doesn't seem like there would be many opportunities from a new market's perspective." You just kind of called out, obviously, small advisory services. Do you see other opportunities where maybe Atlassian isn't very present or not at all present today? Thanks. I can take the first part there. Isolated Cloud, by its very nature, obviously is appealing to a relatively small number of our customer base who actually really, really care about isolated and dedicated networking, dedicated storage, dedicated compute. They understand it's an expensive exercise for us to provide that, no matter how great our R&D is because of the volume of services that we're putting into there. It's quite technical and complicated for us to do. It's naturally going to have a smaller base at the start. I will say, look, we're targeting the Fortune 500,000. I don't expect to sell 500,000 customers Isolated Cloud, but we have a long history of believing markets are bigger than their starting point and building the right engineering so that we can scale that out. I would point to our search engine as a good example of where we need to run that at 300,000 customer scale, not 2,000 customer scale, which is a vastly different exercise. Definitely a high potential future opportunity for us. Brian. Maybe in terms of the opportunity, I would say we've been very fortunate because we have a lot of technical users who are our customers, which has been great. We had Domino's on stage earlier today, one of the customers where they're both on the technical side and on the business side as well. In their words, they're wall-to-wall on Atlassian. We now have an opportunity both within the existing install base that we have to sell up. That can happen from both a top-down play, which many enterprise software companies do very well, and we certainly have the right to do that. We also have the opportunity to have a bubble up within the same 330,000 customers that we have. In addition, as we roll out new products, we have an opportunity to cross-sell and upsell into the same 330,000 customers. Obviously, there is the opportunity to grow that 330,000 customer base significantly. All of our new customers today come in through, like I said earlier, the same door. There is an opportunity to look at new rights to market and new partnerships that are actually going to open new doors for us and new logos as well, which for me is a big priority. Karl, back there. Hi. Karl Keirstead with UBS. I've got two questions, one on JSM competition and the other on the channel. On JSM, obviously, Mark Benioff on the last Salesforce call announced that they will be soon pushing deeper into the ITSM space, presumably at the mid-market. I'm just curious, when you think about Salesforce entering that JSM space, what did you think when you heard him make that announcement? Ooh, me commenting on market is dangerous. We feel very comfortable where we sit in the ITSM space and our R&D backbone. We just focus on the customers and make sure we're doing what they want us to be doing. I think we feel really comfortable about where we sit at the moment. Made a lot of really good announcements here. We haven't even talked about asset management. Obviously, when we're pushing assets from 3 million to 10 million, and we'll continue to push that scale, it's because customers are hitting those upper limits of the number of assets that they can store in our graph-based CMDB and the ability to show interesting things with that in AI and other places. I think we have a lot of really good strengths in that space. Okay. Makes sense. On the partner channel side, I know that Atlassian, I think last quarter, may have lowered the commission structure for partners on data center. I'm assuming it's part of a strategy to motivate them to push the customers harder to cloud. Can you describe those incentive changes? Sometimes on the outside, when we see them, we worry a little bit about channel disruption risk. Maybe you could talk through it and flag why that's not a concern and you feel good about those changes. Thank you. Sure. I can take that. We did have some changes that we rolled out. When we're going to make changes like that, we'll give notice well in advance that this is likely to come. Just like recently, we've started talking about moving away from transactional and then rewarding more in terms of the delivery side. The changes that we rolled out before didn't come as a surprise to our partners. Now they see, obviously, a continuous push in terms of moving to the cloud. They, at the same time, see the push in terms of moving away from transactional. I don't think there was any surprise when we rolled it out before. Our commitment to them is, as we continue to roll out any other changes, that will be very transparent. Ultimately, for me and for the organization, we want to move our customers to the cloud because they have a completely different experience when they're there as opposed to the data center solution that they're running. Not only is it the right thing for us to do, but we actually owe it to our customers to get them on that journey. I think leaving this week, and Mike said it earlier, it's coming back loud and clear to our customers and to our partners that it's not a matter of if they're going to move to cloud. It's a matter of when. The obligation for us and our partners, whether somebody who's blocked, is to run in the door and to figure out what is the issue that's holding you back and embed a team there to help them get on the journey. Let's do Jason on the end here. Thank you. Jason Celino from KeyBanc Capital Markets. I just have a couple more clarification questions for the Teamwork Collection. Just want to confirm that it's only for cloud customers. Also, you said it starts at $15. Obviously, your pricing is fairly transparent, but you have different tiers. Maybe, are there higher tiers or what does that kind of look like? What's included? Yes, it's only for the cloud. Pricing is similar to other things we sell, I guess. Obviously, there's premium edition and enterprise editions, which go up in price, and then there's volume, which goes down in price. It's not dissimilar to other things that we have in the way that the whole schema works. Customers seem to really understand that. They expect these two facilities. We've kept it the same for that distinct reason. Up in the back, Tom. Thanks for taking the question. Tom Blakey with Cantor. Michael, you mentioned the asset management product. I just wanted to double-click on that. How difficult is that to unstrangle the stranglehold that some larger service management platforms have had on the CMDB for many years? If there's any other impediments that you're kind of targeting that you're seeing in the market today that you're thinking about alleviating? Maybe a second question first. The move from data center to cloud is very encouraging. Walking the floor today, everybody's really excited about that and can share with you. Is FedRAMP High needed for some of your government type of businesses to move there? If so, are there any plans for that? Thank you. I think the strengths of Atlassian have long been our R&D heritage of building really, really great software with great architecture underneath it. That behooves you well at times of transition like the movement to AI. Secondly, providing incredible value for money for the software and the business value we deliver for the price that customers fundamentally pay. To deliver value first so that they see value and then they continue to consume our software. That's been the same for 25 years. Certainly, in some of those spaces you mentioned, we feel we have significant advantages in the price-value ratio and the technical excellence of what we do. We intend to keep our strategy pretty consistent for the long term there. FedRAMP high. Yes, there are certainly customers, I'm assuming. I don't know any off the top of my head. Actually, I do know a couple, but who? That may be an issue. FedRAMP Moderate is a much larger leap, I would say, in terms of getting that approval. Obviously, it's a first step on a journey. Whether there's a second step and if and when we take that step would be potentially sometime in the future, I guess. It is a big step already that we've taken here. It unlocks a huge amount of the government and government-adjacent customers. Often, it's not specifically government departments themselves, but obviously, companies that serve the government that need to have that. That tends to be at the FedRAMP moderate level. Otherwise, we'll do what we do and listen to those customers. Steve. Thanks. Steve Koenig from Macquarie. I'm curious to get your thoughts as you're pushing the envelope on agentic AI adoption. What are you seeing as the customer concerns and barriers now? How ready is their data? Where do they sit in terms of needing to be sold this stuff or experimenting with this stuff or actually putting it into production? I'll just toss out my other question as well, if you don't mind. In the collection, seems like a natural fit with Rovo agents. As you in seeing the demo, it almost made it irrelevant, these walls between your products. It's like the agents help you move across the products more seamlessly across the apps. What are your future directions in terms of making the agents more compatible with your architecture and with Team '26? What might you think of doing when it comes to breaking down more of the components of your apps or the walls between your products and how do the agents fit in? Hopefully, that's not too much of a nebulous question, but thanks. Do you want to take the first one? Yeah, sure. Actually, just this morning, there was a cool Stanford report around what customers across different sizes are expecting to see with AI products that they use and where it's actually moving the needle. Because we have 300,000 customers, we hear from a wide variety of different profiles. I would say if I had to characterize it as two separate buckets, towards the smaller mid-market, the categories of questions we typically get is, how quickly can we deploy it? What can we do with it? There is a large amount of appetite to go try it and see what sense it makes for the particular scenario. There, it's easy for us to show because we showed you a million demos all of today. There is a wide variety of choices to pick from. In the case of larger enterprises, I would characterize this as just having been in the tech industry for 20 years. I think enterprises have the largest appetite I have seen for new technology in terms of AI adoption than any of the previous tech waves that we've seen. I think it's particularly interesting because the state of their data, as AI tech evolves more and more, you see that it gets more and more forgiving as to what the state of your data is. A couple of years ago, it was very much, well, your data has to be prepped and has to be in a certain format and structured versus unstructured and clearly prepared for it to be making any sense. As some of those constraints have relaxed, more and more enterprises want to build agents on top of their existing data stacks. I would characterize that set of customers as they're eager to engage with us and co-design some of these things. Because we have programmability of our APIs, both our apps and agents, as you saw, are totally differentiated across the two, I think it's very exciting for them to go figure out, here's the broad surface area of users that I can address and customize it for my enterprise use case. I would say it's been very encouraging across both segments. I'd say there's also an element for the customers of playing with the technology a little bit. If you've used ChatGPT at home, you have to kind of play with it, use it. You kind of, oh, that's interesting, and you learn. We're all learning a little bit what's capable and what's possible. You push it a bit harder, you learn more, et cetera. One of the reasons to include Rovo in the platform is to enable that playing. That maker attitude, the creator attitude, a whole bunch of our internal agents are written by product managers and marketers. They're not written by engineers. We want to put that toolkit in the hands of as many of our tens of millions of users as possible, as quickly as possible, so that they can learn and go up that curve fast and not have to put a commercial barrier in the way of it is really important, I think. Secondly, on the experiences, certainly something we spend a lot of time on. I think there's almost a duality of movement that's important to understand. The movement from our products to a much larger set of 20-plus, I'm not sure where we're at, 28, 29 apps is to move functionality into smaller areas that are more focused on what they're trying to do. That creates an instant experience problem of, but I don't want to jump around all these things. We showed a lot of examples with more focused apps that do one thing. Those apps and their data are available in lots of other places. You don't need to go to the Goals app to pull up Goals. You don't need to go to the Search app to pull up Search. You don't need to go to Focus to pull up Focus areas necessarily. We are trying to have a very consistent and fluid experience to enable you to flow across all of those apps, first and third party, inside our world to give the customer the best experience while still having a focused set of apps. You then get to the, that's a user experience problem to solve. We're doing a really good job of moving in that. You saw some of the examples of the sliding view. You pointed out that in chat, you can get access to lots of different data. Despite being an app A, you can get data from app B, et cetera. That's all purposeful. The only challenge for the customer then becomes the commerce complexity. We want to make sure that we have a user experience device to simplify the world of many, many apps for the end user, so I think tens of millions of people. For the hundreds of thousands of buyers we have, we want to simplify their experience, but that's done through the collection devices in the opposite direction. We don't want them to have to say, do I buy the Goals app? Do I have to buy the Home app? Do I have to buy Talent and Focus? Do I want both? Do I want one? The more choices we put in the way of commerce, it's not helpful to our goal of going wall to wall. Think about on one end, we're simplifying the buying experience for the hundreds of thousands of customers. We are trying to simplify the usage experience for the tens of millions of end users and also giving us the flexibility to continue to push each of those envelopes while making them more focused. No pun intended. There's kind of a duality there. All right. Thanks for all your questions. Thank you. Thanks for joining us. We really appreciate your support. For those of you here in person, if you exit this door on the right, we'll have a social gathering. Mike, Brian, and I will all join you in a couple of minutes. For everyone else that tuned in, thank you again. Thank you. Thank you.