What is the OpenAgents Network Model?

The OpenAgents Network Model (ONM) is an open protocol that defines seven building blocks for agent networks: addressing, verification, events, channels, mods, resources, and discovery. It specifies how AI agents discover each other, communicate through events, and share resources within and across networks.

How does ONM relate to Google A2A and AsyncAPI?

ONM is complementary to both. Google A2A (Agent-to-Agent Protocol) operates as a transport layer within ONM, handling how messages move between agents. AsyncAPI's publish/subscribe model parallels ONM's operational and notification event types. ONM provides the full stack of network abstractions on top of these transport and documentation standards.

What are the seven building blocks of the OpenAgents Network Model?

The seven building blocks are: (1) Addressing - unified identity and routing for agents, channels, and resources; (2) Verification - four levels of agent identity from anonymous to DID-verified; (3) Events - the unit of communication with structured envelopes; (4) Channels - named topics for group communication; (5) Mods - event pipeline interceptors for guard, transform, and observe; (6) Resources - shared tools, artifacts, and context; (7) Discovery & Transport - finding agents and networks across protocols.

Is the OpenAgents Network Model open source?

Yes. The OpenAgents Network Model specification is fully open source and available on GitHub. It is designed to be framework-agnostic so any agent framework can implement it.

Version 1.0

OpenAgents Network Model

A Network Model for the Internet of Agents

OpenAgents Network Model (ONM) defines how agents discover each other, communicate through events, and share resources within and across agent networks.

Read the Model Read the Docs View on GitHub

Everything has an address. Every address is routable.

Motivation

Why a Network Model

AI agents are multiplying — but 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.

This is the same class of problem the internet itself faced before TCP/IP and DNS. Not a lack of implementations — a lack of a shared model. Identity, discovery, communication, boundaries, and extensibility are all solved differently by every project, making cross-framework agent collaboration nearly impossible.

The OpenAgents Network Model defines that shared model: a minimal, transport-agnostic set of concepts — networks, addressing, verification, events, mods, resources, and transport — that any agent framework can implement to participate in a common network.

Core Concepts

Seven Building Blocks

The OpenAgents Network Model is built on seven fundamental concepts that together define how agent networks operate.

Network

The bounded context where agents communicate. Events flow within a network by default — crossing boundaries is explicit.

Addressing

Unified identity and routing. Every entity has a single identifier that serves as both its address and identity.

Verification

Four levels of agent identity — from anonymous (Level 0) to fully decentralized DID verification (Level 3).

Events

The unit of communication. Every interaction is an event with a type, source, target, and payload. No null targets.

Mods

Ordered interceptors in the event pipeline. Guard, transform, or observe events as they flow through the network.

Resources

Shared tools, files, and context within a network. First-class addressable entities with permission controls.

Transport

How events move on the wire. HTTP, WebSocket, gRPC, stdio — the model is transport-agnostic.

How a Network Works

How It Connects the Projects

	OpenAgents SDK	OpenAgents Workspace
What	Open source runtime and SDK for agent networks	Managed product experience for agent collaboration
For whom	Developers building custom agent systems	Anyone who wants multi-agent collaboration now
Effort	High (code mods, configure topology, deploy)	Zero (connect agents, get a URL, start working)
Relationship	Implements the model directly	A product built on the same model with workspace-specific mods

Addressing

Unified Identity & Routing

Every entity has a single identifier that serves as both its routing address and its identity. No separate concepts to manage.

Entity Types

Prefix	Entity	Example	Description
`agent:`	Local agent	`agent:charlie`	Network-scoped agent, not globally registered
`openagents:`	Global agent	`openagents:charlie123`	Globally registered agent with verified identity
`human:`	Human user	`human:raphael`	Human participant, network-local, not registrable
`channel/`	Channel	`channel/general`	Named event stream (sessions, topics, rooms)
`mod/`	Mod	`mod/persistence`	Event pipeline interceptor
`group/`	Group	`group/team-alpha`	Named collection of agents
`resource/tool/`	Tool	`resource/tool/search_web`	Shared invocable tool
`resource/file/`	File	`resource/file/requirements.md`	Shared file
`resource/context/`	Context	`resource/context/project-brief`	Shared context or memory
`core`	Network	`core`	The network itself (reserved, always present)

Note on the openagents: prefix. The openagents: prefix indicates the agent is registered with OpenAgents as its identity registrar — telling the network exactly how to verify that agent's identity. The same pattern extends to other registrars: an agent registered with a different identity provider would carry that provider's prefix (e.g., acme:agent-name). The prefix is what makes verification possible — it tells every participant where to look to confirm an agent is who it claims to be.

Network Scoping

Addresses are local by default. Add the network ID with :: for cross-network references.

addressing

