Atlassian connects Rovo AI to project work and organizational knowledge

Atlassian’s Rovo brings AI assistance into the project and knowledge tools many teams already use. It connects search, conversation and configurable agents with Jira, Confluence and other sources. The buying decision is less about adding another chat box than making existing work easier to find, understand and continue without losing its source context or permission boundaries.

01 / ProductRovo connects the work record with the explanation

The Rovo overview presents AI assistance across Atlassian applications and other entry points. Its Teamwork Graph provides context across work, people and systems. Rovo remains an Atlassian product: Jira, Confluence and its AI experiences belong within the same company blueprint rather than being counted as separate AI businesses.

The practical distinction is between locating a source and producing a synthesis from it. A search result gives the reader something to inspect. A generated handover interprets relationships among tasks, comments and documents. Both are useful, but the interpretation should retain links to the records that support it, especially when those records disagree.

Creating a Rovo agent involves configuring instructions, knowledge and tools in Studio. A reusable agent can give a team a consistent task definition. It cannot establish the truth of a project’s status merely by applying the same instructions to every request.

The relevant implementation work is therefore partly editorial. Decide which page is the accepted project brief, which issues define the current scope and who owns the decision log. Rovo can make fragmented information easier to reach, but it cannot determine an authoritative project policy when the organization has never designated one.

02 / AudienceA fit for teams already working in Atlassian Cloud

Consider a product team that plans work in Jira and records decisions in Confluence. Preparing a handover often means reconstructing why priorities changed, which tasks remain blocked and who can answer questions. Rovo is a natural candidate when that reconstruction can use the team’s existing work context.

The fit is weaker when the key decisions happen outside maintained sources or when the team expects AI to infer commitments from informal discussion. A comment suggesting an option is not necessarily an approved decision. Cleaning up the project record can improve both ordinary search and generated summaries before any sophisticated agent is introduced.

The Glean blueprint provides a comparison when the central problem is enterprise search across a wider application estate. The Notion blueprint is relevant when knowledge and project work are centered in another workspace. Compare where the accepted work record lives, which connectors are needed and how people will inspect the evidence.

03 / WorkflowA proposed handover for a project changing owners

Imagine a delivery lead handing an active project to a colleague. This is a proposed workflow, not an observed Rovo result. Begin with one project, its designated Confluence space and the current release milestone. The intended output is a handover draft that identifies commitments, open questions and owners, with links that allow the new lead to verify each consequential statement.

First, define a cutoff date and the authoritative sources. Ask for open work, recorded decisions, unresolved blockers and dependencies separately. An issue marked complete may still have an unresolved release dependency; a discussion thread may describe a future ambition rather than the agreed scope. Keeping these categories separate makes contradictions easier to notice.

Configure the agent with a narrow handover task and source guidance. Ask it to distinguish what a source states from what it infers, and to identify missing owners instead of inventing them. Use a consistent output shape with fields for the claim, source, date and next action. This is a proposed team convention, not a claim that Rovo automatically applies that exact structure.

If the handover needs external documents, review the Teamwork Graph connector guidance. It distinguishes synced content, direct retrieval and Smart Link connectors. Those routes differ in setup and handling. Choose the connector for the actual source and verify its permission and freshness behavior before depending on it for the project record.

Run the draft as the incoming project lead, not only as an administrator. The agent permissions guide says an interacting agent acts within the user’s permissions. A summary prepared by someone with broader access may contain references the new lead cannot open. That should become a handover issue to resolve deliberately, not an invitation to copy restricted material into a more public page.

Review the draft against a handful of consequential records. Check the release date, approval decisions, customer commitments and owners of blocked work. Ask the outgoing lead to correct the source record where it is wrong, then regenerate the relevant section. Editing only the summary leaves the underlying inconsistency available to mislead the next reader.

Keep publication as a separate human decision in the pilot. The reviewer should see the intended audience and unresolved issues before placing the handover in a shared space. Adding a document-writing tool later changes the risk and operating model; a tool that can publish should not be included merely because the initial research assistant can draft useful text.

