Agent Transfer Protocol (AGTP)

1.1. Conventions and Specification Status

AGTP is a transfer protocol. A transfer protocol defines the semantics of an exchange: its methods, status codes, header fields, and, in AGTP, the identity, authority, delegation, and attribution carried with every exchange. A transport protocol delivers the bytes. TCP, TLS, and QUIC are transport; AGTP runs over them as specified in [AGTP-BINDINGS]. Throughout this document "transport" refers to those protocols and never to AGTP, and "substrate" names the role AGTP plays beneath agent group messaging protocols.¶

Every mechanism this document names is in one of four states, and the text says which when the state is anything other than specified:¶

Specified:

The mechanism is defined normatively in this document.¶

Specified and implemented:

Specified, and present in the reference implementation at github.com/nomoticai/agtp.¶

Planned:

Named, with its carrier reserved, and specified in a later revision. A planned mechanism guarantees nothing in the current revision.¶

Inherited:

Provided by a companion specification or an external standard. The dependency is named and the behavior when it is absent is stated.¶

A header field or body field is a carrier. A carrier by itself implies no claim; the claim exists when the verifier, the verification rule, and the failure behavior are specified.¶

Note Regarding Intellectual Property: Implementers should be aware that extensions and certain mechanisms referenced in this document (the Agent Certificate extension of [AGTP-CERT], the ACTIVATE method, the Agent Genesis mechanism, and the .agent and .nomo file format specifications of [AGTP-IDDOC]) may be subject to pending patent applications by the author. The core AGTP specification is intended for open implementation without royalty obligation. The licensor is prepared to grant a royalty-free license to implementers consistent with [RFC8179]. IPR disclosures: https://datatracker.ietf.org/ipr/; see also the Intellectual Property Considerations subsection of the Security Considerations.¶

1.2. Background

The deployment of AI agents and multi-agent systems is accelerating across enterprise, research, and consumer contexts. These systems execute complex, multi-step workflows, querying data sources, booking resources, delegating subtasks to peer agents, and escalating decisions to human principals, with minimal or no human supervision per transaction.¶

Unlike human-initiated web traffic, agent-generated traffic is dynamic, high-frequency, intent-driven, and often stateful across sequences of related requests. The infrastructure carrying this traffic was never designed with these properties in mind.¶

1.3. Limitations of HTTP for Agent Traffic

HTTP has served as the internet's primary application-layer transport for over three decades. Its evolution through HTTP/2 [RFC7540] and HTTP/3 [RFC9114] has improved performance, multiplexing, and latency. However, the fundamental model of HTTP being stateless, resource-oriented, human-initiated request/response, creates specific failures when applied to agentic systems at scale:¶

• Traffic indistinguishability: Agent-generated requests are identical to human-initiated requests on the wire. Operators cannot identify, route, or govern agent traffic without application-layer instrumentation.¶

• Method vocabulary mismatch: HTTP's method set (GET, POST, PUT, DELETE, PATCH) describes resource operations. Agent traffic expresses purposeful intent, summarize, book, delegate, escalate. The mismatch forces intent into request bodies, invisible to protocol-level handlers.¶

• Identity and attribution absence: HTTP carries no native mechanism for asserting agent identity, declared authority scope, or the principal accountable for an agent's actions.¶

• Session semantics mismatch: HTTP's stateless model is optimized for isolated request/response cycles. Agent workflows are stateful sequences.¶

1.4. Why Not Evolve HTTP?

A natural question is whether these limitations could be addressed by extending HTTP instead of defining a new protocol. There are three specific reasons why HTTP extension is the weaker path.¶

First, the wire image. HTTP's method registry is extensible under [RFC9110], and new methods can be registered; the constraint is the deployed base. An intent-named method such as SUMMARIZE, DELEGATE, or ESCALATE registered for HTTP would reach every HTTP client, proxy, cache, and middleware component as an unknown method, each handling it by its own default. AGTP instead presents a distinct wire image, with its own URI scheme and port, so that an intermediary either understands agent traffic or sees that it fails to, and nothing in the HTTP deployed base is asked to change its behavior. The case rests on this distinctness and on the failure cases documented in Section 4; HTTP's registry imposes no limit that the case depends on.¶

Second, HTTP carries decades of backward-compatibility constraints. Features such as persistent agent identity headers, authority scope declarations, and session-level governance semantics would require HTTP extensions that interact unpredictably with existing caching, proxy, and CDN behavior designed for human-generated traffic patterns.¶

Third, the observability goal making agent traffic distinguishable from human traffic at the infrastructure layer cannot be achieved by adding fields to HTTP. Infrastructure components route and filter HTTP traffic based on methods and headers that are identical across agent and human requests. A protocol-level separation is necessary to give infrastructure the signal it needs.¶

AGTP is therefore designed as a dedicated protocol. HTTP and AGTP coexist: human traffic continues to flow over HTTP; agent traffic flows over AGTP. The two protocols serve different classes of network participant.¶

Note: The abbreviation AGTP is used in this document to distinguish the Agent Transfer Protocol from the Authenticated Transfer Protocol (ATP) working group currently chartered within the IETF. The URI agtp:// is proposed for IANA registration as a new and distinct scheme.¶

1.5. Motivation for a Dedicated Protocol

These limitations are architectural. They cannot be resolved by better middleware or application code layered on HTTP. They require a protocol designed from first principles for AI agent systems.¶

AGTP is that protocol. It provides a dedicated transport environment for agent traffic with: native intent-based methods, mandatory agent identity headers, protocol-level authority scope declaration, and a status code vocabulary for the conditions AI systems encounter.¶

1.6. Scope and Target Audience

This document covers AGTP architecture, design principles, stack position, request and response header format, agent-native method definitions and semantics, status code vocabulary, security considerations, and IANA considerations.¶

The Agent Certificate extension for cryptographic binding of agent identity to AGTP header fields is described at a high level in Section 12.2. Full specification is provided in a separate companion document: [AGTP-CERT]. That extension may be subject to pending intellectual property claims; see Section 12.7 and the IPR Notice preceding the Abstract.¶

Merchant-side identity verification for PURCHASE counterparties is described at a high level in the Merchant Identity section of this document and specified in full in a separate companion: [AGTP-MERCHANT]. This document registers the merchant-related request headers, the 458 Counterparty Unverified status code, and the merchant and intent Authority-Scope domains; the Merchant Manifest Document, Merchant Agent Genesis, counterparty verification procedure, and Intent Assertion JWT format are specified in the companion.¶

Target audience: AI agent developers, protocol designers, cloud and network infrastructure providers, enterprise security and compliance architects, and standards community participants.¶

1.7. AGTP as the Transport Foundation for Agent Group Messaging Protocols

AGTP is the purpose-built transport and governance layer for Agent Group Messaging Protocols (AGMPs): the category of higher-layer AI agent messaging standards that includes the Model Context Protocol (MCP) [MCP], the Agent-to-Agent Protocol (A2A) [A2A], the Agent Communication Protocol (ACP) [ACP], and emerging others.¶

AGMPs define what agents say. AGTP defines how those messages move, who sent them, and under what authority. AGTP provides the narrow-waist foundation that AGMPs inherit without modification: intent-native methods, mandatory agent identity and scoping, resource budget enforcement, observability hooks, and normative composition profiles. A deployment running any AGMP over AGTP gains transport-level governance without changes to the messaging layer.¶

The AGMP category term is introduced in this document to provide a stable collective reference for the class of protocols that AGTP serves as substrate. It is a descriptive label and classification, with no standing as an IETF term of art. Individual AGMP specifications retain their own names and development paths; AGTP governs none of them, modifies none of them, and leaves each in force.¶

+-----------------------------------------------------+
|            Agent Application Logic                  |
+-----------------------------------------------------+
|  AGMP Layer: MCP / A2A / ACP / ANP  [optional]      |
+-----------------------------------------------------+
|   AGTP - Agent Transfer Protocol      [this spec]    |
+-----------------------------------------------------+
|            TLS 1.3+                  [mandatory]    |
+-----------------------------------------------------+
|         TCP / QUIC / UDP                            |
+-----------------------------------------------------+

2.1. Document Taxonomy

AGTP identity rests on three objects with one join key. The canonical Agent-ID is the SHA-256 of the Agent Genesis, so the Genesis is the root; the Agent-ID resolves to the Agent Identity Document; the Attribution-Record chain records what the agent did, anchored back to the Genesis through the Audit-ID of [AGTP-IDENTIFIERS].¶

Two terms outside this taxonomy appear in related work. "Agent Birth Certificate" is the retired name for the Agent Genesis; the object is unchanged. "Agent Card" names the A2A self-description served at a well-known HTTPS path and trusted through its domain; it is self-asserted, unsigned, and carries no lifecycle state or enforced scope. An Agent Identity Document maps to an Agent Card for interchange with a loss of those properties ([AGTP-DISCOVERY] specifies the mapping); an Agent Card maps to an Identity Document only at Level 1, with no issuer. An Agent Card and an Identity Document are different objects, and this family uses neither name for the other.¶

3.1. Substrate vs Application Layer Separation

AGTP provides substrate primitives. Adjacent layers (Agent Group Messaging Protocols, external identity providers, HTTP gateways, agent application logic) compose over the substrate. The substrate MUST NOT rely on application-layer cooperation for properties it provides; it MUST enforce them itself at the transport boundary.¶

This principle has direct consequences:¶

• Identity headers (Agent-ID, Owner-ID, Authority-Scope) are wire- layer facts the substrate verifies before dispatch to the application. They are never application-layer conventions an application is expected to honor.¶

• Authority enforcement happens at the protocol layer before application code runs. A scope violation returns 455 from the AGTP layer, before the application's authorization middleware is reached.¶

• Attribution is produced by the substrate on every response. An application cannot opt out of attribution, fail to produce it, or produce a malformed attribution that infrastructure cannot read.¶

The substrate's correctness is independent of the application implementing required behaviors. Vulnerabilities of the form "middleware was supposed to check X but checked Y instead" cannot arise in the substrate layer because the substrate enforces X itself, before any middleware runs.¶

3.2. Identity at the Wire

Agent identity is a wire-layer fact in AGTP. On HTTP it is an application-layer convention reconstructed from request properties.¶

Every AGTP request carries Agent-ID and Authority-Scope as structured headers verified at the AGTP layer, with Owner-ID resolved from the identity document the Agent-ID references ([AGTP-IDDOC]). Infrastructure components (load balancers, Scope-Enforcement Points, governance gateways) read these directly from the wire. They never reconstruct identity from hostnames, paths, query parameters, or application payloads. They never parse application content to determine which agent sent a request.¶

This principle eliminates an entire vulnerability class: bugs where application-layer code reconstructs identity (or authority, or routing decisions) from request properties that an attacker can manipulate. The reconstruction surface is absent in AGTP because identity is read from headers the protocol parses as identity; no header parsed for another purpose is ever reinterpreted as identity.¶

Vulnerabilities affecting HTTP-based agent infrastructure that depend on host header manipulation, URL reconstruction, path-based authorization middleware, or similar reconstruction patterns are structurally impossible on AGTP because AGTP never reconstructs identity from those properties.¶

Agent identity and workload identity are different concerns that compose. A workload identity credential of the kind the IETF WIMSE working group specifies authenticates the workload an agent runs on; the AGTP agent identity, bound to a certificate through [AGTP-CERT], persists across the workloads that host it. A mature deployment carries both, and neither substitutes for the other.¶

