Rovo for Microsoft 365: Does AI need more context?

Atlassian recently announced a major step forward for Rovo in Microsoft 365: Rovo is now available in Microsoft Teams and Microsoft 365 Copilot, while Jira Cloud for Microsoft Teams can use Rovo to understand natural-language requests.

And to be honest, we like where this is going. With yasoon’s Atlassian Marketplace app Microsoft 365 for Jira, we have spent years working on a fairly simple assumption: people will continue communicating in Microsoft Teams and Outlook even when their work is managed in Jira. Asking everyone to choose one ecosystem was never particularly realistic. Now AI is making the connection between these ecosystems even more interesting.

Atlassian’s vision is clear: bring the context from Jira, Confluence, Microsoft 365, and other connected tools together so Rovo can understand work and act on it. In Teams, users can now ask Jira to create, update, or assign work in natural language. Rovo can use the surrounding Teams conversation as context. Atlassian has also introduced a Microsoft Teams connector that makes Teams conversations and meeting context available to the Teamwork Graph. That is quite a leap from the simple Jira notifications we were talking about a few years ago.

But it raises an interesting question: Does better AI simply need more context, or does it need the right context?

Rovo, Microsoft 365 Copilot and the race for context

Context has become one of the big themes in enterprise AI. Atlassian has the Teamwork Graph, Microsoft is building Work IQ, and ServiceNow has its Context Engine. The terminology differs, but the underlying idea is similar: AI becomes more useful when it understands not only an isolated prompt, but the organization around it. Who is working on what? Which project does this belong to? What decisions have already been made? Which conversations and documents contain relevant information?

The premise makes sense. An AI agent that knows only the title and description of a Jira work item will understand less than one that also knows the project, dependencies, documentation and conversations surrounding it. But anyone who has worked in a large organization also knows that a lack of information is rarely the only problem. There are five versions of the same document, old email threads contradicting current documentation, three Teams conversations discussing the same topic, and meeting transcripts capturing everything that was said, including quite a lot that turned out not to matter.

In other words: Long live context! But more context is not automatically better context. The interesting question is shifting from “How much information can an AI access?” to “Which information is actually relevant to the work it is trying to understand?” We think the next step for enterprise AI will increasingly be about orchestrating context, not simply collecting it.

Creating Jira work from Teams is only the beginning

This gets particularly interesting between Jira and Microsoft 365. Imagine a product team discussing a customer requirement in Teams. With Rovo and Jira in Teams, that conversation can become Jira work without somebody manually transferring the information. That’s useful. But creating the work item is only the beginning.

The next day, somebody forwards additional customer feedback through Outlook. Engineering discusses an implementation detail in another Teams conversation. A meeting changes the scope. Two months later, somebody new takes ownership of the work and wants to understand why a particular decision was made. All of these interactions create new context.

The challenge is not necessarily getting every Teams message, Outlook email and meeting transcript into Jira. It’s knowing which communication belongs to which work. This is a problem we have been working on for quite a while. Microsoft 365 for Jira creates explicit relationships between communication in Microsoft 365 and work in Jira. Teams conversations, Outlook email threads and meetings can stay connected to the relevant Jira context, while templates, Presets and automation help define how those communication workflows are managed.

You could think of this as a specialized context layer between Microsoft 365 and Jira. It doesn’t try to replicate the entire Microsoft world inside Atlassian. Instead, it answers a much narrower question: Which Microsoft 365 communication is relevant to this Jira work?

Until recently, we primarily thought about these relationships as a way to help humans work across Microsoft 365 and Jira. With Rovo and AI agents, they will become useful for something else.

What if AI already knew where to look?

Imagine asking Rovo to improve the description of a Jira work item. If there is also a Teams conversation, an Outlook thread and a meeting explicitly associated with that work item, those relationships could provide valuable additional context.

Ideally, the user shouldn’t have to explain: look at this Jira issue, find this Teams conversation, check this email thread, and use the notes from last Thursday’s meeting. A genuinely contextual system should increasingly understand those relationships itself.

That’s where we see an interesting opportunity for Rovo Skills and Actions. A yasoon capability can retrieve the communication connected to a Jira work item or Epic, while another can provide a summarized view of that context. Customers can make these capabilities available to their own agents, and yasoon can build ready-to-use agents for specific workflows, such as summarizing communication around an Epic or turning meeting outcomes into follow-up work.

The important part isn’t giving Rovo access to as much Microsoft data as possible. It’s giving it Microsoft context that already has a meaningful relationship with the Jira work.

And the idea doesn’t need to stop with Rovo. Through standards such as MCP, another AI system could potentially request that context when it needs it. For example, a coding agent working on a Jira issue might also benefit from understanding the customer feedback contained in the Teams conversation associated with it.

One context graph to rule them all? Probably not.

As of today, we don’t expect enterprises to move all their Microsoft context into Atlassian, or all their Atlassian context into Microsoft. Microsoft, Atlassian, Salesforce, ServiceNow and others are building their own context and AI layers. Each with different data, permission models, products and, naturally, their own strategic interests.

A lot will depend on which horse an organization chooses to back more heavily. Some will standardize around Microsoft, others around Atlassian, and many will continue to operate across both. A multi-platform context landscape therefore seems more realistic than one universal context layer.

Microsoft understands a great deal about communication and work happening in Microsoft 365. Atlassian understands a great deal about work managed across Jira, Confluence and its other products. The interesting challenge is moving the right pieces between those worlds when they are needed, while respecting the permissions of the underlying systems.

For yasoon, that’s a familiar problem. We’ve been sitting between Microsoft and Atlassian since 2012.

Rovo in Microsoft 365 vs. Microsoft 365 for Jira: Where’s the difference?

There is overlap. Rovo can understand a Teams conversation and turn it into Jira work, which clearly touches part of the same workflow that Microsoft 365 for Jira supports. The difference is what happens around that Jira work. Rovo brings AI, search, and Jira actions into Microsoft 365. Microsoft 365 for Jira keeps the underlying communication in Teams and Outlook connected to the relevant Jira work item as the work continues.

That makes the two approaches more complementary than contradictory. Rovo helps users act on context. Microsoft 365 for Jira helps create and preserve the relationships that make that context useful in the first place. The interesting next step is bringing both together. Making the Microsoft 365 context already connected through Microsoft 365 for Jira available to Rovo, Copilot, and other AI systems when it is relevant and permitted.

Because better enterprise AI is not about giving an agent access to everything. It is about giving it the right context for the right work at the right moment.