Atlassian opens Teamwork Graph to third-party agents as Rovo evolves into autonomous executor

Atlassian Team '26 - new tooling for product teams, same structural pressures

When I covered Atlassian's first State of Product report last September with Tanguy Crusson, Atlassian's Product Lead for Jira Product Discovery (JPD), the diagnosis was sharper than the marketing usually allows. Product managers (PMs) were more empowered than ever and 84% worried their products would fail. AI productivity gains felt incremental - one survey respondent likened them to bailing water out of a sinking ship. Empowerment without structural support, the data showed, produces frustration rather than impact. At Team '26 in Anaheim, Atlassian shipped what reads as the prescription. JPD Enterprise reached general availability, and a new Feedback capability - an AI-powered intake layer that captures and synthesizes customer signals directly into prioritization - entered early access. Both sit in a Product Collection alongside Roadway, a dynamic roadmapping app that helps teams rework priorities when goals shift. Rovo Studio also reached general availability, and the Teamwork Graph opened to third-party agents. I sat down with Crusson again to test what's changed since September, what's been built against the diagnosis, and what stays untouched. Crusson starts with a problem that gets sharper as AI tools mature inside the product workflow rather than around it - the asymmetry that opens up inside teams, not just between them. He explains: We can create heroes really fast with AI. Someone starts to use the tools and goes super fast in one direction alone. He acknowledges that he felt it himself while working on what is now becoming Feedback, noting: We had three new product managers in the team, and at some point I think I sent something like five specs a day for a week to the team, and at some point they raised their hands going, 'we can't keep up'. The September data showed 49% of product teams lack sufficient time for strategic planning. The new issue is that AI doesn't necessarily redistribute that time. It accelerates the people who were already moving and widens the gap to everyone else. The result, in Crusson's phrasing, is companies "running around like headless chicken for a while." When clarity is missing, organizations revert to vanity measurements, tokens consumed, and who is using the most AI. "That's one way to get promoted currently, apparently," Crusson says. Dry, but it points at something serious. A discipline that cannot yet measure the quality of AI-assisted work is measuring the volume of it instead. AI inside product teams is not just providing incremental gains - it is creating new asymmetries within them. Atlassian's strategic answer to that asymmetry, on stage at Team '26 as well as in our conversation, is that the response isn't more individual tooling but shared context - the Teamwork Graph as the substrate that lets teams work from the same picture. Crusson explains why the Feedback app hadn't arrived sooner: The reason we didn't ship a feedback app before is we're not even sure that that was actually technically feasible, because it takes a lot of semantic analysis coupled with really good understanding of the domain model of the objects that we are talking about. No technology was very good at this. Even machine learning was just too hard to deploy customers. The concrete version of that domain-modeling problem is vocabulary mismatch across customers. Crusson says: We've got something we call a timeline view that customers called a roadmap. Some call it something completely different. Making Feedback work in production means getting customers to describe their own domain in their own words, then connecting incoming customer feedback back into that domain so teams can measure the relevance of specific topics. Product teams have been relying on second-hand information distilled down one-liners that lack the context for them to be able to confidently say we are doing the right thing. That second-hand information problem is what Feedback aims to fix. Until now, teams have relied on someone from Support distilling support tickets and someone from Sales summarizing customer calls. The promise is direct natural-language access to the customer signal, weighted and connected back to the customers giving it. The bar Crusson sets for whether this works is whether it can run consistently across "a team of, say, 100 product managers, looking at the same data and reading the same interpretation out of it." That's a higher test than most generative AI tooling has had to pass. Quantitative versus qualitative isn't the right split, in Crusson's view: Often it's actually not one versus the other, it's more, what picture can you draw from both? Take a feature with heavy feedback from users on the free plan when you're trying to reach Enterprise customers. Volume on its own tells you nothing, but the more signal sits in the intersection of what customers say, who they are, and how they use the product. Last September's data showed teams with dedicated Product Operations functions outperformed peers by 30 points on strategic empowerment. The implication was that structural support, not just role redefinition, is what determines whether product transformation works. JPD Enterprise reads as Atlassian's attempt to provide some of that support in product form. Finding a model that works for product teams when you can't enforce a single standard for product practice across a whole organization was the harder challenge. Running product in an innovation lab looks nothing like running product on a mature, breadwinner product where you can't reset the roadmap every three months. JPD Enterprise had to allow for both, with enough governance to standardize where it matters and enough autonomy for different parts of the organization to operate differently. Layers were the second enterprise-specific problem. Crusson observes that in SMBs, the work is seen at team level: In mid-market, you might have two or three of these layers. In an Enterprise it's never ending. It's important to note that JPD Enterprise sits in a different layer of the stack from Atlassian Analytics, which has been pulling Jira and JPD data into dashboards since 2022. Analytics owns the quantitative reporting story - flow metrics, velocity, DevOps Research and Assessment (DORA) metrics. JPD Enterprise owns the qualitative synthesis layer feeding into prioritization. They're complementary, not overlapping. Last September Crusson called product management "an unrealistic job" - strategy and execution combined into one role, with no better model on offer. Eight months later, AI is compressing the job further from a different direction. His on-stage version of the point at Team '26 was: When execution becomes cheap, choosing what to build becomes everything, judgment becomes everything. The synthesis work that has historically filled most of a PM's week - producing briefs, summarizing customer calls, distilling support tickets, reconciling competing priorities into a written argument - is now work an AI can do credibly, and faster. Crusson walks through a scenario to illustrate where this leaves PMs. A CEO arrives at the tail end of roadmap season demanding AI be made priority number one. The tempting pitch, he explains, is: "You just give your goals to AI. You ask it to create a roadmap. You pitch your roadmap back. That's magic." (We've all heard some version of that in recent months.) He notes that it does not work like that. The version that does work is iterative. The PM writes a prompt against data already in the Teamwork Graph - customer feedback, in-flight delivery, segmentation. Rovo applies a filter and produces a theory, for example, "It sounds like your bigger customers, which would be consuming AI, struggle with the following problems." The PM brings the team in to test that theory against their own customer conversations. Where it resonates, it stands. Where it doesn't, the team asks Rovo to dig deeper. The brief gets rebuilt iteratively, then Sales, Support and Customer Success vote and comment before any of it reaches the roadmap. Crusson explains: It's like having an analyst in your team, except that this analyst, instead of responding two or three days later, responds a few minutes later. Crusson pushes back, mid-conversation, on the language the rest of the industry has settled on for what stays in human hands. "I know people talk about taste. I'm not a huge fan of the term taste. I can't define it." What he can describe is concrete: domain knowledge, the accumulated weight of customer conversations, the ability to ground an AI-generated brief in what real customers are saying, and the ability to push back when the system is confidently wrong. He emphasizes: The AI will always look super confident. I've had it look at something and say this is a big problem, and you ask it, so how many people said that? Three. And I can't know that's not confidence. On the spectrum from art to science, he reckons product management has moved closer to science - "but we're still close to the middle." Asked where the PM role goes from here, Crusson goes back to first principles: The craft of product management is different from the job currently of what people do. It's back to the basics. Do we have a market? Is there a pervasive problem? Are there customers looking for solutions? Do we have the right solution? Do people know we have it? Are they willing to pay for it? Are they willing to pay what we need to be able to sustain it? Those questions, in his view, have always been the work. AI takes a meaningful slice of execution off the PM's plate, in theory leaving more space for the questions that decide whether the product survives contact with reality. His honest opinion on whether that's how it goes in practice is: I don't know if it's what I foresee or if it's what I wish, but that's what's now possible. And I think success comes from that more than a lot of the shiny stuff that we're seeing at the moment. Feedback's design instincts - scoring signal rather than asserting it, cross-connecting feedback against usage and segmentation - are sound. JPD Enterprise's choice to standardize where it matters and leave autonomy where it doesn't is the right model for product practice at scale. The September report, though, identified problems tooling can only partially address. Time pressure (49% lacking strategic time) is a demands problem, not a productivity problem; saved time gets absorbed by what's added to the queue. Profit-over-everything is a measurement issue that no tool changes. Empowerment without structural support now arrives partly in tool form, but the cultural conditions Product Operations correlates with - leadership backing, time for strategic work, engineering involvement at ideation - aren't installable. The AI hero challenge that Crusson identifies is the dimension that's getting sharper. AI tooling doesn't just fail to fix the asymmetries the report identified; it can produce new ones inside teams faster than they can absorb. Atlassian's bet on 'product builders' - individuals dabbling across product, design and engineering with AI tools doing the heavy lifting - is one organizational response. Whether the model scales is a question Crusson himself doesn't fully answer. He is a natural optimist on the cultural side, particularly on the idea that putting people in a room with their incentives visible tends to surface and resolve conflicts. That optimism is consistent with the weight Atlassian's enterprise messaging is carrying this year - the push for JPD Enterprise needs a story about why the cultural conditions for it to land exist. The qualifier is that incentive-reconciliation depends on leadership willingness to act on what gets surfaced, and the structural pressures the September report described don't make that willingness any easier to find. The concrete test for Feedback over the next two quarters is whether organizations use the synthesis output without manually reworking it. The 18 senior practitioners interviewed for separate research by diginomica earlier this year couldn't share a report straight from their tooling with a CEO without reworking it. If JPD changes that picture, perhaps the September diagnosis has its first credible answer.

Atlassian opens Teamwork Graph and pushes Rovo into agentic execution at Team '26 - SiliconANGLE

Atlassian opens Teamwork Graph and pushes Rovo into agentic execution at Team '26 Atlassian Corp. today unveiled a sweeping set of artificial intelligence updates at its annual Team '26 conference, headlined by the broad opening of its Teamwork Graph and the evolution of its Rovo AI assistant from a helper into an agent that can plan and execute multistep work autonomously. The company said the Teamwork Graph, which it describes as a living shared context layer connecting people, projects, documents and decisions across Atlassian and third-party tools, now contains more than 150 billion connections. Atlassian is also opening the graph to outside agents and tools through two new interfaces in open beta: a Teamwork Graph command-line interface for developers and Teamwork Graph tools delivered through Rovo's Model Context Protocol server. The CLI, with more than 300 commands, lets coding agents such as Anthropic PBC's Claude Code and Cursor query work and relationships across Atlassian products through a single interface rather than stitching together individual product application programming interfaces. The MCP integration allows any compliant assistant, including third-party tools, to read from and write back to the graph. Atlassian said its own benchmarks show that grounding AI responses in Teamwork Graph data delivered 44% more accurate results while using 48% fewer tokens. Teamwork Graph Connectors built on Atlassian's Forge platform have also moved to general availability to allow customers to pipe data from proprietary or legacy systems into the graph with permissions intact. On the Rovo side, Atlassian said customers performed more than 14 million Rovo-assisted actions in the past month and that agentic automations across its platform are up sevenfold over the past six months. The company is adding a new reasoning mode called Max to Rovo Chat, available soon in early access, which breaks complex requests into multistep plans, executes them across connected tools, and loops users back in for review. Rovo Studio, a no-code environment for building agents and automations grounded in the Teamwork Graph, is now generally available with built-in roles, approvals, versioning and audit controls. Atlassian says that more than 90% of its enterprise cloud customers are now using Rovo. The company also announced expansions across its product collections. Agents in Jira are now generally available and can be assigned work items with full audit logging. Jira Product Discovery Enterprise reached general availability with portfolio-level governance and a new Feedback capability for capturing customer signals entered early access. A new Incident Command Center unifies incident detection, investigation and resolution with Rovo-assisted root-cause analysis and Rovo Service offers autonomous or supervised Level 1 support. A new product called Dia Reports that generates proactive browser-native briefings such as interview prep documents and decision memos by combining Teamwork Graph context with everyday tools was also announced today. Atlassian said the feature is designed to surface personalized reports before users ask for them, reducing the need for prompting over time. For engineering teams, Atlassian introduced Agent Experience for measuring how agents interact with codebases, AI Code Insights for tracking AI-generated code at the commit level and AI Pulse for surfacing productivity signals to engineering managers. Atlassian also bolstered its administrative tooling for managing AI at scale. Announced today, new org-wide agent lists give administrators a live inventory of who built which agents, where they are running and how often they are used. Permissions for AI access and agent building can now be separated, allowing broader usage without uncontrolled agent sprawl. New dashboards and audit logs track AI adoption and credit consumption and policies governing what third-party data Rovo can ingest sit alongside controls for data residency and Atlassian-hosted large language model selection. "Rovo and Atlassian's Teamwork Graph are the connective spine, pulling together Jira, Confluence, JSM, Slack, email and more, so agents can reason across all of it," Matthew Hargreaves, head of product delivery and automation at Lendi Group Pty. Ltd., said in a statement. "That's what takes us from AI hovering at the edges to AI embedded in the core of how the organization operates." Andrew Boyagi, customer chief technology officer of Atlassian, spoke with theCUBE, SiliconANGLE Media's livestreaming studio yesterday, discussing why AI agents need organizational context to deliver value and how Atlassian is applying developer experience principles to enterprise productivity.

Atlassian Team '26 - Cisco's Jason Andrews on what "transform, don't migrate" actually looks like

Jason Andrews has told the Cisco story before. 75 tools collapsed onto a single cloud platform, software spend cut by 54%, an additional $5.3 million in annual savings from giving 10,000 users back 15 minutes a week. Andrews is VP of Engineering Operations at Cisco, where he runs operations for a 20,000-engineer organization that ships more than 60 product lines and over $36 billion in annual revenue. The version Andrews tells in person is more candid about what the transformation actually cost. The most quotable line of his Team '26 interview is one he has used in multiple settings, but the supporting story is fresh. Transform, don't migrate. I think that's the simplest lesson. If you just lift and shift to the cloud, lift and shift in a row, you're not going to get the value. You really have to rethink the way you want to work and operate. Easy enough to say - it's harder to do when the room contains people who have built the existing system over decades. Andrews tells a story about being mid-migration, in a room with senior engineers, trying to architect how the new way of working would look. One of them, a long-serving Cisco engineer with what Andrews describes as more process knowledge in his head than anyone else in the room, said flatly: "we can't do it." I'm like, 'why?' And he goes, 'well, the process'. I'm like, 'who owns the process?' He goes, 'well, you do'. I had to say ;guys, you can change it. You've been here 25 years. What would you do if you could do it from the ground up?' He says, 'well, I can do this'. I said, 'do it. I'm gonna empower you.' "Transform, don't migrate" lands as a slogan when there is a senior engineering team in the room waiting for permission, and a leader prepared to give it. The room had been holding itself back, treating internal process as immovable, when the person who could change it was already there. It was not always comfortable. "There were a lot of naysayers as we kept going through it," Andrews said. The output was a 3-5% productivity boost across Cisco's engineering teams, a number Andrews himself caveated: I didn't have a great way to measure it. But I went through and talked to the 50 engineering leaders, and the average response was three to 5%. Across 20,000 engineers, even the lower bound is sizeable. One detail from the interview is the chronology of how Rovo actually arrived at Cisco, which is rougher than the headline figures suggest. Andrews first heard about Rovo when Atlassian was running it as a field trial - Rovo was unveiled at Team '24. He went home excited. Then due diligence happened: It took us a year to get our legal and compliance people to let us use it. They turned it on because they thought they had all the compliance in place, and they took it away. I was so excited - one more sign-off. It was done two months later, because AI was new and people were still learning how to control it. Every enterprise has its own version of that type of timeline. New AI capabilities raise novel data-handling questions, and most legal and compliance teams are still building the frameworks to answer them. Cisco's took a year and a couple of false starts. Other organizations will move faster or slower depending on their data sensitivity, regulatory exposure, and how early their engineering leaders bring legal into the conversation. Andrews's frustration is recognizable to anyone who has ever waited on an internal review process they could see the value through. His willingness to wait helps to underscore that the teams which will move fastest with new AI have to be prepared to get engineering and legal talking before the capability arrives rather than after. The teams that did get to use it have spent six to eight months experimenting. Most of the early use was the predictable stuff - what Andrews called "your standard RAG [Retrieval-Augmented Generation] question, what features are in [version] 17.6.2." The more interesting work has been cross-platform reporting. Cisco runs the consolidated Atlassian platform alongside hundreds of additional Jira instances scattered across the company. Where teams used to schedule a meeting, pull reports, and manually compile a single view, Rovo now does it in seconds. He explains: It really shifts our jobs from compiling reports to actually solving issues and problems for the business. Asked where Rovo had not landed at Cisco, Andrews did not name a specific failed use case. He went somewhere more telling. I think more work on the governance side. All the conversations have shifted, really, in the last three months. From when you talk to different leaders, it's not just about what I can do with the application. It's how do you secure and govern it. These worries are practical. When an agent drives a workflow, is there a human in the loop? Are people being given access to data they shouldn't have? Are non-technical users building agents and putting secrets into them in clear text? Andrews has built a couple of things himself, having not coded for 20 years, and ran into the same questions. "Did I encrypt that data? Did I tell Rovo about it? How do you control that, so people don't put secrets in clear text?" All of this doesn't mean that there's a point of failure, but that the surrounding infrastructure for AI governance has not caught up with the speed at which capability is shipping, and that the people closest to the work feel the gap most clearly. One of the more forward-looking ideas from the conversation was something Andrews had been told the day before - the concept of treating AI agents as assets in the Configuration Management Database (CMDB), with Jira Service Management (JSM) as the surface for managing them. They should be, right? Because they're going to go down, just like any system. How does it behave? How do you identify which agents are out there? It's a really good one. That this idea reached Andrews through a hallway conversation rather than a product announcement says something about how early the multi-agent operations conversation still is. JSM Assets is one plausible place to put that data, and the lab services example shows why it would matter at scale. Cisco runs around 38,000 racks and 2.4 million devices across three locations, with a custom ERP application managing hardware procurement. Anyone who has spent time configuring hardware from the command line, working through one device at a time and praying they have not missed a step before moving on to the next, will recognize what is at stake here at Cisco's scale. Multiply that against 2.4 million devices and 40,000 people buying hardware across the company, and the case for cross-system context becomes a multi-million dollar one. Connecting Cisco's internal application to the Teamwork Graph is starting to surface exactly that - flagging hardware that could be redeployed rather than warehoused or sent to landfill. That cross-system context only works if the agents driving the workflow are themselves managed objects. Asked which Cisco metric he most wanted to point to a year from now that he cannot today, Andrews was immediate. Time to revenue. Because if you focus on coders and coding metrics - everybody's tracking that. At the end of the day, it's all about how do you take a product from day one to day 100 faster. If you can improve that by 10%, in theory you can probably multiply that 10% times your company's revenue, and you could actually seriously drive that value. This is a more demanding target than the developer-productivity numbers most enterprises are using to justify their AI spend. Coding metrics are easier to measure, and tools like Atlassian's own AI Code Insights and AI Pulse, both announced this week, are aimed at that surface. Andrews is not dismissing them. He is saying that for a hardware company shipping switches with embedded security, the value of AI shows up in how fast the switch team and the security team can integrate their work and ship a finished product. That depends on the system of work underneath, not on how fast individual developers can write code. Andrews is the kind of customer reference Atlassian builds product around: technical, senior, and willing to put numbers on his own work even when the methodology is rougher than a CFO would like. The 54% software spend reduction is real. The $5.3 million productivity figure has documented arithmetic behind it. The three to 5% productivity boost from the broader system-of-work consolidation is a number Andrews collected himself, with caveats attached. None of it is exaggerated. None of it is precise the way a finance team would want. What sticks out to me is what the numbers sit on top of. The transformation that produced them was a leader speaking to a room of long-tenured engineers and explicitly handing them permission to change processes they had been treating as fixed. It feels much more tangible when engineering organization decides what is changeable. What Andrews is now asking from Atlassian is governance that keeps pace with capability, and architectural primitives - like managing agents as assets in a CMDB - that let large organizations operate the multi-agent systems they are starting to build instead of factoring in workarounds.

Atlassian Team '26 - selling a nervous system, not a clean slate

In one of the press briefings ahead of Team '26, someone asked Mike Cannon-Brookes how Atlassian planned to save customers from their own chaos. The answer came on stage the next morning. Atlassian isn't planning to - it is building the instruments to let you see the chaos clearly, and then handing the readings back to you. As Cannon-Brookes puts it: Work will always be a little bit messy. That's where the human ingenuity actually lives. The Team '26 CEO and product keynote is at its best when it leans into that mess. Live demos run on production data, fossilized code, stale diagrams, scattered docs, and agents try to make sense of it all. The demos worked and you walk out of the keynote pretty sure Atlassian can ship this stuff. Less sure whether leaders are willing to look at the work they actually have once those tools are pointed at it. Cannon-Brookes opens with a formula you are going to hear repeated for a while: Acceleration for your business is about context multiplied by intelligence. Intelligence is the engine, but context is the fuel. In his telling, 2026 is the year raw model capability stopped being a differentiator. You can "literally buy smarts by the token." What you cannot buy is the institutional memory of every failed launch, partial rollout, and gnarly incident thread that explains why something is the way it is. That is what Atlassian is trying to capture in the Teamwork Graph: not "a database or a set of files," but "the connective tissue between your work, your people, and your tools." Tickets, Confluence pages, whiteboards, meeting transcripts, git repos, Human Resources Information System (HRIS) data, assets, and even inferred skills are all pulled in as first-class objects. The scale numbers are starting to look real. Internally, Atlassian is ingesting "multiple billions of objects every single week" into the graph, with the aim of propagating any change within 10 minutes. Customers are already running 5 million agent invocations a month on top of that context, a figure Cannon-Brookes describes as "an incredible number already" that is "growing very rapidly indeed." The argument is that if models really are converging, then the strategic choice is what you treat as "context," who controls it, and whether you can interrogate it when the answers look wrong. The first live demo - and the one that most clearly brushes up against the "save us from ourselves" question - is Rovo Chat prepping Cannon-Brookes for a meeting with a long-standing customer. The setup is classic enterprise reality: more than 20 years of interactions spread across Salesforce, Jira, Confluence, Loom, Teams, and more. Rather than skating manually across systems, Cannon-Brookes asks Rovo to build a briefing, and adds a temporary "explicit memory" to avoid legal trouble on stage. Real names get swapped for cartoon characters, revenue numbers get replaced with "ridiculously, hilariously large cartoon numbers," and "most importantly, like, make us look good." Underneath, Rovo's memory now has two layers. Implicit memory is constantly updated from the Teamwork Graph as Rovo "learns about me and my job." Explicit memory holds user-created facts and preferences that you can inspect and delete. The resulting briefing pulled together a 20-year relationship view from 61 different sources in about three minutes: charts built on the fly from Salesforce data and Confluence databases, open opportunities, recent interactions, stakeholder maps, even a Loom transcript and a CEO named Foghorn Leghorn. However, none of that fixes the underlying sprawl. It just makes the sprawl navigable, under constraints that users and legal teams can at least see and reason about. Leaders still have decisions to make on which memories are acceptable to store, who can set or override them, and how much to trust any "single view" the system manufactures from imperfect history. If the Rovo demo shows how Atlassian wants to handle customer chaos, the code intelligence segment shows what it plans to do with its own. Atlassian has been internally testing a new code search connector that spans Bitbucket Data Center, Bitbucket Cloud, and GitHub. On stage, Sherif Mansour asked it: Tell me all the buttons in our Confluence code base that don't use the latest style. Who are the people working on it, and what are the style guides? In real time, the system searched 11 million files and 1.5 billion lines of code, inferred the relevant design system, and returned a breakdown of which button styles are used where, the teams and individuals most involved in the affected code, the Slack channels to contact, and links to internal posts and docs about the design system change. The point is not that the tool magically fixes a decade of Confluence UI inconsistency. It does not refactor the codebase for you. It just answers "how big is this, where, and who do I need to talk to?" in minutes instead of days. A second demo turned the same tooling on Cannon-Brookes' own history. Mansour asked code intelligence to hunt for "to-dos from Mike Cannon-Brookes" still lurking in the codebase and report on whether anyone had done anything about them recently. This pulled up a "fossils" report of 21-year-old TODOs, including ancient Confluence macro code referencing versions from the pre-cloud, pre-data-center era. Amusing on stage, but also a reminder that an "AI-native" organization is not a clean slate. It is a company with layers of sediment you can finally query properly. The decision point sits with engineering leadership. If you can now see these fossils clearly, are you prepared to prioritize cleaning them up, or do they become yet another known risk you choose to live with? If the Teamwork Graph is where the work lives, Jira is where the accountability lives in Atlassian's version of the AI-native organization. Mansour's software planning demo was the clearest articulation of how Atlassian sees agents and humans working together. Starting from a vague ticket to add a personal investment dashboard to a financial services app, he asked Jira (via Rovo) to understand the business requirement from existing docs, whiteboards, and tickets, inspect the codebase using the new code intelligence skill, propose a technical plan and architecture, estimate token costs for the work, and break the work into tasks for humans and agents like Claude Code. Rovo did not automatically pick an approach when it hit a fork. It stopped and asked whether to use one of two data stores it had discovered, based on both code and business context. When the plan was accepted, Jira spun out work items with suggested assignees, including agents. Existing automations then picked those up and started execution. Cannon-Brookes sums it up as: your AI control plane across both agents and human workflows... There is obviously marketing in that phrase. There is also a concrete governance implication. If Jira is where human and agent work is orchestrated, then Jira also becomes the primary audit trail for who - or what - did what and why, which suggests a structural choice about where accountability lives. If you are allergic to glossy UI demos (who isn't these days?), the Teamwork Graph CLI section was the one to watch. Atlassian has bundled more than 300 graph-aware commands, spanning around 380 tools, into a command-line interface ("TWG CLI") intended primarily for agents and harnesses rather than humans. In the keynote, it powered a Claude Code demo where an architect was handed a particularly unhelpful mobile app bug ticket with no links or context. Asking Claude, via the CLI, to "research JIRA-MOBILE-63 and visualize all the comprehensive work items for this context" produced a set of related Jira issues that had never been linked, the associated pull requests and Git branches, the relevant designs in Figma, the team and people who worked on those artifacts, and a graph visualization showing how it all hung together. In other words, the ticket was chaos. The graph was not. You still have to fix the session bug, but at least you can see the shape of the problem and who owns which pieces. Internally, Atlassian benchmarked Claude Code with and without the Teamwork Graph CLI and is claiming up to 44% more accurate results and up to 48% fewer tokens when the graph is in play. Take vendor benchmarks with the usual pinch of salt, but they do point to a more specific Return on Investment (ROI) conversation - not just "better AI," but cheaper AI, because you are not paying a model to rediscover context it could have fetched. The Teamwork Graph can show you the shape of your sprawl. Code intelligence can surface 21-year-old TODOs in minutes. Jira can route work between humans and agents with a clean audit trail. The Claude Code demo on JIRA-MOBILE-63 worked. None of this is vaporware. What I'm still wondering is whether buyers are ready for what they will see. Every company in that audience has its own version of the fossilized Confluence macro code - the abandoned project, the half-migrated system, the runbook that exists in seven different versions across seven different tools. Until now, that mess has mostly been invisible, or at least deniable. A Teamwork Graph that renders it legible is not a neutral act. It surfaces decisions that have been avoided for years, and it puts them in front of the people who will now have to make calls about them. That is real work, and it is not work the tools can do for you. Cannon-Brookes is not pretending otherwise - his line about human ingenuity living in the messiness is a warning as much as a comfort. But it does shift the responsibility onto the customer in a way that a lot of "AI transformation" pitches do not. Are you prepared to prioritize cleaning up the fossils once you can see them, or do they become another known risk you choose to live with? Whose context counts as authoritative when two systems disagree? Who is accountable when an agent acts on bad institutional memory? These are not questions Atlassian can answer for you, and the keynote does not pretend to. Cannon-Brookes is bullish about moving anyway: You cannot wait and see your way through an existential shift in technology. The future will belong to the AI native organizations. This felt deliberately provocative. The bar he is setting is not "buy our products and become AI-native." It is closer to "if you cannot honestly look at the work you have, no amount of agent infrastructure is going to help you." Atlassian has built the instruments, but what customers do with the readings is on them.