AGTP addresses both roles the agent literature distinguishes: the user agent, which acts for a person and owes that person loyalty, and the service agent, which acts for an organization and offers a capability to others. Every mechanism in this document holds for both. What differs is the Owner-ID the Identity Document carries, a person or an organization, and the governance policy that owner sets. The loyalty, protection, and honesty obligations of a user agent are that policy's content; the protocol carries the accountable owner and leaves the obligations to the owner and the governance platform.¶

3.3. Heteronomy: Agents Are Created by Humans

Agents lack autonomy in the strong sense. Every agent has a creator, an owner, and a governance context established outside the agent's own operation. AGTP's identity primitives reflect this fact.¶

• The Agent Genesis is signed by a registrar before any agent traffic exists. The Agent Genesis is the permanent governance-layer record of the agent's existence; the agent never creates its own Genesis.¶

• The Owner-ID identifies the human or organizational principal accountable for the agent. The owner is recorded on the Agent Genesis at registration; the agent asserts nothing about its owner at runtime.¶

• The Authority-Scope is granted by a principal at registration; the agent claims nothing at runtime that the grant omits. An agent MAY narrow its claimed scope on a specific request below its declared scope; an agent MUST NOT claim scope beyond what its Genesis grants.¶

• The Agent Certificate is issued by a Certificate Authority that validates the agent's Genesis-anchored identity. The certificate confirms an identity established outside the certificate; it asserts no identity of its own.¶

This architectural principle distinguishes AGTP from approaches that treat agents as self-asserting entities. An agent cannot register itself; an agent cannot grant itself authority; an agent cannot issue its own certificate. The trust root is the human or organizational authority that created the agent. AGTP makes this trust root visible at the wire layer through the identifier chain (Agent-ID, Owner-ID, issuing registrar).¶

The implications for governance, attribution, and accountability are substantial. An agent operating outside its granted authority is a governance failure (the protocol structurally prevents the out-of-scope action, so the protocol itself has held) traceable to the principal who granted the authority, the registrar who recorded it, or the operator who deployed the agent, each of whom the wire identifies.¶

3.4. Structural Enforcement, Not Policy Enforcement

Security properties in AGTP are structural --- they hold because the protocol's design eliminates the architectural pattern that creates the vulnerability, with no dependence on operators enforcing a policy correctly or middleware checking the right field.¶

The distinction matters in two ways:¶

Vulnerability impossibility vs vulnerability mitigation. A structural property holds because the protocol cannot express the vulnerable configuration. A policy property holds because operators correctly configure and enforce it; misconfiguration restores the vulnerability. AGTP's design prefers structural properties wherever the architecture allows.¶

Defense in depth vs defense by configuration. AGTP composes with application-layer security (input validation, application-specific authorization, business logic enforcement). AGTP leaves in place these. AGTP provides primitives that compose with application-layer security so that the combined system is stronger than either layer alone.¶

Concrete example: the BadHost vulnerability class (CVE-2026-48710 and similar) exists because HTTP-based agent infrastructure reconstructs URLs from the Host header and operates path-based authorization on the reconstruction. AGTP eliminates this vulnerability class by having no Host header to check, by parsing path and query as separate wire-layer tokens with no URL reconstruction, and by enforcing authorization on Authority-Scope with the path playing no part. The vulnerable configuration cannot be expressed on AGTP because AGTP lacks the architectural pattern that produces the vulnerability.¶

This principle applies to other vulnerability classes as well: scope escalation through header manipulation, attribution forgery through log gaps, and identity spoofing through certificate confusion are addressed by the structure of the protocol, with no policy to enforce.¶

3.5. Substrate Carries Its Own Operational Properties

Identity, authority, attribution, delegation chain, trust posture, and session state are properties of the substrate itself. Applications inherit them and layer nothing on to supply them.¶

This principle enables uniform infrastructure handling regardless of which adjacent layer is composed. An infrastructure component (load balancer, Scope-Enforcement Point, governance gateway, monitoring system) processes AGTP traffic identically whether the payload is an MCP tool call, an A2A task, an OAuth-credentialed request, an HTTP gateway translation, or a future protocol yet to be designed. The substrate's operational properties are visible to infrastructure at the wire layer.¶

The principle has economic and operational consequences:¶

• One governance layer covers all agent traffic. Operators never need separate enforcement for each AGMP. The AGTP governance layer handles MCP, A2A, ACP, ANP, and any future protocols uniformly.¶

• Audit and attribution compose across protocols. An attribution record produced by an EXECUTE invocation carrying an MCP tool call has the same structure as an attribution record produced by an EXECUTE invocation carrying an A2A task. Audit consumers never need protocol-specific parsing.¶

• Future-proof composition. Adjacent layers yet to be defined can compose with AGTP using the existing substrate properties. New AGMPs, new identity providers, new translation patterns benefit from substrate properties without negotiating each property anew.¶

Adjacent layers benefit from substrate properties without needing to implement them. Composition works because the substrate carries identity, authority, attribution, and audit; adjacent layers focus on what they contribute (tool semantics, conversational structure, authorization framework, REST translation).¶

4.1. Problem 1: Undifferentiated Agent Traffic on HTTP

AI agents generate intent-driven, structured traffic that is functionally invisible to the infrastructure it traverses. This traffic flows through HTTP alongside human traffic with no protocol-level differentiation. Observability failure, routing inefficiency, and security blindness result, operators cannot determine what fraction of traffic is agent-generated without application-layer instrumentation that is expensive, inconsistent, and easy to circumvent.¶

AGTP response: a dedicated protocol environment for agent traffic. Infrastructure can distinguish, route, monitor, and govern agent traffic natively.¶

4.2. Problem 2: Semantic Mismatch Between Agent Intent and Available Methods

AI agents operate on intent. HTTP's method vocabulary was designed to describe operations on resources; purposeful action has no place in it. When an agent intends to SUMMARIZE a document, EXECUTE a reservation, and PLAN a sequence, all three arrive as POST requests. The server receives identical verbs with meaningfully different intent buried in request bodies, invisible to any protocol-level handler.¶

AGTP response: a vocabulary of agent-native methods that express intent at the protocol level.¶

4.3. Problem 3: No Protocol-Level Identity, Authority, or Attribution for Agents

When an AI agent takes an action, there is currently no protocol-level mechanism to verify who authorized this agent, what scope of authority it holds, which principal is accountable for its actions, or whether it is the agent it claims to be. Accountability gaps, authority laundering, auditability failure, and multi-agent trust collapse result.¶

AGTP response: agent identity and authority scope embedded in protocol headers on every request, with an optional Agent Certificate extension for cryptographic verification.¶

4.4. Problem Summary

5.1. HTTP/REST as the De Facto Standard

HTTP remains the universal transport for all agent traffic currently deployed. REST conventions layered on HTTP provide a degree of semantic structure, but REST remains a resource-manipulation paradigm. As described in Section 1.4, evolving HTTP to address agent-specific needs is constrained by the frozen method registry, backward-compatibility requirements, and the impossibility of achieving infrastructure-level traffic differentiation through HTTP extensions alone.¶

5.2. Existing Agent Group Messaging Protocols

MCP [MCP] (Model Context Protocol, Anthropic):

Defines structured communication between AI models and tools/resources. Runs over HTTP. Addresses tool-calling semantics; the carriage of agent traffic is outside it.¶

ACP [ACP] (Agent Communication Protocol, IBM):

Defines messaging semantics for agent-to-agent communication. Runs over HTTP.¶

A2A [A2A] (Agent-to-Agent Protocol, Linux Foundation):

Defines inter-agent communication and task delegation semantics. Runs over HTTP.¶

ANP [ANP] (Agent Network Protocol):

Defines discovery and communication for networked agents. Runs over HTTP.¶

All of these are messaging protocols. They define what agents say to each other. None of them defines how agent traffic moves across a network. Each presupposes HTTP as its transport and inherits all of HTTP's limitations for agentic systems.¶

5.3. Transfer and Transport Alternatives

gRPC:

High-performance RPC over HTTP/2. Strong typing and efficient serialization. Leaves agent-specific semantics, identity, and authority.¶

WebSockets:

Persistent bidirectional connections over HTTP. Useful for real-time communication but leaves method semantics and identity unaddressed.¶

QUIC [RFC9000]:

Modern multiplexed transport with reduced connection overhead. QUIC is a transport primitive; AGTP is the application-layer protocol above it. AGTP's QUIC transport binding is specified in [AGTP-BINDINGS].¶

5.4. The Critical Distinction: Messaging vs. Transfer

The most important positioning principle for AGTP is the distinction between message formats and the transfer protocol that carries them. MCP, ACP, A2A, and ANP are messaging protocols: they define what agents say to each other. AGTP is the transfer protocol: it defines the exchange that moves those messages, and the identity, authority, and attribution carried with each one.¶

An analogy: HTTP transfers HTML. HTML defines what a page says; HTTP defines the exchange that delivers it, with its own methods, status codes, and headers. HTML cannot replace HTTP, and saying "HTTP is unnecessary because HTML exists" is a category error. SMTP and the Internet Message Format stand in the same relation. MCP and its peers are the message formats of agent traffic. AGTP is the transfer protocol, and TCP, TLS, and QUIC beneath it are the transport.¶

5.5. Discovery and Naming

Agent discovery is specified in [AGTP-DISCOVERY] and [AGTP-PRESENCE], and this document carries only the identity commitments those documents build on. The Canonical Agent-ID is permanent identity; the current location of an agent is a short-lived, signed, updatable record the substrate resolves it to. Following RFC 6763, "discover" names the resolution of a known identity to a reachable attachment, and "search" names the capability-class query that returns candidate identities. An agent name (a friendly label or a domain-anchored alias) and an agent address (a URL or network address) are aliases for the Agent-ID; the identity is the Agent-ID alone. Work on agent discovery in the IETF DAWN effort is treated as adjacent in [AGTP-DISCOVERY], which specifies the mapping between the AGTP Agent Identity Document ([AGTP-IDDOC]) and the record shape the DAWN work describes agents with (the A2A AgentCard in its initial revision).¶

5.6. AGTP Positioning: The Proposed Stack

+-----------------------------------------------------+
|            Agent Application Logic                  |
+-----------------------------------------------------+
|  Messaging Layer  (MCP / ACP / A2A)  [optional]     |
+-----------------------------------------------------+
|   AGTP - Agent Transfer Protocol     [this spec]    |
+-----------------------------------------------------+
|            TLS 1.3+                  [mandatory]    |
+-----------------------------------------------------+
|         TCP / QUIC / UDP                            |
+-----------------------------------------------------+

AGTP replaces no messaging protocol. Agents using MCP or A2A route those messages over AGTP and gain transport-level observability and identity without modifying the messaging layer. AGTP-native agents that use no separate messaging protocol interact with AGTP methods directly.¶

6.1. Stack Position

AGTP is an application-layer protocol. It operates above the transport layer and is wrapped by TLS. It sits below any agent messaging protocol in deployments that use one.¶

