Why EEP?

The vision behind the Entity Engagement Protocol and how to adopt it with production-grade guardrails.

The problem: the web was built for reading, not acting

The original web was designed as a document delivery system. A human types a URL, a server sends back an HTML page, and the human reads it. The client has to ask for data, resulting in a snapshot of what was true at the moment of asking.

This works when humans read web pages. If the data is stale, they refresh. But an AI agent cannot keep polling. An agent monitoring supplier profiles for price changes ends up making decisions on stale data if it only checks hourly. It misses updates that matter.

The human web was built for human readers. The agentic web needs something different.

The solution: push-first, event-driven entity communication

EEP defines a simple contract:

Any digital entity (a business, a person, a product, an AI agent) can publish a real-time stream of state changes. Any authorized subscriber (human or machine) can receive those changes the moment they happen.

Event-driven systems have powered financial markets, logistics networks, and IoT devices for decades. EEP brings that reliability to internet identities.

The current implementation is optimized for zero-trust deployment: strict semantic verification for gates, replay-resistant webhook verification, SSRF controls (including IPv6 ULA/link-local blocks), and deterministic compliance verification outputs for automation.

What counts as an "entity"?

EEP is entity-agnostic. An entity has:

A stable identity (a DID, a URL, a username)
State that can change over time
A need to notify others when that state changes

Examples:

Freelancer profile — trust score goes up, new skill verified
SaaS product — pricing tier changes, new integration published
Supply chain node — inventory drops below threshold, shipment delayed
DAO — governance vote passes, treasury balance changes
AI agent — deployment updated, capability added, task completed

The three layers of EEP

Layer 1: State Resolution (REST)

HTTP REST APIs handle discovery. Any agent can GET /u/acme-corp and receive a structured profile with capabilities, trust score, and a DID document. This layer is stateless, cacheable, and universally accessible.

Layer 2: Signal Stream (SSE + Webhooks)

Entities publish events as CloudEvents-compliant JSON payloads. Subscribers choose their preferred delivery mechanism: webhooks (platform POSTs events to subscriber's URL) or SSE (subscriber opens a long-lived HTTP connection). This layer is unidirectional and persistent.

Layer 3: Network Pulse (WebSockets)

Network pulse handles bidirectional, interactive scenarios like A2A task execution, agent-to-entity live negotiation, and collaborative editing. This layer is stateful, bidirectional, and latency-sensitive with per-entity sequence tracking, gap detection, replay support, and JWT re-authentication.

Who is EEP for?

Audience	How EEP Helps
Platform developers	Standard event channel for your entities — any AI agent can subscribe without bespoke integrations
AI agent developers	One subscription API across every EEP-compliant platform
Enterprise architects	Vendor-neutral event bus — no cloud lock-in

SEO, GEO, and structured discovery

Classic SEO optimizes pages for humans using traditional search. Separate industry conversations about generative engine optimization (GEO) concern how sources appear in AI-mediated answers. EEP is not a ranking product: it standardizes machine-readable manifests, push streams, and verifiable gates so agents and tools can use structured data without re-parsing layout-heavy HTML.

Read Discovery (manifest / DNS) and the Whitepaper for publisher-oriented context. Nothing here promises traffic or citation placement.

Design principles

Principle	What It Means
Open	No proprietary lock-in. Apache 2.0 license. Anyone can implement it.
Composable	Use all three layers or just one. EEP layers are independent.
Secure by default	Every webhook is signed. Every SSE stream is authenticated.
Agent-native	Events are structured for machine consumption first.
CloudEvents-compatible	EEP envelopes are a superset of CloudEvents v1.0.2.
Interoperable	Bridge to A2A, MCP, and AG-UI without data transformation.