Atlassian AMP Explained: The Agentic Multiplayer Protocol and AI Agents as Teammates

TL;DR: AMP, the Agentic Multiplayer Protocol, is what Atlassian announced at Team '26 Europe in Amsterdam on October 7, 2026 to make AI agents named teammates in Jira, Confluence and Loom. Its core rule: "Every agent under AMP has a clear owner and distinct profile." Agents show up in presence bars, take @mentions, work from the Teamwork Graph (250+ billion objects), run under scoped permissions and leave an audit trail. Atlassian says humans and agents already work together more than 10 million times a month and its MCP server handles 15 million tool calls a day. Two caveats: AMP is not a published open specification that other vendors can implement, and dedicated agent accounts are still "coming soon," so for now many agent actions run as the person who started them. Below: how AMP works, what's shipped and what isn't, what admins should do now, and a permission model you can copy.

This is one of four deep dives that follow my overview, Agentic AI in October 2026: Agents Now Need Owners. The others cover OpenAI Dots, Oracle Fusion Claw and the agentic commerce trust gap.

What Is Atlassian AMP?

Atlassian calls AMP "the foundation for connected human-agent teamwork" [2]. In practice, it's a set of product rules and features that treat an AI agent the way Jira already treats a person: it has a profile, an owner, permissions and a history of what it did.

Co-founder Mike Cannon-Brookes summed up the bet: "We're betting that most teams will have people and agents working side by side" [2].

AMP has three layers [1][2][3]:

The Numbers

All of these are Atlassian's own figures [1][2]:

• Humans and agents work together more than 10 million times a month
• The Atlassian MCP server has nearly 2 million monthly active users and handles over 15 million tool calls a day, up 15x in six months
• The rebuilt MCP server uses up to 25% fewer tokens for the same Jira and Confluence work (internal benchmark on Claude models)
• The Teamwork Graph connects more than 250 billion objects and relationships, up from about 150 billion six months earlier [3]
• 80+ connectors, including new ones for Zoom, Gong, Microsoft Entra ID and Google Identity [2]

Why the Teamwork Graph Matters More Than AMP

The protocol gets the headlines, but the Teamwork Graph is what makes it valuable. It's the context layer: issues, docs, code, people, and now structured data and code down to the function, symbol and class level through the new Code Search app [2].

Steve McDowell's Forbes piece calls this Atlassian's move to own the context powering enterprise agentic AI [5]. The 25% token saving shows why. Agents spend most of their tokens looking for context, so whoever holds well-structured context makes every agent cheaper and more accurate. That holds whether the agent is Rovo, Claude, Cursor or Codex.

That's also why Atlassian opened the graph to outside agents. Its rebuilt MCP server has 200+ tools, governed by Atlassian Guard, and works with Cursor, Claude, VS Code and CLIs [2][3]. Agent runs from Rovo, Claude, Cursor or Codex link to Jira work items, and boards flag agents that are waiting on a human [3].

What's Shipped vs. What's Coming

This is where you need to read carefully [3][4]:

Two gaps matter most:

1. 01Not an open protocol. NAND Research notes that "despite the name, Atlassian has not published AMP as an open specification that other vendors can independently implement" [3]. Today, AMP is a set of Atlassian platform features.
2. 02Agent accounts aren't here yet. Atlassian's materials describe agents running as a user or under service accounts, and an inventory of non-human identities with a revoke switch [1][2]. But dedicated agent accounts were still described as "soon," with no date or pricing [4]. Until they ship, Rovo Work tasks inherit all the launching user's permissions and can look like that person's own edits [4].

The Permission Model, and Its Risk

Atlassian's own example explains the model: "An HR agent inherits the strict access of the person prompting it" [2]. Rovo only shows content the user can already see.

That's safe in one direction and risky in the other. If an agent can do whatever its user can do, every over-broad permission and stale space becomes a retrieval path for the agent [3][4]. People rarely notice an old Confluence space they can technically read. An agent that searches everything will find it.

The fix is to give the agent the intersection of the user's permissions and the agent's own scope, never the union. This runs with npx tsx amp-permissions.ts on Node 22+:

// amp-permissions.ts: run with `npx tsx amp-permissions.ts` (Node 22+)
// An agent acting for a person should get the intersection of what the
// person can do and what the agent is scoped to do, never the union.

type Permission = `${"read" | "write"}:${string}`;

interface Principal {
  id: string;
  kind: "human" | "agent";
  permissions: Set<Permission>;
}

interface Agent extends Principal {
  kind: "agent";
  owner: string;
}

function effectivePermissions(agent: Agent, invokedBy: Principal): Set<Permission> {
  return new Set([...agent.permissions].filter((p) => invokedBy.permissions.has(p)));
}

interface AuditEvent {
  actor: string;
  onBehalfOf: string;
  owner: string;
  action: Permission;
  allowed: boolean;
}

function attempt(agent: Agent, user: Principal, action: Permission, log: AuditEvent[]) {
  const allowed = effectivePermissions(agent, user).has(action);
  log.push({ actor: agent.id, onBehalfOf: user.id, owner: agent.owner, action, allowed });
}

const priya: Principal = {
  id: "priya (engineer)",
  kind: "human",
  permissions: new Set<Permission>(["read:jira/APP", "write:jira/APP", "read:confluence/eng"]),
};

