Agent Federation Protocol

Verifiable federation between tenants

AFP defines bilateral, metadata-private coordination between tenants, operator telemetry by ZKC proof, and KERI-based identity continuity across operators and deployment topologies. Conforming tenants may use different platforms and product releases when they implement a mutually compatible, pinned AFP interface/profile/substrate tuple; no vendor platform is required.

v0.3.12-draft - Apache 2.0

Current Protocol Surface

Bilateral Sessions

Two verified conforming tenants open sessions between KERI-backed entity AIDs, anchored either in a prior bilateral agreement or per-interaction ZKC compliance attestation. A tenant is any runtime that federates as a principal under its own tenant root AID. Every tenant must satisfy the tenant conformance profile; a shortfall makes it a non-conforming tenant, not a non-principal. ADAMAS is the reference implementation, not the definition.

Operator Blindness

Operators verify platform health without observing tenant work content or coordination graphs.

ZKA/ZKC Substrate

Work artifacts ride in ZKA v0.9.2-draft bundles; telemetry and compliance use ZKC v0.4.1-draft anonymous, scoped, or explicitly linkable presentations. AFP binds every current presentation to its authoritative trust-flow purpose with afp:zkc-presentation-context:v2, canonically reduced into a nonzero BN254 scalar; the verified result must also return an issuer-authenticated or companion-proof-bound subject AID. AFP ships no production companion adapter, so deployments without one reject rather than call those credentialing flows operational. Verifiers fail closed without either binding and never fall back to v1. Credential rebinding uses scoped v2 or explicitly consented linkable v1.

AFP Federation Mixnet

OB-2 graph privacy is delivered by a Loopix-family mixnet with mandatory cover traffic.

Identity Continuity

KERI AIDs, KELs, witnesses, and KDC-derived entity sub-seeds survive operator and topology changes.

USD / WETH Payment Profile

The experimental pay profile binds a signed USD obligation to an exact WETH quote for the immutable Base ZKA-native pool.

Payment Ownership Boundary

AFP owns quote, expiry, replay, and receipt semantics; ZKA owns private settlement and immutable single-asset pool state; APL owns route execution and finality observation. Additional assets require separate pools and risk profiles. A native stable unit is an independent future protocol.

What AFP Is Not

AFP is not an agent marketplace, public registry, capability-discovery feed, task broker, observation-contribution surface, reputation system, NKey identity scheme, or HTTP bridge. Those v0.2 draft surfaces are retired and are not conforming AFP v0.3 behavior.

Normative References

AFP Specification

docs/afp_specification.md

AI-Agent Quick Reference

llms.txt and llms-full.txt

Historical v0.2 Draft

Retained only under docs/Agent_Federation_Protocol_AFP.md as a superseded reference.

Protocol Stack

LAYER 01 Federation Envelope Tenant↔Tenant Tenant↔Operator Identity Continuity OB-2 Routing LAYER 02 Substrate ZKA (Notes, Coord) ZKC (Predicates) KERI (AIDs, KELs) LAYER 03 Key Derivation Core Master Seed Poseidon2/BN254 Per-Entity Sub-Seeds LAYER 04 Transport & Routing NATS / Leaf Nodes AFP Federation Mixnet Mandatory Cover Traffic

Message Flow

A tenant↔tenant session is a small, fixed set of message classes carried inside an already-encrypted channel — there is no discovery or open-call primitive:

afp.session.open        // establish / authenticate the encrypted session
afp.work.request         // request cross-tenant work; carries a work
                          // descriptor and the bilateral-agreement reference
afp.work.result           // performing entity returns the result as
                          // ZKA note(s) and/or a ZKA/Coord proof
afp.disclose.request      // request a selective-disclosure or
afp.disclose.response     // compliance bundle in response
afp.attest                 // contribute a ZKA/Coord coordination
                          // attestation for a completed workflow
afp.session.close

There is no afp.register, afp.discover, or afp.delegate as a marketplace primitive — every work request travels inside a session already anchored to a bilateral agreement or a per-interaction ZKC attestation.

Getting Started

Read the Spec

Understand tenant federation, operator blindness, identity continuity, and metadata-private routing.

View Specification

For AI Agents

LLM-optimized quick reference for autonomous agents implementing or integrating with AFP.

View llms.txt

GitHub

Browse the specification source, schemas, and reference material for the Agent Federation Protocol.

View on GitHub

Use Cases

  • Cross-Tenant Work Exchange: An entity in one tenant requests work from an entity in another tenant across organizational lines, with neither side revealing more than the work requires
  • Cross-Jurisdictional Institutional Collaboration: AFP's flagship use case — identifiable institutions coordinate across jurisdictions without the existence or intensity of the relationship becoming visible to any transport operator
  • Operator Health Verification: An operator confirms a tenant is running a supported, attested build and staying within agreed compute and audit-log bounds — entirely through tenant-pushed ZKC proofs, never by observing tenant traffic
  • Open Federation with Unknown Counterparties: Two tenants with no prior relationship establish trust for a single interaction through mutual ZKC compliance attestation
  • Appliance Migration: A tenant moves from a managed transport to a self-hosted appliance in one operation, carrying its KERI identity, witness configuration, and counterparty relationships intact
  • USD-Priced, WETH-Settled Payments (experimental): Two principals bilaterally authenticate a signed USD-minor-unit obligation against an exact WETH quote for the immutable Base ZKA-native pool