A Team ’26 Retrospective on AI and Rovo

[#1]

---

Last week shows Atlassian understands AI will not live in one interface

---

Looking at Team ’26 through an AI lens, the most interesting thing coming out of Anaheim was Atlassian acknowledging that many customers are already standardizing elsewhere for AI interaction: Claude, ChatGPT, Copilot, Cursor, and other AI-native environments.

We are witnessing a sea change

Historically, enterprise software vendors largely assumed AI interaction would stay inside their own products. But most organizations are not going to adopt a separate AI interaction model for every enterprise platform they use. Nor are they going to funnel all enterprise context exclusively through a single product interface.

Atlassian appears to understand that reality now.

That helps explain the much heavier emphasis at Team ’26 around MCP (Model Context Protocol), Teamwork Graph, and developer-oriented tooling like the Teamwork Graph CLI.

Taken together, those announcements suggest a larger shift is underway. Atlassian no longer appears focused primarily on “AI inside Atlassian.” It increasingly looks like the company wants Atlassian’s operational context itself to become portable, reusable infrastructure for external AI systems.

That is a much bigger strategy.

MCP changes how organizational context gets used

Atlassian announced the Rovo MCP Server is now generally available.

On its own, that's not very interesting. But the surrounding announcements changed the meaning considerably.

The Team ’26 direction suggests Atlassian is no longer trying to force AI interaction with Atlassian data exclusively through Atlassian product APIs, or Rovo interfaces. Instead, it is positioning Teamwork Graph, and the Jira, Confluence, Jira Service Management, data it contains as operational context layers that external AI systems can consume directly.

Now, organizational context increasingly becomes accessible inside tools like Claude, Cursor, VS Code, ChatGPT, GitHub Copilot CLI, and other AI-native workflows without requiring users to live inside Atlassian products all day.

Once organizational context becomes portable, the value shifts away from the interface and toward the quality of the operational context itself.

That is where Teamwork Graph becomes much more interesting.

Teamwork Graph is becoming an operational memory layer

One of the biggest strategic themes at Team ’26 was Atlassian’s continued investment in Teamwork Graph.

They say most AI systems today still operate with very shallow organizational awareness (I agree wholeheartedly). Personal productivity is going up, but meaningful business transformation is spotty at best.

With AI, employees can more easily summarize information, generate content, or automate personal tasks, but they often do not understand ownership, dependencies, workflow relationships, operational history, service impact, or how work actually moves across an organization.

That missing context is where a lot of enterprise AI starts breaking down in practice.

And it is where Atlassian potentially has a very large advantage.

By coupling Rovo MCP with Teamwork Graph, Atlassian is showing they are increasingly willing to expose the operational context embedded in Jira, Confluence, and related systems as a usable platform layer for AI systems.

That is a much bigger strategy than simply adding Rovo features to the Atlassian product collections.

The CLI announcement may have been the biggest signal

For me, the Teamwork Graph CLI announcement was probably the strongest signal of the entire event. Not because of the tooling itself. But because of what it implies.

The Teamwork Graph CLI suggests Atlassian expects AI agents, automation layers, developer tooling, and operational workflows to increasingly interact directly with organizational context, not just browser interfaces.

That aligns with what many engineering organizations are already experimenting with:

• AI-assisted development
• agent-driven operational tasks
• natural language workflow orchestration
• AI interactions embedded directly into engineering environments

This is where the conversation becomes more interesting.

Historically, permissions, workflows, and operational boundaries were often tied closely to application interfaces themselves. MCP-style interaction models start blurring those boundaries because the execution surface increasingly shifts into external AI systems and agent-driven workflows.

APIs are no longer the entire interface layer.

That’s exciting, but also a bit scary. AI is an immature and rapidly evolving technology, and without proper human oversight, things can quickly become messy.

Nonetheless, Atlassian's vision is spot on in my opinion. Exposing organizational context turns AI into a first-class part of the platform surface.

That changes how organizations need to think about permissions, governance, observability, workflow trust boundaries, and operational design.

My own thinking about MCP changed after Team ’26

Earlier this year, when I wrote about Model Context Protocol and Rovo, I was mostly viewing MCP through the lens of fit-for-purpose AI usage:

• reducing context switching
• connecting AI tools to Jira and Confluence
• improving workflow efficiency
• making organizational knowledge more accessible

All of that still matters.

But Team ’26 made the larger implication much clearer for me. MCP is no longer an integration story alone. It will increasingly become part of the operational infrastructure layer for AI-native work.

When you view Teamwork Graph, MCP, Rovo agents, and CLI tooling together, Atlassian’s direction starts looking much bigger than ‘AI inside products’ It starts looking like an attempt to become the operational context layer AI systems depend on to safely execute work across the enterprise.

This is where the operational reality matters

None of this magically fixes operational maturity problems. If anything, it probably exposes them in uncomfortable ways.

A Teamwork Graph built on stale documentation, inconsistent Jira usage, weak ownership models, fragmented observability, and disconnected workflows does not suddenly become intelligent because AI can now query it.

If anything, AI-native workflows raise the importance of operational discipline. The underlying operational context must be trustworthy for AI systems to deliver meaningful value.

Otherwise, organizations risk creating systems that are fast, confident, and operationally wrong.

My hope is that we can collectively discover ways to use AI to address those operational maturity challenges. And that Atlassian recognizes it has a real opportunity to ship AI-powered solutions that raise the operational maturity bar. ◀◀◀ Attention Jamil Valliani and team.

The larger shift behind Team ’26

The Team ’26 announcements were not just another AI feature cycle. The larger shift is architectural.

Atlassian increasingly appears to be repositioning itself from a collaboration software company toward an operational intelligence platform built around organizational context and AI-assisted execution.

Whether that strategy ultimately succeeds is still an open question.

But the direction feels much clearer now.

And for me, the MCP + Teamwork Graph + CLI combination was the clearest signal yet of where Atlassian thinks AI-enabled work is heading next.

---

📚 Further Reading

• This article is part of a series of articles on AI adoption in the Atlassian ecosystem. See the full list of related articles in this index.

See also…

• Team '26 Digital — Watch the digital experience for a refresh (or first time view) of Atlassian's announcement, and more.