const hrLead: Principal = {
  id: "maya (HR)",
  kind: "human",
  permissions: new Set<Permission>(["read:confluence/hr", "write:confluence/hr"]),
};

const triageAgent: Agent = {
  id: "agent:triage",
  kind: "agent",
  owner: "platform-team",
  permissions: new Set<Permission>(["read:jira/APP", "write:jira/APP", "read:confluence/hr"]),
};

const log: AuditEvent[] = [];
attempt(triageAgent, priya, "write:jira/APP", log);        // both allow it
attempt(triageAgent, priya, "read:confluence/hr", log);    // agent can, Priya can't
attempt(triageAgent, hrLead, "read:confluence/hr", log);   // both allow it
attempt(triageAgent, hrLead, "write:confluence/hr", log);  // Maya can, agent isn't scoped

console.table(log);

Output:

┌─────────┬────────────────┬────────────────────┬─────────────────┬───────────────────────┬─────────┐
│ (index) │ actor          │ onBehalfOf         │ owner           │ action                │ allowed │
├─────────┼────────────────┼────────────────────┼─────────────────┼───────────────────────┼─────────┤
│ 0       │ 'agent:triage' │ 'priya (engineer)' │ 'platform-team' │ 'write:jira/APP'      │ true    │
│ 1       │ 'agent:triage' │ 'priya (engineer)' │ 'platform-team' │ 'read:confluence/hr'  │ false   │
│ 2       │ 'agent:triage' │ 'maya (HR)'        │ 'platform-team' │ 'read:confluence/hr'  │ true    │
│ 3       │ 'agent:triage' │ 'maya (HR)'        │ 'platform-team' │ 'write:confluence/hr' │ false   │
└─────────┴────────────────┴────────────────────┴─────────────────┴───────────────────────┴─────────┘

Row 2 is the important one: the triage agent is scoped to read HR docs, but Priya can't, so the agent can't read them while acting for her. Row 4 is the other direction: Maya can edit HR docs, but the triage agent was never scoped to write there. Every row also records who owns the agent and who it acted for, which is the audit question AMP is built to answer.

What Admins Should Do Now

The Jira Guy's admin write-up gives a practical checklist [4]. My condensed version:

1. 01Inventory every non-human actor: automation rules, API tokens, connected apps and Studio-built Rovo agents. Record what each can reach, who owns it, why it exists and when it was last reviewed.
2. 02Clean up permissions and stale content before turning on agents, because Rovo surfaces whatever a user can technically see.
3. 03Restrict who can build agents. By default, anyone in the org can build Rovo agents in Studio.
4. 04Review connector and Artifact settings. An "open" Artifact is searchable by the whole organization.
5. 05Ask how Rovo credits work. Consumption billing starts December 3, and it isn't yet clear how long-running Work tasks are billed or whether a single task can be capped.
6. 06Check compliance coverage. In July, agent features weren't supported in HIPAA or FedRAMP environments.

How AMP Compares

NAND Research's competitive read [3]: Microsoft (Graph and Entra Agent ID) has broader reach but less engineering data. ServiceNow is strong in IT governance but weaker in software development. Salesforce owns sales and service, and GitHub Copilot is closest to code. Atlassian is strongest where Jira and Confluence are already the system of record.

Atlassian also isn't tied to one model provider. OpenAI's GPT-6 models power Rovo agents, Claude is available in Rovo, and both ChatGPT and Claude connect to Atlassian data through MCP [3].

My Take

AMP is mostly a product strategy described as a protocol, and that's fine. The ideas are right: every agent has an owner, agents show up where the work is, human and agent edits are separated, and permissions are scoped. Most companies building internal agents should copy these rules whether or not they use Atlassian.

What will decide AMP's value is the part that hasn't shipped: dedicated agent accounts. Until agents have their own identities, "the agent did it" and "Priya did it" look the same in the logs. If you run Jira at scale, do the permission cleanup now. It pays off whether agent accounts arrive next month or next year.

For how AMP fits with OpenAI Dots, Oracle Fusion Claw and SAP, read the agentic AI October 2026 overview. If you're building on MCP yourself, my Model Context Protocol developer guide covers the server side.

References

1. 01Atlassian via Business Wire, "Atlassian Introduces AMP: The Agentic Multiplayer Protocol to Power Human-AI Collaboration," October 7, 2026. financialcontent.com
2. 02Atlassian, "The End of Single-Player AI" (Team '26 Europe founder update). atlassian.com
3. 03NAND Research, "Atlassian AMP: Making Governed AI Agents Part of the Team." nand-research.com
4. 04The Jira Guy, "Team '26 Europe: What AMP Means for Admins," October 7, 2026. thejiraguy.com
5. 05Steve McDowell, "Atlassian's Move To Own The Context Powering Enterprise Agentic AI," Forbes, October 9, 2026. forbes.com
6. 06Forbes, Agentic AI topic page. forbes.com/topics/agentic-ai

Harsh Rastogi is an AI Product Engineer at Modelia, building production generative-AI systems for fashion commerce, and the creator of carcode. He writes about AI systems, developer tooling and production engineering at harshrastogi.tech.