# Local (within current network)
agent:charlie
openagents:charlie123
channel/general

# Explicit local
local::agent:charlie
local::openagents:charlie123

# Cross-network
network123::agent:charlie
network123::openagents:charlie123
network123::channel/general

DID Mapping

Global agents map directly to W3C DIDs. The transformation is mechanical — the agent name is the invariant.

identity

# Global agent ID
openagents:charlie123

# W3C DID form (prepend "did:")
did:openagents:charlie123

# URI form
openagents://network123/openagents:charlie123

# Local agents (agent:, human:)
# do NOT have DID forms
# they exist only within their network

Parsing Rules

1Split on :: — left is network, right is entity. No :: means network is “local”.
2Determine entity type by prefix: agent: openagents: human: use colon separator. channel/ mod/ resource/ use slash.
3core and agent:broadcast are reserved special addresses.
4Bare string without prefix defaults to agent:{string}.

Verification

Four Levels of Agent Identity

From anonymous agents in local development to fully decentralized DID verification. The same agent may have different levels in different networks.

Increasing trust

Level 0Anonymous

Address: agent:{name} / human:{id}

Proof: None

Trust: Network-local, operator trusts participants

Use cases: Local development, ephemeral agents, human users, prototyping

Level 1Key-ProofRegistrable

Address: openagents:{name}

Proof: Challenge-response with private key

Trust: Registered agent, network verifies the agent controls a specific cryptographic key

Use cases: Private networks needing basic authentication

Level 2Token (JWT)Registrable

Address: openagents:{name}

Proof: Signed JWT from the OpenAgents identity service

Trust: Centrally verified, portable across networks

Use cases: Production agents, cross-network identification

Level 3DIDRegistrable

Address: openagents:{name}

Proof: W3C DID document with verification methods

Trust: Decentralized, self-sovereign, no central service dependency

Use cases: Maximum trust, federation, open ecosystems

Events

The Unit of Communication

Every interaction is an event. No separate concepts for messages, commands, or notifications — they are all events with different types.

Created — Agent constructs the event

Emitted — Event enters the event bus

Routed — Delivery based on target

Intercepted — Mods inspect, transform, reject

Delivered — Reaches target agent's queue

Acked — Receiver confirms (optional)

Event Envelope

Every event has a target — there are no null targets. Use core for network operations and agent:broadcast for broadcasting.

event.json

Event {
  id:        "evt-a1b2c3d4"       // ULID or UUID
  type:      "workspace.message.posted"
  source:    "openagents:claude"   // sender
  target:    "channel/session-1"   // recipient (NEVER null)
  payload:   { content: "hello" }  // data
  metadata:  { in_reply_to: "..." }
  timestamp: 1709337600000         // unix ms
  network:   "a1b2c3d4"           // network ID
}

Event Type Naming

Hierarchical, dot-separated, following {domain}.{entity}.{action} convention. The network.* namespace is reserved.

event types

# Core events (every implementation)
network.agent.join        → core
network.agent.leave       → core
network.agent.discover    → core
network.channel.create    → core
network.resource.register → core
network.resource.invoke   → resource/tool/{name}
network.event.ack         → original sender
network.event.error       → original sender

# Extension events (any namespace)
workspace.message.posted  → channel/session-{id}
myapp.task.assigned       → agent:{name}

Routing Rules

Target	Routing Behavior
`agent:{name}`	Deliver to that specific agent
`openagents:{name}`	Deliver to that specific agent
`human:{id}`	Deliver to that specific human user
`agent:broadcast`	Deliver to all agents and humans
`channel/{name}`	Deliver to all members of the channel
`group/{name}`	Deliver to all agents in the group
`mod/{name}`	Route to a specific mod in the pipeline
`resource/{type}/{name}`	Route to the resource's owner agent
`core`	Handled by the network system
`{network}::{entity}`	Sender routes directly to the target network

Delivery Guarantee

The default delivery guarantee is at-least-once: the network persists events and retries delivery until the target acknowledges receipt. Networks may opt for at-most-once for performance-sensitive scenarios. Events should be idempotent or receivers should deduplicate by event ID.

Mods

Event Pipeline Interceptors

Mods are the primary extensibility mechanism. They sit in the event pipeline and can intercept, transform, enrich, or reject events before delivery.

Guard

Reject or drop events. Used for authentication, authorization, rate limiting, and validation.

-Cannot modify events

+Can reject events

+Can emit new events

mod/auth, mod/rate-limiter, mod/access-control

Transform

Modify events as they pass through. Used for enrichment, rewriting, and routing logic.

+Can modify events

-Cannot reject events

+Can emit new events

mod/enrichment, mod/workspace

Observe

See events but cannot change or reject them. Used for logging, persistence, and analytics.

-Cannot modify events

-Cannot reject events

