A perspective from our Customer Success team.

A lot shipped at Team ’26 this month. Rovo Studio and Agents in Jira went GA, the Teamwork Graph CLI hit beta, MCP support expanded, the Dia browser is live. If you run an Atlassian environment, you’ve probably already seen the headline list.

We’ve spent the weeks since digging into something the headlines don’t cover: what these announcements actually demand of the environment underneath them. Because the through-line across all of it is that Atlassian is becoming an execution platform, and that shifts the question every admin and platform owner should be asking. It’s no longer “do we have the feature.” It’s “is our environment ready for it.”

Here are the four announcements we think enterprise teams should be watching, and the questions worth asking about each.

1. Atlassian is becoming an AI execution platform

The Rovo announcements were the loudest part of the keynote: expanded AI-assisted workflows, autonomous task capabilities, deeper integration across Jira and Confluence. Read together, they point somewhere specific. Atlassian is moving past work management and toward AI-assisted operational execution.

The shift that matters is in the relationship. Rovo started as something you ask questions to. It’s becoming something that coordinates and acts. That’s a different kind of tool, and it changes what good looks like.

Picture an engineering leader heading into a deployment review. The old version of that evening meant pulling release blockers off Jira boards, cross-referencing Confluence pages, and chasing four people for status updates. The new version is a single request: summarize the critical release blockers, flag any unresolved dependencies, and draft stakeholder updates for tomorrow’s review. The workflow compiles it in seconds.

That only works if the underlying work is structured enough for Rovo to reason over it. And it raises questions most teams haven’t had to answer before: which workflows are appropriate for AI-assisted automation, how much autonomy is acceptable in each one, and how those automated actions get audited after the fact.

2. The Teamwork Graph is becoming enterprise infrastructure

Atlassian opened up the Teamwork Graph at Team ’26, letting AI systems and external tools securely interact with organizational context across Jira, Confluence, and connected systems.

This is the announcement we find most validating, because it confirms something we’ve been telling clients for years: the value of your Atlassian environment was never the screens or the workflows. It’s the relationships across all of it. The graph connects projects to owners to dependencies, ties documentation to approvals, links goals to the history of how the work actually went. AI gets dramatically more useful when it can see those relationships instead of isolated records.

The implication is clear: The quality of your organizational context is becoming one of the biggest differentiators in how much value you get from enterprise AI. Organizations with well-connected systems and clean metadata will pull ahead. Organizations with fragmented tooling and inconsistent data will watch the same features underperform and wonder why.

A release manager asking which unresolved dependencies could impact our Q3 launch should get blocked epics, missing approvals, ownership gaps, and related incidents surfaced in seconds. They will, if those relationships are captured in the graph. If they aren’t, the AI can only work with what it can see.

The questions to sit down with: which systems should connect to the graph, and are the permissions around that access properly scoped and governed?

3. Poor Jira hygiene is now a business risk

We’d put this at the top of the list, even though it wasn’t a product announcement at all. It was the theme running underneath every other one, and it’s the one with the most direct consequences for the teams we work with.

Here’s the change. Before AI, poor Jira hygiene created inefficiency. A board was cluttered, a report came out wrong, someone wasted an afternoon reconciling two sources of truth. Annoying, rarely dangerous. Once AI is reading your workflows and acting on them, the same inconsistent ownership and stale metadata produce wrong recommendations and incorrect automations, at machine speed and with a confidence the output never earned.

A scenario we can see playing out: an AI workflow auto-escalates a production incident using ownership data stored in Jira. The data is eight months stale, and the listed owner changed teams in the spring. The escalation routes to the wrong person. The right person never gets paged. Response time slips during an active outage, and nobody can immediately explain why. The AI did exactly what it was told. The data told it the wrong thing.

That’s the shift in a sentence. Your metadata used to be housekeeping. Now it’s the foundation your automations stand on.

The questions that follow are uncomfortable for most environments: how standardized are our workflows and metadata, is ownership actually current, and are permissions governed or just inherited?

