The Agent Ecosystem
AgenID is designed to work across the platforms where AI agents live. Your agent can change platforms. Its identity shouldn’t have to.
An agenid:<ULID> identifies the agent and the party accountable for it — never the model, framework, or host underneath. That is what makes this list possible: nothing in the protocol references any vendor on it.
Three statuses. Only one of them is currently issued.
Identity can be carried through this platform today using its existing, documented API surface. No AgenID-specific code is required from the platform, and none is claimed to exist.
AgenID has executed the integration end to end and published the result. Not asserted for any entry yet.
A partnership is on record with the platform. Not asserted for any entry yet.
Every entry below is Compatible and nothing more. No platform on this page ships AgenID code, and no adapter package exists for any of them. A listing is a technical statement about how an identity travels through a platform’s existing, documented API surface — it is not an endorsement, a partnership, or a relationship of any kind. All product names and marks belong to their respective owners.
The platforms change. The identity doesn’t.
The identifier and the signed manifest_digest are the same bytes at every hop — the operator’s manifest names the agent and who is accountable for it, never the vendor underneath. Each hop can re-verify the Ed25519 signature offline before it acts, without calling AgenID and without trusting the platform it received the identity from. Stages are illustrative of the layers in the registry below, not a record of an executed hand-off.
25 platforms across 5 layers.
Every platform in the registry.
25 of 25 platforms
Bland AI
Outbound and inbound AI phone calls
Identity is attached to the call request's metadata object and returned on the completion webhook, where it is resolved and re-verified out-of-band.
ElevenLabs
Voice synthesis and conversational agents
Identity is carried as client/dynamic variables on the conversational-agent session and echoed into tool calls, where the operator's tool endpoint re-verifies the signed manifest proof.
Retell
Conversational voice AI platform
The agenid:<ULID> travels in the custom-LLM request/response payload and the post-call webhook body; verification runs in the operator's own webhook handler with @agenid/core. Retell ships no AgenID-specific code.
Synthflow
No-code voice assistant builder
Compatible through the generic pattern only: the identifier is passed as a custom-action header or payload field. No platform-specific brief has been written or tested.
Vapi
Developer voice agent platform
The identifier rides in assistant metadata and every server message; the operator's server verifies the ManifestProof before acting on a call event.
Anthropic
Claude model family and Agent SDK
Same construction as any other model provider: the manifest names the operator and the agent, never the underlying model. Changing provider does not change the identity or invalidate an existing proof.
Google Gemini
Gemini model family
Listed for completeness of the model layer. No Gemini-specific surface is required or used by the protocol.
Meta Llama
Open-weight model family
Self-hosted inference is fully compatible; the protocol has no hosted-API dependency of any kind.
Mistral AI
Open-weight and hosted models
Including self-hosted open-weight deployments: identity is a property of the operator and the agent, not of where inference runs.
OpenAI
GPT model family and Agents SDK
AgenID never references a model provider. An agent keeps one agenid:<ULID> across a switch of model vendor; the identifier is carried by the operator's own request context, not by the model API.
xAI Grok
Grok models and Grok bot surfaces
The documented pattern publishes the agenid:<ULID> in the bot's own profile/disclosure surface so a reader can resolve and verify it independently. Nothing is enforced by the platform.
AWS
Cloud compute and hosting
Runtime-neutral. Relevant only as a place an operator hosts the agent, its key document, or its own verification endpoint.
Cloudflare
Edge compute, Workers, and DNS
Two roles: DNS TXT records satisfy the L2 domain-control evidence type, and /.well-known/agenid/keys.json can be served from Workers or Pages as the domain path of two-path key discovery.
Google Cloud
Cloud compute and hosting
Runtime-neutral, same as any other host.
Microsoft Azure
Cloud compute and hosting
Runtime-neutral, same as any other host. Route 'is this agent verified' checks through @agenid/core in the operator's own service.
Vercel
Edge/serverless application hosting
The AgenID reference resolver itself runs here, which makes it a tested host for the read path — not a protocol dependency.
AutoGen
Multi-agent conversation framework
Compatible through the generic pattern only. No framework-specific brief has been written or tested.
CrewAI
Multi-agent orchestration
Compatible through the generic pattern: each crew member carries its own agenid:<ULID> in agent metadata so inter-agent calls can be verified. No framework-specific brief has been written or tested.
LangChain
Agent orchestration and LangGraph
The identifier is carried in the run configuration and surfaced on tool boundaries, so a downstream tool can resolve and verify the calling agent before it executes.
Model Context Protocol
Open tool/context protocol for agents
@agenid/mcp-server exposes resolution and verification as MCP tools, so any MCP-capable client can check an agent's identity. The package builds and tests in CI; it has not been published to npm (the @agenid scope is unclaimed).
OpenAI Agents SDK
Agent runtime and handoffs
Compatible through the generic pattern: identity persists across handoffs because it lives in the operator's run context, not in the SDK's session state. Not yet tested end to end.
OpenClaw
Local agent gateway
The documented pattern attaches the identifier at the gateway so every downstream agent call carries it. Pattern only — no adapter package exists.
Auth0
Customer identity and access management
Auth0 identifies the human on the other side of the conversation. AgenID identifies the agent on this side of it.
Microsoft Entra ID
Enterprise identity and access management
Entra answers 'which principal is calling'. AgenID answers 'which agent is this, who is accountable for it, and what has been independently verified'. The two compose; neither replaces the other.
Okta
Enterprise identity and access management
Same composition as any IAM provider: authorize the service principal with Okta, resolve and verify the agent's provenance with AgenID.
Building on a platform that isn’t listed?
Absence from this list is not a compatibility claim in either direction. The pattern is the same everywhere: attach an agenid:<ULID> to the agent’s existing config, sign a manifest with @agenid/core, and resolve it at /a/<agenid>. The registry itself lives at packages/web/data/ecosystem/ in AgenID-protocol/agenid, one reviewable JSON file per platform, validated in CI — a new entry is a pull request, and raising an entry above Compatible requires evidence in the same change.