Atlassian introduced the Agentic Multiplayer Protocol, or AMP, at Team ’26 Europe on Wednesday, giving AI agents a more visible and permissioned role inside Jira, Confluence, Loom and the wider Atlassian platform. The company says AMP begins rolling out now, alongside an expanded Model Context Protocol server, richer code and data context, and new ways to track work performed by agents.
The name suggests a new technical standard, but Atlassian’s public material currently describes something broader and more product-specific: a set of interaction, identity and governance patterns for people and agents working in the same enterprise systems. There is no public wire specification, interoperability test suite or independent standards body attached to AMP. For buyers, the immediate story is therefore about how Atlassian is changing its own products, not a drop-in alternative to MCP or an agent-to-agent protocol.
What AMP is designed to change
Most workplace agents still operate in private chat windows or terminal sessions. Their instructions, intermediate work and mistakes may be invisible to colleagues, while the useful context disappears when the session ends. AMP is Atlassian’s attempt to move that activity into the shared surfaces where teams already plan, review and approve work.
Atlassian describes three connected layers: agents embedded in day-to-day workflows, a shared context layer drawn from the Teamwork Graph, and identity and governance controls. A person can brief an agent with a Loom recording, mention one in a Confluence page, debate its proposal in a Jira comment thread or connect an outside tool such as an IDE through MCP.
The company is also publishing AMP interaction patterns for four modes of work: an individual using AI alone, delegating a task, pairing with an agent and collaborating in a mixed group of people and agents. The guidelines call for agents to appear in collaborator lists, show their edits in real time, leave attribution in page history and expose the human responsible for invoking them. They also recommend granular tool controls and explicit approval points for consequential actions.
Those rules address a practical problem that model benchmarks do not: a capable agent can still be dangerous or useless if nobody knows which account it used, what source material it saw, which tools it called or who owns the result.
The products behind the protocol
AMP arrives with several concrete product changes, but they are at different stages of availability.
- Rovo Work is a new mode for long-running, multi-step jobs. It proposes a plan, lets a person revise it and then executes in an administrator-governed sandbox. Atlassian says a task can run for hours, find and learn new tools, run scripts and return a result for review.
- Record for Agent, now in open beta, turns a Loom screen-and-voice recording into an actionable brief. The agent can use the speaker’s narration, cursor and on-screen selections to create Jira work items, a prototype or slides in Confluence.
- Artifacts gives AI-generated plans, models and HTML views permanent, permissioned URLs. Those outputs can be embedded in Jira, Confluence or Slack and indexed back into the Teamwork Graph instead of remaining inside a temporary chat.
- Third-party agents can be brought into Jira and Confluence workflows with a history of what they did and when. Atlassian gives the example of a Salesforce status change starting an agent workflow, with a human checkpoint before anything is sent.
- Code Search and data context extend the Teamwork Graph into source code and structured business data. Atlassian says the graph can now understand code at the function, symbol and class level, while its data integrations reach services including Snowflake, Databricks and BigQuery.
The context layer is already large. Atlassian reports that the Teamwork Graph spans seven context types, more than 250 billion connected objects and over 80 connectors. Those are company figures, not an independent measure of accuracy or completeness, but they explain the product strategy: Atlassian wants agents to reason over the tickets, documents, conversations, code and organizational relationships that generic model providers do not possess.
Atlassian MCP gets a much larger action surface
AMP does not replace the Model Context Protocol. Atlassian is using MCP as the bridge between its graph and outside clients including Claude, ChatGPT, Cursor, VS Code and command-line agents.
The rebuilt Atlassian MCP server exposes more than 220 tools, up from dozens, and now reaches further beyond Jira and Confluence. Atlassian says the integration handles more than 15 million tool calls a day. In internal tests using Claude models, the company measured token savings of up to 25% for equivalent Jira and Confluence work; that efficiency claim has not yet been independently reproduced.
A broader tool surface creates both utility and risk. An agent that can create pages, change tickets, read Loom transcripts and write results back into the graph can complete an entire workflow, but a bad instruction or poisoned document can also travel farther. The relevant control is not simply whether an agent can connect. Administrators need to know which individual actions it may take, in which projects and spaces, under whose identity and with what approval requirement.
Some of the most important controls are still coming
Atlassian says AMP gives agents assigned identities and scoped authority, but the accompanying product announcement is careful about timing. Agent accounts and a non-human identity inventory are described as coming soon. These controls are intended to give every agent, app and service account a manageable identity that an administrator can inspect and revoke.
Tracking of agent sessions started in terminals and IDEs is also framed as a future capability. Loom’s automatically generated visual overlays are in early access, while Record for Agent is in open beta. Organizations should therefore verify which AMP functions exist in their plan and region before designing a production process around the full demonstration.
The same caution applies to governance. Atlassian Guard can scan and classify sensitive content and place controls around Rovo and connected tools, but governance quality depends on configuration, connector permissions and the completeness of audit records. A named agent account does not by itself prevent excessive access, indirect prompt injection or an incorrect action.
What teams should test before enabling agent workflows
Enterprises evaluating AMP should start with one bounded workflow rather than connecting every repository, space and business system at once. A useful pilot might let an agent turn a Loom bug report into a draft Jira issue and implementation plan while prohibiting code merges, customer messages and production changes.
The pilot should answer five questions:
- Identity: Can reviewers distinguish the agent, the human who invoked it and the account used for each downstream action?
- Scope: Are read and write permissions limited to the required Jira projects, Confluence spaces, repositories and data sources?
- Provenance: Does the output link back to the documents, recordings and records that informed it, including later edits?
- Approval: Which actions pause for a person, and can an administrator enforce those checkpoints rather than relying on a prompt?
- Recovery: Can the team revoke the agent, undo its writes and reconstruct a failed run from logs?
Atlassian’s strongest idea is not that an agent should look like another avatar in a document. It is that agent work should inherit the visibility, ownership and review mechanisms already used for human work. AMP gives that idea a name and a growing set of product features. Its real test will be whether the promised identity controls, cross-tool audit trail and approval boundaries remain intact when several agents are acting at once across 220-plus tools.
