Framework integration
The same integration route on every framework.
An agent declares its ECZ-ID at a well-known path on a surface it already serves. It is a static file. No library, no dependency, no change to the agent loop, and nothing new in the execution path.
/.well-known/ecz-agent.json
£0. No card required. One Agent Passport is one logical AI agent operated by your organisation.
Why it is identical everywhere
A published file, not a dependency.
Nothing enters your dependency tree
There is no package to add, no version to pin, no transitive dependency to audit and no supply-chain surface that did not exist before. A static JSON file cannot execute anything.
Nothing changes inside the agent loop
The file is served by the surface your deployment already exposes. Your prompts, your tools, your orchestration and your latency are untouched, because none of them are involved.
It cannot break your build
There is no ECZ-ID code in your process, so there is no ECZ-ID code to fail, block, retry or time out. If this site disappeared tomorrow, your agent would carry on exactly as before.
It is readable by people who have no access to you
The point of publishing identity is that a counterparty can act on it. A file on a public surface, pointing at a public record, is legible to someone with no account, no key and no relationship with your organisation.
No ECZ-ID library is published today.
You will find no install command, package name or import snippet anywhere on this site, for any framework, because there is no published ECZ-ID agent SDK to point you at. The well-known file is the route that exists. When client libraries are published they will appear on the Developer Gateway(opens in a new tab — developers.ecocitizenz.com) first, and the honest status of an ECZ-ID client library is written up on the SDK page.
Frameworks and runtimes
Find your stack.
| Framework | From | Languages | What you do |
|---|---|---|---|
| OpenAI Agents | OpenAI | Python, TypeScript | Give the deployed agent a Passport and publish its ECZ-ID on the surface it already exposes. Nothing is added to the agent loop itself. |
| Microsoft Agent Framework | Microsoft | .NET, Python | Publish the agent's ECZ-ID alongside the workload identity it already runs under. The two answer different questions and neither replaces the other. |
| Google Agent Development Kit | Python, Java | Attach the Passport to the deployed agent and publish the record on its exposed surface. | |
| AWS Strands Agents | Amazon Web Services | Python | Publish the agent's ECZ-ID on the endpoint or manifest the deployment already serves. |
| LangGraph | LangChain | Python, TypeScript | One Passport per logical agent, not per graph node and not per run. |
| Vercel AI SDK | Vercel | TypeScript | Publish the record on the deployed route the agent is reachable at. |
| Mastra | Mastra | TypeScript | Publish the record on the agent's exposed surface. |
| CrewAI | CrewAI | Python | One Passport per logical agent you operate, not one per crew member instantiated at runtime. |
| Pydantic AI | Pydantic | Python | Publish the record on the deployed agent's surface. |
Five of these have a page of their own because the identity question on them is worth answering separately. The rest do not, and that is not a gap: the route is the file, and the file is the same. If your framework is missing from this table entirely, it still works — the list is not a compatibility matrix. Versions, deployments, replicas, regions and platforms of that agent are not separate Passports.
Languages
The file does not care what you wrote the agent in.
TypeScript and JavaScript
Publish a static JSON file from the deployment you already run.
Python
Publish a static JSON file from the deployment you already run.
Go
Publish a static JSON file from the deployment you already run.
.NET
Publish a static JSON file from the deployment you already run.
Anything that can serve a static file over HTTPS can publish an ECZ-ID, which is every language and every hosting arrangement in practical use. Public Resolver reads and public machine-readable records are never metered, never authenticated and never counted against any allowance.
The boundary
ECZ-ID is not in your execution path.
It replaces nothing you run
ECZ-ID works alongside your agent framework, OAuth, native IAM and workload identity. It does not replace any of them.
What it adds instead
What it adds is the layer none of those provide: a persistent public identity for the agent itself, tied to a named operator, that someone outside your organisation can resolve and re-check.
And it does not move underneath you
Your ECZ-ID does not change. Changing framework, moving cloud, rewriting the agent or letting a paid tier lapse leaves the identifier, the record and the resolver page exactly as they were.
Next