Agent readiness is whether your Atlassian estate is safe and useful for agents before you switch them on. You check five things: identities, permissions, content, who controls the agents, and how you will measure them and turn them off.
Most readiness checklists focus on the agent: which use case, which prompt, which model. Those questions matter, but they are the easy part. The hard part is what the agent lands on. A Rovo agent either works with the permissions of the person using it or runs under its own agent account. Either way, it reads the content your teams have written over the years, and acts through the same Jira and Confluence your people use. If those layers are messy, the agent is messy too, only faster.
This guide covers the five checks Atlas Bench runs in an agent readiness assessment, what "ready" looks like for each, and how to check it yourself. For a shorter version focused on a first Rovo pilot, see our guide on assessing agent readiness before your first Rovo rollout.
What ready looks like: every account with access to Jira or Confluence belongs to a real person or a system with a named owner. Leavers lose access the same day. Nobody has two accounts.
Why it matters for agents: an agent that uses a person's account acts as that person. An account that should have been removed is an account that can still use agents. A duplicate account is two sets of permissions for one person, and usually one of them is wrong.
How to check it:
Atlassian bills for everyone with access to an app, whether or not they log in, so this check usually pays for itself. If your provider is Okta, our Okta SSO and SCIM for Atlassian Cloud service covers this layer end to end.
What ready looks like: your Jira permission schemes, Confluence space permissions, and groups grant what their names say, and sensitive content is restricted where it lives.
Why it matters for agents: agents make over-sharing visible. A Confluence space open to the whole site was a small risk when finding a page meant knowing it existed. An agent can search it, summarize it, and quote it back to anyone who asks.
How to check it:
Fix problems in the permission model, not in each agent. One fix protects every person and every agent that uses a person's account. Agents with their own account need a separate check of what they have been granted, which is covered in Check 4.
What ready looks like: the pages and work items an agent will draw on are current, owned, and not duplicated across sites or spaces.
Why it matters for agents: an agent answers from what it finds. Three versions of the onboarding page produce three answers. Custom fields duplicated across Jira sites produce reports that do not add up.
How to check it:
What ready looks like: you know who can build agents, who owns each one, which identity each uses, what each can change, and which automations call them.
Why it matters: by default, anyone with access to Rovo Studio can create an agent, and new agents are open to all users. Agents can create Jira work items, update statuses, and create or edit Confluence pages. In automation rules they can be set up to act without asking for confirmation.
How to check it:
Our step-by-step guide on how to review Rovo agent access covers this check in detail.
What ready looks like: each agent has a test set it has to pass before more people use it, you can see what agents and connected tools did, and you know exactly how to stop one.
How to check it:
| Area | Ready when | Most common gap |
|---|---|---|
| Identities | Every account has a person or an owner; leavers lose access the same day | Deactivated in the identity provider, still active in Atlassian |
| Permissions | Groups grant what their names say; sensitive spaces are restricted | Old project groups with broad grants |
| Content | Source spaces are current and owned | Duplicate pages and fields across sites |
| Agent control | Creation limited; every agent owned; identity chosen on purpose; automations listed | Agents built by anyone, owned by no one |
| Measurement and off switch | Test sets pass; audit log reviewed; stop procedure written | No test set, so nobody knows if answers are right |
Start at the bottom. Identity first, then permissions, then content, then the agents themselves. It is tempting to start with the agent because that is the visible part. But every gap in the lower layers shows up in the agent's behavior, and fixing it there means fixing it once per agent instead of once for the estate.
This is the model Atlas Bench, an Atlassian Platinum Solution Partner, uses across its work: four layers, from identity and access at the bottom to agents and automation at the top, and each one load bearing for the one above. Our agent readiness assessment is fixed scope. You get the findings, the ownership gaps, and the order to close them in.
Our agent readiness assessment covers all five checks in this guide, in this order, with fixed scope agreed up front. You get the findings, the ownership gaps, and the order to close them in.
Get an agent readiness assessment Or talk to an architect
No. A small pilot with a known group and low-risk content is a good way to learn. Readiness matters before you open agents to everyone, turn on write actions, or connect them to automation.
It depends on the size of the estate. Ours is fixed scope and agreed up front, and the output is a findings report with the order to close each gap.
No. The same checks apply to outside assistants connected through the Rovo MCP server and to Forge apps. Forge apps can act as the app itself, not only as a user, so also review the scopes and permissions each app is granted.
Accounts and groups nobody can explain. It is also the finding that most often lowers the license bill once it is fixed.
Yes. Everything in this guide uses settings and exports you already have. Teams bring us in when the estate is large, spans several sites, or needs evidence an auditor will accept.