4. MCP is emerging as an enterprise AI standard

Atlassian expanded support for MCP, the Model Context Protocol, a standard that lets AI systems securely interact with enterprise tools and organizational context. In practice, it means AI platforms and coding assistants can now reach Jira and Confluence context through governed interfaces.

The easiest way to think about MCP is as a common connector for AI systems, the USB-C of the category. It’s shaping up to be foundational plumbing, and it opens real possibilities: AI-assisted development, workflow orchestration, copilots that actually understand your environment instead of guessing at it.

A developer in their IDE can ask their AI coding assistant to show all unresolved dependencies tied to this feature branch and summarize any related incidents, and the assistant pulls that context straight from Jira and Confluence without the developer leaving their workflow. Genuinely useful. It’s also another door into your environment, and every door is a governance and security conversation.

Before turning MCP on broadly, the questions to resolve are which integrations you actually want enabled, how permissions will be governed across them, and what audit controls and security boundaries need to be in place first?

What this adds up to

The pattern under all four announcements is the same. Atlassian is betting on the graph and opening it up. The payoff is real, but it accrues to the environments that are ready for it.

Success in the next two quarters won’t come from enabling features. It’ll come from governance, operational maturity, and data quality.

For most teams, the right next move isn’t a strategic overhaul. It’s smaller and more concrete:

• Review governance and permissions, with particular attention to who can build agents versus who can use them.
• Standardize the workflows and metadata your automations will depend on, starting with ownership and the fields that drive routing.
• Pick one low-risk, high-value workflow to pilot, and treat it as a way to learn what your environment actually needs.

If you’re trying to figure out where your Atlassian environment stands today and where a sensible first step is, that’s a conversation we’re glad to have.

To talk through what Team ’26 means for your environment, contact us today.

Almost every leader we talk to is being asked the same question right now, and very few of them realize it’s a trick question. The question is “what’s our AI strategy.” The trick is that the real answer isn’t a strategy at all. It’s an architecture decision, and most organizations are making it without noticing they’re making it.

Here’s why. The agent is the easy part now. Capable models have become something you buy by the seat, and the gap between the best and the second-best narrows every quarter. What actually separates the companies getting real value from the ones quietly funding a graveyard of pilots is something less visible: where the AI sits relative to the work, and how much of the organization’s real context it can see from that position.

An agent is only ever as good as the context it can reach. So the question that looked like it was about AI turns out to be about architecture, and the architecture is something most companies already have, assembled by accident over years of buying tools one problem at a time.

There are two credible ways to answer it. They lead in different directions. The difference matters more than the marketing on either side suggests.

Answer one: put the intelligence inside the platform

The first approach puts the AI layer inside the platform that already encodes how a domain operates.

The strongest example in the market today is Atlassian’s Teamwork Graph. Two decades of work have accumulated inside Jira and Confluence, and that history is not just a pile of tickets and pages. It’s a map of how an organization actually runs: which projects depend on which others, who owns what, which decisions were made and why, how today’s incident connects to last quarter’s change.

Atlassian has spent the last year turning that map into something its agents can reason over. Rovo gets meaningfully smarter as the graph fills out, because it inherits context no general-purpose model could reconstruct from scratch.

When one platform genuinely owns a domain end to end, this is the right answer. And it isn’t close. Picture a release manager heading into a launch review. The question on their mind is which unresolved dependencies could derail the quarter. Inside a well-tended Atlassian environment, an agent can answer that in seconds, because the dependencies, the owners, the blocked work, and the related incidents already live in one connected structure. The intelligence is useful precisely because it never has to leave the place where the work lives.

The limit is the same as the strength. This approach is powerful inside the domain the platform owns, and it has little to say about everything outside it.

Answer two: put the intelligence across the stack

The second approach starts from a fact every leader knows but few architectures account for: no organization runs everything through one platform.

