You’d like to ask AI for a status update on your project work, but instead of clarity, you get a vague summary and outdated information.
This can happen when your prompts aren’t specific enough. However, even with the perfect prompt, if your AI isn’t well-connected to the systems you use to manage work, the results won’t be as good as if you did it manually.
To get the desired result, AI needs to understand how your work fits together, and that’s where the Atlassian Teamwork Graph comes in.
Teamwork Graph connects the dots between people, projects, and knowledge. It’s what allows Rovo to understand how your work fits together—not just what it’s called or where it’s stored.
For this article, the key point is this: Rovo doesn’t look at Jira and Confluence in isolation. It looks at the graph—a structured, permission-aware map of work that reflects your environment’s actual relationships.
And that’s what makes the difference between kind of helpful and actually useful.
🧠 If you’re new to Teamwork Graph, check out this companion article on how it works under the hood and why it matters.
Let’s say someone asks:
“What did we learn from the last three P1 incidents on Checkout, and what’s still outstanding?”
Without the graph, Rovo is guessing. It might pull in random P1s from other services, overlook key follow-ups, or surface outdated docs.
With the graph, Rovo can:
Anchor on the Checkout service
Pull the three most recent and relevant linked incidents
Follow relationships to post-incident reviews, decision logs, and follow-up Jira tickets
Summarize what happened, what was resolved, and what’s still open—by team, by component, by impact
That’s not search. That’s synthesis.
Most search tools treat your words literally. Ask about “Q3 Reliability,” and they’ll go hunting for that exact phrase in document titles. Real work doesn’t live in titles and headings. It lives in acronyms, evolving initiatives with changing scope, and team-specific shorthand from three years ago.
The graph doesn’t just match words. It asks: What does this phrase mean inside your environment?
If “Q3 Reliability” maps to an initiative in Jira, Rovo finds the work items and stories tied to it. If that initiative is linked to incidents or architectural decisions in Confluence, those show up too. If the requester is part of the platform team, Rovo adjusts what it pulls in based on what they normally work on.
This context-aware lookup is what makes Rovo feel like it “gets” your environment. Because it does—it’s following the same pathways your teams already use to do the work.
Here’s the good news: you don’t have to train a model or write any prompts. You just need to make your system of work legible.
Some of the highest-impact moves we’ve seen:
Link Jira work items to their actual specs, runbooks, or PIRs
Use meaningful issue relationships (blocks, duplicates, caused by, etc.)
Keep team-to-service ownership up to date (Compass helps here)
Make the customer portal usable (not just usable-by-admins)
Use automation rules to reflect how your org really operates
The more meaningful the relationships, the better the graph—and the smarter Rovo gets.
Rovo is powerful, but it’s not magic. If your system is messy, it will reflect that mess right back.
Here are a few places where things can break down:
Fuzzy ownership: If no team clearly owns a service, Rovo won’t know who to assign work to—or who to loop in on a summary.
Disconnected documentation: If key Confluence pages aren’t linked to the work, they won’t show up in answers—even if they have the answers.
Ambiguous labels: If three different teams use “Migration” to mean three different things, expect confused output.
The fix? Don’t start by overhauling everything. Pick one problem area—say, incidents for a high-impact service—and clean up the links, ownership, and naming. Then test Rovo again.
Think of it less like AI configuration and more like gardening your graph. The results are immediate and measurable.
In The 7 Habits of Highly Effective People (1989), Stephen Covey popularized the idea that our internal maps—the mental models we use to understand the world—aren’t the same as the territory they attempt to represent.
That metaphor applies just as well to how AI (and people) interpret work.
Rovo’s intelligence depends on the accuracy and clarity of your map—not just the tools you use, but the assumptions baked into how your teams name, structure, and connect things. A disorganized system reflects a distorted map. And when the map is wrong, the AI can’t find the right path.
The Teamwork Graph doesn’t create the map—it reveals the one you’ve already built. And like any good map, it can evolve. You can clean it up, add new markers, make the paths more obvious. You can update it as the territory changes.
That’s why Rovo isn’t just smarter search. It’s a reflection of your current understanding—and an invitation to redraw your internal landscape with greater clarity.
But you don’t have to fix the whole map before you start using it.
Rovo isn’t perfect at spotting what’s broken—but it can still help. Ask it what’s unclear, and you’ll often surface duplicate docs, conflicting answers, or work items that don’t line up. That’s not a flaw—it’s a starting point. Use what it finds as fuel to clean up your environment, one inconsistency at a time.
You don’t need a full-blown AI rollout out-of-the-gate.
Pick a scenario:
“Give me a weekly update on our Q3 Reliability initiative”
“Summarize the last 30 days of incident activity for Service X”
“Help onboard a new teammate to the Data Platform group”
Run it through Rovo. See what’s missing. Improve the links, labels, ownership, or project structure. Try again.
That’s how you tune the AI—by refining your environment, not the algorithm.
If you're already using Rovo, your graph is shaping it. If you’re not, now’s the time to start mapping how your work fits together.
See also...
What Teamwork Graph Is (Atlassian)
How Rovo Helps Your Teams (Atlassian)
Dave Rosenlund is an Atlassian Community Champion and the founder of the virtual Atlassian Community Events chapter, CSX Masters (fka ITSM/ESM Masters). He also helps out on the Program/Project Masters chapter and Boston ACE. In his day job, he works for Platinum Atlassian Solution Partner, Trundl.
Dave Rosenlund _Trundl_
0 comments