What can Rovo change in your Jira, and what can it not?

Written by Ben Friedman, Atlassian expert & builder of JAMEs, the AI Jira administrator · Published 15 August 2026

Rovo, Atlassian’s own AI, has the capability to save you hours of Jira work. Knowing where it stops allows you to fully maximise it, and saves you from experimenting down a rabbit hole.

Rovo works on the contents of your Jira and Confluence, and can connect to external sources. It excels at drawing on information sources and producing an output or an action in Jira. It can be used inside Jira’s automation, as an MCP server, or to build an AI agent.

It can search thousands of work items, raise one, edit it, and move it through statuses. It cannot change the workflow it just moved that item through.

In fact, nothing on the list Atlassian publishes creates or alters a custom field definition, a screen, a workflow, a permission scheme, a request type, a board or an automation rule.

The whole list is public. On 15 August 2026 it held fourteen tools for Jira, and every one acts on a work item: get, comment, log time, create, edit, transition, or run a JQL query (supported tools).

What does Rovo actually do in Jira?

Work inside issues, and it is genuinely good at it. Rovo can fetch an issue and everything hanging off it, add a comment, log time against it, raise a new one, edit the fields on an existing one, and move it to another status. One more tool runs a JQL query, which is what lets an assistant answer questions across a whole backlog instead of one ticket at a time (Rovo MCP).

Put together, that covers a real slice of a working day. Drafting tickets from a meeting note, tidying a messy backlog, summarising where a project stands, moving a batch of items after a triage call: all of it sits inside what Atlassian ships, at no extra cost, on infrastructure you already trust.

None of this is the whole of Rovo either. It draws on Confluence and the other sources you connect to it, answers in chat, and builds agents that run across products.

What is the difference between Rovo MCP, Rovo agents and Rovo in automation?

Rovo allows three interfaces, each with its own capabilities and tools. Rovo reaches Jira as an MCP server that an outside user connects to. It can be used as an AI agent you build and run inside Atlassian. Lastly, it appears as a rule action that wrangles an agent you created (automation actions). Which one you are using decides what it can actually do.

The order is the reverse of what most people assume. The surface that runs unattended has the fewest tools, not the most: Atlassian states that an agent triggered in an automation flow cannot use its own tools, so it hands back a response and the rule does whatever it was already able to do (agent tools). The widest surface is the one a person drives by hand. It matters because "Rovo can do it" is usually true of a different surface from the one you were planning to use, and because the same boundary holds across all three: everything Rovo writes to lives inside a work item, and everything an administrator configures sits on the other side of it.

What happens when a Rovo request needs a configuration change?

Consider your team needs every bug to carry a severity rating before it can move to In Progress. Can Rovo fill in the gap? Easily.

Rovo runs a JQL query for open bugs with no severity set, comes back with 340 of them. Then its AI component can assign a severity based on the description and comments. It can even find duplicates based on the content of tickets to raise the urgency. An afternoon of clicking disappears into a few minutes, and the summary at the end is accurate.

Stopping it from happening again is the part where Rovo stops. Enforcing severity on that transition means a validator on the workflow. Getting the field to appear on the two projects that never had it means a new field context and a screen change. No published tool covers any of that, so the same request arrives next month with a fresh set of tickets. Still, your team can use Rovo’s engine to analyse the severity when needed.

This pattern is what you see across most administration work. The data half sits inside Rovo’s reach and the rule half sits outside it. Cleaning up is issue work. Making the cleanup unnecessary is configuration.

Can Rovo read configuration it has no way to change?

To some extent, yes. Two published tools cover it: Rovo can tell you which issue types a project has, and which fields those issue types carry. A third lists the projects the connected account can see, based on that account’s permissions.

An assistant holding that can describe your setup fluently. It can tell you a field exists, which screen family it belongs to, which issue types use it. That is genuinely useful, and it saves an administrator time.

Reading is not a step towards writing here. Knowing part of a project’s configuration does not tell you where else those objects are shared, or how, and shared configuration is exactly where an administrator’s risk sits. Rovo publishes no tool for that work.

When is Rovo the right answer on its own?

Whenever the work you want help with lives in tickets. If your week goes on writing up issues, chasing status, summarising for a stakeholder, or turning a call into a set of items someone can pick up, Rovo covers that, it is included, and adding anything else would be waste.

Which of the three you reach for follows from how the work arrives. Ad hoc requests can use the MCP server, or an agent if the data is already in a ticket. Work that repeats on a trigger is fitted for an automation task, with the caveat that Rovo only returns a response, and it is up to the rule to make the action.

The same holds for service teams doing Ops work. Atlassian added JSM tools for alerts, on-call schedules and team information, so the questions an on-call engineer asks at 2:00 AM are inside the published list too.

What you shouldn’t expect Rovo to do

Take work off your administrator. The workload that builds up for a Jira site is made of the objects with no published Rovo tools supporting them. A field that needs another context, a request type that has to exist before Monday, a workflow with one condition wrong on one transition. None of it can be handed to something with no tools for it, however the request is phrased. If anything, consider that the administrator now needs to care for Rovo agents and MCP connections as well.

Don’t let it tell you how the change should be made, either. Reading a configuration is not the same as judging it, and the judging is most of the work: whether a new field belongs in a context that already exists or one of its own, whether a status is worth adding or the workflow is too wide already, what a change quietly breaks three projects away. Rovo will answer all of that fluently, from the fraction of the picture its tools return.

Weigh what any of it is worth to your business. Rovo can read a description and put a severity on it, as above. Whether a bug raised five times in the area that takes payments outranks one raised once in an internal report is a different question, and the answer is not in the text it is reading. That ranking sits with the people who know what the company sells and what it cannot afford to break, and encoding it is what a severity scheme is for.

Hand you a clean record of what it ran. Rovo acts through the account that connected it, so what you have afterwards is issue history rather than a log of the request. Working out what one instruction touched across a few hundred items means reading those items. On a site where changes get explained later, to an auditor or to whoever inherits it, that reconstruction is the real cost.

Frequently asked questions

Take the five things you most want to hand off. If they live inside issues, Rovo already covers you and there is nothing to buy. If it is admin work that you are concerned about, what JAMEs can manage sets out the other half object by object.