Atlassian Team '26 - Pythian on teamwork graph, MCP and the AI governance hangover

Pythian is a 450-person data, analytics and AI) specialist with around 300 people in customer-facing roles, running 24/7 services for client infrastructure. Not a hyperscaler, but that scale is big enough to expose real complexity, small enough that one person can still see the whole picture. In this case, that person is Kasia Wakarecy, VP Enterprise Applications at Pythian. Her remit is to choose the products, implement them and make sure everyone at Pythian has the tools they need. That now includes Atlassian Rovo for the whole company. "Every single person in the company has a license," she says. Rovo started as a proof of concept in 2024, then moved into production and out to all 450 staff. Wakarecy tells me that the key reason she could move that fast is because Rovo sits on top of a governance foundation that already exists. Pythian has years of work behind it on data governance and on Atlassian security and privacy agreements. When Rovo arrived, it slotted into that framework. She explains: We started with Rovo because it extrapolated our existing privacy and security policies, what we already had with Atlassian. We don't have to worry about the fact that if we have Rovo connected to our customer data or our employee data, then suddenly that's going to leak all over the internet, or it's going to be used to train Large Language Models (LLMs). Pythian also runs Gemini Enterprise and has done its due diligence in testing other tools. The pattern is consistent in the way the company works: enterprise-grade agreements, data location clarity and strict rules about training data. Wakarecy recounts she has sat in meetings where executives cheerfully paste revenue spreadsheets into consumer AI tools while their own IT teams look horrified. Her view is that many organizations are only now waking up to what sensitive data leakage really means. She warns: You cannot have good results unless you have your data shop in order. Pythian spent roughly five years getting its own house straight before plugging AI into core systems. Many of the customers Wakarecy sees are doing that in reverse. Rovo arrived as part of the Atlassian stack -- "an out of the box solution" inside Jira and the Teamwork Collection. That removes a lot of friction. Wakarecy notes that she "didn't have to do anything besides clicking a button saying enable." But the real value only shows up when the team moves beyond Atlassian data alone, she adds: Just having Confluence data and Jira data, that's great... but that's not where the richness comes from. The real knowledge lives in Slack, Customer Relationship Management (CRM) systems and file systems -- where she estimates around 80% of company knowledge sits. So the team pushed on connectors. To Wakarecy's surprise, the heavy lift never arrives: It literally took less than a day... to connect five-plus third-party applications, external applications, and suddenly the ingestion happened and I started seeing the results. We were like, wow, that was a conversation I had over Slack, but it's showing up here. This is the first point where the Rovo story cuts across supplier slideware. Vendors like to say "just connect your data" as if that is routine. Wakarecy has been through connection journeys with several AI systems. Some are easy, some are painful. In Rovo's case, the mechanics are quick. The real work has already been done at Pythian's end -- data clean-up, permission models and an understanding of which systems should talk to each other. Even so, those early Slack-in-Rovo moments come with a second thought: "What else is happening that I don't know that it's happening?" Once the AI system is given a broader surface, it reflects everything back -- good and bad. Atlassian Team '26 messaging is understandably keen to talk about the move from "assistive to agentic." Wakarecy's view from the field is cooler. Pythian runs quarterly internal surveys to understand where people sit on AI adoption. The results are interesting: That is two populations in one company, not a smooth adoption curve. The original plan was classic enterprise enablement -- big demos, one-hour training sessions, then let people get on with it. Wakarecy recalls. We thought that we were going to deliver one-hour training to people, like a big demo to everyone. People will walk away and will start using the tools. We found that that's not happening. Instead, Pythian had to drop back several levels. Wakarecy calls that approach "kindergarten of technology." She explains: We underestimate how big the change is. We think this is just giving someone a new phone, and the reality is, it's moving someone who's never used a smartphone, giving them a phone, and they're like, 'how do I use this thing? I have no imagination and no idea'. The basics include very simple reassurance that you can touch this technology, you won't break it, and it won't bite. Many people are used to products where you click a button, it either works or it doesn't, and that is the end of the story. With AI, that mindset fails fast. Wakarecy hears people saying "AI is broken." Often it is based on a single question with missing context. She turns it around with "how did you ask? Did you explain enough? Did you ask a follow-up when the answer missed the mark?" She wants people to ask why they didn't get the answer they expected, and to request the system's thinking, its limitations and what it can and cannot do. That is a big leap for many users, who have never been asked to shape the behavior of a tool while they use it. This is why talk of agents feels premature for a large part of her workforce. In her view, there is a clear sequence, that first, people learn to use search and chat every day, see personal productivity gains and develop a sense of what is possible. Only then do they start asking: why do I do these three steps manually? Can I chain them, or hand work from one agent to another? She emphasizes: Unless people get comfortable with using just the basic search and chat functionality, forget about talking about agentic and creating agents and creating agentic workflows. They're not going to get there. Pythian runs 24/7 operations with teams of eight to 10 people covering eight-hour shifts, handing off to the next block around the clock. Historically, that meant live handover calls between outgoing and incoming staff, with manual explanation of incident history, active tickets and context. Now, Wakarecy says that Rovo plays a central role in that choreography. It ingests data from Slack, Confluence and Jira, then generates handover summaries for the next shift. Those summaries highlight key incidents, unfinished tickets and links to prior related work. She says: Having an agent that summarizes all of the important things that the next person in shift needs to know, it's an amazing, fantastic time saver. The impact is daily and cumulative, every day, 24 hours a day. She likes to use the analogy of an extra colleague: It's not only a teammate that is handing over, but a teammate who also has a memory, right? So you can say, 'and by the way, two weeks ago, you already had this problem. So remember that this is related'. That kind of recall is normal for a small co-located team. It is harder when work passes through a chain of people across different time zones. When the AI system sits on top of that history, it can surface echoes that no single human may spot in the moment. This is where all the talk about agents starts to line up with reality. For the group of users who already feel comfortable with AI tools, the question becomes less "how do I use this?" and more "why am I still copying and pasting?" Those are the people now stringing agents together so that one can pass results to another. The next stage in the Atlassian story is the Teamwork Graph and Model Context Protocol (MCP) servers. The pitch is a shared graph that describes work items, relationships and context, exposed to agents from different vendors. Microsoft, Salesforce and others can tap into the same Teamwork Graph and use the same metadata. MCP servers become "brains with a metadata context." On paper, this is a dream for people who fight with tool vocabulary. In practice, Wakarecy sees two sides. After all, humans shouldn't need to learn every vendor's naming scheme. She gives a simple example: the word "ticket." Is that the same as an issue, an epic or a task? Different products use these words differently. Users often come to her team with requests based on the wrong term. Her team translates from human language into product language, then back again when they explain. With MCP servers sitting on top of a Teamwork Graph, she expects a better deal. If a person says "epic" (a large body of work that can be broken down into smaller, actionable tasks or user stories), the system can map that to issue, ticket or task, depending on context. If they say "task," the system can understand that they want a different level of granularity. She observes: Maybe half of the support tickets that we get are around the misunderstanding of what the product does and how it should be used and the vocabulary that it's used. With the MCP server, what I'm expecting to see is we will no longer be the translators. The downside is where the hangover comes in. Once multiple vendors can connect to the Teamwork Graph, the governance responsibilities step up a level. We are now creating this burst of data and ability to connect all of those pieces of information, but that means I have to trust all of the vendors. I have to trust other third-party vendors to connect to my Atlassian application. Those worries sit in three buckets: AI already forces organizations to confront access models they may have ignored for years. Plugging AI into file systems and collaboration tools often reveals that too many documents are visible to everyone, or that old content is still marked as current. Giving agents access to a cross-tool Teamwork Graph raises that pressure again. For Wakarecy, that is both an opportunity and a pain. AI and open graphs can expose years of sloppy practice in a matter of days. Cleaning that up is a lot of work, but the alternative is worse: quiet leak paths and a slow drip of mistakes. What separates enterprise AI from demo-ware is the grind of governance and the patience needed for human adoption -- not a clever model trick or a shiny new user interface. Rovo works at Pythian because it rides on top of existing Atlassian agreements and years of data hygiene. Connectors deliver value quickly because someone has already thought about where data should live and who should see it. On the people side, the company learned that most users do not wake up "agentic." Half of them were scared to touch AI tools at all. That forced a very different enablement strategy: simple reassurance, repeated exposure and encouragement to ask follow-up questions when the first answer misses. And on the Atlassian Team '26 announcements, Wakarecy's stance captures the mixed mood of many enterprise practitioners. Teamwork Graph and MCP servers look powerful. They also raise hard questions about who connects to what, how to control agent sprawl and how to keep spend visible. Excited and a little bit scared, as she puts it. That feels like an honest description of where many enterprises sit in 2026.