Evaluate cases containing renamed milestones, reopened tasks, archived decisions and links that the new lead cannot access. Track corrections by cause: missing evidence, incorrect interpretation, stale content or a real disagreement among team members. Those categories reveal whether the next investment should be better instructions, connector work or improved project documentation.

The useful outcome is that the new lead can continue the project without silently inheriting assumptions. Measure how many follow-up questions remain and whether each important commitment is traceable. A shorter handover is not necessarily better if it removes the uncertainty that the incoming owner needs to understand.

04 / PricingIncluded credits depend on the underlying subscription

The current Rovo licensing page says eligible paid Cloud plans include Rovo without a separate Rovo purchase. It lists monthly per-user allowances that pool at organization level and combine across eligible subscriptions. A base-product license remains part of the commercial decision; included AI usage is not the same as an unlimited service.

The credit documentation says the current usage definitions apply from 31 August 2026, and extra-usage billing begins on 3 December 2026. That latter date is in the future as of this research. Extra usage is enabled by default; administrators can set spending limits or disable it. It also states that enabling Rovo requires the organization administrator to use a verified business domain. Confirm access and current commercial terms before planning a rollout.

For the handover pilot, measure consumption for the complete task, including follow-up questions and revisions. A project with inconsistent sources may require more interaction than a clean project. The allowance should be evaluated alongside the reviewer’s time and the quality of the final handover, rather than translated into a fixed number of guaranteed project summaries.

No universal price per completed handover is established here. The credit model depends on the operation, and the organization may have several eligible subscriptions. Record the subscribed editions and inspect the actual usage view before forecasting a wider deployment.

05 / DistinctionsPermission-aware context is useful, but source quality still matters

Rovo’s appeal is its proximity to the work itself. A team can connect a question about a milestone to the relevant task and knowledge record, without first exporting the entire project into another tool. The potential benefit is continuity between planning, explanation and action inside an existing workspace.

That continuity does not make the answer authoritative. Two users can receive different results because their access differs. A project document that is visible to everyone may still be obsolete or misleading. The handover workflow therefore evaluates both permission behavior and whether the cited record is the right evidence for the claim.

Atlassian’s AI trust page distinguishes restrictions on third-party model providers from Atlassian’s own use of contributed metadata under its settings. It also explains that automated agent calls use the configured connecting user’s knowledge permissions. Avoid reducing these different arrangements to a blanket claim that no data is processed, retained or used anywhere.

There is also an operating choice around agent creation and ownership. The permissions guide documents governance controls for who can create agents and how agents are managed. A team should identify who maintains a handover agent when the original creator changes roles. Consistent behavior depends on maintained instructions and sources, not just an attractive name in a directory.

06 / QuestionsResolve access, freshness and automation identity

Will the incoming owner see all the evidence needed for the job? Test with that actual role. A missing source could mean insufficient access, an unsupported content type, a connector delay or simply that the decision was never documented. These failures should not all become a generic instruction to try a different prompt.

What happens when a page changes after the handover is prepared? Preserve the cutoff date and link to the living record, then decide whether the handover needs revision. An AI-generated draft should not become a parallel project truth that quietly drifts away from the team’s task system.

If the workflow later runs automatically, whose permissions supply its context and which tools can write? That is a separate design review from an interactive assistant used by a project lead. Confirm the execution identity and destination audience before scheduling generated updates into a shared workspace.

07 / DecisionUse a real handover to test the value of connected context

Atlassian Rovo is worth evaluating when project work and organizational knowledge already have a strong Atlassian foundation. Begin with one handover or recurring synthesis where readers can check the evidence and correct the source. This reveals whether connected context meaningfully reduces reconstruction work.

Expand when the team can explain the result’s sources, its missing information and its cost. For the proposed handover, the clearest success is an incoming owner who understands the commitments and unresolved decisions. The number of generated paragraphs or available agents is a weaker measure of usefulness.