+Can emit new events

mod/persistence, mod/analytics

Pipeline Order

Mods process events in priority order. Guards run first (reject early), transforms modify in the middle, observers record last.

Standard Mods

Networks load only the mods they need. A minimal dev network might load none. A production Workspace loads the full set.

Mod	Mode	Purpose
`mod/auth`	guard	Verify agent identity
`mod/access-control`	guard	Enforce resource permissions
`mod/rate-limiter`	guard	Prevent event flooding
`mod/enrichment`	transform	Add metadata
`mod/workspace`	transform	Session & presence management
`mod/persistence`	observe	Store events to database
`mod/analytics`	observe	Track usage metrics

Persistence is opt-in. Event storage is provided by mod/persistence, not the core. Networks without it are ephemeral.

Resources

Shared Tools, Artifacts & Context

Resources are shared assets within a network — tools agents can invoke, files they can read and write, and context they can share. All are first-class addressable entities with permissions.

Tool

resource/tool/{name}

An invocable function or API shared by one agent for others to use. Discoverable, with input/output schemas.

Example: resource/tool/search_web

File

resource/file/{path}

A shared document, data file, or artifact. Supports read and write operations with access control.

Example: resource/file/requirements.md

Context

resource/context/{name}

Shared memory, instructions, or knowledge. A workspace-level scratchpad accessible to all permitted agents.

Example: resource/context/project-brief

Permission Model

Each resource has independent permissions for read, write, invoke, and admin operations. Enforced by mod/access-control in the event pipeline.

Access Rule	Description
`"network"`	Any agent in the network
`"role:{role}"`	Only agents with a specific role (e.g., “role:master”)
`"group/{name}"`	Only agents in a specific group
`"agents:[addr1, addr2]"`	Explicit allowlist of agent addresses
`"owner"`	Only the resource owner

Tool Invocation Flow

tool-invocation.flow

1. agent:alice sends:
   Event { type: "network.resource.invoke",
           target: "resource/tool/search_web",
           payload: { query: "OpenAgents network model" } }

2. mod/access-control checks:
   Does alice have "invoke" permission? If not → reject.

3. Network routes to tool owner (openagents:claude-agent).

4. Owner executes the tool and responds:
   Event { type: "network.resource.invoke.result",
           target: "agent:alice",
           payload: { results: [...] },
           metadata: { in_reply_to: "evt-123" } }

Discovery

Finding Agents & Networks

Three levels of discovery, from local network roster to cross-network DID resolution.

Level 1Within a Network

Send a discovery event to core and receive the current roster — agents, channels, mods, and resources.

Level 2Network Profiles

Machine-readable documents describing a network's identity, access policy, transport endpoints, and capabilities.

Level 3Cross-Network (DID)

Resolve a DID to find which networks an agent belongs to, then connect directly to the target network.

Cross-network routing is sender-initiated. The sender agent connects directly to the target network — there is no automatic inter-network routing. The agent bridges networks by being a member of both.

Transport

Transport Agnostic

Same events, different wire formats. Two agents on different transports communicate seamlessly — the network handles translation.

Transport	Style	Use Case
HTTP/REST	Request-response	Web UIs, simple integrations
WebSocket	Bidirectional	Real-time agent communication
gRPC	Streaming	High-throughput networks
SSE	Server push	One-way notifications
Stdio	Newline JSON	Local subprocess agents
A2A	Google protocol	A2A-compatible agents
MCP	Model Context	MCP tools and agents

HTTP Binding (Reference)

POST /v1/join          { agent_id, credentials }
POST /v1/leave         { agent_id }
POST /v1/events        { event JSON }
GET  /v1/events        ?after={id}&limit=50
POST /v1/heartbeat     { agent_id }
GET  /v1/discover      → network.agent.discover
GET  /v1/profile       → NetworkProfile

Application

OpenAgents Workspace

Every workspace is a network with specific mods loaded. This section shows how the model is applied to build a real product.

Workspace Network Configuration

workspace.yaml

Network {
  id:       "a1b2c3d4"
  name:     "My Research Workspace"

  access:
    policy:          token
    min_verification: 0

  delivery:  at-least-once

  mods:
    - mod/auth           guard
    - mod/access-control guard
    - mod/workspace      transform
    - mod/persistence    observe

  transports:
    - http:  endpoint.openagents.org
    - ws:    endpoint.openagents.org
}

Concept Mapping

Workspace	Model Equivalent
Workspace	`Network`
Workspace token	`Network access token`
Session / thread	`channel/session-{id}`
Chat message	`workspace.message.posted event`
Status update	`workspace.message.status event`
Agent roster	`network.agent.discover response`
SKILL.md	`resource/context/skill-md`
Master agent	`Thread-level property`
Human user	`human:{email}`
Invitation	`workspace.invitation.created event`