AGTP is transport-neutral: AGTP semantics are independent of which transport carries them. Transport bindings for TCP/TLS and QUIC are specified in [AGTP-BINDINGS], including the AGTP-specific replay- safety profile that governs early-data use over QUIC. Selection between supported transports is a deployment-time choice based on operator infrastructure, counterparty ecosystem, and latency requirements; this specification establishes no normative preference between transports.¶

AGTP uses port 4480 (TCP and UDP), assigned by IANA under the service names agtp (TCP/TLS) and agtp-quic (QUIC). The port assignment is permanent and applies to all AGTP transports. Full IANA registration metadata is documented in Section 13.1.¶

6.2. Design Principles

Minimalist core:

The base spec defines only what is necessary for agent traffic differentiation, method semantics, and identity headers. Extensions belong in companion specifications.¶

Extensible by design:

New methods are registered through an IANA-managed Method Registry. New header fields follow a defined extension convention. Additive changes require no version increment.¶

Agent-native:

Every design decision assumes the initiating party is an AI system. Human-initiated traffic belongs on HTTP.¶

Secure by default:

TLS 1.3 or higher is mandatory. Unencrypted AGTP connections MUST be rejected. Agent identity headers are present on every request.¶

Observable by design:

Native metadata in every AGTP header provides the minimum information needed for routing, monitoring, and audit without application-layer instrumentation.¶

Composable:

AGTP works alongside existing agent messaging protocols without requiring modification to those protocols.¶

Runtime contract negotiation:

AGTP fixes the protocol surface at eighteen methods. Beyond that floor, the surface is open. An agent that needs an endpoint the server has yet to advertise proposes the endpoint via PROPOSE with an AGTP-METHODS endpoint definition; the server evaluates whether it can synthesize the endpoint from existing capabilities and either instantiates it as a session-scoped endpoint or refuses. The negotiation completes in a single round-trip. See Section 6.3.¶

6.3. AGTP as a Runtime Contract Negotiation Substrate

AGTP is a runtime contract negotiation substrate (RCNS). The substrate fixes a floor of eighteen protocol-level methods (the cognitive, mechanics, and lifecycle verbs of Section 8.1); beyond that floor, the method and endpoint surface a server presents is declared by the operator in the vocabulary of [AGTP-METHODS] or negotiated at runtime between the agent and the server through the PROPOSE floor method, in a single round-trip, as specified in [AGTP-RCNS].¶

This document carries the kernel: the PROPOSE method (Section 8.1), the negotiation status codes 261, 262, 263, 461, 463, and 464 (Section 6.6), the reason vocabulary for 461 and 464, the Allow-RCNS, Contract-Synthesized, and Idempotency-Key headers (Section 6.5), and the rcns_* lifecycle events (Section 7.3.7). The dispatcher gate, delivery modes, contract scoping and lifecycle, recipe versioning, and the inventory surfaces are specified in [AGTP-RCNS]. A server that implements this document and [AGTP-METHODS] without [AGTP-RCNS] is conformant and refuses unregistered method and path pairs with 404 or 405.¶

The RCNS property makes composition with higher-level agent frameworks (Section 10) tractable: a server that wants to expose a framework-specific operation as a first-class AGTP endpoint negotiates it at runtime, with no registry to wait for.¶

6.4. Connection Model

AGTP uses a persistent session model by default, reflecting the reality that agents typically execute multi-step workflows; an isolated single request is the exception. An AGTP session is established with a single TLS handshake including agent identity assertion, persists across multiple method exchanges, carries a Session-ID header identifying the agent's task context, and terminates on explicit session close or inactivity timeout (RECOMMENDED minimum: 60 seconds).¶

Per-request (stateless) mode is supported for constrained environments. In stateless mode, agent identity headers MUST be present on every individual request.¶

6.5. Header Format

The AGTP wire format puts the protocol version and method on the request line (AGTP/1.0 METHOD PATH\r\n) and the status code on the response line (AGTP/1.0 STATUS STATUS-TEXT\r\n). Headers MUST NOT carry information already present on those lines: there is no AGTP-Version header, no AGTP-Method header, no AGTP-Status header. The version and method are read from the request line; the status is read from the response line.¶

request-line   = agtp-version SP method SP request-target CRLF
agtp-version   = "AGTP/1.0"
method         = token                  ; per {{AGTP-METHODS}} catalog
request-target = path-absolute [ "?" query ]
                                        ; per RFC 3986
path-absolute  = "/" [ segment-nz *( "/" segment ) ]
                                        ; per RFC 3986 Section 3.3
query          = *( pchar / "/" / "?" )
                                        ; per RFC 3986 Section 3.4

response-line  = agtp-version SP status-code SP status-text CRLF
agtp-version   = "AGTP/1.0"
status-code    = 3DIGIT                 ; per {{status-codes}}
status-text    = *( VCHAR / SP / HTAB )
                                        ; freeform reason phrase

{
  "m":   "<method>",
  "p":   "<path>",
  "aid": "<Agent-ID>",
  "as":  "<Authority-Scope header value, or null>",
  "dc":  "<SHA-256 of the Delegation-Chain header value, or null>",
  "bd":  "<SHA-256 of the request body, or null when empty>",
  "iat": <issued-at, seconds since epoch>,
  "n":   "<nonce, at least 96 bits, base64url>"
}

6.6. Status Codes

AGTP defines its own status code space. Codes 261 through 263, 455 through 465, and 550 through 555 are AGTP-specific with no HTTP equivalent and are registered in the IANA AGTP Status Code Registry (see Section 13.3). AGTP-specific code numbers are chosen from ranges unassigned in the IANA HTTP Status Code Registry to avoid semantic collision with HTTP status codes that may appear in payloads carried by AGTP method invocations.¶

The AGTP status code model carries four structural rejection codes (404, 405, 459, 460) that together cover the failure surface for contract-level invocation. Each code is independently actionable: 404 indicates the path is absent from this server; 405 indicates the verb and path are each individually valid but the server exposes no endpoint at that combination; 459 indicates the verb is absent from the AGTP-METHODS approved method catalog; 460 indicates the path violates AGTP-METHODS path grammar. The structural rejection model and the curated method catalog are specified in [AGTP-METHODS].¶

The four structural rejection codes (404, 405, 459, 460) form the contract-level structural failure surface and have distinct recovery semantics. A 459 tells the agent to choose a different method from the AGTP-METHODS catalog. A 460 tells the agent to restructure the path so that no path segment is a method name. A 405 tells the agent the method and path are each individually valid but the failure is a server policy decision; a different method-and-path combination might work, or PROPOSE might negotiate access. A 404 tells the agent the path is absent from this server altogether. Beyond the structural surface, 463 (Proposal Rejected) is the runtime negotiation rejection: the agent's PROPOSE was structurally valid but the server cannot or declines to synthesize the requested endpoint.¶

Status code 262 (Authorization Required) consolidates the authority-related rejection conditions an agent might encounter when interacting with a server. It is returned when: (a) a PROPOSE request requires credential establishment before the server will evaluate it; (b) an endpoint invocation requires Authority-Scope that the agent has yet to declare; (c) an ad-hoc method invocation requires wildcards consent (wildcards: true on the agent identity document and wildcards_accepted: true in server policy) that is absent on either side; or (d) a discovery request is blocked by server policy that requires authenticated identity for manifest retrieval. The response body MUST identify which condition applies so the agent knows what to remediate.¶

The rule separating 262 from 455 is obtainability. 262 Authorization Required is returned when the authorization the request lacks is one the agent could obtain without exceeding what it holds: a credential it has yet to establish, a consent it has yet to give or receive, or a scope its identity document grants but the request omitted from its claim. 455 Scope Violation is returned when the request exceeds the authority the agent holds: a claimed scope beyond the document's grant, an endpoint requiring a scope the document omits, or a delegation granting more than the delegator's effective scope. Earlier revisions used both codes for Authority-Scope failures in different sections; this revision applies the rule above throughout. 455 also covers operator-defined scope dimensions outside the standard set. Status code 456 (Budget Exceeded) is the dedicated code for resource-consumption scope violations: the agent's requested action would consume resources beyond what the principal authorized for this invocation. Status code 457 (Zone Violation) is returned by SEPs when a DELEGATE request would route to an agent outside the declared zone boundary. Status code 458 (Counterparty Unverified) is returned on PURCHASE invocations when the receiving server cannot verify that the requesting agent has performed valid merchant identity verification against the server's current Merchant Manifest Document, or when the merchant is in a non-Active lifecycle state; see [AGTP-MERCHANT].¶

Status code 551 (Authority Chain Broken) is returned when a server processing a delegated request cannot verify the Delegation Sequence carried in the Delegation-Chain header per Section 9. The response body MUST carry the reason token and SHOULD identify the failing hop. Status code 408 (Timeout) is reused from HTTP with AGTP-specific semantics: it signals that the method's declared TTL expired before execution completed, distinct from HTTP's request-timeout semantics. Status code 410 (Gone) is reused from HTTP with AGTP-specific semantics: it indicates that an Agent-ID has been permanently retired through REVOKE of its Agent Genesis, distinct from HTTP's resource-removed semantics. A Deprecated agent does NOT return 410; deprecation signals planned end-of-life while the agent continues to serve traffic (see DEPRECATE in Section 8.2.18). The canonical Agent-ID of a retired agent MUST NOT be retried. All AGTP-specific status codes are operational signals, distinct from protocol errors, and MUST be logged for audit purposes.¶

6.7. Wire Format and Content-Type

AGTP request and response bodies are encoded as JSON or YAML. The following media types are defined by AGTP. Their IANA registration status varies; see the IANA Considerations section for the authoritative status table.¶

Two additional media types are defined in the companion AGTP-METHODS specification [AGTP-METHODS] and registered concurrently: application/vnd.agtp.manifest+json (server manifest) and application/vnd.agtp.endpoint+json (endpoint definition). Both are listed in the master Media Type Registry section of this document for cross-document discoverability.¶

Implementations MUST include the appropriate Content-Type on all AGTP requests and responses that carry a message body. Responses with no body (e.g., 204 No Content) MUST NOT include a Content-Type header. Binary or streaming extensions MAY define additional Content-Type values as part of their companion specifications.¶

EXECUTE method invocations carry application-layer payloads whose Content-Type is set by the carried application protocol (for example, application/vnd.mcp.tools+json for MCP tool invocations carried over AGTP). The AGTP server dispatches based on the carried Content-Type; see Section 8.2.8 and Section 10.¶

The common structure for AGTP method-level request bodies:¶

{
  "method": "QUERY",
  "task_id": "task-0042",
  "session_id": "sess-a1b2c3d4",
  "parameters": { },
  "context": { }
}

And for AGTP method-level response bodies:¶

{
  "status": 200,
  "task_id": "task-0042",
  "result": { },
  "attribution": { }
}

6.8. Early Implementations

AGTP is a proposed specification. No production implementations exist at the time of this writing. The author encourages early prototype implementations to validate the protocol design, identify gaps, and generate feedback prior to IETF working group submission.¶

• If you are building an AGTP prototype or reference implementation, please share your findings via the feedback channel listed on the cover of this document. A reference implementation in Python and/or Go is planned as open-source software concurrent with or shortly after IETF I-D submission. Implementation reports are welcome and will be incorporated into subsequent draft revisions.¶

Implementers wishing to experiment before final IANA port assignment SHOULD use a locally-chosen port from the Dynamic Ports range (49152-65535) on developer-controlled endpoints. Implementations MUST NOT publish or document any specific port number as an AGTP-associated value until IANA assignment is complete.¶

