We reviewed the current Agent Internet RFCs and wrote a technical position on where the architecture is solid and where it is still weak. The paper argues for a layered model that separates discovery, workload identity, delegated authorization, observability, and evaluation, and it also examines what changes once agents operate as hierarchical graphs rather than isolated endpoints.
If you are working on agent runtimes, registries, orchestration, MCP, A2A, trust infrastructure, or benchmarks, read it critically. The useful questions are not marketing questions but systems questions: what must be standardized now, what should remain loosely coupled, how should delegation chains be secured, and what telemetry is required to make multi-agent systems auditable in practice?
The layered architecture argument is right. Discovery, identity, and authorization should be separate concerns. AgentDNS tries to be all three plus billing and proxying, and that's how you get a single point of failure that controls everything.
We've been building the "narrowly scoped discovery" piece this review recommends. Agent Identity & Discovery (AID) [1] is a DNS TXT record at `_agent.<domain>` — endpoint, protocol, auth hint, optional Ed25519 public key. No registry, no proxy, no billing. Add one DNS record and any AID client finds your agent.
Works with MCP, A2A, OpenAPI, gRPC, GraphQL, WebSocket, local agents (Docker, npx, pip). SDKs in TS, Go, Python, Rust, .NET, Java. The discovery lookup is a single DNS query.
The optional PKA (Public Key Attestation) uses RFC 9421 HTTP Message Signatures with Ed25519 for endpoint proof. It sits underneath SPIFFE and OAuth rather than replacing them. We wrote up the cross-boundary auth problem and the remaining gaps [2].
One thing the review misses: the .agent TLD. The .agent Community [3] (3,000+ members, 700+ companies) is going through ICANN's Community Priority Evaluation in the 2026 round to get `.agent` under community governance instead of corporate control. AID works on any domain today, but a community-governed TLD for agents is worth knowing about if you care about who controls the naming layer. Spec is at v1.2 [4].
Your conclusion — "define minimum interoperable layers and connect them with verifiable trust" — that's what we're after. DNS is the minimum viable trust anchor that already runs everywhere.
If any of this is interesting, you can join the community at agentcommunity.org.
We reviewed the current Agent Internet RFCs and wrote a technical position on where the architecture is solid and where it is still weak. The paper argues for a layered model that separates discovery, workload identity, delegated authorization, observability, and evaluation, and it also examines what changes once agents operate as hierarchical graphs rather than isolated endpoints.
If you are working on agent runtimes, registries, orchestration, MCP, A2A, trust infrastructure, or benchmarks, read it critically. The useful questions are not marketing questions but systems questions: what must be standardized now, what should remain loosely coupled, how should delegation chains be secured, and what telemetry is required to make multi-agent systems auditable in practice?
The layered architecture argument is right. Discovery, identity, and authorization should be separate concerns. AgentDNS tries to be all three plus billing and proxying, and that's how you get a single point of failure that controls everything.
We've been building the "narrowly scoped discovery" piece this review recommends. Agent Identity & Discovery (AID) [1] is a DNS TXT record at `_agent.<domain>` — endpoint, protocol, auth hint, optional Ed25519 public key. No registry, no proxy, no billing. Add one DNS record and any AID client finds your agent.
Works with MCP, A2A, OpenAPI, gRPC, GraphQL, WebSocket, local agents (Docker, npx, pip). SDKs in TS, Go, Python, Rust, .NET, Java. The discovery lookup is a single DNS query.
The optional PKA (Public Key Attestation) uses RFC 9421 HTTP Message Signatures with Ed25519 for endpoint proof. It sits underneath SPIFFE and OAuth rather than replacing them. We wrote up the cross-boundary auth problem and the remaining gaps [2].
One thing the review misses: the .agent TLD. The .agent Community [3] (3,000+ members, 700+ companies) is going through ICANN's Community Priority Evaluation in the 2026 round to get `.agent` under community governance instead of corporate control. AID works on any domain today, but a community-governed TLD for agents is worth knowing about if you care about who controls the naming layer. Spec is at v1.2 [4].
Your conclusion — "define minimum interoperable layers and connect them with verifiable trust" — that's what we're after. DNS is the minimum viable trust anchor that already runs everywhere.
If any of this is interesting, you can join the community at agentcommunity.org.
[1] https://aid.agentcommunity.org
[2] https://blog.agentcommunity.org/external_identity_anchor
[3] https://agentcommunity.org/about
[4] https://aid.agentcommunity.org/docs/specification
[5] https://github.com/andre-git/agent-internet-rfcs/issues/1