At Atlassian Team in Europe, Jamil Valliani, VP Head of Product, AI at Atlassian, discusses AMP, the Agentic Multiplayer Protocol, with us. We go deep into this rather significant AI architecture announcement. AMP is not a formal specification; it is a collection of technologies, interface patterns, and governance mechanisms designed to define how humans and AI agents collaborate as a unified team inside the enterprise. As that still leaves many questions, we asked many of them during our conversation.
AMP stands for Agentic Multiplayer Protocol. Despite the word protocol, Valliani is clear that it is not a technical standard in the traditional sense. It is a collection of technologies and interface patterns that Atlassian has built over the past year. You can see it as a reflection of the way the company believes humans and AI will collaborate in teams of the future. AMP isn’t just one additional layer. Rather, it consists of multiple layers of the human-agent collaboration stack.
These layers deal with how context is shared. They also cover how agents surface as visible players inside product UIs, how they remain available across applications, and how their actions are governed. In addition, they manage agent visibility and action governance.
AMP is a layer on top of Teamwork Graph
Teamwork Graph is central to everything Atlassian does. So it’s no surprise that underlying piece of technology play an important role for AMP too. It is context layer that connects people, projects, and content across Jira, Confluence, and other products. With AMP on top of it, Teamwork Graph goes from being a single-player construct to one that is multi-player by design. That is, AMP extends it into multiplayer territory. Context is one of the three core pillars Valliani identifies. Every agentic team member inside an organization needs access to shared context. Furthermore, this must be provided with proper permissions and a full audit trail of what each agent accessed and when.
Identity, permissions, and governance
Identity management is also a central element of AMP. Agents operate under their own agent accounts, which appear in admin consoles alongside human accounts. Administrators can review an audit trail, suspend agent accounts, change permissions, or deny access to specific tools. This can all be done from a single control plane. Atlassian is also moving toward a least-privilege model for both humans and agents. Rather than granting elevated permissions by default, access is only granted when a human or agent can prove it is needed. For example, this can be done by referencing a valid Jira ticket.
Third-party agents as team members
AMP is not limited to Atlassian’s own Rovo AI. A major design goal is to allow agents from OpenAI, Anthropic, Cursor, Figma, and other third parties to operate on the Atlassian platform as first-class team members. Users can @mention Figma or Claude in a Confluence comment in the same way they would @mention Rovo. Underneath, standards like MCP and A2A continue to operate. AMP is not a replacement for those protocols. Rather, it’s a holistic layer on top of them that addresses context sharing, governance, and interaction patterns those lower-level specs do not cover.
Agent sessions and cross-platform knowledge capture
AMP can also capture agent sessions. When a Claude agent runs a bug fix on a developer’s laptop, even entirely outside the Atlassian platform, AMP can capture the traces and session context from that run. It then stores them in the Teamwork Graph. The session can then be associated with a Jira issue. This gives the rest of the team visibility into what the agent did and why. The non-human identity inventory extends this visibility further. In addition, admins can see all agents operating across all applications and take action if an agent behaves in undesirable ways.
Rovo Work: long-running agentic tasks
Apart from AMP, we also briefly dive into Rovo Work. This is a new mode within Rovo that allows users to hand the AI a large, multi-step project that might take a human weeks to complete. Rovo Work can even build its own tools to achieve its goals. When a project is submitted, Rovo Work first generates a detailed execution plan and shares it with the user for review. Once running, Rovo Work can operate as a dedicated agent account locked to the minimum permissions needed for that specific job. It sends progress notifications. Also, it signals when it needs additional guidance or when the task is complete.
Rovo Work is not exclusively a developer tool. Atlassian built it with knowledge workers in mind, with business model analysis cited by Valliani as a strong example use case.
AMP as a feedback loop into the Teamwork Graph
Because agent sessions are captured and stored in the Teamwork Graph, AMP creates a compounding knowledge loop, we hear from Valliani. Every task an agent completes becomes part of the shared organizational knowledge base. Therefore, future agents and humans can build on those learnings rather than rediscovering them.
What AMP means for organizational adoption
Valliani acknowledges that many organizations have deliberately slowed their AI adoption because they lack confidence in their ability to govern a growing fleet of agents. AMP is Atlassian’s answer to that hesitation. His practical advice for organizations getting started: revisit your AI policies, run agent inventories regularly, permit connectors incrementally, and use content filters to control what gets indexed. The governance layer AMP provides makes experimentation safer. Furthermore, it makes the eventual expansion of AI across the full organization far more achievable.
Also read: Atlassian takes Teamwork Graph off its leash for even more impact