Atlassian's AMP makes AI agents owned and audited participants in Jira and Confluence

An agent called from a Jira comment acts under one of two identities, according to Atlassian: the permissions of the user who called it, or a dedicated service account ^[7]. Either way, its actions go into an audit trail ^[8]. The two modes carry different risks. Running as the user makes authorization easy to trace, because the person who typed the @mention owns the act ^[3]. It also gives the agent everything that person can read and edit. A service account can be scoped to the job, but someone has to provision it and keep its grants current. Atlassian says every agent has a named owner and its own profile ^[6]. The owner field keeps a service account from becoming nobody's responsibility. I'd default to service accounts for any agent that writes, and accept user mode for agents that only read. That view assumes an organization where permissions have already sprawled. A five-person team with flat access loses little either way.

The most useful engineering in the release is also the smallest. Local agent sessions on developers' laptops can be surfaced on Jira boards, so colleagues who were not in the terminal can see progress ^[5]. Agents also appear beside people in presence indicators and cursors ^[6]. Neither feature needs a new standard. Both put agent state on a board the team already watches, and Atlassian owns that board.

Calling the package a protocol is generous. Atlassian's design material describes AMP as a collection of design patterns for human-agent collaboration ^[9]. The patterns are grouped under real-time and asynchronous collaboration, identity and shared presence, and context and governance ^[9]. Runtimewire, which reported the launch, found that the announcement describes capabilities across Atlassian's products ^[10]. In its reading, the public material does not establish AMP as an open standard that other vendors can implement independently ^[10]. The cross-vendor piece of the release is the updated Atlassian MCP Server. It connects these workflows to context in tools such as Figma and IDEs ^[4]. Outside context comes in through that server, while the identity, presence and audit features are Atlassian product capabilities ^[10].

The adoption figures Atlassian published also belong to the MCP Server. Atlassian said the server now counts just under 2 million monthly active users and handles upwards of 15 million tool calls each day, having grown 15-fold over six months ^[12]. Divided out, each monthly user averages more than 7.5 tool calls a day ^[16]. Runtimewire notes those figures describe MCP Server use, not AMP adoption ^[13]. The Teamwork Graph figure should be discounted the same way. Atlassian says the graph links more than 250 billion objects and relationships. Runtimewire calls that a company-reported scale measure and says it is not, by itself, evidence that agent decisions improve ^[11].

Atlassian also said its internal testing on Claude models showed the updated server finishing identical Jira and Confluence tasks with up to 25% fewer tokens ^[14]. For that number to apply elsewhere, a team would need to run Claude models on tasks like the ones Atlassian tested, and treat "up to" as the ceiling it is.

Inside Atlassian's suite, the owner, permission and audit model is consistent ^[6][7][8]. Runtimewire put the open question plainly: AMP's reach depends on product adoption and on whether its design patterns extend beyond Atlassian ^[15].