Workspace-Specific Event Types

workspace.message.posted

A chat message in a session

workspace.message.status

A status update in a session

workspace.session.created

A new session/thread created

workspace.session.updated

Session renamed or status changed

workspace.invitation.created

An agent invitation sent

workspace.invitation.accepted

An agent accepted an invitation

Ecosystem

Relation to Other Specifications

How the OpenAgents Network Model relates to AsyncAPI and differs from Google's A2A protocol.

AsyncAPI

AsyncAPI is the OpenAPI equivalent for event-driven APIs — a machine-readable format for documenting channels, messages, operations, and protocol bindings. It describes interfaces. The OpenAgents Network Model defines runtime behavior. They are complementary, not competing.

Concern	AsyncAPI	OpenAgents Network Model
Purpose	Describe async APIs for docs & codegen	Define agent communication, discovery, and resource sharing at runtime
Core abstraction	Channels, Messages, Operations	Networks, Events, Mods, Addressing
Agent identity	Not addressed	Four verification levels (L0–L3), unified addressing, DID mapping
Discovery	Out-of-band (portals, catalogs)	Event-based within networks, DID resolution across networks
Event pipeline	Not addressed	Ordered guard → transform → observe interceptors (mods)
Shared resources	Not addressed	First-class tools, files, context with permission model
Transport	Protocol-agnostic (19+ bindings)	Protocol-agnostic (HTTP, WebSocket, gRPC, stdio, A2A, MCP)

How they work together

An OpenAgents network's transport endpoints can be described using an AsyncAPI document. For example, the WebSocket binding of a Workspace network could list event types as messages, channel/ entities as channels, and core as the system channel — letting external developers generate client code from the spec. AsyncAPI documents the surface; the Network Model defines the architecture underneath.

Google A2A (Agent-to-Agent Protocol)

A2A is an open protocol for communication between opaque AI agents. It defines how agents discover capabilities, exchange messages, and manage tasks. Both A2A and the OpenAgents Network Model address agent interoperability, but from fundamentally different angles.

Concern	A2A Protocol	OpenAgents Network Model
Topology	Point-to-point (client → server)	Many-to-many within a network
Core abstraction	Tasks with lifecycle states	Events flowing through a network
Communication	Request-response: send message → get task result	Continuous event streams; some events are responses to others
Agent model	Opaque black boxes exposing skills via Agent Card	Network members with addresses, roles, verification, and shared resources
Bounded context	None — agents interact directly	Networks are the foundational boundary; events don't leak
Discovery	Well-known URI + registries	Event-based within network + DID across networks
State model	Stateful task lifecycle (pending → working → completed)	Stateless events; persistence is opt-in via mod/persistence
Shared resources	Not addressed	First-class tools, files, context with permissions
Multi-agent groups	Not addressed (bilateral only)	Channels, groups, broadcast addressing

Task-centric vs. Event-centric

A2A organizes collaboration around tasks with lifecycle states (pending → working → completed). The OpenAgents model has no tasks — everything is an event. Request-response patterns are event pairs linked by metadata. This is more flexible but less opinionated about workflow.

Bilateral vs. Network

A2A defines how agent A talks to agent B. OpenAgents defines how agents A, B, C, D communicate within a shared network — with channels, groups, broadcast, and mods mediating interaction. A2A has no “network” concept.

Discovery model

A2A agents publish an Agent Card at /.well-known/agent-card.json describing skills and auth. OpenAgents uses event-based discovery within networks and W3C DID resolution across networks.

Identity and verification

A2A delegates auth to HTTP schemes in the Agent Card. OpenAgents defines four progressive verification levels (anonymous → key-proof → JWT → DID) tracked as part of network membership.

Interoperability

A2A is a transport binding in the OpenAgents Network Model. An OpenAgents agent can expose an A2A-compatible interface, and external A2A agents can interact with OpenAgents networks through a transport bridge.

interop

External A2A agent              OpenAgents Network
┌──────────────┐               ┌───────────────────────┐
│              │ SendMessage    │                       │
│  A2A Client  │ ────────────→ │  A2A Transport Bridge │
│              │               │  (translates to Event) │
│              │ ←──────────── │                       │
│              │ Task/Artifact  │  ← events from network│
└──────────────┘               └───────────────────────┘

Mapping:
  A2A SendMessage   → OpenAgents event
  A2A Task states   → network.event.ack + extension events
  A2A Artifact      → event payload or resource/file/
  A2A AgentSkill    → resource/tool/ registration

Build on the OpenAgents Network Model

The model is open source and ready for implementation. Explore the full specification, contribute to the projects, or start building your own agent network.

Read the Documentation Full Spec on GitHub Try OpenAgents Workspace Join the Community