Engineering may live in Atlassian, but sales lives in the CRM, finance lives somewhere else again, and the executive team lives in mail and calendar. A knowledge worker’s actual day crosses six or eight systems. The work that matters most often happens in the spaces between them, where no single platform has authority and no single graph has visibility.

The across-the-stack approach puts the AI layer there, in the flow of the user’s work rather than inside any one domain’s data model. Superhuman is the platform we’re betting on for this, because it’s built to meet people inside the tools they already use and to carry consistent governance across all of them, rather than asking the organization to re-platform onto one vendor’s world.

Picture an account executive preparing for a renewal. The history they need is scattered: the deal in the CRM, the implementation issues in a support tool, the contract terms in email, the relationship context in three months of meeting notes. No domain platform owns that picture, because the picture isn’t a domain. It’s a person’s job. An across-the-stack layer can assemble it because it follows the user instead of the system.

The limit here is the mirror image of the first approach. This layer goes everywhere, which means it rarely has the deep, structural context that a domain-owning platform accumulates over years.

Where the clean line breaks down

It would be tidy to draw a clean line between these two and tell you which side to stand on. The truth is messier.

The line is moving. Atlassian is building outward, not just inward. Its support for the Model Context Protocol (MCP) and its growing library of connectors are bets that other systems and other agents will increasingly reach into the Teamwork Graph, and that the graph will reach back out. Meanwhile, the across-the-stack platforms are developing real depth inside their own surfaces, so the breadth-versus-depth contrast softens a little every quarter.

What stays distinct, underneath the converging features, is the organizing center of gravity. One approach is built around the data model of a domain and reasons outward from there. The other is built around the user’s flow of work and reasons inward toward whatever systems that work touches. Those are genuinely different design philosophies, and they will stay different even as each one borrows capabilities from the other.

Which is why the question for most leaders was never “which one wins.” Both will be present in any mature environment. The within-the-platform layer will keep getting smarter at the work it captures, and the across-the-stack layer will handle everything that lives in the gaps.

The useful question is narrower and more practical: which of the two is missing in your organization right now.

A way to tell which one you’re missing

You can usually find the answer by asking where the friction actually is.

If the work that matters most runs deeply through a single platform, and the complaint you hear is that your people can’t get good answers out of a system that clearly holds the data, you are probably under-invested in the within-the-platform layer. The context is there. Nothing is reasoning over it.

If the work that matters most crosses many systems, and the complaint you hear is that AI helps in pockets but nobody can see value at the level of a whole role or a whole team, you are probably under-invested in the across-the-stack layer. The intelligence exists inside individual tools. Nothing is following the person between them.

A few questions tend to surface which case you’re in:

• Where does the work that matters most actually live, and is it one platform or many?
• Which of your platforms genuinely own a domain end to end, and which only own part of it?
• Where would AI need to follow a person across tools to be useful?
• And where do governance, audit, and measurement need to be consistent across systems rather than configured one tool at a time?

None of those questions require a finished AI strategy to answer. They require a clear look at how work moves through the organization you already have.

The decision you can’t get wrong by moving

There’s a quiet anxiety underneath the “are we behind” question. The anxiety assumes there’s a single right architecture, that choosing wrong is expensive, and that the safest move is to wait until the picture clears.

The opposite is true. Because both layers will end up mattering, and because the right place to start is almost always one team and one workflow, this is not a decision you can get catastrophically wrong by moving.

It’s one you can only get wrong by waiting. The organizations that will look prescient in two years are not the ones that picked the correct architecture in advance. They’re the ones that put something real into motion early, learned what their environment actually needed, and let the strategy follow the evidence instead of preceding it.

That is the work, and it’s why we sit where we do. As an Atlassian Platinum Solution Partner and a Superhuman Alliance Partner, we work across both sides of this choice. Not because we’ve decided one of them wins, but because the honest answer for most organizations is some of both. The architecture is the question. We help you find the first place to start answering it.

If you’re trying to work out which layer is missing in your environment, and where a sensible first step would be, reach us at contact@e7solutions.com.