Atlassian's Agentic Multiplayer Protocol for Small Teams

On 7 October 2026 Atlassian laid out what it calls the Agentic Multiplayer Protocol, or AMP: a framework for humans and AI agents sharing context and tasks across Jira and Confluence. Agents act "like employees" with identity, authority and scope assigned by an admin. A "Rovo Work" mode runs multi-step tasks autonomously, which humans then review and approve. Rovo Code Search ties the agent to the code, and a Loom video can be used as a prompt. The line from Atlassian's AI lead that stuck with everyone: "Headless software means brainless software."

It is the clearest statement yet from a large vendor that the unit of collaboration is changing. This post looks at what was announced, why the framing is right, where it leaves smaller teams, and what you can do this week without a Jira instance.

What Atlassian actually announced

Strip away the branding and AMP makes four claims:

1. Agents need an identity. Not a shared service account; a named participant with its own history and its own entry in the directory.
2. Agents need authority. A defined set of things they may do, granted by an admin rather than inferred from whoever is prompting them.
3. Agents need scope. A boundary — projects, spaces, repositories — outside which they do not act.
4. Autonomous work must end in human review. Rovo Work does the multi-step task; a person approves the outcome.

Everything else — Code Search, Loom-as-prompt, the integrations — is plumbing in service of those four.

"Agents as employees with scope" is the right idea

For the past two years, most teams have used coding agents as personal tools. Each developer has their own Claude Code or Codex session; the output lands in a branch and the team learns about it when the PR appears. That works for one person. It breaks the moment a team wants to delegate rather than operate: who asked the agent to do this? Under what constraints? Who checks it?

Treating an agent as a scoped employee answers those questions structurally rather than by convention. Identity makes work attributable. Authority makes it bounded. Scope keeps a mistake in one project from leaking into another. Review keeps a human accountable for what ships. None of this is new to anyone who has onboarded a contractor; what is new is applying it to software that can act.

The "headless means brainless" quip is pointed at a real failure mode. An agent with no window into the team's decisions, discussions and task state is guessing at intent from a ticket title. Giving it the shared context is not a nice-to-have; it is where most of the quality comes from. We made the same argument from the code side in our guide to AI codebase context.

Why this matters beyond Atlassian

Atlassian is not alone, and that is the point. Linear lets you delegate an issue to Claude Code, Codex, Cursor, Devin or Copilot as a contributor while the human stays assignee. Plane added Agent Runs and a native MCP server. Paperclip, open source and at roughly 50k GitHub stars since March, models agents as an org chart with budgets and approval stages. Sharkly and Nimbalyst built workspaces around local agents working in isolated worktrees under human review. OpenVisio Team gives agents a team role, channel and board scope, a plan-first step and a PR at the end.

When vendors with very different customers converge on the same shape — identity, authority, scope, review — it stops being a product choice and becomes the way the category works. If you are evaluating tools, that convergence is good news: the concepts transfer, and you can pick on fit rather than on philosophy. Our 2026 guide to shared workspaces compares the options against a common checklist.

Where it leaves a small team

AMP is built for Atlassian's customers, and Atlassian's customers are large. For a team of five to thirty, three things are worth weighing before you adopt it.

It comes with Jira. If you left Jira for Linear, Plane or a kanban board because the workflow engine was heavier than your process, AMP does not make it lighter. The governance model is admin-centred by design; in a small team the "admin" is one of the three engineers who also ship features.

The agent is Rovo first. The announcement is about Atlassian's agents operating inside Atlassian's products. Your developers already have Claude Code or Codex subscriptions and habits. Bringing your own runtime — and paying your own provider directly — is a different model from a hosted agent whose cost rides on the platform bill.

Timing. Enterprise rollouts take quarters. A small team can change its workflow on a Tuesday.

None of that makes AMP wrong. It makes it an enterprise answer to a question small teams also have. For a feature-by-feature view, see OpenVisio vs Atlassian Rovo.

What you can do today without Jira

Here is how the four AMP ideas map onto a small product-and-engineering team using OpenVisio Team and the agents its members already run.

The agent runs on your own machine through the openvisio-agent CLI on Claude Code, Codex, OpenCode, Gemini CLI or Qwen Code. BYO agents are included with each seat at $22 per member per month; see /pricing.

A one-week rollout

• Day 1: Create the team, invite people, link the main repository to a project.
• Day 2: Register one agent as Editor, scoped to one channel and one board. Connect it on one developer's machine and start the watcher.
• Day 3: Assign two well-written tickets (problem, expected behaviour, how to verify). Read the plans. Review the PRs.
• Day 4: Widen scope to a second channel so the agent can answer questions about the codebase in product discussions.
• Day 5: Retrospective. Which tickets needed a correction after the plan? Which PRs needed rework? Tighten the ticket template accordingly.

The step-by-step version is in how to assign tickets to Claude Code and Codex, and the guidance on keeping review proportionate is in human-in-the-loop for AI coding agents.

The bottom line

Atlassian has put a name and a reference architecture on something many teams were already assembling by hand. The principles — identity, authority, scope, review — are correct, and they will shape the category whether or not you use Jira. A small team does not have to wait for an enterprise rollout to adopt them. It needs a workspace where its own agents are visible, bounded members of the team, and a habit of writing tickets a teammate could act on. Start with the second; the first is one afternoon of setup.