$ rfc new

Who this is for

This page is for people extending the AgentRoot protocol itself. It is not for consumers installing capabilities or publishers writing manifests for an existing record type. If you want to add a new type=* to the spec, propose a new transport, or attach a new payment scheme to a domain, you're in the right place.

For CLI bug reports, feature requests, or code contributions, the CLI lives at github.com/agent-root/cli (currently private, going public). For everything else (registry, web UI, MCP server), the surface is not yet open-source.

The RFC process

Protocol-level changes go through an RFC before code. The bar is: is this widely useful, and does it preserve DNS-as-source-of-truth?

1. Draft. Describe the use case and proposed shape. No code yet. Mail it to a maintainer or post it in the contact channel below.
2. RFC document. Once the discussion converges, write a short RFC document with the proposed shape, an example, and rationale. Until the public RFC repo exists, this lives wherever the discussion is happening.
3. Review. Maintainers review for protocol fit, back-compat, security, and DNS conformance. Two-week comment window for non-trivial changes.
4. Decision. Accepted RFCs land in the public RFC repo (once it exists) and the implementation tickets are filed. Rejected RFCs are kept with rationale for future reference.

Propose a new record type

Today the spec defines five record types: agent, mcp, skill, a2a, payment. New types are accepted when there is a clear capability class that does not fit cleanly into the existing five.

Worked example: the payment type was added after MPP and x402 surfaced as needing first-class fields (asset, network, methods) that did not fit agent or mcp.

What your proposal needs to cover:

• The capability class: what the new type represents in one sentence.
• Required fields, optional fields, and types (with a Zod schema if you can).
• How v=ar1 consumers should ignore it gracefully (forward-compat).
• One worked manifest example.
• Discovery story: how does a CLI, MCP server, or web UI render it?

Propose a new payment spec

The payment record already supports multiple payment methods (MPP, x402). To add a new one, like a Lightning-network spec or a fiat ACH spec, you do not need a new record type. You extend the payment type's methods, protocols, or assets enums.

What your proposal needs to cover:

• The settlement story: who pays whom, what is the asset, what is the network.
• Whether the spec needs new fields beyond the existing payment shape.
• A test domain you can publish against.
• How an AI agent decides between this and an existing method (e.g. MPP vs x402).

Propose a new transport

MCP records support sse, streamable-http, and stdio. Agent records support a2a, rest, graphql, websocket. New transports go through the same RFC flow.

Transports have a lower bar than new record types because they are additive. Focus your proposal on (a) the wire contract, (b) how clients negotiate fallback, and (c) at least one reference server implementation.

Get in touch

Two channels, different purposes: