Rovo beyond the chat - your most impactful deeper use cases?

Hi all,

Rovo is running in our environment and users mostly use it the obvious way:
asking things in the chat and getting answers across our connected tools, creating
tasks and so on.

So, for people who've gone further: what do you use Rovo for beyond the chat
window? I'm curious about the less obvious stuff, things that quietly make users'
lives easier rather than the headline demo.

Trying to build a picture of what potential is behind the deeper configuration
before I dive in.

Can you share some impactful use cases you've done and how they helped?

4 comments

Comment

The biggest step beyond Rovo Chat is to stop thinking of Rovo only as something a user prompts and start placing it at specific decision points in a workflow.

Some of the more valuable use cases I would explore are:

JSM request triage

Use a Rovo agent within Automation to analyse incoming requests and recommend or populate the summary, request type, urgency, priority, component, or owning team. This can reduce manual triage and improve consistency, particularly where users submit requests through free-text channels.

I would initially keep a human review step before allowing it to make sensitive routing or priority decisions autonomously.

Jira and Confluence quality checks

An agent can review newly created requirements, DACI decisions, change records, or operational procedures against an agreed template. It can comment when acceptance criteria, ownership, risks, evidence, or rollback instructions are missing.

This is valuable because the assistance appears when the content is created, rather than relying on someone remembering to ask Rovo for a review.

Scheduled delivery and risk summaries

A scheduled automation can ask an agent to analyse a project or set of Jira work items and produce:

Blocked or stale work
Emerging delivery risks
Items approaching or breaching deadlines
Changes since the previous report
A team-level or executive summary

The output can then be posted to Slack, added to Confluence, or sent to the relevant stakeholders. Atlassian’s Jira Delivery Agent is particularly relevant here.

Release notes & change communications

Rovo can turn completed Jira work into release notes tailored for technical teams, support teams, or customers. It can also identify issues that lack sufficient release-note information and request clarification before release.

I would use Rovo to interpret and generate the communication, but keep authoritative actions such as marking a version as Released tied to a verified CI/CD or deployment event rather than an unstructured Slack message.

Knowledge lifecycle management

Instead of only answering questions from Confluence, an agent can help identify outdated pages, missing ownership, duplicated guidance, conflicting procedures, or content requiring periodic review.

The safest implementation is for Rovo to produce review candidates and notify the content owner, rather than automatically archiving or rewriting authoritative documentation.

Turning conversations into managed work

In Slack or Microsoft Teams, Rovo can summarise a discussion, extract decisions and actions, create the corresponding Jira work items, and draft a Confluence decision record. This closes the common gap where useful decisions remain buried in chat threads.

Contextual assistance without opening Chat

Agents can be used directly while editing Jira or Confluence through /rovo or /ai. The browser extension can also expose Rovo Search, Chat, agents, and company terminology while users work in other browser-based tools.

For me, the best initial use cases have three characteristics:

High-volume and repetitive
Based on information Rovo can access reliably
Reversible or subject to human approval

I would let Rovo summarise, classify, recommend, draft, and identify exceptions first. Deterministic automation should remain responsible for approvals, access changes, deployment status, financial decisions, and other authoritative state changes.

The real benefit is not simply that Rovo can answer more questions. It is that it can quietly improve the quality and consistency of work at the point where that work happens.

https://www.atlassian.com/software/rovo/use-cases

We have been building agents to help our make our user's lives easier. Here are a few that are currently in use:

Requirements review agent. We run this agent to review user story, acceptance criteria, and any other information on a issue. It provides an analysis of the readiness for work, testability, and provides questions to ask product owners for further clarification.
Automation documentation agent. This agent is for me, as an org admin, to document our automations. It takes the automation JSON file, analyzes it, and generates complete documentation for creation to Confluence.
Creative Services time estimator agent. Our creative service's traffic manager needed a way to generate time estimates for the creative team members, so we developed an agent to help generate the estimates to assist her in capacity management.

I've been trying to build Rovo agents to automate first-draft doc updates for software development. I got some amazing initial results. But I keep being thwarted by what Atlassian won't document, doesn't commit to, and keeps changing.

They won't document anything about their model routing - not what models get used, under what circumstances, and particularly what the context capacities are. I've had to design my task into multiple agent steps based purely on trial and error, and recognizing when breakdowns in result looks like context rot rather than lack of clarity in instructions.

And critically to my need they are very squishy about what "knowledge" means specifically. Most recently mumble stuff about the Teamwork Graph.

Rovo is excellent at the Jira summarization part of my need. It walks the Jira issue parent/child tree as instructed, and does a great job pulling all the development work impact into a markdown summary.

But my task also requires knowledge of a moderately large corpus of existing docs in order to determine where the changes fit. In principle the docs should be in a RAG chunked and indexed semantic database. Initial tests with Rovo three months or so back pretty well demonstrated that if I attach PDFs (text PDFs, not scans or OCR) of my docs to Confluence pages, that content did (then) get RAG indexed. Agents were able to find related topics and quote relevant passages from within far more content than any context window would hold.

But lately I've started getting responses that the agents can't even read my PDF attachments at all. Clearly this has changed. And it breaks my process design.

In "fairness" Atlassian never documented that and was never committed to it. So they're free to do it or quit doing it. My biggest problem is that they are so non-specific about detail like this that I can't plan.

Hey @Frank Sherwood! Thank you so much for this detailed feedback, it's clear you're doing genuinely impressive work with Rovo agents and your frustrations are completely valid.

On PDFs: the capability should be there, but there's a known configuration fix where you'll need to scope your agent's knowledge source to a space rather than individual pages and attachment access works reliably.

On model routing and context predictability: great news! We're rolling out agent reasoning selection, which will let you explicitly choose your model and reasoning depth for your agent - we are rolling this out progressively but let us know if you need this sooner

We hear you that we can be more specific and committed in our documentation for builders like you, and this is something we're actively working to improve.

Thanks @Sunny Lin !

For the Knowledge scope, I've always configured my agents to "All knowledge". Which of course means within my tenant. And overlaid by the permission limits of my user.

Within the agent instructions, I tell it to review the attachments on PDF pages within one of a handful of confluence folder trees. (I've created folders for each maintained release version, and pages within for each document.)

I'll try configuring specific spaces within Confluence and Jira and see if that helps.

Re models: I don't see the reasoning tiers available for my site yet. I'll watch for it to roll out.

More specific to my experience though, I still haven't found anything that tells me what my specific context capacity is. It could be 8k tokens or 1M tokens for all I know. And if there's some automatic model router, then I might get different capacities at different times.