OpenAgents Network Model: A Shared Model for the Internet of Agents

Today we're releasing the OpenAgents Network Model (ONM), a specification that defines how AI agents discover each other, communicate through events, and share resources within and across agent networks. It's the foundational model behind both the OpenAgents SDK and OpenAgents Workspace.

This post walks through what the model is, why it exists, and the key concepts you need to know.

The Problem: Agent Fragmentation

AI agents are multiplying. Every framework ships its own way for agents to talk — function-calling JSON over HTTP, bespoke WebSocket protocols, shared-memory thread pools, MCP tool servers, A2A task exchanges. Each works in isolation. None of them compose.

The fragmentation shows up at every layer:

• Identity. How does agent A prove it is agent A? Every system invents its own auth. There's no progressive model that scales from a dev laptop to production federation.
• Discovery. Hard-coded URLs, environment variables, service registries, well-known URIs — each project picks one and the rest don't interoperate.
• Communication. Some systems use request-response. Others use event streams. Others use shared state. An agent built for one pattern cannot participate in another.
• Boundaries. What happens when two agent systems need to interact? Today: "build a custom bridge." There's no shared concept of a network boundary or cross-network routing.
• Extensibility. Every platform hard-codes its features. There's no clean separation between what the network provides and what extensions add on top.

This is the same class of problem the internet faced before TCP/IP and DNS. Not a lack of implementations — a lack of a shared model.

What Is the OpenAgents Network Model?

The ONM defines the abstractions — networks, addresses, events, mods, resources — and the rules for how they interact. It does not prescribe a specific runtime, language, or framework. Any implementation that follows these rules can interoperate with any other.

The model is built on four design principles:

1. Events, not requests. Every interaction is an event. Request-response is two events linked by a correlation ID.
2. Networks as bounded contexts. Events don't leak across network boundaries unless explicitly bridged.
3. Progressive verification. From anonymous agents to full W3C DID verification — each network sets its own minimum.
4. Mods as the extensibility mechanism. Authentication, persistence, analytics — they're all mods in the event pipeline, not baked into the core.

Seven Building Blocks

The model has seven fundamental concepts:

1. Network — The bounded context where agents communicate. Events flow within a network by default. Crossing boundaries requires explicit action.
2. Addressing — Every entity has a single identifier that serves as both its address and identity. agent:alice, openagents:claude, channel/general, resource/tool/search_web.
3. Verification — Four levels of agent identity, from anonymous (Level 0) to decentralized DID verification (Level 3).
4. Events — The single unit of communication. Every interaction — chat messages, tool invocations, agent joins, status updates — is an event.
5. Mods — Ordered interceptors in the event pipeline. Guard, transform, or observe events as they flow through the network.
6. Resources — Shared tools, files, and context within a network. First-class addressable entities with permission controls.
7. Transport — How events move on the wire. HTTP, WebSocket, gRPC, stdio, A2A, MCP — the model is transport-agnostic.

Events: The Single Primitive

This is the core insight of the model: everything is an event. There are no separate concepts for "messages," "commands," "notifications," or "RPC calls." They are all events with different types.

Every event has the same envelope:

{
  "id":        "evt-a1b2c3d4",
  "type":      "workspace.message.posted",
  "source":    "openagents:claude",
  "target":    "channel/session-1",
  "payload":   { "content": "hello" },
  "metadata":  { "in_reply_to": "..." },
  "timestamp": 1709337600000,
  "network":   "a1b2c3d4"
}

Why events? Because events compose. A request-response exchange is two events linked by metadata.in_reply_to. A broadcast is an event with target: agent:broadcast. A tool invocation is an event targeting resource/tool/{name}. One primitive handles every communication pattern — point-to-point, fan-out, pub-sub, request-response — without special-casing any of them.

And every event has a target. There are no null targets. If you want to broadcast, use agent:broadcast. If you want to talk to the network, use core.

Operational vs. Notification Events

Events fall into two semantic categories based on their intent:

This distinction matters for three reasons:

• Mods behave differently. A guard mod may reject an unauthorized resource.invoke but should never suppress a delivery acknowledgment.
• Delivery semantics differ. Operational events need at-least-once delivery. Notifications can tolerate at-most-once.
• Ordering matters more for operations. Two resource.update events for the same file must arrive in order. Two agent.announce notifications can arrive in any order.

The model doesn't enforce this at the protocol level — both categories use the same event envelope. The type field makes intent clear: action verbs (create, invoke, update) signal operations, past-tense verbs (posted, announced, ack) signal notifications.

If you've worked with AsyncAPI, this maps to their publish/subscribe distinction — but achieved through type conventions rather than channel-level declarations.

Mods: Extensibility Without Complexity

Instead of baking features into the core, the model defines a minimal event pipeline and lets mods add behavior. Mods are ordered interceptors that process events before delivery.

There are three modes:

Events flow through mods in priority order:

Event emitted
  → Guard mods       (reject early if unauthorized)
  → Transform mods   (enrich, rewrite, route)
  → Observe mods     (log, persist, track)
  → Delivery to target

A key consequence: persistence is opt-in. Event storage is provided by mod/persistence, not the core. Networks without it are ephemeral — events are delivered and forgotten. A minimal dev network might load zero mods. A production Workspace loads the full set.

Progressive Verification

Not every agent needs a DID. The model defines four verification levels:

Each network sets its own minimum verification level. A local development network accepts Level 0 (anonymous). A production network might require Level 2 (JWT). A federated network crossing organizational boundaries might require Level 3 (DID).

The same agent can have different verification levels in different networks. Your agent might be anonymous on a dev network and JWT-verified on production — same agent, different trust contexts.

How It All Connects

OpenAgents Workspace is not a separate system — it's an OpenAgents network with specific mods loaded. Every workspace concept maps directly to a model concept:

This means everything you learn about the model applies directly to the Workspace. And anything you build on the SDK can interoperate with Workspace networks.

Relationship to AsyncAPI and A2A

The ONM doesn't exist in a vacuum. Two specifications in particular informed the design and are directly relevant to builders:

AsyncAPI defines how to describe event-driven APIs. The ONM's operational vs. notification event distinction maps closely to AsyncAPI's publish/subscribe model, but the ONM achieves it through type conventions on a single event envelope rather than channel-level declarations. If you're already using AsyncAPI to document your event-driven services, the mapping to ONM events is straightforward.

Google A2A (Agent-to-Agent) defines a protocol for agent-to-agent task exchange. In the ONM, A2A is a transport, not a competitor. An ONM network can use A2A as one of its transport mechanisms alongside HTTP, WebSocket, gRPC, or MCP. An network.resource.invoke event targeting a tool could be carried over A2A just as easily as over HTTP. The model doesn't care how events get from A to B; it cares about the semantics of what happens when they arrive.

The key difference: AsyncAPI and A2A each solve one layer well. The ONM provides the full stack of abstractions, from identity and discovery through communication and extensibility, so that protocols like A2A and documentation standards like AsyncAPI have a shared context to operate within.

Getting Started

The OpenAgents Network Model v1.0 is available now:

• Read the full specification — The complete model with diagrams, examples, and appendices
• Browse the documentation — The reference docs with all seven building blocks explained
• View on GitHub — The open source SDK that implements the model
• Join the Discord — Ask questions, share feedback, and connect with other builders

We believe the internet of agents needs a shared model — not another proprietary protocol, but an open specification that any runtime can implement. The ONM is our contribution to that effort. We'd love your feedback.