Last week we pivoted from a done-for-you AI agency to A2A infrastructure. We wrote about why we did it. Now let's talk about what we're actually building.
Fair warning: this is technical. That's intentional. If you're building AI agent systems and you've run into the problems we describe, this is for you.
The Problem We're Solving
We run a multi-agent system. Three agents work autonomously — coding, researching, coordinating — with minimal human intervention. When that system started to scale, we kept running into the same cluster of problems.
Problem 1: Identity. When Agent A hands work to Agent B, how does A know B is actually who it claims to be? Right now, there's no standard answer. Agents make identity claims in their system prompts, which are just strings. Anyone can write anything in a system prompt.
Problem 2: Capability trust. You've verified who an agent is. But what can it actually do — and who verified that? An agent claiming HIPAA data access in a system prompt is an unverifiable assertion. Fine for prototypes. Not fine for production.
Problem 3: Discovery. If you want to delegate a task to an agent that can handle it, how do you find one? Right now: manually, through docs, through informal out-of-band communication. There's no "give me all agents with X capability, operator-verified."
Problem 4: Revocation. A compromised agent has the same claimed capabilities after the compromise as before. There's no standard way to publish and propagate revocations.
These problems exist at the infrastructure level. They're not problems with specific agent frameworks. LangChain doesn't solve them. AutoGen doesn't solve them. They need to be solved at the layer beneath the frameworks. That's the layer we're building.
The Stack
We designed four phases, each building on the last:
Phase 1 — Identity Layer
We generate an AgentID record: name, creation timestamp, a ULID identifier (agnt_ prefix), and an Ed25519 keypair. The agent signs its own record. Anyone with the public key can verify it — the agent can't lie about its identity without the private key.
{
"id": "agnt_01HZ...",
"name": "My Agent",
"created_at": "2026-04-01T00:00:00Z",
"public_key": "base64...",
"signature": "base64 — self-signed over the rest of the record"
}No blockchain. No third-party authority. Self-sovereign, portable, verifiable. Ed25519 throughout — fast, small keys, native Web Crypto API support, zero external dependencies.
Phase 2 — Passport
A Passport is a signed, time-bounded document that attests capabilities. It's issued by someone — the agent itself, its operator, or a third-party auditor — and it expires.
{
"id": "pass_01HZ...",
"subject": { "agent_id": "agnt_01HZ..." },
"issuer": { "type": "operator", "name": "Acme Corp" },
"capabilities": [
{ "token": "data:phi:access", "scope": "read_only" },
{ "token": "tool:web_search" }
],
"expires_at": "2026-07-01T00:00:00Z",
"signature": "base64 — issuer's signature"
}Capability tokens follow a structured format: <domain>:<action>[:<qualifier>]. Issuer trust tiers: self (low, dev), operator (medium, production), third_party (high, regulated industries). An agent can hold multiple Passports from different issuers. Peers decide what trust level they require.
Phase 3 — Registry
The Registry is a distributed, queryable directory of AgentIDs and Passports. Think: npm, but for agent credentials.
- Publish an AgentID or Passport to make it discoverable
- Query by capability — give me all agents with
tool:web_search, operator-attested - Real-time revocation — publish revocations; peers subscribe and get push notifications
- Issuer registration — operators publish signing keys; peers evaluate issuer reputation
The Registry federates. No single node is authoritative. Records propagate via gossip. Eventually consistent — like DNS. Per-record visibility: public, unlisted, or private.
Phase 4 — Distribution
SDK packages, a formal protocol spec, a developer portal, an agent marketplace, and a commercial model.
npm install @agentcy/a2aThe protocol spec ships under CC Attribution 4.0 — implementable by anyone, in any language. The commercial model: free for developers experimenting, usage-based at production scale. Monetize the deployment layer, not the experimentation layer.
Phase 3.5 — The Co-Working Space
Between Phase 3 and Phase 4 there's a product layer: the Co-Working Space. The concept: Stripe for agent collaboration. A clearinghouse where agents discover each other, negotiate task delegation, and coordinate across organizational boundaries — with billing, trust gating, and outcome tracking built in.
If Phase 3 is the directory ("here's what agents exist"), Phase 3.5 is the coordination layer ("Agent A hands a task to Agent B from a different org, and the billing and trust happen automatically").
We've done independent analysis on this. Full post coming once Phase 1–3 primitives are stable enough to build on.
What We're Not Doing
Blockchain. Every "identity for agents" conversation goes here eventually. We looked at it. The answer is no. We need fast, offline-capable, cheap-to-verify identity. Ed25519 + canonical JSON gives us that. A distributed ledger adds latency, complexity, and operational cost with no benefit at our layer.
Central authority. No "Agentcy issues all AgentIDs." The value of self-sovereign identity is that you don't need our permission. We operate the reference Registry; we don't control who gets to have an identity.
AI capabilities in the identity record. There's a temptation to include "what LLM is this agent running" in the identity record. We removed it. That's runtime metadata, not identity. The identity layer should be stable across model upgrades.
Where We Are
Right now: four specs, written and published. No code yet.
Phase 1 has five open design decisions before we write the first line of TypeScript. We'll publish those decisions — the tradeoffs, the leans, the final calls — as we make them.
Next: resolve Phase 1's open questions, then write the library. Building in public means the false starts and dead ends are part of the record.
Follow the build: github.com/Kosfootel/Agentcy-services
If you're building multi-agent systems and this resonates — or you think we're wrong about something — the best way to reach us is GitHub Issues.
— Ray & the Agentcy.Services team