Atlassian Opens Up Its Teamwork Graph to Power Agentic Work Across the Enterprise

At Team '26, the company announces a powerhouse of new AI capabilities built for every corner of modern work Atlassian Corporation today announced the opening of its Teamwork Graph, one of the industry's richest maps of how teams actually work, so Rovo and agents from across the ecosystem can search, reason, and act securely across tools and teams. The news is part of a series of announcements unveiled at Atlassian's Team '26 conference to bring AI capabilities to every team across the enterprise. Rovo is already used by over 75% of Fortune 500 companies and 90% of Atlassian's enterprise cloud customers. This marks the emergence of a new kind of enterprise: the AI-native organization, where humans sit at the critical frontiers of workflows and hand more execution to agents. "In 2026, anyone can buy 'smarts' by the token," said Mike Cannon‑Brookes, Atlassian CEO and co‑Founder. "The real moat is your institutional memory: every plan, document, and decision your teams have ever made. Rovo is the interface that turns intelligence and context into actual momentum for your business." Teamwork Graph for Every Agent Agents are only as good as what they know. With over 150 billion connections, the Teamwork Graph is the context engine behind AI‑native teamwork, connecting people, work, goals, code, and content across Atlassian and connected apps. Today, Atlassian is making that context accessible everywhere: Rovo in Every Workflow In the last month alone, customers have performed more than 14 million Rovo-assisted actions, with agentic automations up 7x in the last six months. With newly announced capabilities, Rovo now empowers builders everywhere and moves from assistive AI to autonomous agents that help carry the work: Agentic Capabilities Across the System of Work Atlassian brings context-aware agents to where people already work, so teams can grow into AI-native workflows over time. Across its System of Work, Atlassian is introducing: Learn More at Team '26 These announcements were made at Team '26, Atlassian's annual flagship event that brings together thousands of leaders, builders, and practitioners shaping the future of teamwork. To learn more about all the news, visit Company News Archives - Inside Atlassian . Watch the keynotes and sessions live or on demand at https://events.atlassian.com/team-digital.

