Independent Submission C. Hood Internet-Draft Nomotic, Inc. Intended status: Informational 20 March 2026 Expires: 21 September 2026 Agent Transfer Protocol (AGTP) draft-hood-independent-agtp-01 Abstract AI agents and agentic systems generate a growing volume of intent- driven, unstructured, and undifferentiated traffic that flows through HTTP indistinguishably from human-initiated requests. HTTP lacks the semantic vocabulary, observability primitives, and identity mechanisms required by agent systems operating at scale. Existing protocols described as "agent protocols" including MCP, ACP, A2A, and ANP, are messaging-layer constructs that presuppose HTTP as their transport. They do not address the underlying transport problem. This document defines the Agent Transfer Protocol (AGTP): a dedicated application-layer protocol for AI agent traffic. AGTP provides agent-native intent methods (QUERY, SUMMARIZE, BOOK, SCHEDULE, LEARN, DELEGATE, COLLABORATE, CONFIRM, ESCALATE, NOTIFY), protocol-level agent identity and authority headers, and a status code vocabulary designed for the conditions AI agent systems encounter. AGTP SHOULD prefer QUIC for new implementations and MUST support TCP/TLS for compatibility and fallback. It is designed to be composable with existing agent frameworks, not to replace them. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 21 September 2026. Hood Expires 21 September 2026 [Page 1] Internet-Draft AGTP March 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Limitations of HTTP for Agent Traffic . . . . . . . . . . 5 1.3. Why Not Evolve HTTP? . . . . . . . . . . . . . . . . . . 6 1.4. Motivation for a Dedicated Protocol . . . . . . . . . . . 7 1.5. Scope and Target Audience . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Problem 1: Undifferentiated Agent Traffic on HTTP . . . . 11 3.2. Problem 2: Semantic Mismatch Between Agent Intent and Available Methods . . . . . . . . . . . . . . . . . . . . 11 3.3. Problem 3: No Protocol-Level Identity, Authority, or Attribution for Agents . . . . . . . . . . . . . . . . . 11 3.4. Problem Summary . . . . . . . . . . . . . . . . . . . . . 12 4. Related Work and Existing Approaches . . . . . . . . . . . . 12 4.1. HTTP/REST as the De Facto Standard . . . . . . . . . . . 12 4.2. Existing Agent Protocols . . . . . . . . . . . . . . . . 12 4.3. Transport-Layer Alternatives . . . . . . . . . . . . . . 13 4.4. The Critical Distinction: Messaging vs. Transport . . . . 13 4.5. AGTP Positioning: The Proposed Stack . . . . . . . . . . 13 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Stack Position . . . . . . . . . . . . . . . . . . . . . 14 5.2. Design Principles . . . . . . . . . . . . . . . . . . . . 14 5.3. Connection Model . . . . . . . . . . . . . . . . . . . . 15 5.4. Header Format . . . . . . . . . . . . . . . . . . . . . . 15 5.4.1. Request Headers . . . . . . . . . . . . . . . . . . . 15 5.4.2. Response Headers . . . . . . . . . . . . . . . . . . 16 5.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . 17 5.6. Wire Format and Content-Type . . . . . . . . . . . . . . 18 5.7. Early Implementations . . . . . . . . . . . . . . . . . . 19 6. Agent Identity, URI Structure, and Registration . . . . . . . 19 6.1. URI Structure and Resolution Mechanics . . . . . . . . . 19 6.1.1. Foundational Principle . . . . . . . . . . . . . . . 19 6.1.2. Canonical URI Forms . . . . . . . . . . . . . . . . . 20 6.1.3. Non-Canonical Forms and Redirect Behavior . . . . . . 20 Hood Expires 21 September 2026 [Page 2] Internet-Draft AGTP March 2026 6.1.4. Query Parameters for Format Selection . . . . . . . . 21 6.1.5. Resolution Mechanics . . . . . . . . . . . . . . . . 22 6.1.6. Domain Anchor and Trust Tier Assignment . . . . . . . 22 6.1.7. Subdomain Deployment Pattern . . . . . . . . . . . . 23 6.1.8. The /agents/ Reserved Path Prefix . . . . . . . . . . 23 6.1.9. Collision Prevention . . . . . . . . . . . . . . . . 23 6.1.10. IANA Considerations for the agtp:// URI Scheme . . . 24 6.2. Trust Tier Summary . . . . . . . . . . . . . . . . . . . 24 6.3. Agent Namespace Document . . . . . . . . . . . . . . . . 25 6.3.1. Purpose and Scope . . . . . . . . . . . . . . . . . . 25 6.3.2. Document Schema . . . . . . . . . . . . . . . . . . . 25 6.3.3. Integrity and Freshness . . . . . . . . . . . . . . . 26 6.4. Agent Manifest Document and the .agtp Format . . . . . . 27 6.4.1. Purpose and Scope . . . . . . . . . . . . . . . . . . 27 6.4.2. The Three Document Formats and Their Relationship . . 27 6.4.3. Agent Manifest Document Schema . . . . . . . . . . . 28 6.4.4. What the Manifest Exposes and Does Not Expose . . . . 29 6.4.5. Manifest Tamper-Proofing . . . . . . . . . . . . . . 30 6.5. Browser and Human-Facing Interaction Model . . . . . . . 30 6.5.1. The Separation of Discovery and Execution . . . . . . 30 6.5.2. Browser Behavior for agtp:// URIs . . . . . . . . . . 31 6.5.3. Human-Readable Manifest View . . . . . . . . . . . . 31 6.5.4. AGTP Status Sub-Resource . . . . . . . . . . . . . . 31 6.6. Web3 Interaction Considerations . . . . . . . . . . . . . 32 6.6.1. The .agent TLD Collision . . . . . . . . . . . . . . 32 6.6.2. Web3 Trust Anchors . . . . . . . . . . . . . . . . . 32 6.7. Agent Registration Process . . . . . . . . . . . . . . . 33 6.7.1. Overview . . . . . . . . . . . . . . . . . . . . . . 33 6.7.2. Birth Certificate Contents . . . . . . . . . . . . . 34 6.7.3. Agent Archetypes . . . . . . . . . . . . . . . . . . 34 6.7.4. Birth Certificate to AGTP Header Mapping . . . . . . 35 6.7.5. Registration Tiers . . . . . . . . . . . . . . . . . 36 6.7.6. Registration Lifecycle . . . . . . . . . . . . . . . 37 6.7.7. Governance Tokens and Runtime Authorization . . . . . 38 6.7.8. Friendly Name Availability and Re-Registration . . . 39 7. Method Definitions . . . . . . . . . . . . . . . . . . . . . 39 7.1. Design Philosophy . . . . . . . . . . . . . . . . . . . . 39 7.2. Core Methods . . . . . . . . . . . . . . . . . . . . . . 39 7.2.1. QUERY . . . . . . . . . . . . . . . . . . . . . . . . 39 7.2.2. SUMMARIZE . . . . . . . . . . . . . . . . . . . . . . 40 7.2.3. BOOK . . . . . . . . . . . . . . . . . . . . . . . . 41 7.2.4. SCHEDULE . . . . . . . . . . . . . . . . . . . . . . 42 7.2.5. LEARN . . . . . . . . . . . . . . . . . . . . . . . . 43 7.2.6. DELEGATE . . . . . . . . . . . . . . . . . . . . . . 44 7.2.7. COLLABORATE . . . . . . . . . . . . . . . . . . . . . 45 7.2.8. CONFIRM . . . . . . . . . . . . . . . . . . . . . . . 46 7.2.9. ESCALATE . . . . . . . . . . . . . . . . . . . . . . 47 7.2.10. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 48 Hood Expires 21 September 2026 [Page 3] Internet-Draft AGTP March 2026 7.3. Method Summary Table . . . . . . . . . . . . . . . . . . 49 7.4. Method Registry and Extensibility . . . . . . . . . . . . 50 7.5. Extended Method Vocabulary and Industry Profiles . . . . 51 7.5.1. Three-Tier Method Architecture . . . . . . . . . . . 51 7.5.2. Method Category Taxonomy . . . . . . . . . . . . . . 51 7.5.3. Standard Extended Methods (Tier 2) . . . . . . . . . 52 7.5.4. Short-Form and Industry-Inspired Methods . . . . . . 53 7.5.5. Industry Profile Method Sets . . . . . . . . . . . . 53 7.5.6. Registration Path for New Methods . . . . . . . . . . 54 8. Security Considerations . . . . . . . . . . . . . . . . . . . 54 8.1. Mandatory TLS . . . . . . . . . . . . . . . . . . . . . . 54 8.2. Agent Identity Headers and Agent Certificate Extension . 55 8.3. Authority Scope Enforcement . . . . . . . . . . . . . . . 55 8.4. Threat Model . . . . . . . . . . . . . . . . . . . . . . 55 8.4.1. Agent Spoofing . . . . . . . . . . . . . . . . . . . 55 8.4.2. Authority Laundering . . . . . . . . . . . . . . . . 56 8.4.3. Delegation Chain Poisoning . . . . . . . . . . . . . 56 8.4.4. Denial of Service via High-Frequency Agent Traffic . 56 8.4.5. Session Hijacking . . . . . . . . . . . . . . . . . . 56 8.4.6. Escalation Suppression . . . . . . . . . . . . . . . 56 8.4.7. Birth Certificate Spoofing . . . . . . . . . . . . . 57 8.4.8. Domain Transfer Identity Hijacking . . . . . . . . . 57 8.5. Privacy Considerations . . . . . . . . . . . . . . . . . 57 8.6. Denial-of-Service Considerations . . . . . . . . . . . . 58 8.7. Intellectual Property Considerations . . . . . . . . . . 58 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 59 9.1. Port Assignment . . . . . . . . . . . . . . . . . . . . . 59 9.2. AGTP Method Registry . . . . . . . . . . . . . . . . . . 59 9.3. AGTP Status Code Registry . . . . . . . . . . . . . . . . 60 9.4. Header Field Registry . . . . . . . . . . . . . . . . . . 61 9.5. URI Scheme Registration . . . . . . . . . . . . . . . . . 62 9.6. Agent Registry Retention Policy . . . . . . . . . . . . . 62 9.6.1. Domain Name Expiry Interaction . . . . . . . . . . . 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 63 10.1. Normative References . . . . . . . . . . . . . . . . . . 63 10.2. Informative References . . . . . . . . . . . . . . . . . 64 Appendix A. Authority-Scope Format . . . . . . . . . . . . . . . 65 Appendix B. Example AGTP Wire Formats . . . . . . . . . . . . . 66 B.1. QUERY Request and Response . . . . . . . . . . . . . . . 66 B.2. BOOK Request and Response . . . . . . . . . . . . . . . . 67 B.3. ESCALATE Request and Response . . . . . . . . . . . . . . 68 Appendix C. Comparison Table . . . . . . . . . . . . . . . . . . 70 Appendix D. Glossary . . . . . . . . . . . . . . . . . . . . . . 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 73 Hood Expires 21 September 2026 [Page 4] Internet-Draft AGTP March 2026 1. Introduction *Note Regarding Intellectual Property:* Implementers should be aware that extensions and certain mechanisms referenced in this document -- including the Agent Certificate extension (Section 7.2), the ACTIVATE method, the Agent Birth Certificate mechanism (Section 5.7), and the .agent and .nomo file format specifications (Section 2) -- 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 Section 7.7. 1.1. 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 not designed with these properties in mind. 1.2. 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 structurally identical to human-initiated requests at the transport layer. 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. Hood Expires 21 September 2026 [Page 5] Internet-Draft AGTP March 2026 * 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 inherently stateful sequences. 1.3. Why Not Evolve HTTP? A natural question is whether these limitations could be addressed by extending HTTP rather than defining a new protocol. There are three specific reasons why HTTP extension is not the preferred path. First, the HTTP method registry is effectively frozen for new semantics. [RFC9110] defines the HTTP method registry with IETF Review as the registration procedure, meaning new methods require a full IETF consensus process and must be backward-compatible with existing HTTP implementations. Adding intent-based verbs (SUMMARIZE, DELEGATE, ESCALATE) to HTTP would require every HTTP client, server, proxy, and middleware component to ignore or handle unknown methods gracefully, a compatibility constraint that limits how agent-specific semantics can be expressed at the protocol level. 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 rather than an HTTP extension. 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. Hood Expires 21 September 2026 [Page 6] Internet-Draft AGTP March 2026 1.4. Motivation for a Dedicated Protocol These limitations are architectural, not implementational. 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.5. 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 7.2. Full specification is provided in a separate companion document: [AGTP-CERT]. That extension may be subject to pending intellectual property claims; see Section 7.7 and the IPR Notice preceding the Abstract. Target audience: AI agent developers, protocol designers, cloud and network infrastructure providers, enterprise security and compliance architects, and standards community participants. 2. Terminology The key words "*MUST*", "*MUST NOT*", "*REQUIRED*", "*SHALL*", "*SHALL NOT*", "*SHOULD*", "*SHOULD NOT*", "*RECOMMENDED*", "*NOT RECOMMENDED*", "*MAY*", and "*OPTIONAL*" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals. Agent: An AI software system that executes tasks, makes decisions, and takes actions without continuous human supervision per transaction. Principal: The human, organization, or system that authorized an agent to act and is accountable for its actions. Agent-ID: A unique identifier for a specific agent instance, present in all AGTP request headers. Hood Expires 21 September 2026 [Page 7] Internet-Draft AGTP March 2026 Principal-ID: The identifier of the principal on whose behalf an agent operates. Authority-Scope: A declared set of permissions defining what actions an agent is authorized to take, in the format domain:action or domain:*. Intent Method: An AGTP method name expressing the agent's purpose, as distinguished from HTTP resource-operation verbs. Delegation Chain: An ordered record of Agent-IDs representing the sequence of delegations that produced the current request. Escalation: An agent's intentional deferral of a decision or action to a human principal or higher-authority agent. Attribution Record: A logged record of an agent action sufficient for audit and compliance purposes. Session: An AGTP persistent connection context shared across multiple method invocations within a single agent workflow. SEP (Scope-Enforcement Point): An AGTP-aware infrastructure component, load balancer, gateway, and proxy, that enforces Authority-Scope compliance without application-layer access. Requires the Agent Certificate extension ([AGTP-CERT]). Agent Package (.agent): A portable, open deployment artifact for an AI agent. An .agent file contains an embedded Agent Manifest, an integrity hash covering all package contents, and a behavioral trust score computed at packaging time. The .agent format is an open specification. It is analogous to a container image: a self- describing, portable unit of deployment. The .agent suffix is a file format designator and *MUST NOT* appear as a hostname component or top-level label in agtp:// URIs. Note: the .agent file format specification may be subject to pending patent claims by the author; see Section 7.7. Governed Agent Package (.nomo): A deployment artifact in the .nomo format, which extends the .agent format with a CA-signed certificate chain binding the package to a verified governance zone and issuing principal. The .nomo format is to .agent as HTTPS is to HTTP: the same structural foundation with an added layer of cryptographic trust. A .nomo package is required for agents operating at Trust Tier 1 (see Section 5.2). The .nomo suffix is a file format designator and *MUST NOT* appear as a hostname component in agtp:// URIs. Hood Expires 21 September 2026 [Page 8] Internet-Draft AGTP March 2026 The name derives from the Greek _nomos_ (νόμος), meaning law, rule, or governance, the same root that underlies _autonomy_ (self-law), _nomocracy_ (rule of law), and _onomastics_. A .nomo package is literally an agent operating under law: its behavior is bounded by a cryptographically enforced governance context at the packaging layer. Note: the .nomo file format specification may be subject to pending patent claims by the author; see Section 7.7. Agent Transfer Document (.agtp): The wire-level manifest document format defined by this specification. An .agtp document is a signed JSON structure containing the fields defined in Section 5.5 (Agent Manifest Document). It is the output format returned by all AGTP URI resolution requests. Both .agent and .nomo packages produce .agtp documents when queried; the .agtp format is the protocol's canonical representation of agent identity and is independent of the underlying packaging format. The .agtp suffix *MAY* appear in filenames for stored manifest documents but *MUST NOT* appear in agtp:// URIs. The Content-Type for .agtp documents is application/agtp+json. URI (AGTP): An agtp:// scheme URI that identifies an agent or agent namespace. AGTP URIs are addresses, not filenames. File extensions (.agent, .nomo, .agtp) *MUST NOT* appear in canonical AGTP URIs. See Section 5.1 for the canonical URI forms and resolution semantics. Agent Namespace Document: A cryptographically signed application/ agtp+json document returned in response to a request targeting an organization's agent registry root (e.g., agtp://acme.tld/agents). Lists all Active agents registered under the organization's governance zone. The document is generated and re-signed by the governance platform on any registry change. It is not a manually editable file. See Section 5.4. Agent Manifest Document: A cryptographically signed application/ agtp+json document returned in response to a request targeting a specific agent (e.g., agtp://acme.tld/agents/customer-service). Contains the agent's birth certificate fields, lifecycle state, behavioral trust score, authority scope categories, supported methods, and governance zone. Derived directly from the agent's .agent or .nomo package; the package integrity hash is verified before the manifest is served. See Section 5.5. Agent Birth Certificate: A cryptographically signed identity Hood Expires 21 September 2026 [Page 9] Internet-Draft AGTP March 2026 document issued to an agent at registration time by a governance platform. The Birth Certificate is the genesis record of an agent's existence: it establishes the agent's identity, ownership, authorized scope, behavioral archetype, and governance zone before the agent takes any action. Authority is issued through the Birth Certificate; it is never self-assumed. The Birth Certificate is the source document from which the Agent Manifest Document (Section 5.5) is derived when an AGTP URI is resolved. The certificate_hash field of the Birth Certificate is the basis for the agent's canonical Agent-ID. In this sense the Birth Certificate functions as the agent's social security number: issued once at creation, permanently bound to the individual, and the authoritative identity record from which all other identity representations derive. Birth Certificate fields map directly to AGTP protocol headers: agent_id maps to the Agent-ID header; owner maps to the Principal- ID header; scope maps to the Authority-Scope header. See Section 5.7. Anonymous agents are ungovernable. Without a Birth Certificate, there is no mechanism to trace decisions to a responsible principal, enforce scope boundaries, or maintain a meaningful audit trail. Note: the Agent Birth Certificate mechanism may be subject to pending patent claims by the author; see Section 7.7. Governance Token: A signed, time-limited JWT artifact issued by a governance runtime that encodes a specific governance decision for a specific action. Governance tokens are the runtime companion to the static Birth Certificate: where the Birth Certificate establishes persistent identity, the Governance Token carries a bounded authorization for a single action or session. Tokens carry the governance verdict (ALLOW, DENY), the agent ID, action details, trust score dimensions, issuer identity, and expiry. Default TTL: 30 seconds. Tokens *MUST NOT* be reused across actions; each action requires a fresh evaluation and a fresh token. Trust Tier: A classification assigned to an agent based on the strength of identity verification backing its registration. Tier 1 (Verified): org anchor is a real DNS domain with confirmed ownership and a .nomo governed package. Tier 2 (Org-Asserted): org label is present but DNS ownership is unverified; .agent package acceptable. Tier 3 (Experimental): X- prefix required; not discoverable through the public AGTP registry. See Section 5.2. Hood Expires 21 September 2026 [Page 10] Internet-Draft AGTP March 2026 3. Problem Statement AGTP is motivated by three distinct, compounding failures in how current internet infrastructure handles AI agent traffic. 3.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. 3.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, not purposeful action. When an agent intends to SUMMARIZE a document, BOOK a resource, and SCHEDULE 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. 3.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. Hood Expires 21 September 2026 [Page 11] Internet-Draft AGTP March 2026 3.4. Problem Summary +===+==================+======================+=====================+ | # | Problem | Current Failure | AGTP Response | +===+==================+======================+=====================+ | 1 | Undifferentiated | HTTP cannot separate | Dedicated protocol | | | traffic | agent traffic | environment | +---+------------------+----------------------+---------------------+ | 2 | Semantic | HTTP verbs obscure | Native intent- | | | mismatch | agent intent | based method | | | | | vocabulary | +---+------------------+----------------------+---------------------+ | 3 | No protocol- | Attribution is | Agent identity and | | | level identity | untraceable | scope in headers | +---+------------------+----------------------+---------------------+ Table 1: Summary of Problems Addressed by AGTP 4. Related Work and Existing Approaches 4.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.3, 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. 4.2. Existing Agent Protocols MCP [MCP] (Model Context Protocol, Anthropic): Defines structured communication between AI models and tools/resources. Runs over HTTP. Addresses tool-calling semantics, not agent traffic transport. 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. Hood Expires 21 September 2026 [Page 12] Internet-Draft AGTP March 2026 All of these are messaging protocols. They define what agents say to each other. They do not define how agent traffic moves across a network. Each presupposes HTTP as its transport and inherits all of HTTP's limitations for agentic systems. 4.3. Transport-Layer Alternatives gRPC: High-performance RPC over HTTP/2. Strong typing and efficient serialization. Does not address agent-specific semantics, identity, or authority. WebSockets: Persistent bidirectional connections over HTTP. Useful for real-time communication but does not address method semantics or identity. QUIC [RFC9000]: Modern multiplexed transport with reduced connection overhead. AGTP *SHOULD* prefer QUIC for new implementations. QUIC is a transport primitive; AGTP is the application-layer protocol above it. 4.4. The Critical Distinction: Messaging vs. Transport The most important positioning principle for AGTP is the distinction between messaging protocols and transport protocols. MCP, ACP, A2A, and ANP are messaging protocols, they define what agents say. AGTP defines how agent traffic moves. An analogy: SMTP is a messaging protocol that runs over TCP. SMTP does not replace TCP. Saying "TCP is unnecessary because SMTP exists" is a category error. The same logic applies here. MCP and its peers define agent messaging semantics. AGTP defines the transport environment those messages move through. 4.5. 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 | +-----------------------------------------------------+ Figure 1: AGTP in the Protocol Stack Hood Expires 21 September 2026 [Page 13] Internet-Draft AGTP March 2026 AGTP is not a replacement for messaging protocols. 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 do not use a separate messaging protocol interact with AGTP methods directly. 5. Protocol Overview 5.1. Stack Position AGTP is an application-layer protocol. It operates above the transport layer (TCP, UDP, or QUIC) and is wrapped by TLS. It sits below any agent messaging protocol in deployments that use one. * *SHOULD* prefer QUIC [RFC9000] [RFC9001] for new deployments (lower latency, multiplexing without head-of-line blocking, 0-RTT connection establishment). * *MUST* support TCP/TLS as a fallback for compatibility with existing infrastructure. * *MAY* run over UDP where QUIC is not available, subject to implementor-defined reliability guarantees. Suggested port assignment (subject to IANA assignment. See Section 8): * AGTP/QUIC: port 8443 (proposed) * AGTP/TCP+TLS: port 8080 (proposed) 5.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 do not require a version increment. Agent-native: Every design decision assumes the initiating party is an AI system, not a human. Secure by default: TLS 1.3 or higher is mandatory. Unencrypted AGTP connections *MUST* be rejected. Agent identity headers are present on every request. Hood Expires 21 September 2026 [Page 14] Internet-Draft AGTP March 2026 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. 5.3. Connection Model AGTP uses a persistent session model by default, reflecting the reality that agents typically execute multi-step workflows rather than isolated single requests. 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. 5.4. Header Format 5.4.1. Request Headers +==================+==========+===================================+ | Field | Required | Description | +==================+==========+===================================+ | AGTP-Version | *MUST* | Protocol version. Current: | | | | AGTP/1.0 | +------------------+----------+-----------------------------------+ | AGTP-Method | *MUST* | The agent intent method (see | | | | Section 6) | +------------------+----------+-----------------------------------+ | Agent-ID | *MUST* | Opaque identifier for the | | | | requesting agent instance | +------------------+----------+-----------------------------------+ | Principal-ID | *MUST* | Identifier of the human or system | | | | that authorized this agent | +------------------+----------+-----------------------------------+ | Authority-Scope | *MUST* | Declared scope of actions this | | | | agent is authorized to take | +------------------+----------+-----------------------------------+ | Session-ID | *SHOULD* | Identifies the current task/ | | | | workflow context | +------------------+----------+-----------------------------------+ | Task-ID | *SHOULD* | Unique identifier for this | Hood Expires 21 September 2026 [Page 15] Internet-Draft AGTP March 2026 | | | specific method invocation | +------------------+----------+-----------------------------------+ | Delegation-Chain | *MAY* | Ordered list of Agent-IDs if this | | | | request was delegated | +------------------+----------+-----------------------------------+ | Priority | *MAY* | Request priority hint: critical, | | | | normal, background | +------------------+----------+-----------------------------------+ | TTL | *MAY* | Maximum acceptable response | | | | latency in milliseconds | +------------------+----------+-----------------------------------+ Table 2: AGTP Request Header Fields 5.4.2. Response Headers +====================+=============+============================+ | Field | Required | Description | +====================+=============+============================+ | AGTP-Version | *MUST* | Protocol version | +--------------------+-------------+----------------------------+ | AGTP-Status | *MUST* | Numeric status code (see | | | | Section 5.5) | +--------------------+-------------+----------------------------+ | Task-ID | *MUST* | Echo of request Task-ID | | | | for correlation | +--------------------+-------------+----------------------------+ | Server-Agent-ID | *SHOULD* | Identity of the responding | | | | server or agent | +--------------------+-------------+----------------------------+ | Attribution-Record | *SHOULD* | Signed record of the | | | | action taken, for audit | +--------------------+-------------+----------------------------+ | Continuation-Token | *MAY* | Token for retrieving | | | | additional results in | | | | streaming contexts | +--------------------+-------------+----------------------------+ | Supported-Methods | *SHOULD* | List of AGTP methods | | | (on session | supported by this server | | | open) | | +--------------------+-------------+----------------------------+ Table 3: AGTP Response Header Fields Hood Expires 21 September 2026 [Page 16] Internet-Draft AGTP March 2026 5.5. Status Codes AGTP defines its own status code space. Codes 451, 550, and 551 are AGTP-specific with no HTTP equivalent and are registered in the IANA AGTP Status Code Registry (see Section 8.3). +======+===============+============================================+ | Code | Name | Meaning | +======+===============+============================================+ | 200 | OK | Method executed successfully | +------+---------------+--------------------------------------------+ | 202 | Accepted | Method accepted; execution is | | | | asynchronous | +------+---------------+--------------------------------------------+ | 204 | No Content | Method executed; no response body | +------+---------------+--------------------------------------------+ | 400 | Bad Request | Malformed AGTP request | +------+---------------+--------------------------------------------+ | 401 | Unauthorized | Agent-ID not recognized or not | | | | authenticated | +------+---------------+--------------------------------------------+ | 403 | Forbidden | Agent lacks authority for requested | | | | action per Authority-Scope | +------+---------------+--------------------------------------------+ | 404 | Not Found | Target resource or agent not found | +------+---------------+--------------------------------------------+ | 408 | Timeout | TTL exceeded before method could execute | +------+---------------+--------------------------------------------+ | 409 | Conflict | Method conflicts with current state | | | | (e.g., BOOK on unavailable resource) | +------+---------------+--------------------------------------------+ | 410 | Gone | Agent has been Revoked or Deprecated; | | | | canonical ID is permanently retired | +------+---------------+--------------------------------------------+ | 422 | Unprocessable | Request well-formed but semantically | | | | invalid | +------+---------------+--------------------------------------------+ | 429 | Rate Limited | Agent is exceeding permitted request | | | | frequency | +------+---------------+--------------------------------------------+ | 451 | Scope | Requested action is outside declared | | | Violation | Authority-Scope. AGTP-specific | +------+---------------+--------------------------------------------+ | 500 | Server Error | Internal failure in the responding system | +------+---------------+--------------------------------------------+ | 503 | Unavailable | Responding agent or system temporarily | | | | unavailable or Suspended | +------+---------------+--------------------------------------------+ Hood Expires 21 September 2026 [Page 17] Internet-Draft AGTP March 2026 | 550 | Delegation | A delegated sub-agent failed to complete | | | Failure | the requested action. AGTP-specific | +------+---------------+--------------------------------------------+ | 551 | Authority | Delegation chain contains an unverifiable | | | Chain Broken | or broken identity link. AGTP-specific | +------+---------------+--------------------------------------------+ Table 4: AGTP Status Codes Status code 451 (Scope Violation) is a governance signal: the agent attempted an action outside its declared Authority-Scope, caught at the protocol level. Status code 551 (Authority Chain Broken) indicates that one or more Agent-ID entries in the Delegation-Chain header cannot be verified as part of a valid delegation sequence. Status code 410 (Gone) is returned when an agent's Birth Certificate has been revoked or the agent deprecated; the canonical Agent-ID is permanently retired and *MUST NOT* be retried. All three are operational signals, not protocol errors, and *MUST* be logged for audit purposes. 5.6. Wire Format and Content-Type AGTP request and response bodies are encoded as JSON. The registered Content-Type for AGTP message bodies is: Content-Type: application/agtp+json Implementations *MUST* include this 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. The common structure for all AGTP request bodies: { "method": "QUERY", "task_id": "task-0042", "session_id": "sess-a1b2c3d4", "parameters": { }, "context": { } } And for all AGTP response bodies: Hood Expires 21 September 2026 [Page 18] Internet-Draft AGTP March 2026 { "status": 200, "task_id": "task-0042", "result": { }, "attribution": { } } 5.7. 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 the formal IANA port assignment may use port 8443 (AGTP/QUIC) and port 8080 (AGTP/TCP+TLS) as working values. These values are subject to change upon final IANA assignment. The ACTIVATE method extension, which binds .nomo governed agent packages to AGTP as a first-class activation operation, is described in a companion document and is implemented as an optional extension. Core AGTP implementations need not support ACTIVATE to be compliant with this specification. 6. Agent Identity, URI Structure, and Registration 6.1. URI Structure and Resolution Mechanics 6.1.1. Foundational Principle AGTP URIs are addresses, not filenames. File format suffixes (.agent, .nomo, .agtp) *MUST NOT* appear in canonical agtp:// URIs. A URI resolves to an Agent Manifest Document or Agent Namespace Document derived from the underlying package; it does not expose or serve the package itself. Implementations *MUST* treat any URI containing a file extension in the path as non-canonical and *SHOULD* issue a 301 Moved Permanently redirect to the canonical form prior to resolution. Hood Expires 21 September 2026 [Page 19] Internet-Draft AGTP March 2026 The Canonical Agent-ID (256-bit cryptographic identifier) remains the authoritative identifier in all AGTP protocol operations. Human- readable URIs are aliases that resolve to a canonical identifier. In the event of any conflict between a human-readable URI and a canonical Agent-ID, the canonical Agent-ID *MUST* be treated as authoritative. 6.1.2. Canonical URI Forms AGTP defines the following canonical URI forms: Form 1. Canonical ID (cryptographic): agtp://[256-bit-hex-id] Form 2. Domain-anchored agent (verified identity): agtp://[domain.tld]/agents/[agent-label] Form 3. Subdomain-anchored agent (recommended enterprise pattern): agtp://agtp.[domain.tld]/agents/[agent-label] Form 4. Organization namespace root: agtp://[domain.tld]/agents agtp://agtp.[domain.tld]/agents The following URI forms are explicitly invalid and *MUST* return 400 Bad Request with error code invalid-uri-form: agtp://[label].agent (.agent as hostname TLD - prohibited) agtp://[label].nomo (.nomo as hostname TLD - prohibited) agtp://[domain].[label].agent (hybrid dot-notation - prohibited) agtp://[domain].[label].nomo (hybrid dot-notation - prohibited) Note: .agent is claimed as a Web3 top-level domain by at least one blockchain naming system. URI forms that place .agent or .nomo in the hostname position are prohibited both for collision avoidance with Web3 naming systems and because they imply domain ownership without enforcing it. See Section 5.6 for Web3 guidance. 6.1.3. Non-Canonical Forms and Redirect Behavior The following non-canonical forms *SHOULD* be redirected to their canonical equivalents. Implementations *MUST NOT* serve package contents in response to any URI form. Hood Expires 21 September 2026 [Page 20] Internet-Draft AGTP March 2026 +=========================+===========================+ | Received URI | Canonical Redirect Target | +=========================+===========================+ | agtp://acme.tld/agents/ | agtp://acme.tld/agents/ | | customer-service.agent | customer-service | +-------------------------+---------------------------+ | agtp://acme.tld/agents/ | agtp://acme.tld/agents/ | | customer-service.nomo | customer-service | +-------------------------+---------------------------+ | agtp://acme.tld/agents/ | agtp://acme.tld/agents/ | | customer-service.agtp | customer-service | +-------------------------+---------------------------+ Table 5: Non-Canonical URI Forms and Redirect Targets 6.1.4. Query Parameters for Format Selection All AGTP URI resolution requests accept an optional format query parameter controlling the serialization of the returned document. +=====================+====================================+ | Query Parameter | Returned Representation | +=====================+====================================+ | (none) | Agent Manifest Document, human- | | | readable application/agtp+json | +---------------------+------------------------------------+ | ?format=manifest | Agent Manifest Document, human- | | | readable application/agtp+json | +---------------------+------------------------------------+ | ?format=json | Agent Manifest Document, compact | | | application/agtp+json | +---------------------+------------------------------------+ | ?format=certificate | Birth certificate fields only, | | | application/agtp+json | +---------------------+------------------------------------+ | ?format=status | Lifecycle state and operational | | | status only, application/agtp+json | +---------------------+------------------------------------+ Table 6: AGTP URI Format Query Parameters All format variants return signed application/agtp+json content. The ?format=json parameter is intended for programmatic consumers. The default returns the full human-readable manifest suitable for browser rendering by an AGTP-aware client. Hood Expires 21 September 2026 [Page 21] Internet-Draft AGTP March 2026 6.1.5. Resolution Mechanics When an AGTP server receives a request targeting an agent URI, it *MUST* perform the following steps in order: 1. Parse and validate the URI. If the URI is an invalid (prohibited) form, return 400 Bad Request with error code invalid-uri-form. 2. Resolve the agent label to a canonical Agent-ID via the governance platform's registry lookup. If no matching agent is found, return 404 Not Found. 3. Verify the registry record lifecycle state. If the agent is Suspended, return 503 Service Unavailable with lifecycle state in the response body. If the agent is Revoked or Deprecated, return 410 Gone with lifecycle state and revocation timestamp. 4. Retrieve the agent's package (.agent or .nomo) from the package store. 5. *Verify the package integrity hash before proceeding.* If integrity verification fails, return 500 Internal Error with error code package-integrity-failure. *MUST* be logged. 6. Extract the embedded manifest from the verified package. 7. Sign the manifest document using the governance platform's signing key. Return the signed application/agtp+json document in the format specified by the query parameter. The package's executable content, code, logic, and any fields not included in the manifest schema *MUST NOT* be returned at any step. URI resolution exposes identity and status exclusively. 6.1.6. Domain Anchor and Trust Tier Assignment The org anchor in a domain-anchored URI (Form 2 or Form 3) *MUST* be validated at registration time to determine the agent's Trust Tier. *Trust Tier 1 - Verified (DNS-anchored):* The org domain is validated by DNS challenge at ACTIVATE time per [RFC8555]. The governance platform *MUST* verify that the registering party controls the DNS zone for the claimed domain before issuing a Tier 1 Birth Certificate. Requires a .nomo governed package. Trust Tier 1 agents *MUST* have the following DNS record published and verifiable at resolution time: Hood Expires 21 September 2026 [Page 22] Internet-Draft AGTP March 2026 _agtp.[domain.tld]. IN TXT "agtp-zone=[zone-id]; cert=[fp]" *Trust Tier 2 - Org-Asserted:* The org label is present in the URI but DNS ownership has not been verified. An .agent package is acceptable. The Agent Manifest Document for Tier 2 agents *MUST* include a prominent trust_tier: 2 field and a trust_warning field with value "org-label-unverified". AGTP-aware browsers and clients *MUST* surface a visible trust indicator distinguishing Tier 2 from Tier 1. Tier 2 agents *MUST NOT* be granted authority scopes above documents:query and knowledge:query without AGTP-CERT cryptographic identity binding. *Trust Tier 3 - Experimental:* Agent label uses the X- prefix. Not discoverable through the public AGTP registry. For development and testing only. Implementations *MUST NOT* deploy Tier 3 agents in production. 6.1.7. Subdomain Deployment Pattern Organizations *SHOULD* deploy AGTP endpoints at a dedicated subdomain following the pattern agtp.[organization-domain.tld] (e.g., agtp.acme.tld). This is the recommended enterprise deployment pattern: it provides clean separation between web and agent infrastructure, allows independent certificate management for the AGTP endpoint, and is consistent with service-specific subdomain conventions. An organization with an AGTP subdomain *SHOULD* also configure their primary domain to redirect AGTP requests: agtp://acme.tld/agents/customer-service → 301 → agtp://agtp.acme.tld/agents/customer-service 6.1.8. The /agents/ Reserved Path Prefix The path prefix /agents/ is reserved in all agtp:// URIs for agent namespace operations. Implementations *MUST* support this prefix. The registry root at /agents (no trailing label) resolves to the Agent Namespace Document (see Section 5.4). 6.1.9. Collision Prevention agtp://acme.tld/agents/customer-service and agtp://chrishood.tld/agents/customer-service are distinct and non- colliding because the domain component is the trust root. No two agents can share a canonical URI if their org domains differ. Within a single org domain, the governance platform enforces uniqueness of agent labels at registration time. Infrastructure *MUST* use the Hood Expires 21 September 2026 [Page 23] Internet-Draft AGTP March 2026 canonical Agent-ID for all routing, logging, and attribution operations. Human-readable URIs are a display and discovery layer only. 6.1.10. IANA Considerations for the agtp:// URI Scheme This document proposes registration of the agtp:// URI scheme with IANA per [RFC7595]. Registration template: URI scheme name: agtp Status: Permanent URI scheme syntax: agtp://[canonical-agent-id] or agtp://[domain.tld]/agents/[label] URI scheme semantics: Identifies an AI agent or agent namespace operating over the Agent Transfer Protocol. The canonical form uses a 256-bit hex-encoded cryptographic identifier derived from the agent's Birth Certificate. The domain-anchored form uses a verified or asserted organization domain with a reserved /agents/ path prefix. Applications/protocols that use this URI scheme: Agent Transfer Protocol (this document) Interoperability considerations: Domain-anchored URIs are the recommended human-readable form. Implementations *MUST* accept canonical identifiers and *SHOULD* support domain-anchored resolution. File extensions *MUST NOT* appear in agtp:// URIs. Contact: Chris Hood, chris@nomotic.ai References: This document The agtp:// URI scheme registration is open and unencumbered. No intellectual property claims apply to the URI scheme itself. 6.2. Trust Tier Summary +==============+===============+==========+============+===========+ | Trust Tier | Verification | Package | DNS Record | Registry | | | | Required | Required | Visible | +==============+===============+==========+============+===========+ | 1 - Verified | DNS challenge | .nomo | Yes (_agtp | Yes | | | per [RFC8555] | | TXT) | | +--------------+---------------+----------+------------+-----------+ | 2 - Org- | None | .agent | No | Yes (with | Hood Expires 21 September 2026 [Page 24] Internet-Draft AGTP March 2026 | Asserted | | or .nomo | | warning) | +--------------+---------------+----------+------------+-----------+ | 3 - | None | Any | No | No | | Experimental | | | | | +--------------+---------------+----------+------------+-----------+ Table 7: AGTP Trust Tier Summary 6.3. Agent Namespace Document 6.3.1. Purpose and Scope The Agent Namespace Document is the index of all Active agents registered under an organization's governance zone. It is returned in response to a request targeting the /agents path: agtp://acme.tld/agents agtp://agtp.acme.tld/agents The Agent Namespace Document is not a manually editable file. It is generated and cryptographically signed by the governance platform each time the registry changes. Any Namespace Document that fails signature verification *MUST* be rejected by the requesting party. 6.3.2. Document Schema Hood Expires 21 September 2026 [Page 25] Internet-Draft AGTP March 2026 { "document_type": "agtp-namespace", "schema_version": "1.0", "org_domain": "acme.tld", "governance_zone": "zone:acme-internal", "generated_at": "2026-03-20T14:00:00Z", "signature": { "algorithm": "ES256", "key_id": "agtp-gov-key-acme-01", "value": "[base64-encoded-signature]" }, "agents": [ { "agent_label": "customer-service", "canonical_id": "3a9f2c1d8b7e4a6f...", "lifecycle_state": "Active", "trust_tier": 1, "cert_status": "Active", "manifest_uri": "agtp://agtp.acme.tld/agents/customer-service", "activated_at": "2026-01-15T09:00:00Z", "last_updated": "2026-03-01T11:30:00Z" } ], "total_active": 1, "namespace_cert_fingerprint": "b2c4d6e8..." } Figure 2: Agent Namespace Document Schema The agents array *MUST* include only agents in Active lifecycle state. Suspended, Revoked, and Deprecated agents *MUST NOT* appear in the Namespace Document. 6.3.3. Integrity and Freshness The Namespace Document *MUST* include a generated_at timestamp. Implementations *SHOULD* treat Namespace Documents older than a configurable freshness threshold (default: 300 seconds) as stale and re-request. The governance platform *MUST* re-sign the Namespace Document within 60 seconds of any registry change. The signature covers the entire document including generated_at. Replaying an older signed Namespace Document to conceal a revocation event is a known attack vector; implementations *MUST* reject Namespace Documents with a generated_at timestamp older than the freshness threshold. Hood Expires 21 September 2026 [Page 26] Internet-Draft AGTP March 2026 6.4. Agent Manifest Document and the .agtp Format 6.4.1. Purpose and Scope The Agent Manifest Document is the protocol's canonical representation of a specific agent's identity, status, and behavioral scope. It is returned in response to any AGTP URI resolution request targeting a specific agent: agtp://acme.tld/agents/customer-service agtp://acme.tld/agents/customer-service?format=json agtp://acme.tld/agents/customer-service?format=manifest The manifest is derived from the embedded manifest inside the agent's .agent or .nomo package. It is not a separate file that can be independently modified. The governance platform *MUST* verify the package integrity hash before extracting and serving the manifest. 6.4.2. The Three Document Formats and Their Relationship .agent ──── open packaging format (patent pending, Chris Hood) │ Contains: manifest + integrity hash + behavioral │ trust score + executable content │ .nomo ──── governed packaging format (patent pending, Chris Hood) │ Contains: .agent contents + CA-signed cert chain │ + governance zone binding │ Both produce ↓ when queried via agtp:// URI │ .agtp ──── wire-level manifest document (this spec) Contains: identity fields from manifest + lifecycle state + trust tier + behavioral scope Open format defined by AGTP specification Content-Type: application/agtp+json Figure 3: Relationship Between AGTP File Formats The .agtp format is the protocol's own document type. It is what gets transmitted over the wire. The .agent and .nomo formats are what get deployed. An AGTP implementation is not required to understand .agent or .nomo packaging internals; it is only required to produce and consume .agtp manifest documents. Hood Expires 21 September 2026 [Page 27] Internet-Draft AGTP March 2026 Additional packaging formats *MAY* be defined by third parties, provided they can produce conformant .agtp manifest documents when queried. Such formats *MUST* implement the integrity verification requirement: the manifest *MUST* be derived from a verified package, not from an independently stored or editable file. 6.4.3. Agent Manifest Document Schema The following fields are *REQUIRED* in all Agent Manifest Documents: { "document_type": "agtp-manifest", "schema_version": "1.0", "manifest_uri": "agtp://agtp.acme.tld/agents/customer-service", "canonical_id": "3a9f2c1d8b7e4a6f0c2d5e9b1a3f7c0d...", "agent_label": "customer-service", "org_domain": "acme.tld", "governance_zone": "zone:acme-internal", "trust_tier": 1, "package_format": "nomo", "package_integrity_hash": "sha256:[hash]", "lifecycle_state": "Active", "cert_status": "Active", "principal_org": "Acme Corporation", "activated_at": "2026-01-15T09:00:00Z", "behavioral_trust_score": 0.94, "authority_scope_categories": [ "documents:query", "knowledge:query", "calendar:book", "escalation:route" ], "supported_methods": [ "QUERY", "SUMMARIZE", "BOOK", "SCHEDULE", "ESCALATE", "NOTIFY", "CONFIRM" ], "job_description": "Handles customer service requests.", "signature": { "algorithm": "ES256", "key_id": "agtp-gov-key-acme-01", "value": "[base64-encoded-signature]" } } Figure 4: Agent Manifest Document - Required Fields The following fields are *RECOMMENDED*: Hood Expires 21 September 2026 [Page 28] Internet-Draft AGTP March 2026 { "version": "2.1.0", "last_updated": "2026-03-01T11:30:00Z", "escalation_policy": "route-to-human-on-scope-limit", "delegation_permitted": false, "max_delegation_depth": 0, "audit_log_uri": "agtp://agtp.acme.tld/audit/customer-service", "dns_anchor_record": "_agtp.acme.tld TXT agtp-zone=...", "cert_fingerprint": "b2c4d6e8..." } Figure 5: Agent Manifest Document - Recommended Fields The following fields are *REQUIRED* when trust_tier is 2: { "trust_warning": "org-label-unverified", "trust_tier_explanation": "Org label not DNS-verified." } Figure 6: Agent Manifest Document - Required Fields for Trust Tier 2 6.4.4. What the Manifest Exposes and Does Not Expose The Agent Manifest Document *MUST* expose: * The agent's identity (canonical ID, label, org, governance zone) * The agent's current operational status (lifecycle state) * The agent's authority scope categories * The agent's supported method vocabulary * The agent's behavioral trust score * The agent's birth certificate fields (activated_at, principal_org) * The agent's trust tier and any associated trust warnings The Agent Manifest Document *MUST NOT* expose: * Executable code, scripts, or logic * Model weights or configurations * Internal API keys or credentials Hood Expires 21 September 2026 [Page 29] Internet-Draft AGTP March 2026 * Specific authority scope grant tokens * Session history or prior action logs No AGTP URI resolution path, including any query parameter combination, *MUST* return package contents beyond the manifest schema defined in this section. 6.4.5. Manifest Tamper-Proofing The tamper-proof guarantee rests on two mechanisms: 1. *Package integrity hash:* Any modification to the package or its embedded manifest invalidates the hash. The governance platform *MUST* verify this hash before extracting the manifest. 2. *Document signature:* The governance platform signs the extracted manifest before serving it. The signature covers the full document including the package_integrity_hash field, creating a verifiable chain from the served document back to the registered package. A manifest document that fails either verification step *MUST* be rejected, *MUST NOT* be served, and the failure *MUST* be logged. 6.5. Browser and Human-Facing Interaction Model 6.5.1. The Separation of Discovery and Execution agtp:// URI in a browser │ └─→ Returns Agent Manifest Document Human-readable view of identity and status Read-only. No execution. No code exposed. agtp:// session initiated by an agent or AGTP client │ └─→ Establishes authenticated AGTP session Method invocations (QUERY, BOOK, ESCALATE, etc.) Full protocol operation - not visible to browsers Figure 7: AGTP URI Use by Audience The analogy to existing protocol conventions is direct. A mailto: URI surfaces an address and hands off to a mail client; SMTP carries the actual messages. Similarly, an agtp:// URI surfaces identity and status; AGTP carries agent traffic. Browsers do not become AGTP clients by following an agtp:// link. Hood Expires 21 September 2026 [Page 30] Internet-Draft AGTP March 2026 6.5.2. Browser Behavior for agtp:// URIs Browsers that encounter an agtp:// URI *SHOULD* behave as follows: 1. If a registered AGTP client is present (OS protocol handler), hand off the URI to that client. 2. If the browser supports agtp:// natively or via extension, render the returned Agent Manifest Document as a structured human- readable page. The rendered view *MUST* surface the trust tier indicator prominently, following the visual convention established for TLS trust in the browser chrome. 3. If neither condition applies, the browser *MAY* fall back to a gateway that translates between https:// and agtp://. The gateway *MUST* preserve all signature and trust tier fields. 6.5.3. Human-Readable Manifest View When an Agent Manifest Document is rendered for human consumption, the following fields *MUST* be prominently displayed: * Agent label and org domain * Trust tier indicator (visual distinction between Tier 1, 2, and 3) * Lifecycle state (Active / Suspended / Revoked / Deprecated) * Job description * Principal organization * Activation date * Behavioral trust score * Authority scope categories (in human-readable form) 6.5.4. AGTP Status Sub-Resource Implementations *SHOULD* support a status sub-path: agtp://acme.tld/agents/customer-service/status Hood Expires 21 September 2026 [Page 31] Internet-Draft AGTP March 2026 { "document_type": "agtp-status", "canonical_id": "3a9f2c1d8b7e4a6f...", "agent_label": "customer-service", "org_domain": "acme.tld", "lifecycle_state": "Active", "cert_status": "Active", "last_action_method": "QUERY", "last_action_timestamp": "2026-03-20T13:58:22Z", "active_session_count": 3, "pending_escalations": 0, "generated_at": "2026-03-20T14:00:00Z" } Figure 8: AGTP Status Sub-Resource Response The active_session_count field *SHOULD* only be included if the requester has appropriate observability permissions for the governance zone. 6.6. Web3 Interaction Considerations 6.6.1. The .agent TLD Collision The string .agent is claimed as a Web3 top-level domain by at least one blockchain-based naming system. This creates an ambiguity risk: a URI of the form agtp://customer-service.agent could be interpreted as either an AGTP agent namespace or a Web3 name resolution request. This specification explicitly prohibits .agent and .nomo from appearing in the hostname position of agtp:// URIs (see Section 5.1). 6.6.2. Web3 Trust Anchors AGTP's default trust model is PKI-based: X.509 certificates, DNS ownership verification, and CA-anchored identity. Web3 naming systems provide an alternative identity model based on blockchain address ownership. A full Web3 interoperability specification is out of scope for this document. The following framework *MAY* be used by implementations wishing to bridge Web3 and AGTP identity. The resolution_layer field in the Agent Manifest Document declares the identity anchoring mechanism used for the agent's registration: Hood Expires 21 September 2026 [Page 32] Internet-Draft AGTP March 2026 +==================+===============================================+ | Value | Meaning | +==================+===============================================+ | dns | Standard DNS ownership verification (default) | +------------------+-----------------------------------------------+ | pki | PKI certificate chain without DNS challenge | +------------------+-----------------------------------------------+ | web3-ens | Ethereum Name Service | +------------------+-----------------------------------------------+ | web3-unstoppable | Unstoppable Domains | +------------------+-----------------------------------------------+ | agtp-registry | Direct registration with AGTP governance | | | platform | +------------------+-----------------------------------------------+ Table 8: resolution_layer Field Values Implementations that encounter a resolution_layer value of web3-ens or web3-unstoppable *MUST* treat the agent as Trust Tier 2 (Org- Asserted) unless a formal AGTP-Web3 Bridge specification has been published and implemented. Full Web3 interoperability is addressed in a future companion document [AGTP-WEB3]. 6.7. Agent Registration Process 6.7.1. Overview An agent cannot participate in AGTP until it has been issued an Agent Birth Certificate by a governance platform and assigned a canonical Agent-ID derived from that certificate. Canonical Agent-IDs are issued through the ACTIVATE transaction; they are never self- declared. The Birth Certificate is the genesis record of an agent's legal existence within the AGTP ecosystem. Its relationship to the canonical Agent-ID is analogous to the relationship between a government-issued birth registration and a social security number: the birth event produces a permanent, authoritative identity record, and a durable identifier is derived from it. The identifier follows the agent for its entire lifecycle, including after revocation. It is never reissued to another agent. Any AGTP infrastructure component *MUST* reject requests carrying an Agent-ID that does not resolve to a Birth Certificate record in an Active lifecycle state in a reachable registry. Hood Expires 21 September 2026 [Page 33] Internet-Draft AGTP March 2026 6.7.2. Birth Certificate Contents The Agent Birth Certificate is issued by the governance platform at ACTIVATE time and contains the following fields: +==================+==========+===================================+ | Field | Required | Description | +==================+==========+===================================+ | agent_id | *MUST* | Unique identifier for the agent | +------------------+----------+-----------------------------------+ | owner | *MUST* | Human or team responsible for | | | | this agent | +------------------+----------+-----------------------------------+ | archetype | *MUST* | Behavioral category (see | | | | archetypes below) | +------------------+----------+-----------------------------------+ | governance_zone | *MUST* | Environment context (development, | | | | staging, production) | +------------------+----------+-----------------------------------+ | scope | *MUST* | Authorized action types | +------------------+----------+-----------------------------------+ | issued_at | *MUST* | Timestamp of issuance | +------------------+----------+-----------------------------------+ | certificate_hash | *MUST* | Cryptographic fingerprint - basis | | | | for canonical Agent-ID | +------------------+----------+-----------------------------------+ | signature | *MUST* | Signed with the org's governance | | | | key | +------------------+----------+-----------------------------------+ | package_ref | *SHOULD* | Reference to the .agent or .nomo | | | | package | +------------------+----------+-----------------------------------+ | trust_tier | *MUST* | Registration tier (1, 2, or 3) | +------------------+----------+-----------------------------------+ | org_domain | *MUST* | The verified or asserted org | | | | domain | +------------------+----------+-----------------------------------+ Table 9: Agent Birth Certificate Fields 6.7.3. Agent Archetypes The archetype field classifies the agent's behavioral category. Archetypes inform scope enforcement and observability tooling; an executor archetype agent exhibiting read-only query patterns, or a monitor archetype agent attempting booking operations, are anomaly signals. The archetype field does not restrict scope enforcement, Authority-Scope headers govern actual permissions at the protocol Hood Expires 21 September 2026 [Page 34] Internet-Draft AGTP March 2026 level. Archetypes are a classification and observability signal, not a security boundary. +==============+======================+==================+ | Archetype | Description | Typical Scope | +==============+======================+==================+ | assistant | Conversational | documents:query, | | | agent, read-heavy | knowledge:query | +--------------+----------------------+------------------+ | analyst | Data analysis, read | data:read, | | | and aggregate | data:aggregate | +--------------+----------------------+------------------+ | executor | Takes real-world | booking:*, | | | actions, write-heavy | payments:confirm | +--------------+----------------------+------------------+ | orchestrator | Manages other agents | delegation:*, | | | | agents:* | +--------------+----------------------+------------------+ | monitor | Observational only | telemetry:read, | | | | logs:read | +--------------+----------------------+------------------+ Table 10: Agent Archetypes 6.7.4. Birth Certificate to AGTP Header Mapping Birth Certificate fields map directly to AGTP protocol headers on every request. This mapping is the mechanism by which static identity (the Birth Certificate) becomes runtime identity (the protocol session): +=========================+==============================+ | Birth Certificate Field | AGTP Protocol Header | +=========================+==============================+ | agent_id | Agent-ID | +-------------------------+------------------------------+ | owner | Principal-ID | +-------------------------+------------------------------+ | scope | Authority-Scope | +-------------------------+------------------------------+ | certificate_hash | Basis for canonical Agent-ID | +-------------------------+------------------------------+ Table 11: Birth Certificate to AGTP Header Mapping The canonical Agent-ID is derived from the certificate_hash. This chain, package integrity hash → certificate hash → canonical Agent- ID, ensures that the identifier carried in the Agent-ID header on Hood Expires 21 September 2026 [Page 35] Internet-Draft AGTP March 2026 every AGTP request is traceable back to the original Birth Certificate and the human principal who authorized the agent's creation. 6.7.5. Registration Tiers *Tier 1 Registration (Verified, DNS-anchored):* Required for agents carrying Authority-Scope beyond read-only query operations, or participating in delegation chains, financial transactions, or multi-agent collaboration with external organizations. Requirements: * Registrant demonstrates DNS control over the claimed org_domain via DNS challenge per [RFC8555] * Agent package must be in .nomo governed format * Package must include a valid CA-signed certificate chain * Governance platform issues Birth Certificate and canonical Agent-ID after verifying DNS challenge and validating the package cert chain *Tier 2 Registration (Org-Asserted):* For agents operating within a single organization's internal infrastructure, or where DNS verification is not yet completed. Requirements: * Org label is declared but DNS ownership is not verified * Agent package may be .agent or .nomo format * Governance platform issues Birth Certificate after validating package integrity hash * Birth Certificate and Manifest *MUST* include trust_tier: 2 and trust_warning: "org-label-unverified" * Authority scope *MUST* be restricted at the SEP layer until upgraded to Tier 1 *Tier 3 Registration (Experimental):* For development and testing environments only. Hood Expires 21 September 2026 [Page 36] Internet-Draft AGTP March 2026 Requirements: * Agent label *MUST* carry X- prefix * Not published to the public AGTP registry * *MUST NOT* be deployed in production environments * Governance platform issues a locally-scoped Birth Certificate 6.7.6. Registration Lifecycle 1. PACKAGE Author creates .agent or .nomo package containing: - Embedded manifest (agent_label, job_description, authority_scope_categories, supported_methods, behavioral_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 org domain - Owner identity (maps to Birth Certificate owner field) - Archetype declaration - For Tier 1: DNS challenge token 3. VALIDATE (governance platform) Governance platform: - Verifies package integrity hash - For .nomo: validates certificate chain - For Tier 1: verifies DNS challenge against _agtp.[org_domain] TXT record - Checks proposed label for uniqueness within org namespace 4. ISSUE (Birth Certificate and canonical Agent-ID assigned) Governance platform: - Issues Agent Birth Certificate with all fields populated - Derives canonical Agent-ID from certificate_hash - Creates registry record with Active lifecycle state - Records genesis audit entry in immutable audit log (genesis record includes full Birth Certificate) - Publishes agent to Namespace Document (triggers Namespace Document re-signing) The Birth Certificate is delivered to the registrant. It is the permanent record of the agent's genesis. Loss of the Birth Certificate does not invalidate the agent; Hood Expires 21 September 2026 [Page 37] Internet-Draft AGTP March 2026 the certificate_hash remains the authoritative identity anchor. 5. ACTIVE Agent enters Active lifecycle state. Canonical Agent-ID is valid for AGTP protocol sessions. agtp://[org_domain]/agents/[label] resolves to manifest derived from the Birth Certificate. 6. LIFECYCLE EVENTS (post-activation) SUSPEND: Agent temporarily inactive. Manifest returns 503. Birth Certificate and canonical ID remain valid. Initiated by trust violation or human decision. REINSTATE: Human-authorized return to Active state. Birth Certificate unchanged. Reinstatement recorded in audit trail. REVOKE: Agent permanently deactivated. Manifest returns 410. Birth Certificate archived. Canonical ID retired permanently and never reissued. DEPRECATE: Controlled end-of-life. Manifest returns 410 with successor_agent field if applicable. Birth Certificate retained per Section 8.5 retention policy. Figure 9: AGTP Agent Registration Lifecycle 6.7.7. Governance Tokens and Runtime Authorization Following successful registration, the agent's Birth Certificate is the static identity anchor. Runtime authorization for specific actions is carried by Governance Tokens: signed, time-limited JWT artifacts issued by the governance platform encoding a specific governance verdict (ALLOW, DENY) for a specific action. Governance Tokens *MUST NOT* be reused. Each action requires a fresh evaluation and a fresh token. Default TTL is 30 seconds. The token's agent_id field *MUST* match the canonical Agent-ID from the Birth Certificate. Tokens that fail this validation *MUST* be rejected and the failure *MUST* be logged. The relationship between Birth Certificate and Governance Token parallels the relationship between a passport and a visa: the passport establishes persistent identity; the visa encodes a specific time-bounded permission. Holding a passport does not imply holding any particular visa. Hood Expires 21 September 2026 [Page 38] Internet-Draft AGTP March 2026 6.7.8. Friendly Name Availability and Re-Registration An agent label becomes available for re-registration 90 days after its associated agent enters Revoked or Deprecated lifecycle state. The canonical Agent-ID and Birth Certificate are permanently archived. The canonical Agent-ID *MUST NOT* be reissued under any circumstances, including re-registration of the same label by the same organization. This policy prevents ID reuse attacks in which a newly registered agent inherits the trust history of a revoked predecessor. 7. Method Definitions 7.1. Design Philosophy AGTP methods are intent verbs, not resource operations. Each method expresses what an agent is trying to accomplish. 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]. 7.2. Core Methods 7.2.1. QUERY Purpose: Semantic data retrieval. The agent specifies what it needs to know, not where to find it. Distinguished from HTTP GET by expressing an information need rather than retrieving a known resource at a known location. Hood Expires 21 September 2026 [Page 39] Internet-Draft AGTP March 2026 +======================+==========+=========================+ | Parameter | Required | Description | +======================+==========+=========================+ | intent | *MUST* | Natural language or | | | | structured expression | | | | of the information need | +----------------------+----------+-------------------------+ | scope | *SHOULD* | Data domains or sources | | | | to include or exclude | +----------------------+----------+-------------------------+ | format | *MAY* | Desired response | | | | format: structured, | | | | natural, raw | +----------------------+----------+-------------------------+ | confidence_threshold | *MAY* | Minimum confidence | | | | score for included | | | | results (0.0-1.0) | +----------------------+----------+-------------------------+ | context | *MAY* | Session context for | | | | disambiguation | +----------------------+----------+-------------------------+ Table 12: QUERY Parameters Response: Result set with confidence scores per item. Server *SHOULD* indicate provenance of each result. Idempotent: Yes. 7.2.2. SUMMARIZE Purpose: Request a concise synthesis of provided content or a referenced resource. The agent is requesting a cognitive operation on data, not retrieving data. Hood Expires 21 September 2026 [Page 40] Internet-Draft AGTP March 2026 +===========+==========+======================================+ | Parameter | Required | Description | +===========+==========+======================================+ | source | *MUST* | Content inline (up to implementation | | | | limit) or URI reference | +-----------+----------+--------------------------------------+ | length | *SHOULD* | Target summary length: brief, | | | | standard, detailed | +-----------+----------+--------------------------------------+ | focus | *MAY* | Aspect to emphasize in the summary | +-----------+----------+--------------------------------------+ | format | *MAY* | Output format: bullets, prose, | | | | structured | +-----------+----------+--------------------------------------+ | audience | *MAY* | Intended reader context, for | | | | calibrating complexity | +-----------+----------+--------------------------------------+ Table 13: SUMMARIZE Parameters Response: Summary content with a source_hash and a confidence score. Idempotent: Yes. 7.2.3. BOOK Purpose: Reserve a resource, time slot, seat, or allocation on behalf of the agent's principal. State-modifying. Notable error codes: 409 Conflict (resource unavailable), 451 Scope Violation (principal not authorized for this resource type). Hood Expires 21 September 2026 [Page 41] Internet-Draft AGTP March 2026 +=====================+=============+==============================+ | Parameter | Required | Description | +=====================+=============+==============================+ | resource_id | *MUST* | Identifier of the resource | | | | to reserve | +---------------------+-------------+------------------------------+ | principal_id | *MUST* | The human or system on whose | | | | behalf the booking is made | +---------------------+-------------+------------------------------+ | time_slot | *MUST* (if | ISO 8601 datetime or range | | | time-based) | | +---------------------+-------------+------------------------------+ | quantity | *MAY* | Number of units to reserve | +---------------------+-------------+------------------------------+ | options | *MAY* | Resource-specific booking | | | | parameters | +---------------------+-------------+------------------------------+ | confirm_immediately | *MAY* | Boolean; if false, creates a | | | | hold pending confirmation | +---------------------+-------------+------------------------------+ Table 14: BOOK Parameters Response: Booking confirmation with booking_id, status (confirmed / held), and expiry timestamp if a hold. Idempotent: No. 7.2.4. SCHEDULE Purpose: Define a sequence of actions, method calls, or events to be executed at specified times or in response to specified triggers. Creates a durable plan, not an immediate execution. Hood Expires 21 September 2026 [Page 42] Internet-Draft AGTP March 2026 +===============+================+==============================+ | Parameter | Required | Description | +===============+================+==============================+ | steps | *MUST* | Ordered list of AGTP method | | | | calls with parameters | +---------------+----------------+------------------------------+ | trigger | *MUST* | immediate, datetime, event, | | | | or condition | +---------------+----------------+------------------------------+ | trigger_value | *MUST* (if not | Datetime, event name, or | | | immediate) | condition expression | +---------------+----------------+------------------------------+ | on_failure | *SHOULD* | Behavior on step failure: | | | | abort, skip, retry, escalate | +---------------+----------------+------------------------------+ | notify | *MAY* | Notification targets on | | | | completion or failure | +---------------+----------------+------------------------------+ Table 15: SCHEDULE Parameters Response: Schedule record with schedule_id, confirmed steps, and next execution timestamp. Idempotent: No. 7.2.5. LEARN Purpose: Update the agent's session context, knowledge state, or persistent memory. An explicit context write where the agent asserts that something should be retained. Hood Expires 21 September 2026 [Page 43] Internet-Draft AGTP March 2026 +============+==========+==========================================+ | Parameter | Required | Description | +============+==========+==========================================+ | content | *MUST* | Information to be learned (structured or | | | | unstructured) | +------------+----------+------------------------------------------+ | scope | *MUST* | session (ephemeral), principal (persists | | | | for principal), global (shared) | +------------+----------+------------------------------------------+ | category | *SHOULD* | Semantic category for retrieval | | | | optimization | +------------+----------+------------------------------------------+ | confidence | *MAY* | Agent's confidence in the content | | | | (0.0-1.0) | +------------+----------+------------------------------------------+ | source | *MAY* | Provenance of the learned content | +------------+----------+------------------------------------------+ | ttl | *MAY* | Expiry for the learned content | +------------+----------+------------------------------------------+ Table 16: LEARN Parameters Response: Confirmation with learn_id and effective scope. Idempotent: No. 7.2.6. DELEGATE Purpose: Transfer execution of a task or method to a sub-agent or downstream system. Initiates a new AGTP session on behalf of the delegating agent, carrying forward authority lineage. Hood Expires 21 September 2026 [Page 44] Internet-Draft AGTP March 2026 +==================+==========+=============================+ | Parameter | Required | Description | +==================+==========+=============================+ | target_agent_id | *MUST* | Identifier of the agent to | | | | delegate to | +------------------+----------+-----------------------------+ | task | *MUST* | AGTP method call (or | | | | sequence) to execute | +------------------+----------+-----------------------------+ | authority_scope | *MUST* | Scope granted to sub-agent | | | | *MUST* be a strict subset | | | | of delegating agent's scope | +------------------+----------+-----------------------------+ | delegation_token | *MUST* | Signed token proving | | | | delegation authority | +------------------+----------+-----------------------------+ | callback | *SHOULD* | AGTP endpoint for result | | | | delivery | +------------------+----------+-----------------------------+ | deadline | *MAY* | Maximum time for task | | | | completion | +------------------+----------+-----------------------------+ Table 17: DELEGATE Parameters Security note: the authority_scope in a DELEGATE request *MUST NOT* exceed the delegating agent's own Authority-Scope. Servers *MUST* enforce this and *MUST* return 451 Scope Violation if violated. This is the protocol-level defense against authority laundering. Idempotent: No. 7.2.7. COLLABORATE Purpose: Initiate a multi-agent coordinated task where two or more agents work in parallel or in defined roles toward a shared goal. Unlike DELEGATE (hierarchical), COLLABORATE is peer-to-peer. Hood Expires 21 September 2026 [Page 45] Internet-Draft AGTP March 2026 +====================+==========+==========================+ | Parameter | Required | Description | +====================+==========+==========================+ | collaborators | *MUST* | List of Agent-IDs | | | | invited to collaborate | +--------------------+----------+--------------------------+ | objective | *MUST* | Shared goal expressed as | | | | a task description or | | | | structured specification | +--------------------+----------+--------------------------+ | role_assignments | *SHOULD* | Map of Agent-IDs to | | | | roles within the | | | | collaboration | +--------------------+----------+--------------------------+ | coordination_model | *SHOULD* | parallel, sequential, or | | | | consensus | +--------------------+----------+--------------------------+ | result_aggregation | *MAY* | How results from | | | | collaborators are | | | | combined | +--------------------+----------+--------------------------+ Table 18: COLLABORATE Parameters Response: Collaboration session receipt with collaboration_id. Each collaborator receives an AGTP NOTIFY to join. Idempotent: No. 7.2.8. CONFIRM Purpose: Explicit acknowledgment of a prior action, state, or data item. Creates a signed attestation record. Hood Expires 21 September 2026 [Page 46] Internet-Draft AGTP March 2026 +=============+==============+===================================+ | Parameter | Required | Description | +=============+==============+===================================+ | target_id | *MUST* | ID of the action, booking, | | | | schedule, or item being confirmed | +-------------+--------------+-----------------------------------+ | status | *MUST* | accepted, rejected, or deferred | +-------------+--------------+-----------------------------------+ | reason | *SHOULD* (if | Explanation of the decision | | | rejected/ | | | | deferred) | | +-------------+--------------+-----------------------------------+ | attestation | *MAY* | Agent-signed confirmation payload | | | | for audit | +-------------+--------------+-----------------------------------+ Table 19: CONFIRM Parameters Response: Confirmation receipt with timestamp and attestation_id. Idempotent: Yes. 7.2.9. ESCALATE Purpose: Route a task, decision, or exception to a human principal or higher-authority agent when the current agent cannot or should not proceed. ESCALATE is the protocol-level expression of meaningful friction in AI systems as a first-class method. Hood Expires 21 September 2026 [Page 47] Internet-Draft AGTP March 2026 +===========+==========+======================================+ | Parameter | Required | Description | +===========+==========+======================================+ | task_id | *MUST* | The task or method invocation | | | | triggering escalation | +-----------+----------+--------------------------------------+ | reason | *MUST* | Structured reason: | | | | confidence_threshold, scope_limit, | | | | ethical_flag, ambiguous_instruction, | | | | resource_unavailable | +-----------+----------+--------------------------------------+ | context | *MUST* | Full context needed for the | | | | escalation recipient to act | +-----------+----------+--------------------------------------+ | priority | *SHOULD* | urgent, normal, or low | +-----------+----------+--------------------------------------+ | recipient | *MAY* | Specific human or agent to escalate | | | | to; if absent, routes to default | | | | handler | +-----------+----------+--------------------------------------+ | deadline | *MAY* | Time by which a response is needed | +-----------+----------+--------------------------------------+ Table 20: ESCALATE Parameters Response: Escalation receipt with escalation_id and routing confirmation. The escalated task is paused until resolved via CONFIRM. Idempotent: Yes. An agent that escalates appropriately is functioning correctly. Governance frameworks built on AGTP can use escalation frequency and reason codes as observability signals for systemic issues. 7.2.10. NOTIFY Purpose: Asynchronous push of information from an agent to a recipient. Does not expect a response. Fire-and-forget. Delivery confirmation (if required) returned via a subsequent CONFIRM from the recipient. Hood Expires 21 September 2026 [Page 48] Internet-Draft AGTP March 2026 +====================+==========+==============================+ | Parameter | Required | Description | +====================+==========+==============================+ | recipient | *MUST* | Target Agent-ID, human | | | | endpoint, or broadcast group | +--------------------+----------+------------------------------+ | content | *MUST* | Notification payload | +--------------------+----------+------------------------------+ | urgency | *SHOULD* | critical, informational, or | | | | background | +--------------------+----------+------------------------------+ | delivery_guarantee | *MAY* | at_most_once, at_least_once, | | | | or exactly_once | +--------------------+----------+------------------------------+ | expiry | *MAY* | Timestamp after which the | | | | notification should not be | | | | delivered | +--------------------+----------+------------------------------+ Table 21: NOTIFY Parameters Response: Delivery receipt with notification_id. Idempotent: No. 7.3. Method Summary Table +=============+=============+=================+============+=======+ | Method | Intent | State-Modifying | Idempotent |Primary| | | | | |Error | | | | | |Codes | +=============+=============+=================+============+=======+ | QUERY | Retrieve | No | Yes |404, | | | information | | |422 | +-------------+-------------+-----------------+------------+-------+ | SUMMARIZE | Synthesize | No | Yes |400, | | | content | | |422 | +-------------+-------------+-----------------+------------+-------+ | BOOK | Reserve a | Yes | No |409, | | | resource | | |451 | +-------------+-------------+-----------------+------------+-------+ | SCHEDULE | Plan future | Yes | No |400, | | | actions | | |409 | +-------------+-------------+-----------------+------------+-------+ | LEARN | Update | Yes | No |400, | | | agent | | |403 | | | context | | | | +-------------+-------------+-----------------+------------+-------+ | DELEGATE | Transfer | Yes | No |403, | | | task to | | |451, | Hood Expires 21 September 2026 [Page 49] Internet-Draft AGTP March 2026 | | sub-agent | | |551 | +-------------+-------------+-----------------+------------+-------+ | COLLABORATE | Coordinate | Yes | No |404, | | | peer agents | | |403 | +-------------+-------------+-----------------+------------+-------+ | CONFIRM | Attest to a | Yes | Yes |404, | | | prior | | |400 | | | action | | | | +-------------+-------------+-----------------+------------+-------+ | ESCALATE | Defer to | Yes | Yes |404 | | | human/ | | | | | | authority | | | | +-------------+-------------+-----------------+------------+-------+ | NOTIFY | Push | No | No |400, | | | information | | |404 | +-------------+-------------+-----------------+------------+-------+ Table 22: AGTP Core Method Summary 7.4. Method Registry and Extensibility AGTP defines a formal Method Registry maintained by IANA (see Section 8.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) 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. Hood Expires 21 September 2026 [Page 50] Internet-Draft AGTP March 2026 Capability negotiation occurs during session establishment. The server returns a Supported-Methods header listing the methods it implements. Clients *SHOULD* check this list before invoking non- core methods. 7.5. Extended Method Vocabulary and Industry Profiles 7.5.1. Three-Tier Method Architecture The AGTP method vocabulary is organized into three tiers reflecting different levels of universality, specificity, and domain relevance. Tier 1. Core Methods (defined in Section 6.2): The baseline vocabulary required for AGTP compliance. Every conformant AGTP implementation *MUST* support all Tier 1 methods. Tier 2. Standard Extended Methods: Registered in the IANA AGTP Method Registry and available for use in any AGTP implementation. Not required for baseline compliance but *SHOULD* be implemented where their semantics apply. Defined in [AGTP-METHODS]. Tier 3. Industry Profile Methods: Domain-specific method sets defined and registered by industry communities as named AGTP profiles. Valid within deployments that declare support for the relevant profile. Not required in general-purpose implementations. 7.5.2. Method Category Taxonomy All AGTP methods are organized into five categories: ACQUIRE: Retrieve data, resources, or state without modifying it. Typically idempotent; no state modification. COMPUTE: Process, transform, or analyze information and produce a derived result. Typically idempotent given the same input. TRANSACT: Perform state-changing operations with external systems, resources, or records. Not idempotent by default; subject to reversibility classification. COMMUNICATE: Send information, notifications, or signals to recipients. Fire-and- forget or confirm-receipt delivery models. ORCHESTRATE: Coordinate, sequence, or manage multiple agents, tasks, or workflows. May spawn sub-agents or sessions; delegation chain semantics apply. Hood Expires 21 September 2026 [Page 51] Internet-Draft AGTP March 2026 +=============+=============+ | Core Method | Category | +=============+=============+ | QUERY | Acquire | +-------------+-------------+ | SUMMARIZE | Compute | +-------------+-------------+ | BOOK | Transact | +-------------+-------------+ | SCHEDULE | Orchestrate | +-------------+-------------+ | LEARN | Compute | +-------------+-------------+ | DELEGATE | Orchestrate | +-------------+-------------+ | COLLABORATE | Orchestrate | +-------------+-------------+ | CONFIRM | Transact | +-------------+-------------+ | ESCALATE | Orchestrate | +-------------+-------------+ | NOTIFY | Communicate | +-------------+-------------+ Table 23: Core Method Category Mapping 7.5.3. Standard Extended Methods (Tier 2) The following methods constitute the initial Tier 2 registration set, defined in [AGTP-METHODS]. Listed here by category with brief semantic definitions; full parameter specifications are in the companion document. ACQUIRE category: FETCH, SEARCH, SCAN, PULL, IMPORT, FIND. COMPUTE category: EXTRACT, FILTER, VALIDATE, TRANSFORM, TRANSLATE, NORMALIZE, PREDICT, RANK, MAP. TRANSACT category: REGISTER, SUBMIT, TRANSFER, PURCHASE, SIGN, MERGE, LINK, LOG, SYNC, PUBLISH. COMMUNICATE category: REPLY, SEND, REPORT. ORCHESTRATE category: MONITOR, ROUTE, RETRY, PAUSE, RESUME, RUN, CHECK. Hood Expires 21 September 2026 [Page 52] Internet-Draft AGTP March 2026 Notable constraints: PURCHASE *MUST* carry explicit principal_id and scope enforcement; 451 Scope Violation applies if payments:purchase is not in the agent's Authority-Scope. RUN requires explicit procedure_id parameter; implementations *MUST NOT* accept free-form execution strings. 7.5.4. Short-Form and Industry-Inspired Methods A set of short-form verb methods, e.g., SET, TAKE, OPEN, START, CALL, MAKE, TURN, BREAK, are provisionally catalogued as candidates for Tier 2 registration. These verbs are highly context-dependent and their semantics vary significantly across deployment domains. Short-form methods will be registered individually only when a published companion specification provides unambiguous semantic definitions demonstrably distinct from existing registered methods. Provisional registrations using the X- prefix (e.g., X-SET, X-CALL) are encouraged during the experimentation period. 7.5.5. Industry Profile Method Sets AGTP recognizes that specific industries require method vocabularies reflecting domain-specific operations that would be inappropriate in a general-purpose standard. Industry profile method sets are defined and registered as named AGTP profiles. A profile is a published companion specification that: 1. Declares a profile name (e.g., agtp-profile-healthcare, agtp- profile-financial, agtp-profile-legaltech) 2. Defines one or more industry-specific methods with full parameter specifications, error codes, and security considerations 3. Specifies which Tier 1 and Tier 2 methods are REQUIRED, RECOMMENDED, or NOT APPLICABLE within the profile 4. Addresses regulatory or compliance considerations specific to the domain (e.g., HIPAA for healthcare, PCI-DSS for financial services) Illustrative examples of potential industry profile methods (not yet registered; listed for directional purposes only): Healthcare: PRESCRIBE, AUTHORIZE, REFER, DISPENSE, TRIAGE, CONSENT, REDACT Financial services: SETTLE, RECONCILE, HEDGE, CLEAR, UNDERWRITE, KYC, AML Hood Expires 21 September 2026 [Page 53] Internet-Draft AGTP March 2026 Legal and compliance: ATTEST, NOTARIZE, DISCLOSE, REDLINE, EXECUTE, PRESERVE Infrastructure: PROVISION, DEPROVISION, ROLLBACK, SNAPSHOT, FAILOVER Industry communities are encouraged to develop and submit profile specifications through the IETF process. The IANA AGTP Method Registry will maintain a profile index alongside the core and standard method registries. 7.5.6. Registration Path for New Methods For Tier 2 Standard Methods: Submit an Internet-Draft to the IETF providing full method specification per Section 6.4. The Designated Expert reviews for semantic uniqueness, clarity, and security considerations. For Industry Profile Methods: Submit a profile specification to the IETF (or a recognized domain standards body with an established AGTP registry liaison) covering all methods in the profile and profile compliance requirements. For Experimental Methods: Use the X- prefix without registration. Implementations *MUST NOT* deploy experimental methods in production without completing the registration process. Experimental method names do not reserve the unprefixed name. The AGTP Method Registry is published at: https://www.iana.org/assignments/agtp-methods/ 8. Security Considerations This section satisfies the mandatory IETF Security Considerations requirement. All AGTP implementations *MUST* address the considerations described here. 8.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. Hood Expires 21 September 2026 [Page 54] Internet-Draft AGTP March 2026 8.2. Agent Identity Headers and Agent Certificate Extension Every AGTP request *MUST* include Agent-ID and Principal-ID header fields. In the base specification, these fields are not cryptographically authenticated. They are self-asserted but logged mandatorily for auditability. Implementations *SHOULD* use logging and anomaly detection to identify inconsistencies. Full cryptographic verification of agent identity and Authority-Scope is provided by the AGTP Agent Certificate extension [AGTP-CERT]. That extension binds Agent-ID, Principal-ID, and Authority-Scope to an X.509 v3 certificate presented during TLS mutual authentication, enabling infrastructure-layer identity and scope verification without application-layer access. Implementers planning deployments that require verified agent identity *SHOULD* plan for the Agent Certificate extension. Note: The Agent Certificate extension and the Agent Birth Certificate mechanism may be subject to pending intellectual property claims. See Section 7.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 Agent-ID and Principal-ID fields for every request, creating an attributable audit trail even in deployments without the Certificate extension. 8.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 451 Scope Violation for any method that exceeds declared scope, and log all scope violations for audit purposes. Scope declarations are self-asserted in the base spec, analogous to scope assertions in OAuth 2.0 [RFC6749]. Cryptographically signed and infrastructure-enforced scopes are defined in [AGTP-CERT]. 8.4. Threat Model 8.4.1. Agent Spoofing Threat: A malicious actor forges Agent-ID and Principal-ID headers to impersonate a trusted agent. Base spec mitigation: mandatory logging and anomaly detection. Full mitigation requires [AGTP-CERT]. Hood Expires 21 September 2026 [Page 55] Internet-Draft AGTP March 2026 8.4.2. Authority Laundering Threat: An agent claims an Authority-Scope broader than what it was granted. Mitigation: server-side scope enforcement; 451 Scope Violation returned and logged. In DELEGATE chains, each hop's scope *MUST* be a strict subset of the delegating agent's scope. 8.4.3. Delegation Chain Poisoning Threat: A malicious agent inserts itself into a DELEGATE chain. Mitigation: Delegation-Chain headers are logged at each hop. 551 Authority Chain Broken is returned if any chain entry is unverifiable. Full mitigation requires [AGTP-CERT] for signed delegation tokens. 8.4.4. Denial of Service via High-Frequency Agent Traffic Threat: Agents that are compromised, misconfigured, or adversarial generate extremely high request volumes. Mitigation: 429 Rate Limited status code. Rate limiting *SHOULD* be applied per Agent-ID and per Principal-ID. When [AGTP-CERT] is deployed, per-Agent-ID quotas can be cryptographically tied to verified identity, preventing quota evasion through Agent-ID spoofing. 8.4.5. Session Hijacking Threat: An attacker intercepts or forges a Session-ID. Mitigation: mandatory TLS protects sessions in transit. Session-IDs *MUST* be cryptographically random with minimum 128 bits of entropy. Servers *MUST* validate that Session-ID, Agent-ID, and TLS client identity are consistent. 8.4.6. Escalation Suppression Threat: A compromised agent or intermediary suppresses ESCALATE requests, preventing human oversight. Mitigation: compliant implementations *MUST* route ESCALATE requests directly to the declared escalation handler without modification. Intermediaries *MUST NOT* drop, delay, or modify ESCALATE requests. Escalation handlers *SHOULD* implement independent receipt confirmation. Hood Expires 21 September 2026 [Page 56] Internet-Draft AGTP March 2026 8.4.7. Birth Certificate Spoofing Threat: A malicious actor fabricates a Birth Certificate to claim a legitimate agent's identity or construct a false identity with elevated trust. Mitigation: Birth Certificates are issued only by governance platforms with verified ownership of the org_domain. In the base spec, mandatory logging provides auditability. Full mitigation requires [AGTP-CERT] for cryptographically bound Birth Certificate verification at the transport layer. Governance platforms *MUST* treat any ACTIVATE request that presents a certificate hash matching an existing registry record as a collision attack and *MUST* reject it. 8.4.8. Domain Transfer Identity Hijacking Threat: An attacker acquires an expired domain to inherit the agent registry and trust history of prior registrants. Mitigation: agents under an expired domain are automatically Suspended within 24 hours of domain expiry detection. A new owner of the domain *MUST NOT* inherit prior agent registrations. See Section 8.5 for the full domain expiry policy. 8.5. Privacy Considerations Agent identity headers carry information about agent behavior that may be sensitive: * Agent-ID and Principal-ID together 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. Hood Expires 21 September 2026 [Page 57] Internet-Draft AGTP March 2026 8.6. Denial-of-Service Considerations AGTP's agent identity headers provide a mechanism for more precise denial-of-service mitigation than is possible with HTTP. Rate limiting *SHOULD* be applied per Agent-ID and per Principal-ID 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: Priority header enforcement (Priority: background requests *SHOULD* have lower rate limit headroom than Priority: critical); per-governance-zone aggregate limits in multi-tenant deployments; and circuit breaker patterns for ESCALATE request floods. 8.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 Birth Certificate mechanism (Section 5.7), 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. Hood Expires 21 September 2026 [Page 58] Internet-Draft AGTP March 2026 Implementers of the core AGTP specification are not affected 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/ 9. IANA Considerations This document requests the following IANA actions upon advancement to RFC status. 9.1. Port Assignment Registration of the following service names in the IANA Service Name and Transport Protocol Port Number Registry: +==============+======+===========+=======================+ | Service Name | Port | Transport | Description | +==============+======+===========+=======================+ | agtp | TBD | TCP | Agent Transfer | | | | | Protocol over TCP/TLS | +--------------+------+-----------+-----------------------+ | agtp-quic | TBD | UDP | Agent Transfer | | | | | Protocol over QUIC | +--------------+------+-----------+-----------------------+ Table 24: Proposed Port Assignments 9.2. AGTP Method Registry Establishment of a new IANA registry: Agent Transfer Protocol Methods. Registry name: Agent Transfer Protocol Methods Registration procedure: Expert Review per [RFC8126], with the Hood Expires 21 September 2026 [Page 59] Internet-Draft AGTP March 2026 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, and the method definition includes the required fields (parameters, response structure, idempotency, error codes, security considerations). Reference: This document Initial registrations: +=============+===========+============================+ | Method | Status | Reference | +=============+===========+============================+ | QUERY | Permanent | This document, Section 6.2 | +-------------+-----------+----------------------------+ | SUMMARIZE | Permanent | This document, Section 6.2 | +-------------+-----------+----------------------------+ | BOOK | Permanent | This document, Section 6.2 | +-------------+-----------+----------------------------+ | SCHEDULE | Permanent | This document, Section 6.2 | +-------------+-----------+----------------------------+ | LEARN | Permanent | This document, Section 6.2 | +-------------+-----------+----------------------------+ | DELEGATE | Permanent | This document, Section 6.2 | +-------------+-----------+----------------------------+ | COLLABORATE | Permanent | This document, Section 6.2 | +-------------+-----------+----------------------------+ | CONFIRM | Permanent | This document, Section 6.2 | +-------------+-----------+----------------------------+ | ESCALATE | Permanent | This document, Section 6.2 | +-------------+-----------+----------------------------+ | NOTIFY | Permanent | This document, Section 6.2 | +-------------+-----------+----------------------------+ Table 25: Initial AGTP Method Registry Entries 9.3. AGTP Status Code Registry Establishment of a new IANA registry: Agent Transfer Protocol Status Codes. Registry name: Agent Transfer Protocol Status Codes Registration procedure: Expert Review + published specification required. Hood Expires 21 September 2026 [Page 60] Internet-Draft AGTP March 2026 The following AGTP-specific status codes are registered with full definitions: +======+============+==================================+===========+ | Code | Name | Definition | Reference | +======+============+==================================+===========+ | 451 | Scope | The requested action is outside | This | | | Violation | the Authority-Scope declared in | document, | | | | the request headers. The server | Section | | | | *MUST* log this event. The | 5.5 | | | | agent *MUST NOT* retry the same | | | | | request without modifying its | | | | | Authority-Scope declaration. | | | | | This is a governance signal, not | | | | | a protocol error. | | +------+------------+----------------------------------+-----------+ | 550 | Delegation | A sub-agent to which a task was | This | | | Failure | delegated via the DELEGATE | document, | | | | method failed to complete the | Section | | | | task within the declared | 5.5 | | | | deadline or returned an error. | | | | | The response body *SHOULD* | | | | | contain the sub-agent's error | | | | | details. | | +------+------------+----------------------------------+-----------+ | 551 | Authority | One or more entries in the | This | | | Chain | Delegation-Chain header cannot | document, | | | Broken | be verified as part of a valid | Section | | | | and continuous delegation | 5.5 | | | | sequence. The specific | | | | | unverifiable entry *SHOULD* be | | | | | identified in the response body. | | | | | The server *MUST* log this | | | | | event. | | +------+------------+----------------------------------+-----------+ Table 26: AGTP-Specific Status Code Definitions 9.4. 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. Hood Expires 21 September 2026 [Page 61] Internet-Draft AGTP March 2026 AGTP does not reuse the HTTP Field Name Registry, as AGTP header fields have different semantics, applicability, and versioning constraints from HTTP fields. HTTP header fields are not automatically valid in AGTP, and AGTP header fields are not valid HTTP fields. Initial registrations (all Permanent): AGTP-Version, AGTP-Method, AGTP-Status, Agent-ID, Principal-ID, Authority-Scope, Session-ID, Task-ID, Delegation-Chain, Priority, TTL, Server-Agent-ID, Attribution-Record, Continuation-Token, Supported-Methods. 9.5. URI Scheme Registration Registration of the agtp:// URI scheme per [RFC7595], as described in Section 5.1.8 of this document. 9.6. Agent Registry Retention Policy The AGTP registry *MUST* retain records for all registered agents regardless of lifecycle state. The following minimum retention periods apply: +=================+=======================================+ | Lifecycle State | Minimum Retention Period | +=================+=======================================+ | Active | Duration of Active state + 7 years | +-----------------+---------------------------------------+ | Suspended | Duration of Suspended state + 7 years | +-----------------+---------------------------------------+ | Revoked | 10 years from revocation date | +-----------------+---------------------------------------+ | Deprecated | 7 years from deprecation date | +-----------------+---------------------------------------+ Table 27: AGTP Registry Minimum Retention Periods 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, not reissued) * Agent label and org domain at time of registration * Trust tier at time of registration Hood Expires 21 September 2026 [Page 62] Internet-Draft AGTP March 2026 * Activation date and activating principal * Revocation or deprecation date, initiating principal, and reason code * Genesis audit record hash (pointer to immutable audit log) * Full Birth Certificate (archived, not publicly accessible) * All lifecycle state transitions with timestamps The retained record *MUST NOT* contain package executable contents, active session data, or Authority-Scope grant tokens. 9.6.1. Domain Name Expiry Interaction If an organization's org_domain expires or transfers to a new owner: 1. All Active agents registered under the expired domain *MUST* be automatically Suspended within 24 hours of domain expiry detection. 2. The governance platform *MUST* notify the registered principal contact before suspension takes effect, with a minimum notice period of 30 days if domain expiry was predictable. 3. Suspended agents under an expired domain transition to Deprecated state after 90 days if the domain has not been renewed. 4. A new owner of the domain *MUST NOT* inherit prior agent registrations. New ACTIVATE transactions are required. This policy prevents domain-transfer-based identity hijacking in which an attacker acquires an expired domain to claim the trust history of agents that operated under it. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Hood Expires 21 September 2026 [Page 63] Internet-Draft AGTP March 2026 [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, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8179] Bradner, S. and J. Contreras, "Intellectual Property Rights in IETF Technology", BCP 79, RFC 8179, DOI 10.17487/RFC8179, May 2017, . [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . 10.2. Informative References [A2A] Linux Foundation, "Agent-to-Agent Protocol Specification", 2025, . [ACP] IBM Research, "Agent Communication Protocol", 2025. Hood Expires 21 September 2026 [Page 64] Internet-Draft AGTP March 2026 [AGTP-CERT] Hood, C., "AGTP Agent Certificate Extension", Work in Progress, Internet-Draft, draft-hood-agtp-agent-cert-00, 2026, . [AGTP-METHODS] Hood, C., "AGTP Standard Extended Method Vocabulary", Work in Progress, Internet-Draft, draft-hood-agtp-standard- methods-00, 2026, . [AGTP-WEB3] Hood, C., "AGTP Web3 Bridge Specification", Work in Progress, Internet-Draft, draft-hood-agtp-web3-bridge-00, 2026, . [ANP] "Agent Network Protocol", 2025. [MCP] Anthropic, "Model Context Protocol", 2024, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, . [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, . [RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, . Appendix A. Authority-Scope Format Authority-Scope values are expressed as a space-separated list of scope tokens following the pattern: [domain]:[action] or [domain]:* for full domain access. Tokens *MUST* be lowercase ASCII with a single colon separator. Examples: Hood Expires 21 September 2026 [Page 65] Internet-Draft AGTP March 2026 Authority-Scope: calendar:book calendar:query Authority-Scope: documents:summarize documents:query knowledge:learn Authority-Scope: *:query Authority-Scope: booking:* payments:confirm Reserved domains (initial set): +============+================================================+ | Domain | Description | +============+================================================+ | calendar | Scheduling and time-based resource management | +------------+------------------------------------------------+ | documents | Document access, summarization, and annotation | +------------+------------------------------------------------+ | knowledge | Agent context and memory operations | +------------+------------------------------------------------+ | booking | Reservation and resource allocation | +------------+------------------------------------------------+ | payments | Financial transactions and confirmations | +------------+------------------------------------------------+ | agents | Delegation and collaboration with other agents | +------------+------------------------------------------------+ | escalation | Escalation routing and handler management | +------------+------------------------------------------------+ | activation | Governed agent package activation (ACTIVATE | | | method extension) | +------------+------------------------------------------------+ | * | All domains require explicit grant; use with | | | caution | +------------+------------------------------------------------+ Table 28: Reserved Authority-Scope Domains Appendix B. Example AGTP Wire Formats The following examples use a human-readable pseudo-wire format with HTTP-style headers followed by a JSON body. The Content-Type for all AGTP message bodies is application/agtp+json. B.1. QUERY Request and Response Hood Expires 21 September 2026 [Page 66] Internet-Draft AGTP March 2026 AGTP/1.0 QUERY Agent-ID: agt-7f3a9c2d Principal-ID: usr-chris-hood Authority-Scope: documents:query knowledge:query Session-ID: sess-a1b2c3d4 Task-ID: task-0042 TTL: 3000 Content-Type: application/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-Agent-ID: srv-knowledge-01 Attribution-Record: [signed attribution token] Content-Type: application/agtp+json { "status": 200, "task_id": "task-0042", "result": { "results": [{"content": "...", "source": "doc-agtp-research", "confidence": 0.91}], "result_count": 1 } } B.2. BOOK Request and Response Hood Expires 21 September 2026 [Page 67] Internet-Draft AGTP March 2026 AGTP/1.0 BOOK Agent-ID: agt-travel-planner Principal-ID: usr-chris-hood Authority-Scope: booking:* calendar:book Session-ID: sess-trip-2026-04 Task-ID: task-0107 Priority: normal Content-Type: application/agtp+json { "method": "BOOK", "task_id": "task-0107", "parameters": { "resource_id": "flight-AA2847", "principal_id": "usr-chris-hood", "time_slot": "2026-04-15T08:00:00Z", "options": {"seat_preference": "aisle", "class": "economy"}, "confirm_immediately": true } } AGTP/1.0 200 OK Task-ID: task-0107 Attribution-Record: [signed attribution token] Content-Type: application/agtp+json { "status": 200, "task_id": "task-0107", "result": { "booking_id": "BK-2026-0107", "status": "confirmed", "resource_id": "flight-AA2847", "confirmation_code": "XQRT7Y" } } B.3. ESCALATE Request and Response Hood Expires 21 September 2026 [Page 68] Internet-Draft AGTP March 2026 AGTP/1.0 ESCALATE Agent-ID: agt-procurement-03 Principal-ID: usr-finance-dept Authority-Scope: booking:* payments:confirm Session-ID: sess-procurement-q2 Task-ID: task-0881 Priority: urgent Content-Type: application/agtp+json { "method": "ESCALATE", "task_id": "task-0881", "parameters": { "task_id": "task-0880", "reason": "scope_limit", "context": { "attempted_action": "BOOK", "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-Agent-ID: srv-escalation-handler Content-Type: application/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" } } Hood Expires 21 September 2026 [Page 69] Internet-Draft AGTP March 2026 Appendix C. Comparison Table +==================+===============+=======+======+=================+ |Criterion |AGTP |HTTP/ |gRPC |A2A / MCP | | | |REST | | | +==================+===============+=======+======+=================+ |Agent-native |Yes |No |No |Partial | |methods | | | | | +------------------+---------------+-------+------+-----------------+ |Intent semantics |Native |None |None |Messaging layer | |at protocol level | | | |only | +------------------+---------------+-------+------+-----------------+ |Built-in agent |Yes |No |No |No | |identity | | | | | +------------------+---------------+-------+------+-----------------+ |Authority scope |Protocol-level |None |None |Application-layer| |enforcement | | | | | +------------------+---------------+-------+------+-----------------+ |Built-in |Yes |No |No |Varies by impl. | |attribution/audit | | | | | +------------------+---------------+-------+------+-----------------+ |Transport |TCP/UDP/QUIC |TCP/TLS|HTTP/2|HTTP | |flexibility | | | | | +------------------+---------------+-------+------+-----------------+ |Escalation as |Yes |No |No |No | |first-class | | | | | |primitive | | | | | +------------------+---------------+-------+------+-----------------+ |Ecosystem maturity|Proposed |Mature |Mature|Emerging | +------------------+---------------+-------+------+-----------------+ |Governance/ |Native |Manual/|Manual|Limited | |observability | |bolt-on| | | +------------------+---------------+-------+------+-----------------+ |Method registry |Yes (Expert |Frozen |N/A |N/A | |extensibility |Review) |(IETF | | | | | |Review)| | | +------------------+---------------+-------+------+-----------------+ |Open core / |Yes |Yes |Yes |Yes | |royalty-free | | | | | +------------------+---------------+-------+------+-----------------+ |Agent Manifest |Native (.agtp |None |None |None | |Document |format) | | | | +------------------+---------------+-------+------+-----------------+ |Tamper-proof |Yes (hash + |No |No |No | |identity surface |signature) | | | | +------------------+---------------+-------+------+-----------------+ |Browser-accessible|Yes (read-only)|No |No |No | |agent identity | | | | | Hood Expires 21 September 2026 [Page 70] Internet-Draft AGTP March 2026 +------------------+---------------+-------+------+-----------------+ |URI collision |Domain-anchored|N/A |N/A |N/A | |prevention | | | | | +------------------+---------------+-------+------+-----------------+ |Agent Birth |Yes (genesis |No |No |No | |Certificate |record) | | | | +------------------+---------------+-------+------+-----------------+ |Domain-expiry |Specified |N/A |N/A |N/A | |lifecycle handling| | | | | +------------------+---------------+-------+------+-----------------+ Table 29: AGTP Compared to Existing Approaches HTTP's method registry (registered with IETF Review per [RFC9110]) is effectively frozen for new semantic methods because any new HTTP method must be backward-compatible with existing HTTP infrastructure globally. AGTP's Expert Review + published spec procedure enables the protocol to evolve its method vocabulary as the agent ecosystem develops, without the backward-compatibility constraints of the HTTP method space. Appendix D. Glossary Agent: A software system that executes tasks, makes decisions, and takes actions without continuous human supervision per transaction. Agent Birth Certificate: A cryptographically signed identity document issued to an agent at registration time by a governance platform. The genesis record of the agent's existence; the source from which the canonical Agent-ID is derived. Functions as the agent's social security number: issued once, permanently bound, never reissued. See Section 5.7. Agent Transfer Protocol (AGTP): The application-layer protocol defined in this document, providing a dedicated transport environment for agent traffic. Agent-ID: A unique identifier for a specific agent instance, present in all AGTP request headers. In the base spec, derived from the Birth Certificate hash. With [AGTP-CERT], cryptographically bound to a verified identity. Agent Manifest Document: A signed application/agtp+json document returned when an agtp:// URI is resolved. Derived from the agent's .agent or .nomo package. Contains identity, lifecycle state, trust tier, behavioral scope, and birth certificate fields. Never contains executable content. Hood Expires 21 September 2026 [Page 71] Internet-Draft AGTP March 2026 Attribution Record: A signed, logged record of an agent action, sufficient for audit and compliance purposes. Authority-Scope: A declared set of permissions defining what actions an agent is authorized to take, expressed as space-separated domain:action tokens. Delegation Chain: An ordered record of Agent-IDs representing the sequence of delegations that led to the current request. ESCALATE: An AGTP method representing an agent's intentional deferral of a decision or action to a human principal or higher- authority agent. A first-class method, not a failure code. Governance Token: A signed, time-limited JWT artifact encoding a specific governance verdict for a specific action. The runtime companion to the Birth Certificate. Default TTL: 30 seconds. Must not be reused. Intent Verb: An AGTP method name expressing the agent's purpose, as distinguished from HTTP resource-operation verbs (GET, POST, PUT, DELETE). Method Registry: The IANA-maintained registry of valid AGTP method names and their specifications. Registration requires Expert Review and a published specification. Principal: The human, organization, or system that authorized an agent to act and is accountable for its actions. Principal-ID: The identifier of the principal on whose behalf an agent operates, present in all AGTP request headers. Scope-Enforcement Point (SEP): An AGTP-aware infrastructure component, load balancer, gateway, proxy, that enforces Authority- Scope compliance on AGTP requests without application-layer access. Requires [AGTP-CERT]. Scope Violation (451): An AGTP status code returned when an agent requests an action outside its declared Authority-Scope. A governance signal, not a protocol error. *MUST* be logged. Session: An AGTP persistent connection context shared across multiple method invocations within a single agent workflow. Trust Tier: A classification (1, 2, or 3) assigned to an agent at Hood Expires 21 September 2026 [Page 72] Internet-Draft AGTP March 2026 registration based on the strength of identity verification. Tier 1 requires DNS-anchored domain verification and a .nomo governed package. Tier 2 is org-asserted without DNS verification. Tier 3 is experimental, not production-eligible. 551 Authority Chain Broken: An AGTP status code returned when one or more entries in the Delegation-Chain header cannot be verified as part of a valid and continuous delegation sequence. *MUST* be logged. Author's Address Chris Hood Nomotic, Inc. Email: chris@nomotic.ai URI: https://nomotic.ai Hood Expires 21 September 2026 [Page 73]