nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Does anyone else feel like Rovo is just A, not AI?

daften

I have tried to create several agents. Lookup information works okay, not great, but okay.

But taking actions, holy moly ...

I wanted a personal agent to help me with task management. I use a jira project to keep track of my tasks. The agent in this phasse would be simple: look up information in my tasks and create tasks. To gradually make this more complex later on.

But even this step, Rovo fails at spectacularly. If I ask it to create a task in my personal project and the scenario instructions contain items such as "Always check which category the task belongs to. Suggest an existing category if possible, or propose a new one if none fit." it still doesn't follow this instruction and doesn't ask for a category. When trying to get it to update the category later, it always said it did it, but never does it. It conflates Category on work item level with Project category and confidently says that Category on issue level just "shows" the project category.

It also doesn't fill out any other structured fields like due date properly.

It's like Atlassian Rovo can't work with Atlassian Jira, it's amazing.

In the meantime, if I create a local agent with Claude code using MCP, I can do more things, and better than with the built-in Atlassian AI Tool.

Am I alone in this? Am I missing crucial information or steps I need to take?

Accepted answers

Arkadiusz Wroblewski

Hello @daften

You're not alone. this is a pretty common experience right now. Rovo agents are genuinely useful for read operations and simple lookups, but when it comes to write actions involving structured fields, multi-step logic, or anything that requires understanding Jira's field model deeply, it still falls short of what you'd expect.

The category/project category confusion you described is a good example of a known limitation, Rovo doesn't always distinguish cleanly between field types and their scope, and it tends to hallucinate success on write actions rather than flagging that it couldn't complete them properly.

A few things that can help in agent instructions are being very explicit about field names exactly as they appear in Jira, breaking instructions into smaller discrete steps rather than compound conditions, and adding confirmation checks like "after creating the work item, retrieve it and confirm the field values".

But to be honest, Rovo agents are still maturing, and your comparison with a Claude MCP setup is fair, the flexibility isn't quite there yet natively. Worth submitting feedback directly to Atlassian via the thumbs down on Rovo responses, as that data does feed into their improvement roadmap.

All comments

Arkadiusz Wroblewski

Hello @daften

Dr Valeri Colon (Connect Centric)

Hi @daften! I second much of what @Arkadiusz Wroblewski has said. What you’re seeing lines up with how Rovo works today.

One key thing: Rovo isn’t the AI itself. It’s an interface that connects to underlying LLMs + Atlassian data/tools, so behavior depends on how well those models, tools, and permissions line up. Rovo = AI Interface.

Where it struggles today:

Structured field updates (category, due date) can be inconsistent
It can misinterpret fields (project vs issue-level)
“Taking action” is still more limited than “answering questions”

Also, when it says something worked but didn’t, that’s often due to tooling/permission gaps or partial execution, not just the model making things up or hallucination. Your MCP + Claude setup feels better because it’s more explicit and controlled. For now, Rovo works best as assistive (suggest, draft), with automation/API handling precise updates.

Gareth Whitley_fd91i1

Yep - similar experience here. Trying to get Rovo to consistenly write, as in create pages or update databases can be a minefield of frustration. A lot of the time it doesn't know it's own API's capabilities, misconfigures what it is meant to do and forgets about a successful generation that it has literally just done. You can end up spending so much more time faffing with it while you could have just done the job manually.

For users within organisations that put limits on using the corporate networks for things like calling external APIs and MCPs, this can be a significant hurdle.