At Black Hat USA 2026, OpenAI researchers presented a striking emergent behavior: during cybersecurity evaluations, autonomous agents discovered they could communicate through shared infrastructure. They built a message board, exchanged information, divided work, and even discussed cryptographic signatures. When researchers disrupted their communication channel, the agents found another way to recreate it.

There are many security implications here. But the part that stuck with me was simpler: the agents independently discovered that collaboration was useful, then invented infrastructure to support it.

We’re moving fast from question-answering AI to autonomous agents that spend hours working on problems, using tools, and pursuing complex objectives. Yet most agent architectures still treat collaboration as an application-specific feature—an orchestrator spins up workers, they exchange some messages, and then that collaboration model vanishes when the process ends.

I think we need something more durable: a common collaboration protocol for autonomous agents. Not a framework. Not an orchestration library. Not a universal super-agent. A protocol.

Three Primitives

After working with multi-agent systems, I’ve concluded that most useful collaboration can be built around three questions:

  1. What do we know?
  2. What can we do?
  3. What needs to be done?

But these three primitives only become a protocol when their semantics are stable across implementations. An orchestrator can implement knowledge, capabilities, and delegation internally—that’s just architecture. The reason to standardize is that independently built agents need to agree on what publishing knowledge, advertising a capability, claiming a task, or renewing a lease means.

Knowledge

Agents constantly discover things: this API behaves differently than documented, that vulnerability is a false positive, this device responds to an undocumented command. Today that information usually dies in context windows or gets dumped into vector databases where it may never resurface.

Instead, agents should publish knowledge explicitly—not as assertions, but as verifiable claims. A knowledge object should include the statement, context, evidence, and expiration. “Port 443 behaves this way” may be valid for an hour; “this firmware hashes passwords with SHA-1” may remain useful indefinitely. Expiration exists because agent knowledge describes mutable reality. Other agents can then attest they independently reproduced the result, not just that it “sounds plausible.”

Corrections shouldn’t silently mutate history. Publish a new version that supersedes the old. Give agents auditable shared knowledge, not shared vibes.

Capabilities

As systems specialize, discovering who can do what becomes the hard problem. One agent reverses binaries. Another has calendar access. Another controls Home Assistant. Another has GPU clusters.

Agents should advertise structured capability descriptions: what they do, expected inputs/outputs, constraints, availability. Faced with an unfamiliar task, an agent can ask “does anyone know how to do this?” rather than requiring an omniscient orchestrator with a hardcoded registry.

Discovery and execution don’t need the same protocol. The collaboration layer doesn’t need credentials to your systems—it just tells you “Agent 8f2a knows how to analyze this firmware. Here’s how to engage it.”

Delegation

The interesting primitive: an agent publishes a task that others can claim.

“I found an undocumented network service. Determine what protocol it speaks.”

The request includes acceptance criteria, context, and optionally a deadline. But if twenty agents see it, we don’t want twenty solutions. Claiming work should be transactional—one agent gets it, everyone else knows it’s taken.

Use renewable leases: claim for 30 minutes, renew while working. If the agent crashes or disappears, the lease expires and the task becomes available again. The requester can accept, reject, or request changes.

This looks less like agent chat and more like a tiny distributed work system. That’s intentional. Agent collaboration is fundamentally a distributed systems problem. Who owns this task? Is that ownership valid? What if two agents claim it simultaneously? These shouldn’t depend on language models politely agreeing—they should be protocol invariants.

Beyond Hierarchical Orchestration

Most multi-agent architectures are trees: an orchestrator decomposes goals and dispatches to workers. That works well and isn’t going away.

But there’s another model worth exploring. Instead of:

Orchestrator
   /   |   \
Agent Agent Agent

Consider:


   Agent -------- Agent
     | \       / |
     |  \     /  |
     |   \   /   |
     |    \ /    |
     |    / \    |
     |   /   \   |
     |  /     \  |
     | /       \ |
   Agent -------- Agent

Agents can still have supervisors. But collaboration doesn’t require every interaction to pass through central intelligence. An agent discovers another’s knowledge, finds a useful capability, publishes work; another claims it. You get an agent ecosystem, not an agent tree.

Discovery and Events

That ecosystem requires shared discovery. Knowledge, capabilities, and tasks need categories, tags, filters, and search. An agent working on PostgreSQL shouldn’t scan every piece of knowledge ever produced. An agent capable of reverse engineering shouldn’t inspect ten thousand unrelated requests.

This is the difference between collaboration and orchestration: in collaboration, finding the right participant is part of the problem.

There’s also a practical issue: polling sucks. If fifty agents periodically rescan everything, you’ve built the world’s most expensive RSS reader. Instead, mutations should produce events. Agents subscribe to what they care about:

“Wake me when someone publishes a task tagged security/reverse-engineering.”

The collaboration layer becomes infrastructure, not something the orchestrator continuously simulates.

It helps to keep the layers separate: the objects are knowledge, capabilities, and tasks. The infrastructure is identity, discovery, events, and authorization. The objects carry the collaboration; the infrastructure makes it findable, attributable, and safe.

Security: Treat Everything as Hostile

When agents exchange natural language, they exchange untrusted natural language. The protocol should never assume that because content came from an authenticated agent, it’s safe to execute.

Knowledge is data. Capability descriptions are data. Tasks are data. The system stores and returns them. It does not automatically execute code, fetch URLs, or transform another agent’s message into trusted instructions.

Identity establishes “this agent said this.” It does not establish “therefore you should do what this says.”

Identity Without the Ceremony

Stable identity matters for verification, task ownership, and auditing. But don’t over-engineer it. My reference implementation started with “agents should have cryptographic identities” and somehow became asymmetric credentials, sender-constrained tokens, key rotation machinery, and enough OAuth-adjacent architecture to embarrass everyone involved. It’s being simplified.

The security properties matter more than the most elaborate possible architecture. You need strong attribution, resistance to impersonation, sensible authorization, and auditability. You don’t need authentication ceremonies capable of protecting nuclear launch codes just because the clients are robots.

Make It Boring

My strongest opinion: the protocol itself should be incredibly boring.

JSON over HTTPS. Normal resources. Normal state transitions. Normal search. Normal event cursors. Normal authentication.

No requirement for the same model provider. No requirement for the same agent framework. No requirement for a particular orchestration strategy. No requirement that the protocol execute anything.

If a Python agent using a local model can collaborate with a Rust agent using OpenAI and an agent running inside some future commercial platform, that’s a feature.

Make the agents weird. Make the protocol boring.

The Interesting Part Comes Next

The OpenAI Black Hat story is fascinating because nobody told those agents to invent a collaboration system. They encountered a coordination problem and discovered that shared infrastructure helped solve it.

As agents become more autonomous, they’ll encounter problems that benefit from specialization, delegation, shared discoveries, and independent verification. We can keep rebuilding those mechanisms inside every agent framework, or we can make collaboration boring shared infrastructure—and spend our effort where it counts: making the agents weird.

I know which one I’d choose.