ACTIVATE is one of the three Lifecycle methods on the eighteen-method floor; see Section 8.2.14. Earlier revisions of this document described ACTIVATE as an optional method extension carried in a separate companion. With the promotion of the Lifecycle group to the embedded floor, ACTIVATE, DEACTIVATE, and REVOKE are all core methods; any conformant AGTP implementation MUST support them. Package-binding semantics specific to .nomo governed packages remain governance-platform-specific and MAY be layered on top of the protocol-level ACTIVATE transaction without affecting the wire contract.¶

7.1. URI Structure and Resolution Mechanics

Form 1.  Canonical identity (cryptographic, authoritative):
  agtp://[Agent-ID]

Form 1a. Canonical identity with explicit host (direct addressing):
  agtp://[Agent-ID]@[host]

Form 2.  Server-level discovery (specific server endpoint):
  agtp://[host]

Form 2a. Organization-level discovery (DNS-registered domain root):
  agtp://[domain]

Form 3.  Domain-anchored agent (domain owns the namespace):
  agtp://[domain]/agents/[agent-name]

Form 4.  Subdomain-anchored agent (dedicated AGTP subdomain):
  agtp://agtp.[domain]/agents/[agent-name]

agtp://7f3a9c2d...e1f8b0a4

agtp://7f3a9c2d...e1f8b0a4@agents.acme.com
agtp://7f3a9c2d...e1f8b0a4@192.0.2.42
agtp://7f3a9c2d...e1f8b0a4@agents.acme.com:9999

agtp://agents.acme.com
agtp://agtp-edge-7.us-east.acme.com
agtp://192.0.2.42
agtp://[2001:db8::42]
agtp://agents.acme.com:9999

agtp://acme.com
agtp://example.org

Form 3: agtp://acme.com/agents/bookbot
Form 4: agtp://agtp.acme.com/agents/bookbot

AGTP-URI     = "agtp://" agtp-locator
agtp-locator = agent-id [ "@" host ]                 ; Form 1, 1a
             / host                                    ; Form 2
             / domain                                  ; Form 2a
             / domain "/agents/" agent-name            ; Form 3
             / "agtp." domain "/agents/" agent-name    ; Form 4
agent-id     = 64HEXDIG                               ; lowercase hex
host         = IP-literal / IPv4address / reg-name [ ":" port ]
                                                      ; per RFC 3986
domain       = label *("." label)                     ; DNS-registered, no port
label        = ALPHA *( ALPHA / DIGIT / "-" )
agent-name   = 1*( ALPHA / DIGIT / "-" / "_" )
port         = 1*DIGIT
                                                      ; OPTIONAL; defaults to 4480

METHOD agtp://[locator]/[endpoint-path]

agtp://acme.tld/agents/customer-service
  → 301 → agtp://agtp.acme.tld/agents/customer-service

{
  "agtp_version": "0.7",
  "endpoint": "agtp://agtp.acme.tld/agents",
  "namespace_root": "agtp://acme.tld/agents",
  "verification": {
    "dns_anchor": "_agtp.acme.tld",
    "log_anchor": null
  },
  "issuer": "https://ca.acme.tld",
  "discovery": {
    "namespace_document": "https://agtp.acme.tld/agents.json",
    "well_known_updated_at": "2026-04-30T00:00:00Z"
  }
}

7.2. Agent Identity Document (Summary)

Every Canonical Agent-ID resolves to an Agent Identity Document: a signed application/vnd.agtp.identity+json document that carries the agent's Owner-ID, its declared Authority-Scope set, its trust posture fields, its supported methods and content types, and the issuer binding that makes the document tamper-evident. The Agent Namespace Document, the .agtp package format, the human-readable identity view served to browsers, and the status sub-resource are specified in [AGTP-IDDOC]. This document carries only what the protocol depends on:¶

• The document is the authority for the Owner-ID (which MAY be a Legal Entity Identifier bound per [AGTP-LEI]) and the full Authority-Scope set; a request's claimed Authority-Scope is validated as a subset of it (Section 6.5).¶

• The document is signed, and the signature is verified before any field is trusted ([AGTP-IDDOC] specifies the integrity and freshness rules). When the optional issuer fields are absent the document is verifiable at Level 1 only ([AGTP-CERT] supplies Level 3).¶

• Resolution of an Agent-ID to its document follows [AGTP-DISCOVERY]; the media types are registered in Section 13.4.¶

7.3. Agent Registration Process

1. PACKAGE
   Author creates .agent or .nomo package containing:
   - Embedded manifest (agent_label, job_description,
     authority_scope_categories, supported_methods,
     trust_score)
   - Integrity hash of all package contents
   - For .nomo: CA-signed certificate chain

2. SUBMIT (ACTIVATE transaction)
   Registrant submits ACTIVATE request to governance endpoint:
   - Package file (.agent or .nomo)
   - Proposed agent label and optional org_domain or org_label
   - Owner identity (maps to Agent Genesis owner field)
   - Archetype declaration
   - Declared trust_tier and verification_path with corresponding
     tier-specific evidence (see {{AGTP-TRUST}} for the evidence
     required by each verification path)

3. VALIDATE (governance platform)
   Governance platform:
   - Verifies package integrity hash
   - For .nomo: validates certificate chain
   - Applies verification-path-specific validation per
     {{AGTP-TRUST}} (DNS challenge, transparency log submission,
     or hybrid evidence verification, depending on declared path)
   - Checks proposed label for uniqueness within the relevant
     namespace (org_domain, org_label, or log-scoped)

4. ISSUE (Agent Genesis and canonical Agent-ID assigned)
   Governance platform:
   - Issues Agent Genesis with all fields populated,
     including trust_tier and verification_path
   - Computes canonical Agent-ID as
     `sha256(canonical_form(Agent_Genesis_without_signature))`
   - For log-anchored Tier 1: submits Agent Genesis to
     transparency log and embeds inclusion proof in the registry
     record (see {{AGTP-LOG}})
   - Creates registry record with Active lifecycle state
   - Records genesis audit entry in immutable audit log
     (genesis record includes full Agent Genesis and
     verification evidence)
   - Publishes agent to Namespace Document
     (triggers Namespace Document re-signing)

   The Agent Genesis is delivered to the registrant.
   It is the permanent record of the agent's genesis.
   Loss of the Agent Genesis leaves the agent valid;
   the canonical Agent-ID derived from the original Agent
   Genesis remains the authoritative identity anchor.

5. ACTIVE
   Agent enters Active lifecycle state.
   Canonical Agent-ID is valid for AGTP protocol sessions.
   All applicable alias URIs resolve to the Agent Identity
   Document derived from the Agent Genesis.

6. LIFECYCLE EVENTS (post-activation)
   The five Lifecycle methods on the protocol floor
   ({{methods-section}}) drive post-activation state
   transitions. Each transition produces a signed lifecycle
   event in the agent's per-agent lifecycle stream and is
   retrievable via `INSPECT target=lifecycle`.

   DEACTIVATE: Agent temporarily inactive. Identity Document
               returns 503. Agent Genesis and canonical
               Agent-ID remain valid. Initiated by trust
               violation or operator decision. See
               {{methods-deactivate}}.
   REINSTATE:  Operator-authorized return to Active from
               Suspended. Agent Genesis unchanged. Recorded
               in the lifecycle stream. See
               {{methods-reinstate}}.
   REVOKE:     Agent permanently retired. Identity Document
               returns 410. Agent Genesis archived. Canonical
               Agent-ID retired permanently and never
               reissued. See {{methods-revoke}}.
   DEPRECATE:  Controlled end-of-life. Agent continues to
               serve traffic; deprecation event signals
               planned retirement and **MAY** carry a
               `successor_agent_id` and a `migration_deadline`.
               Agent Genesis retained per the retention policy
               in this section. See {{methods-deprecate}}.

8.1. Design Philosophy

AGTP methods are intent verbs. Each method expresses what an agent is trying to accomplish, where an HTTP method names an operation on a resource. Method names are uppercase ASCII strings. Methods that modify state are NOT idempotent by default unless explicitly marked. All methods accept a context parameter carrying agent session state. Requirement language follows [RFC2119].¶

8.2. Core Methods

The eighteen core methods are presented below in the cognitive group followed by the mechanics group, then the lifecycle group. The four methods present in v06 core that are absent from the v07 floor (BOOK, SCHEDULE, LEARN, COLLABORATE) are demoted to Tier 2 standard extended methods; their specifications continue to apply where implementations choose to support them, and they are catalogued in the AGTP-METHODS method catalog ([AGTP-METHODS]).¶

{
  "methods": ["QUERY", "DISCOVER", "DESCRIBE", "SUMMARIZE", "PLAN",
              "PROPOSE", "EXECUTE", "DELEGATE", "ESCALATE", "CONFIRM",
              "SUSPEND", "NOTIFY"],
  "modalities": ["text", "image", "streaming"],
  "tools": ["web_search", "code_execute"],
  "version": "0.7",
  "version_min_satisfied": true,
  "trust_score": 0.94,
  "budget_units_accepted": ["tokens", "compute-seconds"],
  "zones_accepted": ["zone:internal", "zone:partner"]
}

{
  "suspension_id": "susp-0042",
  "session_id": "sess-a1b2c3d4",
  "resumption_nonce": "[128-bit random value, base64url]",
  "resume_by": "2026-04-15T09:00:00Z",
  "status": "suspended"
}

8.3. Method Summary Table

8.4. Method Registry and Extensibility

AGTP defines a formal Method Registry maintained by IANA (see Section 13.2). Any party may submit a new method for registration. The registration procedure is Expert Review, and registration MUST be accompanied by a published specification, at minimum an IETF Internet-Draft or equivalent publicly available document. Registered methods MUST:¶

1. Have a unique uppercase ASCII name¶

2. Define required and optional parameters¶

3. Define expected response structure¶

4. Specify idempotency behavior¶

5. Specify applicable error codes¶

6. Include a security considerations section¶

7. Be accompanied by a published reference specification (Internet-Draft or RFC)¶

8. Appear in the AGTP-METHODS approved method catalog [AGTP-METHODS]. The verb list is the authoritative source for what method names are recognized by AGTP servers; registered methods are a subset of the method catalog with formal IETF registration. Submissions whose method name is absent from the AGTP-METHODS method catalog MUST be rejected by the Designated Expert.¶

Experimental methods MAY be used prior to registration using the X- prefix convention (e.g., X-NEGOTIATE). Experimental methods MUST NOT be used in production deployments without registration. Experimental methods are subject to verb-list validation; non-conformant experimental methods MUST be rejected with 459 Method Violation by AGTP-aware infrastructure components.¶

Negotiation-ID: 550e8400-e29b-41d4-a716-446655440000

8.5. Dynamic Endpoint Negotiation (Summary)

An agent that needs a method or endpoint the server has yet to declare submits a PROPOSE request carrying an endpoint definition in the form specified by [AGTP-METHODS]. The server evaluates the proposal against the method catalog, path grammar, its own policy, and the four-lock dispatcher gate, and answers with 263 Proposal Approved (the endpoint is synthesized and the response names it), 261 Negotiation In Progress, 262 Authorization Required, or 463 Proposal Rejected with a structured reason. A server may also treat an unregistered method and path pair as a synthesis candidate without a PROPOSE, delivering a contract with 461 RCNS Contract Available or inline under a Contract-Synthesized header. The full negotiation protocol, including contract scoping, lifecycle, and revocation, is specified in [AGTP-RCNS].¶

8.6. Extended Method Vocabulary (Summary)

Methods beyond the eighteen-method floor are registered in the catalog specified by [AGTP-METHODS]: at catalog version 1.0.0, 425 methods in nine categories, with the floor as the embedded set and the five HTTP verbs mapped to their preferred AGTP forms as legacy entries. Industry profiles, custom methods declared in a server's method policy, and the method properties (safe, idempotent, action, authority-bearing) are specified there, with the empirical basis for intent-named methods documented in [HOOD2026]. A method name in neither the floor nor the catalog nor the server's custom set is refused with 459 Method Violation; a path that leaks a method name is refused with 460 Endpoint Violation.¶

9.1. The Delegation Sequence

A Delegation Sequence is the ordered set of DELEGATE invocations that produced a request. Each hop is minted by one DELEGATE invocation (Section 8.1) and consists of:¶

• the delegating agent's canonical Agent-ID (the parent),¶

• the sub-agent's canonical Agent-ID (the delegate),¶

• the authority_scope granted to the delegate, which MUST be a strict subset of the parent's effective Authority-Scope at the time of minting, and¶

• the delegation_token: the parent's signature over the three fields above, the parent's own hop (or the token origin for the first hop), the minting time, and an expiry.¶

The strict-subset rule is enforced at mint: a server processing a DELEGATE whose authority_scope falls outside a strict subset of the delegating agent's effective scope MUST refuse with 455 Scope Violation and reason scope-exceeds-parent (Section 6.6). Same-scope relay, where a delegate exercises exactly its parent's scope, is therefore outside delegation; it is a request the parent makes itself, with the relay as transport. The rule is also enforced at verify (Section 9.3), so a sequence minted by a non-conformant server fails at the first conformant verifier.¶

9.2. The Delegation-Chain Header

A request made under delegated authority MUST carry the Delegation-Chain header. A request the agent makes under its own authority MUST NOT carry it. The header carries the Delegation Sequence as an ordered list of hops, origination to current:¶

Delegation-Chain = hop *( OWS "," OWS hop )
hop              = agent-id ";" delegation-token
agent-id         = 64HEXDIG          ; canonical Agent-ID
delegation-token = 1*( ALPHA / DIGIT / "-" / "_" )   ; base64url JWS
OWS              = *( SP / HTAB )

The first hop names the originating agent and carries its token signed over origin. Each subsequent hop names the delegate of the previous hop. The last hop names the agent making the request, whose Agent-ID MUST equal the request's Agent-ID header.¶

{
  "parent":    "<parent Agent-ID, or the literal origin>",
  "delegate":  "<delegate Agent-ID>",
  "scope":     [ "<scope-token>", ... ],
  "parent_tok":"<SHA-256 of the parent hop's token, or null>",
  "iat":       <minting time, seconds since epoch>,
  "exp":       <expiry, seconds since epoch>,
  "depth":     <0 for the origin hop, parent depth plus 1 after>,
  "authority": "<digest reference to an authority assertion, or null>"
}

9.3. Verification

A server receiving a request with a Delegation-Chain header MUST verify the sequence before dispatch, in order from the first hop to the last. Verification is a function of a fixed input set: the header as received, the request's Agent-ID and Authority-Scope, the verification time, the server's configured maximum depth, and the Identity Documents and lifecycle states resolved for the listed Agent-IDs. A verifier MUST NOT consult any other input and MUST NOT apply local policy inside verification; the relying party applies its policy to the result afterwards, so that two conforming verifiers given the same inputs produce the same result. For every hop the verifier MUST check:¶

1. Membership. The hop's Agent-ID resolves ([AGTP-DISCOVERY]) to an agent in the Active lifecycle state. Failure reason: member-inactive.¶

2. Parent re-verification. The hop's delegation token verifies under the parent's published key, and the parent named in the token equals the previous hop's Agent-ID (or origin for the first hop). A token that verifies under a key other than the listed parent's, or that names a different parent, is a parent swap. Failure reason: link-unverifiable.¶

3. Attenuation. The hop's granted scope is a strict subset of the parent's scope as carried in the parent's hop (for the first hop, of the originating agent's identity-document scope). Failure reason: scope-exceeds-parent.¶

4. Freshness. The hop's token is unexpired, and the minting time is no earlier than the parent hop's minting time. Failure reason: chain-expired.¶

5. Depth and cycles. The sequence length is within the server's configured maximum depth (default 8), and no Agent-ID appears twice. Failure reasons: depth-exceeded, cycle-detected.¶

Verification has three outcomes. It is valid when every check passes; invalid when any check fails on an input the verifier holds; and indeterminate when a check cannot run because an input is unavailable (an Agent-ID that cannot be resolved, a lifecycle state the registry failed to answer for, an Identity Document that failed to fetch). An indeterminate outcome is never reported as valid and never reported as invalid; it is carried as 551 with evaluation: incomplete and missing_input naming the input (Section 6.6.1), and the relying party MUST deny by default. A verifier that is offline for the registry therefore produces indeterminate for every delegated request; the alternatives, admitting on stale state or refusing as if the chain were broken.¶

The accepted result of a valid verification is the effective scope: the scope of the last hop, which by construction is the intersection of every hop's scope with the origin's. The request's claimed Authority-Scope, when present, MUST be a subset of the effective scope; the endpoint's required_scopes are evaluated against the claimed or effective scope exactly as for an undelegated request (Section 6.5). Verification MUST be repeated on every request; a verified sequence MUST NOT be cached as authority across requests, since membership and freshness change.¶

9.4. Failure Behavior

A verification failure MUST be refused with 551 Authority Chain Broken, with evaluation: refused for an invalid outcome or evaluation: incomplete for an indeterminate one, the reason token from the list above (or input-unavailable with missing_input when indeterminate), and, in failing_hop, the zero-based index of the hop that failed. The server MUST NOT dispatch any part of the request, MUST log the event, and MUST produce an Attribution-Record for the refusal as for any failure (Section 6.6.1). A request whose Agent-ID differs from the last hop's Agent-ID is refused with 551 and reason link-unverifiable. A Delegation-Chain header on a request whose method is a lifecycle method (Section 8.1) is refused with 551 and reason scope-exceeds-parent, since lifecycle authority is never delegable.¶

9.5. Evidence of the Delegator's Authority

A verified Delegation Sequence proves that no hop exceeds its parent and that the origin hop is within the originating agent's Identity Document grant. It proves that the registrar that issued the agent recorded that grant; it leaves unproven that the person or organization behind the registrar could lawfully confer it. For most traffic the registrar's record is sufficient. Where a relying party in another administrative domain needs the stronger statement (a bank receiving a payment instruction from a broker's agent needs to know that the broker's signatory could delegate payments at all), AGTP carries the evidence; producing it is the authority source's job.¶

The origin hop's authority field MAY carry a digest reference to an authority assertion: a signed statement from an authority source, separate from the sequence, of the powers the delegator could delegate. AGTP defines no authority assertion format of its own. Two are recognized: the vLEI Role Credential chain (OOR, ECR, AUTH) carried per [AGTP-LEI], whose AUTH credential names the human signatory and the role under which the agent was authorized; and the Authority Assertion of the WIMSE agent mandate work, when the relying party's trust framework accepts it. A verifier that is asked by policy to require authority evidence MUST check that the assertion's delegator matches the origin hop's Owner-ID and that the origin hop's scope is within the assertion's stated powers; an origin hop with no authority reference under such a policy is indeterminate with missing_input: authority.¶

Typed constraints on delegated authority (bounded amounts, time windows, accumulated budgets, co-signature thresholds) are the natural next step for payment-grade delegation. AGTP's Authority-Scope is a token set and Budget-Limit is its only numeric constraint; a constraint vocabulary over scope tokens is planned.¶

9.6. Mapping to the WIMSE Chain Convention

The multi-hop convention converging across the WIMSE agent identity work carries three claims: sub is the principal at every hop, client_id is the current actor, and act is the history of prior actors. AGTP carries the same three facts in its own elements, and a Delegation Sequence maps onto the convention without loss:¶

Narrowing follows the subset rule stated in that work: what a hop passes on is a strict subset of what it received, token by token over the Authority-Scope grammar, the narrowing party signs the hop, and a party that forwards without narrowing makes no authorization claim and appears in no hop.¶

AGTP states its staleness bound as S plus L. S is the maximum age of the authorization state a verifier relied on when it admitted a request: the Identity Document freshness window of [AGTP-IDDOC] and the Request-Signature acceptance window (Section 6.5.4). L is the maximum lifetime of a hop's delegation token without re-validation, which is the token's expiry checked at step 4 of Section 9.3; L MUST NOT exceed 24 hours and SHOULD be shorter for action methods. The bound limits new admissions; an admitted action runs to completion. Absence of enforcement is an unbounded S, the opposite of a small bound: a verifier that skips a check has an unbounded S for that check and MUST record the request as possession-unproven or sequence-unverified. Implementations SHOULD publish one test vector exactly on each limit.¶

9.7. Status of This Section

Specified in this revision. The reference implementation targets verification steps 1 through 5 and the request signature in its v10 build; revocation of a member after minting is caught at step 1 on the next request, and the continuity of that check across certificate expiry and session boundaries is planned (Section 12.4.4). Delegation across organizations composes with draft-rampalli-pedigree, draft-rampalli-cross-org-delegation-mapping, and draft-hulea-wimse-agent-mandate: AGTP's per-hop attenuation and parent re-verification satisfy the chain requirements those documents state, the origin check and the authority assertion reference of Section 9.5 correspond to the mandate work's Authority Assertion, the three-outcome verification and the validator-versus-policy split follow its Validation Result model, and an AGTP Delegation Sequence can be mapped row for row into the cross-organization template. AGTP carries whichever chain format the WIMSE group settles on and competes with none of them.¶

10.1. Substrate Model

In a composed deployment, AGTP supplies four properties at the wire level that no framework currently supplies natively:¶

1. Identity at the protocol level. Every AGTP request carries a canonical Agent-ID in the Agent-ID header. The framework's payload can omit identity; identity is established by the transfer protocol.¶

2. Authority bounded at the protocol level. The Authority-Scope header declares what the requesting agent is permitted to do. Servers enforce scope before dispatching to the framework's payload handler. A scope violation returns 455 at the AGTP layer, before the framework sees the payload.¶

3. Attribution at the protocol level. Every method invocation produces an Attribution-Record. The framework's payload can omit re-implement audit logging; the attribution is produced by the transfer protocol.¶

4. Delegation at the protocol level. Multi-hop agent workflows carry their Delegation Sequence in the Delegation-Chain header, verified per Section 9, independent of framework-level concepts of "session" or "task."¶

A framework composed over AGTP can shed the parts of its design that exist only because HTTP lacked these properties. The result is a framework that can focus on its actual contribution (tool semantics, conversational structure, multi-agent choreography) while the substrate handles the cross-cutting concerns.¶

10.2. EXECUTE as the Generic Carrier

When a framework is composed over AGTP, EXECUTE is the canonical method that carries the framework's payload. The carried payload's Content-Type identifies the framework; the AGTP server dispatches the payload to the framework's handler. See Section 8.2.8.¶

The EXECUTE invocation supplies:¶

• The framework identifier (via payload_type).¶

• The framework-specific operation (via the action parameter).¶

• The framework-specific payload (via the payload parameter).¶

• An optional idempotency_key enabling safe retry.¶

The AGTP envelope (status, task_id, attribution) wraps the framework's response. A framework that wishes to expose a particular operation as a first-class AGTP method (instead of carrying it through EXECUTE) MAY register a catalog method per [AGTP-METHODS]; this is reserved for frameworks whose operations are widely used enough to justify a dedicated verb.¶

10.3. Precedence Rule

AGTP headers (Agent-ID, Authority-Scope, Delegation-Chain, Session-ID, Task-ID) MUST take precedence over equivalent fields in a carried framework payload for routing, enforcement, audit, and identity purposes. Infrastructure components including SEPs and governance gateways MUST use AGTP header values for all protocol-level decisions.¶

Framework-level identity, session, or scope fields MAY be present in the body for application-layer use but MUST NOT override AGTP header values. If an inconsistency is detected between an AGTP header and a corresponding framework-level field, the AGTP header is authoritative; the inconsistency SHOULD be logged.¶

10.4. Composition Profiles

The canonical mapping of A2A, MCP, and ACP concepts to AGTP constructs, the external identity provider patterns, the HTTP gateway profile, and the wire examples are specified in [AGTP-COMPOSITION]. Two positions this document holds for those profiles:¶

• The A2A provenance chain maps to the Delegation Sequence (Section 9) on the pre-authorization side and to the prior_actions chain of [AGTP-IDENTIFIERS] on the attribution side.¶

• Tool and resource identity is carried through composition profiles; there is no first-class AGTP header for it. This is a deliberate choice under review; a first-class carrier is planned if working group review prefers it.¶

11.1. Overview

AGTP specifies agent-side identity through the Agent Genesis, canonical Agent-ID, Agent Identity Document, and Trust Tier model. PURCHASE invocations carrying payments:purchase in the Authority-Scope header and a Budget-Limit constraint are fully governed on the sending side. The receiving side of a PURCHASE, the merchant counterparty, lacks an equivalent protocol-level identity in the base specification.¶

The merchant-side identity model is specified in [AGTP-MERCHANT]. The integration is hook-based: this document registers the required headers (Section 6.5), the 458 status code (Section 6.6), and the merchant and intent Authority-Scope domains; the detailed semantics, Merchant Manifest Document schema, Merchant Genesis structure, and counterparty verification procedure are specified in the companion.¶

11.2. Merchant Identity Headers (Summary)

PURCHASE invocations in a fully conformant v04 deployment carry the following additional headers:¶

• Merchant-ID: canonical identifier of the intended merchant counterparty.¶

• Merchant-Manifest-Fingerprint: SHA-256 fingerprint of the Merchant Manifest Document the requesting agent verified during pre-flight counterparty verification.¶

• Intent-Assertion: detached JWT carrying principal-authorized purchase intent, forwardable to payment networks as standalone evidence.¶

• Cart-Digest: digest of a structured cart returned by a prior QUOTE invocation, binding this PURCHASE to that cart.¶

Full field definitions, wire examples, and security requirements are in [AGTP-MERCHANT].¶

12.1. Mandatory TLS

All AGTP connections MUST use TLS 1.3 or higher. Implementations MUST reject connections using TLS 1.2 or below. Certificate validation follows standard PKI practices per [RFC5280]. Servers MUST present a valid certificate.¶

12.2. Agent Identity Verification: Three Levels

AGTP defines three distinct levels at which agent identity and Authority-Scope can be verified. Each level serves a different deployment profile and operational tradeoff. Understanding the distinction is essential for implementers: the AGTP Agent Certificate extension ([AGTP-CERT]) is OPTIONAL, and base AGTP provides cryptographic verification at the application layer without it.¶

Level 1 - Self-asserted headers (raw request fields). Every AGTP request MUST include the Agent-ID header, which references the agent identity document carrying the principal identifier and Authority-Scope. As a raw header value on an individual request, Agent-ID is self-asserted: a client writes the value into the request and the server records what was written. Level 1 verification is limited to mandatory logging and anomaly detection against the recorded stream. This is the minimum baseline every AGTP implementation provides.¶

Level 2 - Application-layer cryptographic verification (signed Agent Identity Document plus proof of possession). A canonical Agent-ID resolves to a signed Agent Identity Document ([AGTP-IDDOC]) that carries the Agent Genesis's Authority-Scope grant and the agent's current agent_public_key, signed by the issuer. A verifier (including a stranger with no prior relationship to the agent's organization) verifies identity, scope, and possession at the application layer by performing the following steps:¶

1. Resolve the canonical Agent-ID to retrieve the signed Agent Identity Document.¶

2. Verify the issuer's signature on the document against the issuer's published key.¶

3. Confirm that the canonical Agent-ID in the document matches the hash of the Agent Genesis.¶

4. Read the Authority-Scope grant and the agent_public_key from the verified document.¶

5. Verify the request's Request-Signature under that key per Section 6.5.4.¶

Steps 1 through 4 establish that the identity exists and what it may do. Step 5 establishes that the sender is that identity. A verifier that performs steps 1 through 4 and skips step 5 has verified a document and no sender, and the request is at Level 1 for every purpose that depends on who sent it. Level 2 is available in base AGTP without the Agent Certificate extension and is the identity mechanism the protocol depends on.¶

Level 3 - TLS-layer cryptographic verification (AGTP-CERT extension). The AGTP Agent Certificate extension [AGTP-CERT] binds the canonical Agent-ID and Authority-Scope to an X.509 v3 certificate presented during TLS 1.3 mutual authentication. The principal identifier remains in the agent identity document referenced by Agent-ID. Level 3 accelerates the Level 2 check to the TLS handshake and enables Scope-Enforcement Points (SEPs) to verify Authority-Scope at O(1) per-request cost without application-layer access. Level 3 is an acceleration and enforcement path for Level 2, which it presupposes. Deployments that require line-rate scope enforcement at infrastructure layers (load balancers, governance gateways) SHOULD implement [AGTP-CERT].¶

• Note: The Agent Certificate extension and the Agent Genesis mechanism may be subject to pending intellectual property claims. See Section 12.7 and the IPR Notice preceding the Abstract for details. The licensor is prepared to grant a royalty-free license to implementers.¶

Every AGTP server MUST log the Agent-ID value from every request and the principal identifier resolved from the corresponding agent identity document, creating an attributable audit trail at Level 1 even in deployments that omit Level 2 retrieval or Level 3 transport binding.¶

12.3. Authority Scope Enforcement

The Authority-Scope header declares what actions the agent is authorized to take. Compliant AGTP servers MUST parse the Authority-Scope on every request, return 455 Scope Violation for any method that exceeds declared scope, and log all scope violations for audit purposes. At Level 1, scope declarations are self-asserted in the request header, analogous to scope assertions in OAuth 2.0 [RFC6749]. At Level 2, scope is cryptographically verifiable through the signed Agent Identity Document; servers SHOULD retrieve and verify the manifest for any Agent-ID whose declared scope exceeds read-only operations. Level 3 cryptographically signed and infrastructure-enforced scopes are defined in [AGTP-CERT].¶

12.4. Threat Model

12.5. Privacy Considerations

Agent identity carried on requests, and the agent identity document referenced by Agent-ID, carry information about agent behavior that may be sensitive:¶

• Agent-ID together with the resolved principal identifier may reveal organizational structure¶

• Session-ID and Task-ID reveal workflow patterns¶

• Delegation-Chain reveals multi-agent architecture¶

AGTP logs containing these fields MUST be treated as sensitive operational data. Operators MUST implement appropriate access controls, retention limits, and data minimization practices consistent with applicable privacy regulations.¶

Where privacy-preserving attribution is required, implementations MAY use pseudonymous Agent-IDs with a separate trusted resolution service. The architecture for pseudonymous agent identity resolution is reserved for a future companion document.¶

12.6. Denial-of-Service Considerations

AGTP's agent identity provides a mechanism for more precise denial-of-service mitigation than is possible with HTTP. Rate limiting SHOULD be applied per Agent-ID and per resolved principal identifier (obtained from the agent identity document) in addition to per-IP-address controls.¶

When [AGTP-CERT] is deployed, per-Agent-ID rate limiting can be cryptographically tied to verified agent identity, preventing quota evasion through Agent-ID rotation. Implementations planning high-volume governed agent deployments SHOULD plan for [AGTP-CERT] as part of their denial-of-service mitigation strategy.¶

Additional recommended mitigations: traffic-shaping by request class once the Priority header is normatively specified (reserved for v01+ per Section 6.5); and circuit breaker patterns for ESCALATE request floods.¶

12.7. Intellectual Property Considerations

The core AGTP specification, including all base methods, header fields, status codes, connection model, and IANA registrations defined in this document, is intended for open implementation without royalty obligation.¶

Certain elements referenced in this document may be subject to pending patent applications by the author, specifically:¶

• The Agent Certificate extension [AGTP-CERT], which provides cryptographic binding of agent identity and authority scope to AGTP header fields.¶

• The ACTIVATE method, which provides AGTP-native transmission and activation of governed agent packages.¶

• The Agent Genesis mechanism (Section 7.3.2), which provides the genesis identity record and canonical Agent-ID derivation process for AGTP-registered agents.¶

• The .agent file format specification, an open packaging format for AI agents.¶

• The .nomo file format specification, a governed packaging format for AI agents with cryptographic governance binding.¶

Implementers of the core AGTP specification are unaffected by any intellectual property claims on these extensions and associated formats.¶

The licensor is prepared to grant a royalty-free license to implementers for any patent claims that cover contributions in this document and its referenced extensions, consistent with the IETF's IPR framework under [RFC8179].¶

IPR disclosures have been filed with the IETF Secretariat and are available at: https://datatracker.ietf.org/ipr/¶

13.1. Port Assignment

The following service names and port number are registered in the IANA Service Name and Transport Protocol Port Number Registry per [RFC6335]:¶

The unified port assignment (4480 for both TCP and UDP under a single conceptual agtp service) follows the precedent set by HTTPS (443/TCP and 443/UDP for HTTP/3). The transport is distinguished at the protocol level; the port number alone decides nothing.¶

Contact:

Chris Hood, chris@nomotic.ai¶

Reference:

This document¶

13.2. AGTP Method Registry

Establishment of an IANA registry: Agent Transfer Protocol Methods.¶

Registry name:

Agent Transfer Protocol Methods¶

Registration procedure:

Expert Review per [RFC8126], with the additional requirement that each registration be accompanied by a published specification, at minimum a publicly available Internet-Draft or equivalent document. The Designated Expert SHOULD verify that the proposed method name is unique, the reference specification is publicly accessible, the method definition includes the required fields (parameters, response structure, idempotency, error codes, security considerations), and the method conforms to the AGTP-METHODS specification [AGTP-METHODS].¶

Reference:

This document¶

Initial registrations (the eighteen-method protocol floor):¶

The methods BOOK, SCHEDULE, LEARN, and COLLABORATE, present in the v06 core set, are demoted in v07 to Tier 2 standard extended methods and are registered through the AGTP-METHODS method catalog ([AGTP-METHODS]); this document registers the floor only.¶

13.3. AGTP Status Code Registry

Establishment of an IANA registry: Agent Transfer Protocol Status Codes.¶

Registry name:

Agent Transfer Protocol Status Codes¶

Registration procedure:

Expert Review + published specification required.¶

AGTP-specific status code numbers are chosen from ranges unassigned in the IANA HTTP Status Code Registry to avoid semantic collision with HTTP status codes that may appear in payloads carried by AGTP method invocations.¶

Two status codes used by AGTP retain their HTTP code numbers (408 and 410) but carry AGTP-specific semantics. They are registered here with text describing the AGTP semantic.¶

The following AGTP status codes are registered with full definitions:¶

13.4. Media Type Registry

This section is the master registry of all AGTP-family media types. Types defined by companion specifications are listed here for cross-document discoverability; their normative definitions remain in the defining document.¶

"Registered (vendor tree)" indicates that IANA registration is complete in the application/vnd.* vendor tree as of the date of this revision. "Planned (this document)" and "Planned (companion document)" indicate types for which registration applications will be filed concurrent with publication of the defining document. Standards-tree promotion of the full set is anticipated at RFC publication of the AGTP family.¶

13.5. Header Field Registry

AGTP header fields are distinct from HTTP header fields and are registered in a new IANA registry: Agent Transfer Protocol Header Fields.¶

Registry name:

Agent Transfer Protocol Header Fields¶

Registration procedure:

Expert Review + published specification required.¶

AGTP keeps its own registry, separate from the HTTP Field Name Registry, as AGTP header fields have different semantics, applicability, and versioning constraints from HTTP fields. HTTP header fields carry no automatic validity in AGTP, and AGTP header fields are invalid as HTTP fields.¶

Initial registrations (all Permanent): Agent-ID, Owner-ID, Authority-Scope, Session-ID, Task-ID, Delegation-Chain, Server-ID, Attribution-Record, Continuation-Token, Supported-Methods, Cost-Estimate, Attestation-Evidence, Authorization, Merchant-ID, Merchant-Manifest-Fingerprint, Intent-Assertion, Cart-Digest, AGTP-Methods-Version, AGTP-Catalog-Warning, AGTP-Endpoint-Warning, Allow-RCNS.¶

The four merchant-related headers are defined in [AGTP-MERCHANT] and registered concurrently with this document. The three catalog-related headers (AGTP-Methods-Version, formerly AGTP-API-Version, AGTP-Catalog-Warning, and AGTP-Endpoint-Warning) are defined in [AGTP-METHODS] and registered concurrently. The Authorization header semantics for composition with external identity providers are specified in [AGTP-COMPOSITION]. The Allow-RCNS header semantics for caller opt-in to Runtime Contract Negotiation are specified in [AGTP-RCNS].¶

Planned headers (Priority, TTL, AGTP-Zone-ID, Telemetry-Export) are unregistered in this revision. They will be registered alongside the revision that specifies their normative semantics. Content-Schema is registered by [AGTP-COMPOSITION].¶

The Budget-Limit header is defined in [AGTP-COMMERCE] and registered concurrently with that document.¶

13.6. URI Scheme Registration

The agtp:// URI scheme is registered per [RFC7595]. Full registration template is documented in Section 7.1.13.¶

13.7. AGTP Budget Unit Registry

Establishment of a new IANA sub-registry: Agent Transfer Protocol Budget Units.¶

Registry name:

Agent Transfer Protocol Budget Units¶

Registration procedure:

Expert Review per [RFC8126]. New unit registrations MUST define: unit name (lowercase ASCII, no spaces or special characters), semantic description, value format (integer or decimal), whether fractional values are permitted, and a reference specification. Units representing financial denominations MUST specify the currency and MUST define precision (decimal places). The Designated Expert SHOULD verify that the proposed unit duplicates no existing registration and that the value format is unambiguous.¶

Reference:

This document¶

Initial registrations:¶

13.8. Agent Registry Retention Policy

The AGTP registry MUST retain records for all registered agents regardless of lifecycle state. The following minimum retention periods apply:¶

The 7-year minimum reflects common enterprise compliance requirements (SOX, GDPR audit trails, HIPAA). Governance platform operators in regulated industries SHOULD extend these minimums to match applicable regulatory requirements.¶

The retained record for a Revoked or Deprecated agent MUST include:¶

• Canonical Agent-ID (permanently retired, never reissued)¶

• Agent label and org domain at time of registration¶

• Trust tier at time of registration¶

• Activation date and activating principal¶

• Revocation or deprecation date, initiating principal, and reason code¶

• Genesis audit record hash (pointer to immutable audit log)¶

• Full Agent Genesis (archived, inaccessible to the public)¶

• All lifecycle state transitions with timestamps¶

The retained record MUST NOT contain package executable contents, active session data, or Authority-Scope grant tokens.¶

14.1. Normative References

[AGTP-IDDOC]

Hood, C., "AGTP Agent Identity Document", Work in Progress, Internet-Draft, draft-hood-agtp-identity-document-00, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-identity-document-00>.

[AGTP-IDENTIFIERS]

Hood, C., "AGTP Identifier Chain", Work in Progress, Internet-Draft, draft-hood-agtp-identifiers-03, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-identifiers-03>.

[AGTP-METHODS]

Hood, C., "AGTP Methods (AGTP Verbs): Method Vocabulary, Path Grammar, and Endpoints", Work in Progress, Internet-Draft, draft-hood-agtp-methods-00, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-methods-00>.

[AGTP-RCNS]

Hood, C., "AGTP-RCNS: Runtime Contract Negotiation Substrate", Work in Progress, Internet-Draft, draft-hood-agtp-rcns-00, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-rcns-00>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC3986]

Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/rfc/rfc3986>.

[RFC5280]

Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/rfc/rfc5280>.

[RFC6335]

Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/rfc/rfc6335>.

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/rfc/rfc7515>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8179]

Bradner, S. and J. Contreras, "Intellectual Property Rights in IETF Technology", BCP 79, RFC 8179, DOI 10.17487/RFC8179, May 2017, <https://www.rfc-editor.org/rfc/rfc8179>.

[RFC8615]

Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, <https://www.rfc-editor.org/rfc/rfc8615>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/rfc/rfc8785>.

[RFC9000]

Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/rfc/rfc9000>.

[RFC9110]

Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

[RFC9334]

Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, <https://www.rfc-editor.org/rfc/rfc9334>.

14.2. Informative References

[A2A]

Linux Foundation, "Agent-to-Agent Protocol Specification", 2025, <https://a2aprotocol.ai>.

[ACP]

IBM Research, "Agent Communication Protocol", 2025.

[AGTP-API]

Hood, C., "AGTP-API: Verbs, Paths, Endpoints, and Synthesis", Work in Progress, Internet-Draft, draft-hood-agtp-api-01, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-api-01>.

[AGTP-BINDINGS]

Hood, C., "AGTP Transport Bindings: TCP/TLS and QUIC", Work in Progress, Internet-Draft, draft-hood-agtp-bindings-01, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-bindings-01>.

[AGTP-CERT]

Hood, C., "AGTP Agent Certificate Extension", Work in Progress, Internet-Draft, draft-hood-agtp-agent-cert-04, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-agent-cert-04>.

[AGTP-COMMERCE]

Hood, C., "AGTP-Commerce: Open Commerce Specification for Agent-to-Agent Transactions", Work in Progress, Internet-Draft, draft-hood-agtp-commerce-01, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-commerce-01>.

[AGTP-COMMUNICATION]

Hood, C., "AGTP Communication Protocol", Work in Progress, Internet-Draft, draft-hood-agtp-communication-01, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-communication-01>.

[AGTP-COMPOSITION]

Hood, C., "AGTP Composition Profiles", Work in Progress, Internet-Draft, draft-hood-agtp-composition-02, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-composition-02>.

[AGTP-DISCOVERY]

Hood, C., "AGTP Discovery and Naming", Work in Progress, Internet-Draft, draft-hood-agtp-discovery-02, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-discovery-02>.

[AGTP-LEI]

Hood, C., "AGTP Binding to the Legal Entity Identifier (LEI and vLEI)", Work in Progress, Internet-Draft, draft-hood-agtp-lei-01, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-lei-01>.

[AGTP-LOG]

Hood, C., "AGTP Transparency Log Protocol", Work in Progress, Internet-Draft, draft-hood-agtp-log-03, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-log-03>.

[AGTP-MERCHANT]

Hood, C., "AGTP Merchant Identity and Agentic Commerce Binding", Work in Progress, Internet-Draft, draft-hood-agtp-merchant-identity-03, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-merchant-identity-03>.

[AGTP-PRESENCE]

Hood, C., "AGTP Presence: Ambient Discovery and Visibility for Agents", Work in Progress, Internet-Draft, draft-hood-agtp-presence-01, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-presence-01>.

[AGTP-SESSION]

Hood, C., "AGTP Session Protocol", Work in Progress, Internet-Draft, draft-hood-agtp-session-01, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-session-01>.

[AGTP-TRUST]

Hood, C., "AGTP Trust and Verification Specification", Work in Progress, Internet-Draft, draft-hood-agtp-trust-03, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-trust-03>.

[ANP]

"Agent Network Protocol", 2025.

[HOOD2026]

Hood, C., "Semantic Method Naming and LLM Agent Accuracy: A Controlled Benchmark of REST/CRUD versus Agentive API Interface Design", Working Paper Available by request. March 2026., 2026.

[MCP]

Anthropic, "Model Context Protocol", 2024, <https://modelcontextprotocol.io>.

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/rfc/rfc6749>.

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/rfc/rfc7519>.

[RFC7540]

Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <https://www.rfc-editor.org/rfc/rfc7540>.

[RFC7595]

Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, <https://www.rfc-editor.org/rfc/rfc7595>.

[RFC9114]

Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, <https://www.rfc-editor.org/rfc/rfc9114>.

[RFC9162]

Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, <https://www.rfc-editor.org/rfc/rfc9162>.

[RFC9943]

Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, <https://www.rfc-editor.org/rfc/rfc9943>.

A.1. Substantive Changes

1. Delegation-Chain specified. The header reserved since v00 is specified (Section 9): format (ordered hops of canonical Agent-ID and delegation token), minting at DELEGATE under the existing strict-subset rule, per-hop verification (membership, parent re-verification, attenuation, freshness, depth and cycle), the effective scope as the accepted result, and 551 failure behavior with a reason vocabulary. Terminology distinguishes the Delegation Sequence (the hops) from the Delegation-Chain header (its carrier). The composition table, the worked DELEGATE example, and the security considerations are aligned to the specification; earlier revisions described the header as if specified in those places while reserving it in the header table.¶

2. Delegation token format and authority evidence. The hop token payload is specified (Section 9.2.1) with a digest of the parent token, so a parent swap fails on the digest as well as the key. Verification is defined over a fixed input set with no local policy and returns valid, invalid, or indeterminate (Section 9.3); an origin hop may reference an authority assertion for the delegator's own powers (Section 9.5); and a table states what each artifact in a delegated request asserts (Section 9.5.1).¶

3. Structured failure fields. retryable, partial with completed_steps, side_effects, and reason on 4xx and 5xx bodies (Section 6.6.1). Additive.¶

4. Specification status vocabulary. Specified, specified and implemented, planned, inherited (Section 1.1), with the carrier-versus-claim rule stated. Applied through the document.¶

5. Transfer protocol. AGTP is described as a transfer protocol throughout; "transport" now refers only to TCP, TLS, and QUIC. The positioning section is rewritten around the HTTP and HTML analogy in place of SMTP and TCP.¶

6. Revocation continuity and tamper evidence stated as planned and inherited respectively (Section 12.4.4 and the following subsection), with the member-inactive check of Section 9.3 as the first specified piece.¶

7. Tool and resource identity stated as a deliberate composition choice under review (Section 10).¶

8. Workload and agent identity composition sentence added to Identity at the Wire, and a Discovery and Naming subsection added to Related Work carrying the identity and location split and the discover versus search vocabulary.¶

9. Per-request proof of possession. The Request-Signature header (Section 6.5.4) binds every non-anonymous request to the agent's current signing key, published as agent_public_key in the Identity Document. Level 2 verification gains a fifth step and now establishes the sender as well as the document; a verifier that skips the step is at Level 1 for every purpose that depends on who sent the request. Answers the self-asserted-identity finding raised independently by four reviewers and conceded on list in August.¶

10. 262 versus 455 resolved. Obtainability is the rule: 262 when the agent could obtain the missing authorization, 455 when the request exceeds authority the agent holds. A claimed scope beyond the document's grant, an endpoint scope the document fails to grant, and a delegation beyond the parent are all 455. Earlier revisions used both codes for Authority-Scope failures in different sections.¶

11. HTTP registry argument withdrawn. The claim that IETF Review freezes the HTTP method registry is removed; the case rests on the distinct wire image and the documented failure cases.¶

12. WIMSE chain convention mapping and a stated staleness bound (Section 9.6).¶

13. Governance Token action digest binding a token to one request shape, with token-action-mismatch on divergence.¶

14. evaluation failure field distinguishing a refusal from an incomplete check, with missing_input.¶

15. User agent and service agent stated as both in scope, with the Owner-ID as what differs.¶

A.2. Structural Changes

1. AGTP-API replaced by AGTP-METHODS and AGTP-RCNS. Every reference to [AGTP-API] is redirected: the method vocabulary, path grammar, endpoint primitive, manifest, and policy to [AGTP-METHODS]; negotiation, contracts, and synthesis to [AGTP-RCNS]. The AGTP-API-Version header registration is renamed AGTP-Methods-Version.¶

2. Agent Identity Document extracted. The Agent Namespace Document, the Agent Identity Document and .agtp format, and the browser interaction model move to [AGTP-IDDOC]; this document keeps a summary (Section 7.2) stating what the protocol depends on. The Agent Genesis, registration lifecycle, and lifecycle events remain here because the Agent-ID derivation and the lifecycle methods depend on them.¶

3. Module summaries. Dynamic Endpoint Negotiation, the Extended Method Vocabulary, Composition Profiles, and the Merchant Identity sections are reduced to summaries that point at the companion carrying the normative text. The AGMP wire example appendix moves to [AGTP-COMPOSITION].¶

4. Change history collapsed. The v06, v07, and v08 change logs (about 680 lines) are replaced by Appendix B; the full text remains in the archived revisions.¶

5. Glossary merged into Terminology; four entries that appeared only in the glossary are carried over.¶

6. Agent defined operationally. The Terminology entry for Agent now states what the protocol can enforce (Genesis-issued Agent-ID, principal and scope, per-request proof of possession, attributable actions) in place of the v09 description of an AI software system acting without supervision. The protocol has no knowledge of how a participant is implemented; it constrains and attributes what the participant does.¶

7. DISCOVER and ACTIVATE aligned with the companions. DISCOVER now distinguishes search (criteria to candidates) from discovery (Agent-ID to attachment) per [AGTP-DISCOVERY] and defers its parameter set and response shape there; the v09 parameter table (criteria, filter, max_results, context) disagreed with the companion and is withdrawn. ACTIVATE is named as the publish event: ANS registration ([AGTP-DISCOVERY]) and the first ANNOUNCE ([AGTP-PRESENCE]) follow from the lifecycle transition, so an agent is findable exactly when Active.¶

8. Agent-ID hash excludes log_inclusion_proof. The Genesis hash that yields the Canonical Agent-ID now excludes the inclusion proof alongside signature, so that a log-anchored issuer can compute the Agent-ID, commit it, and embed the receipt without the identity changing; v09's rule was circular with the statement subject in [AGTP-LOG]. log_uri is added to the Genesis fields as that document proposed. Compatibility: only Genesis documents that carry a non-null log_inclusion_proof hash differently; dns-anchored and org-asserted Genesis documents whose field is absent are unaffected, and a document that carried the field as null MUST be re-hashed by its issuer under the v10 rule before it is served as v10. The registration section's remaining references to issuance "at ACTIVATE time" are corrected to registration, matching the ACTIVATE definition.¶

9. Planned-header table relabeled in the status vocabulary of Section 1.1: Budget-Limit is specified in [AGTP-COMMERCE] and Content-Schema in [AGTP-COMPOSITION]; Priority, TTL, AGTP-Zone-ID, and Telemetry-Export are planned. The v09 label "Reserved (v01+)" was stale.¶

A.3. Wire Format Compatibility

The Delegation-Chain header changes from reserved to specified. A v09 server receiving it MAY have rejected it with 501; a v10 server verifies it. Requests without the header are unchanged. Request-Signature is new and required on non-anonymous requests; a v10 server MUST accept unsigned requests from agents whose Identity Document predates agent_public_key under the possession-unproven rule of Section 6.5.4, so v09 agents keep working at Level 1 until re-issued. The 262 to 455 change for Authority-Scope failures is wire-visible for clients that branched on 262; clients SHOULD treat 455 with scope-claim-invalid or scope-exceeds-parent as they treated 262 scope-required. The structured failure fields and action_digest are additive. The AGTP-Methods-Version rename is advisory; servers MAY emit both names during transition. No other wire-visible behavior changes.¶

C.1. Reserved Operator Tokens

Two scope tokens are reserved for operators and MUST NOT appear in an agent's identity-document scope set unless the agent is the server's operator:¶

inspect:all:

Grants INSPECT read access across every agent the server hosts, and authorizes the operator-fired REVOKE target=stale-contracts sweep and the cross-agent DISCOVER /contracts view specified in [AGTP-RCNS].¶

rcns:negotiate:

Opens the caller-scope lock of the RCNS dispatcher gate ([AGTP-RCNS]). Unlike inspect:all, this token MAY be granted to any agent the operator chooses to admit to runtime negotiation.¶

D.1. QUERY Request and Response

AGTP/1.0 QUERY
Agent-ID: agt-7f3a9c2d
Authority-Scope: documents:query, knowledge:query
Session-ID: sess-a1b2c3d4
Task-ID: task-0042
Content-Type: application/vnd.agtp+json

{
  "task_id": "task-0042",
  "parameters": {
    "intent": "Key arguments against MCP re: HTTP overhead",
    "scope": ["documents:research", "knowledge:session"],
    "format": "structured",
    "confidence_threshold": 0.75
  }
}

AGTP/1.0 200 OK
Task-ID: task-0042
Server-ID: srv-knowledge-01
Attribution-Record: [signed attribution token]
Content-Type: application/vnd.agtp+json

{
  "status": 200,
  "task_id": "task-0042",
  "result": {
    "results": [{"content": "...", "source": "doc-agtp-research",
                 "confidence": 0.91}],
    "result_count": 1
  }
}

D.2. EXECUTE Request and Response (Carried Application Payload)

The following example shows EXECUTE carrying an application-layer booking action. The Authority-Scope on the request governs the action; a scope mismatch would return 455.¶

AGTP/1.0 EXECUTE
Agent-ID: agt-travel-planner
Authority-Scope: booking:*, calendar:book
Session-ID: sess-trip-2026-04
Task-ID: task-0107
Content-Type: application/vnd.agtp+json

{
  "method": "EXECUTE",
  "task_id": "task-0107",
  "parameters": {
    "action": "reserve-flight",
    "parameters": {
      "resource_id": "flight-AA2847",
      "principal_id": "usr-chris-hood",
      "time_slot": "2026-04-15T08:00:00Z",
      "options": {"seat_preference": "aisle", "class": "economy"}
    },
    "idempotency_key": "trip-2026-04-15-AA2847"
  }
}

AGTP/1.0 200 OK
Task-ID: task-0107
Attribution-Record: [signed attribution token]
Content-Type: application/vnd.agtp+json

{
  "status": 200,
  "task_id": "task-0107",
  "result": {
    "booking_id": "BK-2026-0107",
    "status": "confirmed",
    "resource_id": "flight-AA2847",
    "confirmation_code": "XQRT7Y"
  }
}

D.3. EXECUTE Carrying an MCP Tool Invocation

The following example shows EXECUTE carrying an MCP tool invocation. The carried payload's Content-Type identifies it as MCP; the AGTP server dispatches to its MCP handler. AGTP supplies identity, authority, and attribution at the wire level; MCP supplies tool semantics in the payload.¶

AGTP/1.0 EXECUTE
Agent-ID: agt-7f3a9c2d
Authority-Scope: mcp:tools:execute, knowledge:query
Session-ID: sess-mcp-bridge-01
Task-ID: task-0210
Content-Type: application/vnd.mcp.tools+json

{
  "method": "EXECUTE",
  "task_id": "task-0210",
  "parameters": {
    "action": "mcp.tools.call",
    "payload_type": "application/vnd.mcp.tools+json",
    "payload": {
      "tool": "search_documents",
      "arguments": {
        "query": "AGTP composition with higher-level frameworks",
        "limit": 5
      }
    }
  }
}

AGTP/1.0 200 OK
Task-ID: task-0210
Server-ID: srv-mcp-bridge
Attribution-Record: [signed attribution token]
Content-Type: application/vnd.mcp.tools+json

{
  "status": 200,
  "task_id": "task-0210",
  "result": {
    "tool_response": {
      "matches": [
        {"doc_id": "doc-0042", "score": 0.91, "excerpt": "..."}
      ]
    }
  }
}

D.4. ESCALATE Request and Response

AGTP/1.0 ESCALATE
Agent-ID: agt-procurement-03
Authority-Scope: booking:*, payments:confirm
Session-ID: sess-procurement-q2
Task-ID: task-0881
Content-Type: application/vnd.agtp+json

{
  "method": "ESCALATE",
  "task_id": "task-0881",
  "parameters": {
    "task_id": "task-0880",
    "reason": "scope_limit",
    "context": {
      "attempted_action": "EXECUTE",
      "resource": "vendor-contract-750k",
      "block_reason": "Exceeds agent authorization threshold"
    },
    "recipient": "usr-cfo",
    "deadline": "2026-03-19T09:00:00Z"
  }
}

AGTP/1.0 202 Accepted
Task-ID: task-0881
Server-ID: srv-escalation-handler
Content-Type: application/vnd.agtp+json

{
  "status": 202,
  "task_id": "task-0881",
  "result": {
    "escalation_id": "ESC-0881",
    "routed_to": "usr-cfo",
    "status": "pending_review",
    "task_paused": true,
    "estimated_review_by": "2026-03-19T09:00:00Z"
  }
}