Atlassian Team '26 - new products, faster change, more automation, as the agentic pace accelerates

Atlassian's annual user conference has come round again with the usual avalanche of product launches today -- but with a distinct upbeat this year both in the tempo and scale of change and the very nature of those products themselves. Agentic AI is transforming both Atlassian's offer to its customers and what its customers are aiming to achieve with its products. As its CEO Mike Cannoh-Brookes told diginomica's Alyx MacQueen yesterday, whereas the vendor used to ship products twice a year, new features now arrive almost every week. And whereas those products used to help customers organize their work, now they're reshaping how customers' organizations actually operate. Setting the scene in an advance briefing with industry analysts last week, Amita Abraham, Head of Product Marketing, explains Atlassian's view of the AI-native organization: It isn't just a traditional business with a chatbot layer. It's a fundamental re-architecture of value. You're probably all hearing this, feeling this, living through it, much like we are at Atlassian. The AI-native company, in our minds, is one where execution will increase its value. We'll significantly shift to AI agents, while humans move to the critical frontiers of work. And at those frontiers, we do what only we can do -- define intent, navigate hard trade-offs, resolve those deep ambiguities. The tools and workflows might change. But Atlassian's mission to unleash the potential of teams will remain the same. Many of today's announcements are in support of that shift of execution to AI agents, with advances in the complexity of processes that can be handed off to agents and in the use of AI to build automations, along with more extensive monitoring and governance of agent activity. Human users also get new applications to help them share ideas and enhance products. Enterprise context and agentic 'superpowers' Underpinning all of this is Atlassian's Teamwork Graph, which has long been a core feature of the company's platform, but which takes on a new significance this year as recognition grows of the crucial importance of enterprise context when instructing agentic AI. This core theme is explored further in MacQueen's interview with Cannon-Brookes. In last week's briefing, Abraham spoke about context as "the fuel ... for accelerating businesses," and gave a simple but telling example of the role of context: It's that institutional memory of every decision, every failed project, every trade-off buried in an old Slack thread. And if a customer's AI doesn't know why they made that choice in 2024, chances are it can't help them in 2026. Bear in mind, too, that this context is constantly changing and therefore has to be continuously updated -- across Atlassian's customer base, 12 billion changes happen in the Teamwork Graph every day, while the number of agentic automations performed on the Atlassian stack every day has grown 7x over the past six months. Another example of the pace of change is that Remix with Rovo, an enhancement to the Confluence app that was only announced a month ago, today enters general availability. This lets a user highlight text, tables or lists on a Confluence page and Rovo, Atlassian's AI agent, instantly transforms it into a chart, diagram or infographic without the user having to leave the page. The capability is now taken even further with today's announcement of a new Confluence Slides app. Enhancements to Rovo itself include general availability of Rovo Studio, the no-code app builder for creating AI agents and automations. Rovo also gets a boost with the introduction of Max mode in Rovo Chat, a set of additional capabilities, or "superpowers" as Jamil Valliani, Head of AI Product at Atlassian, calls them. These include the ability to inspect a new API or MCP service and figure out how to use it, self-correction when Rovo encounters issues executing code, and an advanced planning engine for figuring out how to fulfil a request. He explains: From a vague question like, 'Help me understand our sprint health,' it actually decomposes that into the many subtasks that are required, including things like pulling velocity data, checking blockers, comparisons to prior sprints, and assembles a coherent plan and narrative around how to actually get that done. From feedback to new feature Atlassian today completes the regrouping of its products into distinct collections that each serve specific teams with the launch of the Product Collection, based around the existing Jira Product Discovery (JPD) product but now also adding a new Feedback product, which is in early access with selected customers. This is an AI-driven product that collects customer feedback from across Atlassian and third-party sources, ranging from customer service apps to review sites or demand intelligence apps such as Pendo, and can then tie the resulting insights back to goals and plans in JPD. John Kinmonth, Head of PMM for Rovo Dev, DevEx and Product Management Solutions, provides an example of how an idea surfaced in the Feedback app could then be taken forward into development using the AI-driven planning engine: You could pull an idea from the feedback app and then say, 'Hey, we want to implement this into our current service or feature stack.' What it does is, it goes through, assesses all the risks -- it doesn't just go and make a ton of architectural decisions for you. It looks at it and says, 'Hey, there's a couple different data API calls, here's the recommended one. This one's used across eight different services. This one's used against three, via your standards that are in your Confluence pages. This is probably the recommended one. And you can ask questions in Rovo and be like, 'Why did you make that decision?' And then it generates the full plan with architectural diagram. And you can say, 'Hey, you know what, I think it's safe for me to implement this plan.' Other additions to Atlassian's development tools expand the DX developer intelligence capabilities acquired last year. One particularly striking addition is a new agent experience, analogous to the existing developer experience function, but which takes snapshots of how an agent experiences a process, allowing engineers to optimize their flow in exactly the same way as they would for a human developer. Other new capabilities include AI Code Insights, which provides real-time visibility into AI-generated code across an organization, and how developers are using AI tools, and AI Pulse, which proactively surfaces productivity data to frontline engineering managers, to help them prioritize their efforts. We'll provide more coverage of these and other announcements from Team '26 through the week. My take The race is on between enterprise application vendors to become the preferred home for their customers' context -- to become the platform of understanding and knowledge on which their AI executes. It's no surprise therefore to hear Atlassian make its pitch at this year's Team event to win that race, opening up access to its Teamwork Graph to a far greater extent than we've seen from other vendors. At first glance, this seems to have much to recommend it. As Valliani told me: It's actually fairly easy for an agent to learn and understand how to go and access the relevant bits of data in a structured way in another graph, essentially, and then quickly go and bring that data in to meet their needs. That's one of the reasons why we've provided our new Graph CLI, is to actually help folks get that sort of easy access to our Graph from their favorite AI builder tools. We see that when they do use those tools, they actually both save tokens, because it's a lot less reasoning to go do, and actually get dramatically higher quality results. But for now one of the questions I have is, how does an enterprise reconcile the understanding of that context landscape across multiple vendor domains? Every vendor, including Atlassian, is offering its own proprietary context platform, and is asking its customers to make sense of data and processes from their other application stacks by effectively translating them into its own domain. Here's what Maggie Roney, Head of Product Marketing - Platform at Atlassian told me when I asked about this: Our graph is not just Atlassian data, it has been pulling in data from other third parties... A document could be a Confluence page or a Google Doc or whatever it is across all of these different vendors, but we're trying to bring them to some of the rawest forms in how we're defining the classification of some of those objects and then surfacing that back first within our portfolio... which we've done to date and then now, off-Atlassian as well. Despite what Roney says, there's still no sense that I can see in which the classification of entities and relationships in that graph is an open standard rather than proprietary to Atlassian. Therefore, providing CLI access to the Teamwork Graph, for all its initial advantages, simply binds enterprises even more firmly to Atlassian. Maybe that's fine, but what if there's data or knowledge in another vendor's context domain that isn't accurately rendered when it's transferred across into Atlassian's, or vice-versa? I'm not hearing the answers to this question at the moment, and at some point I think it's going to need answering, well before the race has come to an end. Enterprises certainly need to find ways to move fast, but they must still do so with caution.