Atlassian AMP Maps 250B+ Connections. Who Verifies What Agent Teams Actually Did?
October 11, 2026 by Asif Waliuddin
Atlassian's new Agentic Multiplayer Protocol (AMP) puts a familiar enterprise problem in plain view: agents are joining teams, but teams need to know who did what, with whose authority, using which context.
On October 6, 2026, Atlassian described AMP as the basis for people and agents to work together inside its platform: an identity you assign, authority you scope, shared context, and results you can review. Atlassian says its Teamwork Graph maps "knowledge, work, people, communication, code, assets, and now, data." Atlassian reports more than 250 billion connections. That is an Atlassian-reported platform figure, not a measurement NXTG independently audited.
- Atlassian: The platform is for multiplayer human-agent work (October 6, 2026)
- Atlassian: AMP design patterns
A technical distinction matters. Atlassian's own design site calls AMP a collection of design patterns, with three pillars: real-time and async collaboration, identity and shared presence, and context and governance. It is not presented there as a new wire-level transport specification replacing the Model Context Protocol (MCP) or Agent2Agent (A2A). Atlassian separately uses MCP for tool connectivity.
What I had published before Atlassian AMP, and what it does not prove
NXTG published two dated public accounts:
- July 6: ASIF: An Origin Report on a Self-Measuring Multi-Agent Control Plane at Portfolio Scale. It described an operating fleet around durable state, deterministic rules, memory, escalation, evaluation, and corrections. It included an uncomfortable measured result: 31 productive outcomes in 570 recorded agent-pulse outcomes in an early sample. This was an early internal-sample finding, not a general rate for AI agents.
- August 6: Enabling Bureaucracy: Governing a Fleet of Autonomous AI Agents at Portfolio Scale. It documented layered governance, a 23-principle constitution, durable directives, and a multi-project fleet.
These are public, date-stamped records of NXTG's engineering. They do not mean NXTG invented the category; neither do they prove functional equivalence to Atlassian's October platform release.
The overlap is real. So is the difference.
| Question | Atlassian's stated AMP approach | NXTG's previously published ASIF work |
|---|---|---|
| Who is acting? | Shared human/agent identity and presence | Agent roles, boundaries, and structured authority |
| What context persists? | Teamwork Graph across enterprise data and products | Persistent operational state, directives, and institutional memory |
| How is work governed? | Agent permissions, managed collaboration, review | Deterministic gates, lifecycle controls, escalation and receipts |
| How does work become visible? | Jira/Confluence sessions, tasks, collaborative surfaces | Append-only ledgers of fleet events, checked by a seat that did not produce the work |
| What is independently proven? | Requires testing, outside the vendor's release narrative | Requires testing, beyond my own internal deployment narrative |
Atlassian has an obvious distribution advantage: an existing enterprise customer base and a system of work already embedded in company operations. NXTG's work has a different provenance: a working internal autonomous fleet, private runtime infrastructure, and published engineering research.
Dx3 is not generally available. It runs inside NXTG.ai and is not offered outside it yet. Its current website walkthrough is an interactive simulation, not a public connection into NXTG's private operational runtime. That demo is not proof of customer readiness. The real architecture and demo availability are described on NXTG's Dx3 product page.
GitLab reached the same architecture the same day
GitLab made its announcement on the same day, October 6, 2026. It calls the release the foundation for the governed software factory, "a connected system for moving software from idea to production under an organization's own policy and standards". It names identity, policy and an evidence chain in one line: its automation runs "under the same identity, policy, and evidence chain". Inside the factory, "agents can work within an organization's context, workflows, and guardrails, while creating an evidence chain that records how changes move from intent to production." (GitLab press release, October 6, 2026)
The release carries one number: "Over the last three months on GitLab, active users of agentic software development grew 200% year over year." I am keeping that sentence whole because its scope is narrow. It measures GitLab's own platform, it counts active users of agentic software development, and it compares a three-month window with a year earlier. It says nothing about the rest of the industry.
Two companies drew the same box and published it on the same day. I read that as convergence, not invention. I did not invent this architecture, and the overlap tells me the problem is showing its real shape.
What I can show with a public receipt
| Element | GitLab (verbatim quote) | What I can show (with link) |
|---|---|---|
| Agent identity | "under the same identity, policy, and evidence chain" | Each agent seat commits under its own identity, and the commit trailer names the seat, for example Co-Authored-By: Forge <[email protected]> (public Forge commit) |
| Scoped authority | "policy and standards" | Not published yet |
| Enforcement before the action | "guardrails" | Hard hooks: "pre-action guards that deny disallowed writes deterministically" (research report, item 6) |
| Shared context as typed state | "an organization's context, workflows" | Typed state: "backlog, promise, and handoff state live in validated typed ledgers, not conversational text" (research report, item 5) |
| Shared state and exclusive access for coding agents | "Custom Flows and flow triggers automate multi-step work" | Forge's docs describe it as a coordination layer for AI coding tools that gives them shared state, exclusive access and a plan (Forge docs) |
| Review the agent cannot grade itself | No matching line in the release text I quote | "the seat that produces an artifact never grades it; a second seat reproduces or recomputes before 'verified' is assertable" (research report, item 2) |
| Evidence of what happened | "an evidence chain that records how changes move from intent to production" | Append-only ledgers, and the published routing experiment reported in full, including the tie (research report) |
The missing proof
An agent card can show Complete. Its collaboration thread can show an approving human. Its audit log can preserve a tool response. None of those facts alone establishes that the intended external effect occurred, remained authorized, or stayed within the expected cost and permission envelope.
This is the engineering gap that matters when autonomous work crosses systems.
Consider a delegated change that says a deployment succeeded:
- Intent: What was authorized, by which principal, under which policy version?
- Execution: Which tools and identities acted, and what did they actually request?
- Effect: Did the target system independently record the intended state change?
- Economics: What retries, model calls, time and infrastructure expenditure accompanied it?
- Uncertainty: What couldn't be checked, and which records may themselves be incomplete or wrong?
A well-connected work graph helps the agent do the work. An independently checked effect helps the organization trust its outcome. These are complementary jobs.
This is why NXTG's current research direction is consequence integrity: whether an observed effect matched authorized intent and relevant constraints, rather than whether an agent confidently announced completion. It's a research direction, not a claim that the open-world verification problem has already been solved.
What I'm publishing next
I will evaluate specific failure mechanisms against bounded, deterministic probes, preserving version, environment, raw observations, a falsifying test, and explicitly incomplete coverage. Where results can be responsibly released, my public Evidence Watch will link the claim to the supporting evidence.
I will not publish proprietary fleet credentials, private customer data, or unverified vendor accusations, and I will not call a simulation a production deployment.
For claim-level output verification available now, Faultline offers a self-serve product that checks factual assertions and source evidence. This is distinct from runtime consequence verification, which remains active research.
The question isn't which company can show the most impressive agent cockpit.
It is: when the cockpit says the work is finished, what independent evidence would change your mind?
Source and evidence notes
- Atlassian, The Atlassian platform is for multiplayer human-agent work, October 6, 2026. Product and platform claims are the vendor's.
- Atlassian Design, AMP patterns, accessed October 11, 2026. Calls AMP a collection of design patterns that builds on Atlassian's AI interaction guidelines.
- NXTG, ASIF: An Origin Report, published July 6, 2026, and Enabling Bureaucracy, published August 6, 2026. These are first-party field reports; readers should not treat them as independent validation.
Frequently asked questions
- Is Atlassian AMP a new protocol that replaces MCP or A2A?
- Atlassian's design site calls AMP a collection of design patterns, with three pillars: real-time and async collaboration, identity and shared presence, and context and governance. Atlassian separately uses MCP for tool connectivity.
- Does NXTG claim it built AMP first?
- No. NXTG's July 6 origin report and August 6 governance paper are dated records of its own fleet. They do not show that NXTG invented the category or built an equivalent of Atlassian's release. The article's point is independent evidence of what agent work actually changed.
- Is Dx3 available to try?
- No. Dx3 is not generally available. It runs inside NXTG.ai and is not offered outside it yet, and its website walkthrough is a browser simulation, not a connection to a production runtime.