MPUG Editorial · August 31, 2026 · ~5 min read · Category: AI & Copilot

AI agents in Jira crossed a meaningful line this month. On 11 August 2026, Atlassian announced that Agent2Agent (A2A) connections are generally available, meaning any A2A-compliant third-party agent can connect directly to Rovo, reason over live Atlassian data, and take action on a user’s behalf. For project managers, the interesting part is not the protocol. It is that work items, comments and Confluence pages in your project record can now be authored by software a teammate connected, rather than typed by that teammate.

If you own a delivery process that depends on the Jira board being an honest reflection of reality, this is worth ten minutes of your attention before it arrives in your instance.

What actually changed on 11 August

Atlassian has offered a Rovo MCP server for a while. That let an AI client – Claude, Cursor, ChatGPT, an IDE As Atlassian’s Rovo A2A protocol goes GA, AI agents can now write directly to Jira and Confluence – using your team’s own permissions.As Atlassian’s Rovo A2A protocol goes GA, AI agents can now write directly to Jira and Confluence – using your team’s own permissions. call individual tools like a JQL search or a “create Confluence page” function, deciding step by step what to invoke. It was granular, and the client did the thinking.

A2A inverts that. An external agent hands Rovo a whole task in natural language – Atlassian’s own example is “summarize my open Jira bugs into a Confluence page” – and Rovo works out the steps internally, then hands back a result. Rather than a flat list of functions, Rovo advertises two skills: Work in Jira and Work in Confluence.

The practical mechanics, per Atlassian:

• A2A is an open protocol, so it works with any compliant agent. You point your agent at the public agent card at a2a.atlassian.com/.well-known/agent.json.
• Gemini users can connect to Rovo in one click via the Google Cloud Marketplace.
• A2A runs over JSON-RPC 2.0 with server-sent events for streaming, and authenticates with OAuth 2.1 only.
• Because A2A hands off whole tasks, it tracks task state and artifacts, with lifecycle methods for retrieving and cancelling tasks.

Atlassian published both general documentation for Agent2Agent connections and separate admin documentation for managing A2A connections in the Admin Hub. The existence of that second document is the signal for anyone running a PMO.

The permission model, stated plainly

The single most important sentence in Atlassian’s own follow-up: both MCP and A2A respect whatever Atlassian permissions the requesting user already has, so the security model does not change underneath you.

That is genuinely reassuring, and it is also narrower than it sounds. It means an agent cannot read a project a user couldn’t already read, or edit a page they couldn’t already edit. It does not mean the agent will exercise that access with the judgement the human would have. A PM with edit rights on forty projects has, in effect, delegated edit rights on forty projects the moment they connect an agent and give it a loosely-worded instruction.

The scenario Atlassian uses to sell the feature makes this concrete: an agent checks a Jira board, pulls performance data from another system, drafts a Confluence page summarising results, emails it to the team, and raises Jira tickets for trends worth acting on. Every one of those last two steps writes something durable that other people will read as a project artifact.

Why it matters for project managers

Three things change for anyone accountable for a delivery record.

Your project data is now an input to systems you don’t administer. Once an agent is connected, live Jira and Confluence content flows into whatever tool the user pointed at Rovo. If your organisation has data-handling rules for project financials, customer names or security findings, those rules now need an answer for agent connections — not just for exports and integrations.

Agent-authored updates look identical to human ones. A ticket raised by an agent on a PM’s behalf carries that PM’s name. If you later need to reconstruct who decided what and when – a routine need in audit, in claims, and in any regulated delivery – you will want a convention now: a label, a component, a comment prefix, something that distinguishes agent-authored work items. Nothing in the platform does this for you.

The quality floor of your backlog is at stake. Atlassian’s own engineering blog argues that better tickets help agents write better code. The converse also holds: agents that write tickets can generate volume far faster than a team can triage it. Backlog hygiene stops being housekeeping and becomes a control.

None of this is an argument against connecting agents. It is an argument for deciding the rules before someone else decides them for you by plugging something in on a Tuesday. If you want the underlying discipline, MPUG’s Jira training path covers permission schemes and workflow governance, and the on-demand master class library includes sessions on governing AI-assisted delivery.

What to do next

• Find out whether A2A is already reachable in your instance. Ask your Atlassian admin to review A2A connections in the Admin Hub, using Atlassian’s admin documentation, and to tell you who currently has connections.
• Write a one-page rule for agent writes. Who may connect an agent; which projects and spaces are in scope; what agents may create versus edit versus transition; what is off-limits entirely.
• Add an agent-authored marker. A label, custom field or comment convention, applied consistently, so your audit trail survives.
• Decide who triages agent-created work items. If the answer is “whoever notices”, your backlog will absorb the difference.
• Re-read your data-classification policy with agent connections in mind, especially for projects containing customer or financial detail.
• Log the learning. Time spent studying AI governance in delivery is claimable – record it in your PDU tracker under Business Acumen or Ways of Working as appropriate.

Frequently asked questions

What is the difference between Rovo MCP and Rovo A2A? MCP gives an AI client direct, granular access to individual Atlassian tools, and the client decides which to call and in what order. A2A lets an external agent hand Rovo an entire task in natural language; Rovo plans and executes the steps internally and returns a result. Both use the requesting user’s existing Atlassian permissions.

Can an AI agent see Jira projects I can’t see? No. Per Atlassian, agent access is bounded by the permissions of the user who invoked it. The exposure is not to new data – it is that your own access is now exercised by software rather than by you.

Do I need Rovo to use A2A? A2A connects third-party agents to Rovo, so Rovo is the endpoint doing the work inside Atlassian. Confirm entitlement and licensing for your specific plan with Atlassian or your admin before assuming availability.

The bottom line

Rovo A2A reaching GA is a small protocol announcement with a large operational consequence: your Jira and Confluence records are now writable by agents, under your team’s own credentials, from tools outside your administration. The permission model holds. The accountability model is the one that needs work, and that work belongs to the PM and the PMO – not to the admin who flips the switch.

Source: Now GA: Connect any third-party AI agent to Rovo with A2A, Atlassian Community, 11 August 2026. Verify licensing, plan entitlement and tenant-level admin controls against Atlassian’s own documentation before acting – availability and admin options vary by plan.