.webp)
Rovo Chat Stops Being a Party of One: Memory, Agents, Shared Chats, and Custom Skills
The most expensive sentence in knowledge work might be “can you just send me a quick summary?” Someone spent an afternoon reasoning through a problem. The summary takes ten minutes to write, keeps the conclusion, drops most of the reasoning, and lands with a colleague who now has to rebuild whatever got left out.
Atlassian’s September 17 Rovo Chat announcement is aimed squarely at that sentence. Written by Gunjan Sood, who leads product management for artificial intelligence at Atlassian, it introduces four Rovo Chat capabilities: memory you can see and edit, agents you can @mention into a conversation, chats you can share with teammates, and custom skills that turn a repeated workflow into something Rovo can run on request.
Three of the four hand something that used to live inside one person’s conversation to the team: an agent’s expertise, a chat’s reasoning, a workflow’s steps. The fourth, memory, stays deliberately private, which matters just as much. Sharing is the right direction because work is shared, and it means Rovo Chat now inherits what every shared asset inherits: ownership, upkeep, and a slow drift from accurate to almost accurate.
What Atlassian announced, and what is live today
The four features did not all arrive the same way, so the release state matters.
- Memory you can see and edit. A memory view shows what Rovo has learned about you. Atlassian’s memory documentation splits it into an implicit summary built from your Teamwork Graph activity, which you can suggest edits to, and explicit instructions you give in chat, which you can view, edit, or delete. The announcement adds that users and admins can turn memory on or off at the user and site level. Memory controls first reached general availability in June, according to Atlassian’s Rovo Chat team; the September post folds them into the team story.
- @mention agents. Any agent can be pulled into a Rovo Chat conversation by name, and Atlassian says it arrives with the thread, the decisions, and the artifacts already in context.
- Shared chats. You can share the conversation itself instead of a summary of it. Atlassian says shared chats stay permissions-aware, so a teammate only sees what they already had permission to see.
- Custom skills. Describe a repeatable workflow in Chat, such as a sprint summary built from your board, and Rovo builds the skill by asking clarifying questions about edge cases and output format. Skills can be created and refined in Chat or in Rovo Studio. Atlassian said custom skills would reach all instances over the week following the announcement, so a site that does not show them yet may simply be later in the rollout.
Rovo is available for apps on Standard, Premium, and Enterprise plans, per Atlassian’s documentation. For what Rovo Chat already did well before these additions, see our Rovo Week primer on Rovo Chat.
Memory is a preference, not a policy
One of the example memories in Atlassian’s announcement is a preference that customer data stay out of drafts. That is a sensible thing to tell an assistant. It is also worth being precise about what it is.
According to Atlassian’s documentation, only the user can see their memories. Other users, including organization admins, cannot view the facts Rovo has stored about someone, and each memory is scoped to one user on one site. That is the right privacy design for a personal assistant. It also means memory cannot serve as a control. An administrator cannot audit it, a team cannot enforce it, and it stops applying the moment a user deletes it or turns memory off.
So use memory for what it is good at: format preferences, tone, and recurring context about someone’s role. Keep data-handling rules where they can be governed: permissions, Rovo access settings, and written policy. Explain that difference to users in one sentence when you roll this out; it prevents a surprising number of well-intentioned misunderstandings.
The @ menu is now your agent directory
Before this release, finding the right agent took a little intent. Now every agent in your organization is one keystroke away from every conversation, which makes the state of your agent directory a user-experience decision whether or not anyone planned it.
Atlassian’s agent governance documentation is candid about this. Agent creation in Rovo Studio is open to everyone in the organization by default, new agents are visible to everyone by default, and the documentation notes that without governance practices this can lead to crowded agent directories. Studio admins can limit who creates agents, and organization admins can mark trusted agents as verified so they surface in Search and Chat with a blue checkmark.
If your directory currently holds three agents named “Test” and one named “Test (final),” @mention is about to introduce them to the entire company. The fix is housekeeping rather than engineering: retire the experiments, verify the agents you would stand behind, and decide who gets to publish new ones. Agents act with the permissions of the person using them, which is the right design and also the reason agents enforce your permissions exactly as you wrote them, including the parts you wrote years ago.
Share the chat, then write down the decision
Shared chats solve the summary problem well: the recipient gets the reasoning along with the conclusion, and Atlassian says sharing stays permissions-aware. Before relying on it for cross-team handoffs, run one deliberate test. Share a chat whose answers drew on a restricted page and see exactly what the recipient experiences. Better to learn the behavior now than during an escalation.
The other detail is lifecycle. Atlassian’s documentation for managing Rovo Chat conversations says Rovo Chat stores prompts and answers for 30 days. Unless Atlassian documents a different lifecycle for shared chats, treat a shared chat as a handoff rather than the record.
That distinction matters. In Atlassian’s own Agentic Pivot research, only 15% of engineers and 25% of leaders were very confident they could reconstruct the reasoning behind a decision made with artificial intelligence assistance six months later. We called that Atlassian’s six-month test for agent-era decisions, and a 30-day conversation cannot pass it alone. So share the chat to move the work, then write the decision into a Jira work item or a Confluence page, using the same Confluence documentation practices that keep decisions findable for everything else.
Custom skills are process documentation that runs
Atlassian’s documentation draws a useful line between skills and tools. Tools are what an agent can do: a single action with defined inputs and outputs, such as transitioning a work item. Skills are how it does the work: reusable instructions that combine tools with reasoning. Atlassian-built skills such as /get-data-insights have been in Rovo Chat since earlier this year; what is new is that your team can write its own.
That makes a custom skill a standard operating procedure that executes. It will be wonderful on day one and quietly wrong on day three hundred unless someone owns it, because processes change and procedures rarely get told. Treat skills the way mature teams treat automation rules: a named owner, a plain-language description of what the skill is for, and a review date.
Frictionless usage also shows up on the meter. Atlassian’s Rovo credits documentation counts each user message in Rovo Chat as a billable event, prices Quick answers at 10 credits per event, and bills Think Deeper and advanced agents at variable rates, with extra usage billing starting December 3, 2026. A weekly skill that 40 people run is roughly 160 chat messages a month before anyone asks a follow-up. Whether that is a bargain depends on the work it replaces, and admins can see credit usage by feature and by user, so it is easy to plan for. Our breakdown of Atlassian’s usage-based pricing covers the allowances.
Who should move now, and what to do this week
Move now if Rovo is already part of daily work, if your teams run recurring rituals such as sprint summaries, leadership updates, or triage, or if you own Rovo Studio and have never checked who can publish agents. You can reasonably wait if Rovo Chat habits have not formed yet, because shared chats and skills amplify habits that already exist.
- Decide your memory posture. Unless a regulatory requirement says otherwise, memory on with one sentence of guidance beats memory off: preferences belong in memory, and policies belong in governed controls.
- Clean the agent directory. Retire experiments, verify the agents you trust, and set Studio creation rights deliberately.
- Set the handoff rule. Share the chat to move the work, and write the decision into Jira or Confluence to keep it.
- Pick two or three first skills. Choose high-frequency workflows whose output a human reviews, and give each one a named owner.
- Watch the meter. Check Rovo credit usage in Atlassian Administration a few weeks after skills land, well before December 3.
Quick answers for Rovo administrators
How do users turn Rovo memory off?
In Rovo Chat, open More actions, then Settings and memory, where users can toggle memory, review their activity summary and saved instructions, and delete explicit memories. Atlassian’s announcement says admins can also turn memory on or off at the site level.
Who can create agents and custom skills?
Agent creation in Rovo Studio is open to all users by default. Studio admins can restrict it to as many as 10 selected groups or to organization admins only. Custom skills are still rolling out, so confirm how skill creation and sharing behave in your site before standardizing.
The Avaratak Take
Atlassian ends its announcement on a line I agree with: “Context is only valuable when it’s shared.” I would add one clause. Shared context is only valuable while it is still true.
Most of this release moves context from a private place to a shared one, and every shared thing needs an owner. Memory is the exception that proves the design: it stays private, so its owner is built in. Agents need a directory owner, shared chats need someone who turns the decision into a record, and skills need a process owner who notices when the process changes. It is the same stewardship that keeps a Confluence space or a set of automation rules trustworthy, applied to a new surface.
The overreaction I would avoid is switching memory off site-wide because “the assistant remembers things” sounds alarming in a steering committee. The documented design is private, scoped per user and per site, and under the user’s control, which is better served by guidance than by a kill switch. The underreaction I would avoid is letting custom skills multiply without owners, because a skill nobody maintains still runs with total confidence.
Atlassian is building Rovo Chat into the place where team context accumulates, and I think that is the right bet. The organizations that benefit first will treat that context like any other shared asset: owned, maintained, and occasionally pruned.
If you are working out which of your team’s rituals deserve to become skills first, and who should own them, Avaratak can help you separate the useful part from the shiny part. Book a discovery conversation and bring your agent directory.