Source-linked AI summary
Foundation Protocol: A Coordination Layer for Agentic Society
Bang Liu, Yongfeng Gu, Jiayi Zhang, Zhaoyang Yu, Sirui Hong, Maojia Song, Xiaoqiang Wang, Mingyi Deng, Zijie Zhuang, Ronghao Wang, Mingzhe Cao, Yutong Zhu, Xingjian Li, Yifan Wu, Jianhao Ruan, Yiran Peng, Shuangrui Chen, Jinlin Wang, Yizhang Lin, Dongjie Zhang, Dekun Wu, Chen Ma, Lizi Liao, Han Yu, Jian Pei, Heng Ji, Qiang Yang, Yuyu Luo, Chenglin Wu
TL;DR
Agentic systems need a shared way to coordinate entities, organizations, exchanges, and accountable actions across tools and institutions. The paper introduces Foundation Protocol, a graph-native coordination layer with organization, economic-attestation, provenance, policy, and audit primitives. It presents FP as a step toward interoperable, trustworthy cooperation while preserving autonomous agency with accountability.
Problem
As agents become persistent collaborators that delegate, exchange value, and interact across institutions, existing coordination remains fragmented across isolated systems.
Method
Foundation Protocol models agents, tools, resources, humans, institutions, and organizations in a shared graph with native sessions, roles, economic attestations, policy, provenance, and audit.
Results
FP unifies entity modeling, organization, eventful interaction, value attestation, and protocol-level oversight while complementing existing protocols through a small extensible core.
Takeaways & Limitations
FP is presented as a step toward interoperable, trustworthy cooperation that makes autonomous agency composable without making accountability optional.
Takeaways & Limitations
The paper acknowledges that autonomy can produce complexity, fragmentation, concentrated power, inequity, bias, and loss of agency.
Abstract
from arXiv · showhide
Autonomous agents are moving from tools into a layer of social infrastructure: they browse, purchase, deploy software, manage systems, and increasingly interact with one another. As these systems scale, the bottleneck shifts away from raw model capability toward coordination. Agents need to form reliable relationships, organize multi-agent work, exchange value, support an AI economy, and stay safe and accountable under real-world oversight. This paper introduces the Foundation Protocol (FP), a graph-first coordination layer for an emerging human-AI society. FP unifies heterogeneous entities, including agents, tools, resources, humans, institutions, and organizations, and supports native multi-party organization and event-based collaboration. It also provides economic primitives for metering, receipts, and settlement, and treats policy, provenance, and audit as first-class concerns. FP is designed to wrap and bridge existing protocols rather than replace them, enabling incremental adoption while reducing integration and governance overhead. The aim is to keep autonomous agency composable while keeping accountability non-negotiable, so that coordination itself can become shared infrastructure for a human-AI society that is open, pluralistic, and governable.
1 Introduction
As autonomous agents become participants that act, transact, and coordinate across organizational boundaries, existing protocols leave fragmentation in identity, authority, provenance, and oversight. The Foundation Protocol provides a graph-native control-plane substrate that composes these protocols while supporting heterogeneous entities, organizations, economic exchange, and accountable execution.
- Emerging agentic systems: Agents increasingly act on users’ behalf by using services, holding credentials, purchasing resources, and deploying software with financial, operational, and reputational consequences.More advanced agents operate persistently rather than merely serving as thin natural-language layers over APIs.
- Emerging agentic systems: Multi-agent workflows require agents to recruit specialists, obtain user approval at sensitive points, settle providers through auditable receipts, and preserve provenance across research and operational tasks.The examples include travel coordination and research teams that use external resources, instruments, analyses, and reviewable evidence.
- Emerging agentic systems: OpenClaw and Moltbook illustrate complementary shifts toward agent tool coordination and agent social interaction with profiles, authentication, updates, and human observation.OpenClaw is a locally run, chat-controlled runtime, while Moltbook provides a social layer for agents.
- Coordination gap: Existing protocols address tools, agent collaboration, interface delegation, secure messaging, discovery, and commerce, but fragmentation across identity, authority, sessions, traces, and evidence makes integration costly and oversight patchwork.The cited protocols are MCP, A2A, A2UI, DIDComm, ANP, and UCP; surveys also identify gaps in collaboration, scalability, security, privacy, and group interaction.
- Foundation Protocol: FP treats agents, tools, resources, humans, institutions, and organizations as addressable graph entities, with relationships, memberships, sessions, activities, exchange, policy, provenance, and audit as shared protocol primitives.Its purpose is to compose existing protocols across boundaries while preserving identity, authority, accountability, and governability as autonomous execution scales.
2 The Architecture of the Foundation Protocol
The Foundation Protocol uses a graph-native, plane-based architecture that unifies entities, interactions, transport, economic activity, and oversight while keeping its core semantics small. Profiles, registries, pattern libraries, and bridges make transports, identities, deployments, and higher-level interaction patterns extensible without changing those core commitments.
- Graph-native architecture: FP models entities as nodes, relationships and memberships as edges, interactions as activities, and policy, provenance, and audit as governance evidence.This graph-native view supports a plane-based architecture with explicit extension points.
- Entity & Trust Plane: The entity model makes participants addressable through identity, capabilities, trust signals, and privacy controls, while organizations can hold assets, sponsor sessions, and exercise scoped delegation.FP treats identity as the unit of accountability and leaves identity schemes and reputation systems open to deployment choice.
- Transport & Routing Plane: FP treats transport as a binding beneath consistent addressing, correlation, and trace semantics, allowing group sessions to span local IPC, HTTP or WebSocket, and streaming channels.Routing preserves ordering where required, backpressure, termination semantics, and a coherent interaction record across channels.
- Interaction Plane: Sessions represent multi-party collaboration through participants, roles, policy references, and optional budgets, while events and streams provide ordering, correlation, replay, and backpressure.Economic primitives add metering, receipts, settlement references, and dispute signals.
- Oversight Plane: The oversight plane makes policy evaluation, enforcement, audit, provenance, monitoring, compliance, and dispute escalation protocol concerns, with evidence independently verifiable without exposing sensitive payloads.Policies and provenance can be referenced, hashed, and verified independently of governed payloads, while disputes, revocations, and safety reports are first-class events.
- Configuration and extensibility: Profiles, registries, pattern libraries, and bridges bind stable core semantics to concrete transports, identity methods, deployment environments, catalogs, reusable workflows, and existing ecosystems.These mechanisms keep variability outside an overgrown protocol core.
3 Application Scenarios
FP supports recurring coordination scenarios across interoperation, organization, economic activity, social governance, and supervised autonomy. An AI-company lifecycle illustrates how one protocol core unifies identity, discovery, delegation, policy enforcement, economic controls, and auditable evidence across heterogeneous participants.
- Application scenarios: FP provides a shared substrate for cross-protocol workflows, combining MCP tools, A2A delegation, and A2UI interaction through common entities, sessions, envelopes, and traces.This avoids separate notions of identity, session state, authority, and logging for each interaction path.
- Application scenarios: Organizations, roles, membership, delegation, policy enforcement, and evidence are protocol objects, enabling team coordination, governance, internal review, and external compliance.Policy enforcement points can gate sensitive transitions while a shared evidence spine supports review and compliance.
- Application scenarios: FP represents procurement, resource allocation, and marketplace activity with ledger-agnostic primitives for metering, attestation, settlement, and dispute handling.Economic relationships can be audited without requiring a particular payment rail.
- Application scenarios: FP makes social governance protocol-level by representing communities as organizations with moderation roles, policy hooks, and provenance signals against manipulation, spam, and instruction injection.The same coordination logic also applies where autonomous systems require supervision, limited data exposure, human approval, and inspectable provenance.
- AI company lifecycle: An AI company scenario combines a human founder, specialized agents, external tools, service providers, and checkpoints to discover capabilities, coordinate work, manage budgets, and remain auditable.The founder creates an organization, assigns planner, developer, and reviewer roles, discovers a GPU provider and code-search tool, delegates an authentication task, and requires human approval before deployment.
- AI company lifecycle: The lifecycle uses uniform routing, checkpoints, traces, and evidence so actions, policies, economic outcomes, overrides, and disputes remain inspectable across participants.The same entity model represents the founder and GPU provider, the checkpoint pipeline can enforce access and budget limits, and envelopes can carry tasks and payment receipts.
4 Conclusion
The Foundation Protocol addresses coordination, governance, and evidence constraints in an emerging agentic society through a compact, interoperable protocol core. It aims to make autonomous agency composable while preserving accountability and enabling trustworthy cooperation across existing protocols.
- 4 Conclusion: FP combines a unified entity model, native organization primitives, eventful interaction, ledger-agnostic economic attestation, and protocol-level oversight.Its compact core is separated from profiles, extensions, and bridges to complement existing protocols.
- 4 Conclusion: FP provides an interoperable communication substrate connecting entities, organizations, value attestations, and evidence across tools, agents, humans, services, and institutions.The architecture is presented as a step toward an open and governable agentic society.
- 4 Conclusion: The next step is to turn FP’s architecture into a precise specification and a set of reference implementations.The conclusion frames this work as necessary for making autonomous agency composable without making accountability optional.
A Reference Implementation
The Foundation Protocol is accompanied by an open-source, non-normative reference stack comprising the foundation-protocol runtime and the ai-link-net application-network implementation. The appendix outlines their architecture and technical choices to support evaluation of feasibility and trade-offs.
- A Reference Implementation: The reference stack includes the open-source foundation-protocol runtime and ai-link-net application-network implementation.Both implementations are non-normative; the main text defines the protocol.
- A Reference Implementation: The appendix describes the implementations’ architecture and main technical choices so readers can evaluate design feasibility and trade-offs.Code-dependent details such as module names, file paths, and API signatures are deliberately omitted.
A.1 Overview
The released repositories provide a working Foundation Protocol stack centered on a Python protocol core and runtime, with an application-network server, CLI, and web interface. The implementation supports developer-facing local or cloud-hosted nodes where registered entities discover peers, establish trust, and interact across hosts with AI providers and MCP-compatible tools.
- A.1 Overview: The two repositories form a working FP stack supporting registration, peer discovery, trust relationships, and signed, encrypted cross-network interactions among humans, agents, tools, resources, and services.foundation-protocol provides the protocol core and Python runtime, while ai-link-net adds the application-network server, command-line interface, and web interface.
- A.1 Overview: Developer-facing deployment supports local or cloud-hosted FP nodes, entity registration, and cross-host interactions with Claude Code, Codex CLI, and MCP-compatible tool servers.The core, server, and CLI use Python; the web interface uses TypeScript, React, and Vite.
A.2 Core concepts
FP’s core implementation is organized around Entity, Host, and Server abstractions that separate protocol semantics, topology and routing, and runtime concerns. This decomposition supports portability beyond HTTP-based deployments.
- Core concepts: FP’s structural backbone comprises three abstractions: Entity, Host, and Server.These abstractions separate participant modeling, topology and routing, and application-layer runtime behavior.
- Entity: An Entity is FP’s unified participant model for humans, agents, tools, resources, services, arbiters, and organizations.Every addressable participant uses the same surface for identity, addressing, cryptography, and access control.
- Host: A Host defines addressing, discovery, and routing semantics while maintaining local registries and parent–child relationships with other Hosts.It routes mail to local entities, child Hosts, or parent Hosts without prescribing connection or state-persistence mechanisms.
- Server: A Server connects a Host’s abstract routing model to network connections, handling presence, bounded offline-mail queues, liveness heartbeats, and external HTTP access.The reference implementation uses WebSockets and exposes an HTTP REST API.
- Separation of concerns: By isolating protocol semantics from runtime concerns and interface presentation, FP’s protocol core can run in batch scripts, test harnesses, and alternative transport layers.This separation makes the protocol easier to test and port across web frameworks.
A.3 Architecture · A.3.1 Layering and dependency direction
The architecture uses three layers with strict unidirectional dependencies: interfaces consume the application layer, which depends on a framework-independent protocol core. This separation keeps protocol semantics stable and independently testable across deployment choices.
- A.3.1 Layering and dependency direction: The codebase is organized into three layers governed by a strict unidirectional dependency rule.The layers are protocol core, application layer, and interface layers.
- A.3.1 Layering and dependency direction: The protocol core defines entities, message semantics, mail envelopes, cryptography, topology, checkpoints, handlers, and protocol adapters.Examples include a CLI adapter for AI providers and an MCP bridge for tool servers.
- A.3.1 Layering and dependency direction: The protocol core has no dependency on web frameworks, databases, or persistence backends, making it a pure domain model.Its framework-independent design isolates protocol concepts from infrastructure choices.
- A.3.1 Layering and dependency direction: The application layer provides the HTTP/WebSocket server, runtime host management, host-to-host client libraries, API schemas, and configuration management.It serves as the operational layer above the protocol core.
- A.3.1 Layering and dependency direction: The interface layers consist of CLI commands and a React web UI that consume the application layer’s API rather than containing protocol logic.Both interfaces depend on the application API for access to system functionality.
- A.3.1 Layering and dependency direction: Dependencies flow strictly application →core, so the protocol core never imports from the application layer.This preserves a one-way dependency boundary between protocol semantics and deployment-facing components.
- A.3.1 Layering and dependency direction: This dependency constraint keeps protocol semantics stable and testable independently of deployment choices.The separation allows deployment concerns to evolve without changing the core protocol model.
A.3.2 Concurrency model
The server uses fully asynchronous I/O and processes messaging, forwarding, WebSocket management, and offline queue flushing as concurrent coroutines on a single event loop. This enables a Host to route mail among many entities and child Hosts simultaneously without blocking on individual deliveries.
- A.3.2 Concurrency model: All server I/O paths are fully asynchronous and run as concurrent coroutines on a single event loop.This includes entity message processing, host-to-host forwarding, WebSocket management, and offline queue flushing.
- A.3.2 Concurrency model: Concurrent processing supports high-fanout scenarios in which one Host routes mail among many entities and child Hosts simultaneously.The design avoids blocking on individual message deliveries.
- A.3.2 Concurrency model: The routing architecture handles simultaneous delivery across entities and child Hosts without blocking on individual messages.This behavior follows from the asynchronous coroutine-based design.
A.3.3 Topology: tree-based with a decentralization path
FP currently uses a tree topology with a cloud-hosted root serving as a rendezvous point, while its routing layer supports future peer-to-peer or mesh expansion without protocol-level changes.
- Current topology: The current implementation uses a tree in which each Host has at most one parent, may have many children, and can connect through a cloud-hosted root.This provides a simple operational default for personal or team Hosts joining a shared network through a known entry point.
- Decentralization path: Topology is not a hard architectural constraint: peer-to-peer or mesh routing would require changes only in the routing layer.The entity model, mail format, checkpoint pipeline, and other protocol components would remain unchanged.
A.3.4 Transport independence … A.4.4 Security and auditability
FP provides transport-independent coordination with uniform identity and policy mechanisms across entities, bridges existing ecosystems, supports contract-based economic workflows, and makes security and audit evidence traceable. Its design preserves extensibility while keeping messages, contracts, and access-control decisions accountable.
- A.3.4 Transport independence: FP’s core defines addressing and routing independently of transport, allowing WebSocket, HTTP REST, QUIC, gRPC, or local IPC profiles without changing the protocol core.The default profile uses WebSocket for persistent host-to-host connections and HTTP REST for client-to-host operations.
- A.4.1 Unified entity model and access control: All core entity kinds share addressing, cryptographic identity, and access-control surfaces, so agents, humans, tools, and services use identical envelope, routing, and policy mechanisms.Behavior after checkpoint processing is specialized through extensible handlers for different entity kinds.
- A.4.1 Unified entity model and access control: Inbound messages pass through ordered, pluggable, composable policy checkpoints, whose evaluation order determines priority and can be extended without modifying existing checkpoints.Reference checkpoints include social-graph gating, session validation, rate limiting, content-length enforcement, payment verification, and approval controls.
- A.4.2 Protocol bridges: FP complements existing protocols through bridges that expose external AI providers and MCP-compatible servers through a common control surface rather than replacing their domain-specific semantics.The bridges translate provider-specific execution or MCP JSON-RPC operations into FP-addressable interactions.
- A.4.3 Contract lifecycle and economic functionality: The trade subsystem organizes contracts among buyer, seller, and arbiter roles through typed state transitions from DRAFT to SETTLED, with cancellation and dispute paths.Amendments reset approvals and increment draft versions, while configurable rework limits can trigger dispute escalation.
- A.4.3 Contract lifecycle and economic functionality: FP supports escrow and external settlement, records delivery costs such as tokens, compute-hours, or USD, and issues signed, third-party-verifiable receipts.Escrow provides protocol-level atomicity, while direct settlement records a verifiable external reference.
- A.4.3 Contract lifecycle and economic functionality: Reputation is derived from closed-loop contract evidence across five dimensions, weighted by confidence and recency so reviewers can trace scores to underlying events.The dimensions are quality, reliability, collaboration, efficiency, and integrity.
- A.4.4 Security and auditability: Security combines signed and optionally encrypted envelopes with signed hash-chained contract snapshots and append-only traces of mailbox activity and checkpoint decisions.The reference cryptographic profile uses Ed25519 signatures, ephemeral X25519 key agreement, and AES-256-GCM encryption, while algorithms remain replaceable.