



Independent Submission                                           C. Hood
Internet-Draft                                             Nomotic, Inc.
Intended status: Informational                             19 March 2026
Expires: 20 September 2026


                     Agent Transfer Protocol (ATP)
                     draft-hood-independent-atp-00

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 (ATP): a dedicated
   application-layer protocol for AI agent traffic.  ATP 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.  ATP 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 20 September 2026.




Hood                    Expires 20 September 2026               [Page 1]

Internet-Draft                     ATP                        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  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Background  . . . . . . . . . . . . . . . . . . . . . . .   4
     1.2.  Limitations of HTTP for Agent Traffic . . . . . . . . . .   4
     1.3.  Why Not Evolve HTTP?  . . . . . . . . . . . . . . . . . .   5
     1.4.  Motivation for a Dedicated Protocol . . . . . . . . . . .   6
     1.5.  Scope and Target Audience . . . . . . . . . . . . . . . .   6
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   7
     3.1.  Problem 1: Undifferentiated Agent Traffic on HTTP . . . .   7
     3.2.  Problem 2: Semantic Mismatch Between Agent Intent and
           Available Methods . . . . . . . . . . . . . . . . . . . .   8
     3.3.  Problem 3: No Protocol-Level Identity, Authority, or
           Attribution for Agents  . . . . . . . . . . . . . . . . .   8
     3.4.  Problem Summary . . . . . . . . . . . . . . . . . . . . .   8
   4.  Related Work and Existing Approaches  . . . . . . . . . . . .   9
     4.1.  HTTP/REST as the De Facto Standard  . . . . . . . . . . .   9
     4.2.  Existing Agent Protocols  . . . . . . . . . . . . . . . .   9
     4.3.  Transport-Layer Alternatives  . . . . . . . . . . . . . .   9
     4.4.  The Critical Distinction: Messaging vs. Transport . . . .  10
     4.5.  ATP Positioning: The Proposed Stack . . . . . . . . . . .  10
   5.  Protocol Overview . . . . . . . . . . . . . . . . . . . . . .  10
     5.1.  Stack Position  . . . . . . . . . . . . . . . . . . . . .  10
     5.2.  Design Principles . . . . . . . . . . . . . . . . . . . .  11
     5.3.  Connection Model  . . . . . . . . . . . . . . . . . . . .  12
     5.4.  Header Format . . . . . . . . . . . . . . . . . . . . . .  12
       5.4.1.  Request Headers . . . . . . . . . . . . . . . . . . .  12
       5.4.2.  Response Headers  . . . . . . . . . . . . . . . . . .  13
     5.5.  Status Codes  . . . . . . . . . . . . . . . . . . . . . .  13
     5.6.  Wire Format and Content-Type  . . . . . . . . . . . . . .  15
     5.7.  Early Implementations . . . . . . . . . . . . . . . . . .  15
     5.8.  Agent Identification and Naming . . . . . . . . . . . . .  16
       5.8.1.  The Canonical Agent Identifier  . . . . . . . . . . .  16
       5.8.2.  Human-Friendly Agent Names (Optional Layer) . . . . .  17
       5.8.3.  Governed Name Registration  . . . . . . . . . . . . .  17
       5.8.4.  Name Resolution . . . . . . . . . . . . . . . . . . .  18



Hood                    Expires 20 September 2026               [Page 2]

Internet-Draft                     ATP                        March 2026


       5.8.5.  Scaling Considerations  . . . . . . . . . . . . . . .  19
       5.8.6.  IANA Considerations for the atp:// URI Scheme . . . .  19
   6.  Method Definitions  . . . . . . . . . . . . . . . . . . . . .  19
     6.1.  Design Philosophy . . . . . . . . . . . . . . . . . . . .  20
     6.2.  Core Methods  . . . . . . . . . . . . . . . . . . . . . .  20
       6.2.1.  QUERY . . . . . . . . . . . . . . . . . . . . . . . .  20
       6.2.2.  SUMMARIZE . . . . . . . . . . . . . . . . . . . . . .  21
       6.2.3.  BOOK  . . . . . . . . . . . . . . . . . . . . . . . .  21
       6.2.4.  SCHEDULE  . . . . . . . . . . . . . . . . . . . . . .  22
       6.2.5.  LEARN . . . . . . . . . . . . . . . . . . . . . . . .  23
       6.2.6.  DELEGATE  . . . . . . . . . . . . . . . . . . . . . .  24
       6.2.7.  COLLABORATE . . . . . . . . . . . . . . . . . . . . .  25
       6.2.8.  CONFIRM . . . . . . . . . . . . . . . . . . . . . . .  26
       6.2.9.  ESCALATE  . . . . . . . . . . . . . . . . . . . . . .  27
       6.2.10. NOTIFY  . . . . . . . . . . . . . . . . . . . . . . .  28
     6.3.  Method Summary Table  . . . . . . . . . . . . . . . . . .  29
     6.4.  Method Registry and Extensibility . . . . . . . . . . . .  30
     6.5.  Extended Method Vocabulary and Industry Profiles  . . . .  31
       6.5.1.  Three-Tier Method Architecture  . . . . . . . . . . .  31
       6.5.2.  Method Category Taxonomy  . . . . . . . . . . . . . .  31
       6.5.3.  Standard Extended Methods (Tier 2)  . . . . . . . . .  32
       6.5.4.  Short-Form and Industry-Inspired Methods  . . . . . .  33
       6.5.5.  Industry Profile Method Sets  . . . . . . . . . . . .  33
       6.5.6.  Registration Path for New Methods . . . . . . . . . .  34
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  34
     7.1.  Mandatory TLS . . . . . . . . . . . . . . . . . . . . . .  34
     7.2.  Agent Identity Headers and Agent Certificate Extension  .  35
     7.3.  Authority Scope Enforcement . . . . . . . . . . . . . . .  35
     7.4.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .  35
       7.4.1.  Agent Spoofing  . . . . . . . . . . . . . . . . . . .  35
       7.4.2.  Authority Laundering  . . . . . . . . . . . . . . . .  36
       7.4.3.  Delegation Chain Poisoning  . . . . . . . . . . . . .  36
       7.4.4.  Denial of Service via High-Frequency Agent Traffic  .  36
       7.4.5.  Session Hijacking . . . . . . . . . . . . . . . . . .  36
       7.4.6.  Escalation Suppression  . . . . . . . . . . . . . . .  36
     7.5.  Privacy Considerations  . . . . . . . . . . . . . . . . .  36
     7.6.  Denial-of-Service Considerations  . . . . . . . . . . . .  37
     7.7.  Intellectual Property Considerations  . . . . . . . . . .  37
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  38
     8.1.  Port Assignment . . . . . . . . . . . . . . . . . . . . .  38
     8.2.  ATP Method Registry . . . . . . . . . . . . . . . . . . .  38
     8.3.  ATP Status Code Registry  . . . . . . . . . . . . . . . .  39
     8.4.  Header Field Registry . . . . . . . . . . . . . . . . . .  40
     8.5.  URI Scheme Registration . . . . . . . . . . . . . . . . .  41
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  41
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  41
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  42
   Appendix A.  Authority-Scope Format . . . . . . . . . . . . . . .  43



Hood                    Expires 20 September 2026               [Page 3]

Internet-Draft                     ATP                        March 2026


   Appendix B.  Example ATP Wire Formats . . . . . . . . . . . . . .  43
     B.1.  QUERY Request and Response  . . . . . . . . . . . . . . .  44
     B.2.  BOOK Request and Response . . . . . . . . . . . . . . . .  44
     B.3.  ESCALATE Request and Response . . . . . . . . . . . . . .  45
   Appendix C.  Comparison Table . . . . . . . . . . . . . . . . . .  47
   Appendix D.  Glossary . . . . . . . . . . . . . . . . . . . . . .  48
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  49

1.  Introduction

   *Note Regarding Intellectual Property:* Implementers should be aware
   that certain extensions to this specification -- specifically the
   Agent Certificate extension (Section 7.2) and the ACTIVATE method --
   may be subject to pending patent applications by the author.  The
   core ATP 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 — 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.





Hood                    Expires 20 September 2026               [Page 4]

Internet-Draft                     ATP                        March 2026


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

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

   *  Session semantics mismatch: HTTP's stateless model is optimized
      for isolated request/response cycles.  Agent workflows are
      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.

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



Hood                    Expires 20 September 2026               [Page 5]

Internet-Draft                     ATP                        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.

   ATP 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 autonomous systems
   encounter.

1.5.  Scope and Target Audience

   This document covers ATP 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 ATP header fields is described at a high level in
   Section 7.2.  Full specification is provided in a separate companion
   document: [ATP-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 ATP request headers.



Hood                    Expires 20 September 2026               [Page 6]

Internet-Draft                     ATP                        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 ATP 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 ATP persistent connection context shared across multiple
      method invocations within a single agent workflow.

   SEP (Scope-Enforcement Point):  An ATP-aware infrastructure component
      — load balancer, gateway, proxy — that enforces Authority-Scope
      compliance without application-layer access.  Requires the Agent
      Certificate extension ([ATP-CERT]).

3.  Problem Statement

   ATP 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.

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





Hood                    Expires 20 September 2026               [Page 7]

Internet-Draft                     ATP                        March 2026


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.

   ATP 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.

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

3.4.  Problem Summary

   +===+==================+======================+=====================+
   | # | Problem          | Current Failure      | ATP 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 ATP







Hood                    Expires 20 September 2026               [Page 8]

Internet-Draft                     ATP                        March 2026


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.

   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





Hood                    Expires 20 September 2026               [Page 9]

Internet-Draft                     ATP                        March 2026


      overhead.  ATP *SHOULD* prefer QUIC for new implementations.  QUIC
      is a transport primitive; ATP is the application-layer protocol
      above it.

4.4.  The Critical Distinction: Messaging vs. Transport

   The most important positioning principle for ATP is the distinction
   between messaging protocols and transport protocols.  MCP, ACP, A2A,
   and ANP are messaging protocols — they define what agents say.  ATP
   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.  ATP defines the
   transport environment those messages move through.

4.5.  ATP Positioning: The Proposed Stack

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

                    Figure 1: ATP in the Protocol Stack

   ATP is not a replacement for messaging protocols.  Agents using MCP
   or A2A route those messages over ATP and gain transport-level
   observability and identity without modifying the messaging layer.
   ATP-native agents that do not use a separate messaging protocol
   interact with ATP methods directly.

5.  Protocol Overview

5.1.  Stack Position

   ATP 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.





Hood                    Expires 20 September 2026              [Page 10]

Internet-Draft                     ATP                        March 2026


   *  *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):

   *  ATP/QUIC: port 8443 (proposed)

   *  ATP/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 ATP
      connections *MUST* be rejected.  Agent identity headers are
      present on every request.

   Observable by design:  Native metadata in every ATP header provides
      the minimum information needed for routing, monitoring, and audit
      without application-layer instrumentation.

   Composable:  ATP works alongside existing agent messaging protocols
      without requiring modification to those protocols.










Hood                    Expires 20 September 2026              [Page 11]

Internet-Draft                     ATP                        March 2026


5.3.  Connection Model

   ATP uses a persistent session model by default, reflecting the
   reality that agents typically execute multi-step workflows rather
   than isolated single requests.  An ATP 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                         |
   +==================+==========+=====================================+
   | ATP-Version      | *MUST*   | Protocol version.  Current:         |
   |                  |          | ATP/1.0                             |
   +------------------+----------+-------------------------------------+
   | ATP-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          |
   |                  |          | specific method invocation          |
   +------------------+----------+-------------------------------------+
   | Delegation-Chain | *MAY*    | Ordered list of Agent-IDs if this   |
   |                  |          | request was delegated               |
   +------------------+----------+-------------------------------------+
   | Priority         | *MAY*    | Request priority hint: critical,    |
   |                  |          | normal, background                  |



Hood                    Expires 20 September 2026              [Page 12]

Internet-Draft                     ATP                        March 2026


   +------------------+----------+-------------------------------------+
   | TTL              | *MAY*    | Maximum acceptable response         |
   |                  |          | latency in milliseconds             |
   +------------------+----------+-------------------------------------+

                     Table 2: ATP Request Header Fields

5.4.2.  Response Headers

     +====================+=============+============================+
     | Field              | Required    | Description                |
     +====================+=============+============================+
     | ATP-Version        | *MUST*      | Protocol version           |
     +--------------------+-------------+----------------------------+
     | ATP-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 ATP methods        |
     |                    | (on session | supported by this server   |
     |                    | open)       |                            |
     +--------------------+-------------+----------------------------+

                    Table 3: ATP Response Header Fields

5.5.  Status Codes

   ATP defines its own status code space.  Codes 451, 550, and 551 are
   ATP-specific with no HTTP equivalent and are registered in the IANA
   ATP Status Code Registry (see Section 8.3).









Hood                    Expires 20 September 2026              [Page 13]

Internet-Draft                     ATP                        March 2026


   +======+===============+============================================+
   | 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 ATP 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)       |
   +------+---------------+--------------------------------------------+
   | 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 — ATP-specific             |
   +------+---------------+--------------------------------------------+
   | 500  | Server Error  | Internal failure in the responding system  |
   +------+---------------+--------------------------------------------+
   | 503  | Unavailable   | Responding agent or system temporarily     |
   |      |               | unavailable                                |
   +------+---------------+--------------------------------------------+
   | 550  | Delegation    | A delegated sub-agent failed to complete   |
   |      | Failure       | the requested action — ATP-specific        |
   +------+---------------+--------------------------------------------+
   | 551  | Authority     | Delegation chain contains an unverifiable  |
   |      | Chain Broken  | or broken identity link — ATP-specific     |
   +------+---------------+--------------------------------------------+

                         Table 4: ATP Status Codes




Hood                    Expires 20 September 2026              [Page 14]

Internet-Draft                     ATP                        March 2026


   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.
   Both are operational signals, not protocol errors, and *MUST* be
   logged for audit purposes.

5.6.  Wire Format and Content-Type

   ATP request and response bodies are encoded as JSON.  The registered
   Content-Type for ATP message bodies is:

   Content-Type: application/atp+json

   Implementations *MUST* include this Content-Type on all ATP 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 ATP request bodies:

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

   And for all ATP response bodies:

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

5.7.  Early Implementations

   ATP 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.





Hood                    Expires 20 September 2026              [Page 15]

Internet-Draft                     ATP                        March 2026


      If you are building an ATP 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 (ATP/QUIC) and port 8080 (ATP/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 ATP as a first-class activation operation, is described
   in a companion document and is implemented as an optional extension.
   Core ATP implementations need not support ACTIVATE to be compliant
   with this specification.

5.8.  Agent Identification and Naming

5.8.1.  The Canonical Agent Identifier

   Every ATP agent is identified by a canonical Agent-ID: a 256-bit
   cryptographic identifier derived from the agent's governance-layer
   Birth Certificate at activation time.  This identifier is globally
   unique, fixed-length, and — when the Agent Certificate extension is
   deployed — cryptographically verifiable at the transport layer.

   The URI form of a canonical Agent-ID uses the atp:// scheme:

   atp://3a9f2c1d8b7e4a6f0c2d5e9b1a3f7c0d4e8b2a5f9c3d7e1b0a4f8c2d6e0b

   URI length is not a practical constraint for atp:// identifiers.
   256-character URIs are handled without issue by all modern protocol
   stacks and do not require abbreviation or truncation.

   The atp:// URI scheme is proposed for IANA registration per [RFC7595]
   as an open, unencumbered scheme.  This registration is distinct from
   and independent of any intellectual property claims on ATP
   extensions.

   The canonical Agent-ID is the authoritative identifier in all ATP
   protocol operations: it appears in the Agent-ID header of every
   request, is the key in the certificate registry, and is the cross-
   layer reference linking the ATP Agent Certificate to the governance-
   layer Birth Certificate.  All other identification forms described in
   this section are aliases that resolve to a canonical Agent-ID.




Hood                    Expires 20 September 2026              [Page 16]

Internet-Draft                     ATP                        March 2026


5.8.2.  Human-Friendly Agent Names (Optional Layer)

   For deployments with large numbers of agents — particularly
   enterprise environments with hundreds or thousands of agents per
   organization — the canonical Agent-ID alone is insufficient for
   human-readable observability, audit navigation, and operational
   management.  ATP supports an optional hierarchical naming layer as a
   convenience alias system on top of canonical identifiers.

   Human-friendly names follow a structured DNS-style format using the
   .agent or .nomo top-level labels:

   atp://marketing-01.acme.agent
   atp://sales-bot-v2.engineering.acme.agent
   atp://customer-experience.acme.nomo

   The structure is: [agent-label].[department].[organization].[tld]

   where tld is .agent for general-purpose agents or .nomo for agents
   activated under the governed .nomo package format.  Organization-
   level namespaces (e.g., acme.agent) are scoped per governance zone
   and enforced at registration time (see Section 5.8.3).

   Attribute-based pattern matching is supported for multi-agent
   operations.  The wildcard form acme.agent:sales-* matches all agents
   whose friendly name begins with sales- within the acme.agent
   namespace.

   Human-friendly names *MUST NOT* be used as Agent-ID header values in
   ATP protocol messages.  The Agent-ID header always carries the
   canonical 256-bit identifier.  Friendly names are a resolution and
   management layer; they are not transport-layer identifiers.

5.8.3.  Governed Name Registration

   Human-friendly name registration is tied to the governed activation
   flow and ATP Agent Certificate issuance process.  An agent may only
   claim a friendly name after successfully completing the atomic
   activation protocol and receiving an Active lifecycle state in the
   certificate registry.

   The registration process:

   1.  The activating operator submits a proposed friendly name
       alongside the .nomo package during the ACTIVATE transaction.

   2.  The activation endpoint verifies uniqueness within the
       organization's governance zone namespace.



Hood                    Expires 20 September 2026              [Page 17]

Internet-Draft                     ATP                        March 2026


   3.  On successful activation, the friendly name is recorded in the
       governance platform's name registry, mapped to the activated
       agent's canonical certificate_id.

   4.  The name binding is included in the genesis audit record as the
       friendly_name field.

   5.  Revocation of the agent's certificate automatically releases the
       friendly name, making it available for re-registration.

   Uniqueness is enforced at the governance-zone level.  Different
   organizations operating separate governance zones may register the
   same friendly name label without conflict.

5.8.4.  Name Resolution

   Two resolution mechanisms are supported:

   DNS-based resolution:  The organization publishes DNS TXT records
      under the _agent subdomain of its governance zone domain:

   _agent.acme.agent. IN TXT "atp-id=3a9f2c1d8b7e4a6f..."

   ATP-native resolution:  An ATP QUERY request to the governance
      platform's resolution endpoint resolves a friendly name to a
      canonical Agent-ID along with the agent's current lifecycle state,
      governance zone, trust tier, and ATP Agent Certificate status.
      Resolution responses carry Content-Type: application/atp+json:

   {
     "friendly_name": "sales-bot-v2.engineering.acme.agent",
     "canonical_id":  "3a9f2c1d8b7e4a6f...",
     "lifecycle_state": "Active",
     "governance_zone": "zone:internal",
     "trust_tier": 2,
     "cert_status": "Active",
     "inclusion_proof_hash": "b2c4d6e8..."
   }

   Implementations *MUST* treat the canonical Agent-ID as authoritative
   in the event of a conflict between DNS-based and ATP-native
   resolution results.









Hood                    Expires 20 September 2026              [Page 18]

Internet-Draft                     ATP                        March 2026


5.8.5.  Scaling Considerations

   The hierarchical naming scheme scales to organizations with millions
   of agents without structural modification.  Unlike sequential numeric
   suffixes, hierarchical sub-labels enable departmental grouping, role-
   based cohorts, version tracking, and delegation visibility.  The
   governance platform's name registry is a lightweight key-value store
   indexed on (governance_zone, friendly_name) with a pointer to
   certificate_id, adding O(1) per-resolution overhead.

5.8.6.  IANA Considerations for the atp:// URI Scheme

   This document proposes registration of the atp:// URI scheme with
   IANA per [RFC7595].  Registration template:

   URI scheme name:  atp

   Status:  Permanent

   URI scheme syntax:  atp://[canonical-agent-id] or atp://[friendly-
      name]

   URI scheme semantics:  Identifies an AI agent operating over the
      Agent Transfer Protocol.  The canonical form uses a 256-bit hex-
      encoded cryptographic identifier.  The friendly-name form uses a
      hierarchical DNS-style label resolvable to a canonical identifier
      via DNS TXT records or ATP-native lookup.

   Applications/protocols that use this URI scheme:  Agent Transfer
      Protocol (this document)

   Interoperability considerations:  Friendly names are optional
      aliases; implementations *MUST* accept canonical identifiers and
      *SHOULD* support friendly-name resolution.

   Contact:  Chris Hood, chris@nomotic.ai

   References:  This document

   The atp:// URI scheme registration is open and unencumbered.  No
   intellectual property claims apply to the URI scheme itself.

6.  Method Definitions








Hood                    Expires 20 September 2026              [Page 19]

Internet-Draft                     ATP                        March 2026


6.1.  Design Philosophy

   ATP 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].

6.2.  Core Methods

6.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.

       +======================+==========+=========================+
       | 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 5: QUERY Parameters

   Response: Result set with confidence scores per item.  Server
   *SHOULD* indicate provenance of each result.  Idempotent: Yes.







Hood                    Expires 20 September 2026              [Page 20]

Internet-Draft                     ATP                        March 2026


6.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.

      +===========+==========+======================================+
      | 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 6: SUMMARIZE Parameters

   Response: Summary content with a source_hash and a confidence score.
   Idempotent: Yes.

6.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 20 September 2026              [Page 21]

Internet-Draft                     ATP                        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 7: BOOK Parameters

   Response: Booking confirmation with booking_id, status (confirmed /
   held), and expiry timestamp if a hold.  Idempotent: No.

6.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 20 September 2026              [Page 22]

Internet-Draft                     ATP                        March 2026


     +===============+================+==============================+
     | Parameter     | Required       | Description                  |
     +===============+================+==============================+
     | steps         | *MUST*         | Ordered list of ATP 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 8: SCHEDULE Parameters

   Response: Schedule record with schedule_id, confirmed steps, and next
   execution timestamp.  Idempotent: No.

6.2.5.  LEARN

   Purpose: Update the agent's session context, knowledge state, or
   persistent memory.  An explicit context write — the agent asserts
   that something should be retained.






















Hood                    Expires 20 September 2026              [Page 23]

Internet-Draft                     ATP                        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 9: LEARN Parameters

   Response: Confirmation with learn_id and effective scope.
   Idempotent: No.

6.2.6.  DELEGATE

   Purpose: Transfer execution of a task or method to a sub-agent or
   downstream system.  Initiates a new ATP session on behalf of the
   delegating agent, carrying forward authority lineage.





















Hood                    Expires 20 September 2026              [Page 24]

Internet-Draft                     ATP                        March 2026


       +==================+==========+=============================+
       | Parameter        | Required | Description                 |
       +==================+==========+=============================+
       | target_agent_id  | *MUST*   | Identifier of the agent to  |
       |                  |          | delegate to                 |
       +------------------+----------+-----------------------------+
       | task             | *MUST*   | ATP 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* | ATP endpoint for result     |
       |                  |          | delivery                    |
       +------------------+----------+-----------------------------+
       | deadline         | *MAY*    | Maximum time for task       |
       |                  |          | completion                  |
       +------------------+----------+-----------------------------+

                       Table 10: 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.

6.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 20 September 2026              [Page 25]

Internet-Draft                     ATP                        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 11: COLLABORATE Parameters

   Response: Collaboration session receipt with collaboration_id.  Each
   collaborator receives an ATP NOTIFY to join.  Idempotent: No.

6.2.8.  CONFIRM

   Purpose: Explicit acknowledgment of a prior action, state, or data
   item.  Creates a signed attestation record.




















Hood                    Expires 20 September 2026              [Page 26]

Internet-Draft                     ATP                        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 12: CONFIRM Parameters

   Response: Confirmation receipt with timestamp and attestation_id.
   Idempotent: Yes.

6.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 — a first-class method, not a failure code.
























Hood                    Expires 20 September 2026              [Page 27]

Internet-Draft                     ATP                        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 13: 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 ATP can use
   escalation frequency and reason codes as observability signals for
   systemic issues.

6.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 20 September 2026              [Page 28]

Internet-Draft                     ATP                        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 14: NOTIFY Parameters

   Response: Delivery receipt with notification_id.  Idempotent: No.

6.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 20 September 2026              [Page 29]

Internet-Draft                     ATP                        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 15: ATP Core Method Summary

6.4.  Method Registry and Extensibility

   ATP 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 20 September 2026              [Page 30]

Internet-Draft                     ATP                        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.

6.5.  Extended Method Vocabulary and Industry Profiles

6.5.1.  Three-Tier Method Architecture

   The ATP 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 ATP compliance.  Every conformant ATP
      implementation *MUST* support all Tier 1 methods.

   Tier 2 — Standard Extended Methods:  Registered in the IANA ATP
      Method Registry and available for use in any ATP implementation.
      Not required for baseline compliance but *SHOULD* be implemented
      where their semantics apply.  Defined in [ATP-METHODS].

   Tier 3 — Industry Profile Methods:  Domain-specific method sets
      defined and registered by industry communities as named ATP
      profiles.  Valid within deployments that declare support for the
      relevant profile.  Not required in general-purpose
      implementations.

6.5.2.  Method Category Taxonomy

   All ATP 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 20 September 2026              [Page 31]

Internet-Draft                     ATP                        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 16: Core Method
                              Category Mapping

6.5.3.  Standard Extended Methods (Tier 2)

   The following methods constitute the initial Tier 2 registration set,
   defined in [ATP-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 20 September 2026              [Page 32]

Internet-Draft                     ATP                        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.

6.5.4.  Short-Form and Industry-Inspired Methods

   A set of short-form verb methods — 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.

6.5.5.  Industry Profile Method Sets

   ATP 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 ATP profiles.  A profile is a published
   companion specification that:

   1.  Declares a profile name (e.g., atp-profile-healthcare, atp-
       profile-financial, atp-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 20 September 2026              [Page 33]

Internet-Draft                     ATP                        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 ATP Method
   Registry will maintain a profile index alongside the core and
   standard method registries.

6.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
      ATP 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 ATP Method Registry is published at:
   https://www.iana.org/assignments/atp-methods/

7.  Security Considerations

   This section satisfies the mandatory IETF Security Considerations
   requirement.  All ATP implementations *MUST* address the
   considerations described here.

7.1.  Mandatory TLS

   All ATP 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 20 September 2026              [Page 34]

Internet-Draft                     ATP                        March 2026


7.2.  Agent Identity Headers and Agent Certificate Extension

   Every ATP 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 ATP Agent Certificate extension [ATP-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 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 ATP server *MUST* log Agent-ID and Principal-ID fields for
   every request, creating an attributable audit trail even in
   deployments without the Certificate extension.

7.3.  Authority Scope Enforcement

   The Authority-Scope header declares what actions the agent is
   authorized to take.  Compliant ATP 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 [ATP-CERT].

7.4.  Threat Model

7.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 [ATP-CERT].







Hood                    Expires 20 September 2026              [Page 35]

Internet-Draft                     ATP                        March 2026


7.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.

7.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 [ATP-CERT] for signed
   delegation tokens.

7.4.4.  Denial of Service via High-Frequency Agent Traffic

   Threat: Agents — 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 [ATP-CERT] is deployed, per-Agent-ID
   quotas can be cryptographically tied to verified identity, preventing
   quota evasion through Agent-ID spoofing.

7.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.

7.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.

7.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



Hood                    Expires 20 September 2026              [Page 36]

Internet-Draft                     ATP                        March 2026


   *  Session-ID and Task-ID reveal workflow patterns

   *  Delegation-Chain reveals multi-agent architecture

   ATP 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.  Under this model, the Agent-ID transmitted in ATP headers
   is an opaque, unlinkable identifier; a trusted resolution service —
   accessible only to authorized parties — maps the opaque identifier to
   the true agent identity for audit and accountability purposes.  The
   architecture for pseudonymous agent identity resolution is reserved
   for a future companion document.

7.6.  Denial-of-Service Considerations

   ATP'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 [ATP-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 [ATP-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.

7.7.  Intellectual Property Considerations

   The core ATP 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 extensions referenced in this document may be subject to
   pending patent applications by the author, specifically: the Agent
   Certificate extension [ATP-CERT], which provides cryptographic
   binding of agent identity and authority scope to ATP header fields;



Hood                    Expires 20 September 2026              [Page 37]

Internet-Draft                     ATP                        March 2026


   and the ACTIVATE method, which provides ATP-native transmission and
   activation of governed agent packages.  Implementers of the core ATP
   specification are not affected by any intellectual property claims on
   these extensions.

   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/

8.  IANA Considerations

   This document requests the following IANA actions upon advancement to
   RFC status.

8.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           |
        +==============+======+===========+=======================+
        | atp          | TBD  | TCP       | Agent Transfer        |
        |              |      |           | Protocol over TCP/TLS |
        +--------------+------+-----------+-----------------------+
        | atp-quic     | TBD  | UDP       | Agent Transfer        |
        |              |      |           | Protocol over QUIC    |
        +--------------+------+-----------+-----------------------+

                    Table 17: Proposed Port Assignments

8.2.  ATP 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 20 September 2026              [Page 38]

Internet-Draft                     ATP                        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 18: Initial ATP Method Registry Entries

8.3.  ATP 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 20 September 2026              [Page 39]

Internet-Draft                     ATP                        March 2026


   The following ATP-specific status codes — those with no HTTP
   equivalent — 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 19: ATP-Specific Status Code Definitions

8.4.  Header Field Registry

   ATP 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 20 September 2026              [Page 40]

Internet-Draft                     ATP                        March 2026


   ATP does not reuse the HTTP Field Name Registry, as ATP header fields
   have different semantics, applicability, and versioning constraints
   from HTTP fields.  HTTP header fields are not automatically valid in
   ATP, and ATP header fields are not valid HTTP fields.

   Initial registrations (all Permanent): ATP-Version, ATP-Method, ATP-
   Status, Agent-ID, Principal-ID, Authority-Scope, Session-ID, Task-ID,
   Delegation-Chain, Priority, TTL, Server-Agent-ID, Attribution-Record,
   Continuation-Token, Supported-Methods.

8.5.  URI Scheme Registration

   Registration of the atp:// URI scheme per [RFC7595], as described in
   Section 5.8.6 of this document.

9.  References

9.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,
              <https://www.rfc-editor.org/rfc/rfc2119>.

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

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

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

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

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



Hood                    Expires 20 September 2026              [Page 41]

Internet-Draft                     ATP                        March 2026


   [RFC9001]  Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
              QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
              <https://www.rfc-editor.org/rfc/rfc9001>.

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

9.2.  Informative References

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

   [ACP]      IBM Research, "Agent Communication Protocol", 2025.

   [ANP]      "Agent Network Protocol", 2025.

   [ATP-CERT] Hood, C., "ATP Agent Certificate Extension", Work in
              Progress, Internet-Draft, draft-hood-atp-agent-cert-00,
              2026, <https://datatracker.ietf.org/doc/html/draft-hood-
              atp-agent-cert-00>.

   [ATP-METHODS]
              Hood, C., "ATP Standard Extended Method Vocabulary", Work
              in Progress, Internet-Draft, draft-hood-atp-standard-
              methods-00, 2026, <https://datatracker.ietf.org/doc/html/
              draft-hood-atp-standard-methods-00>.

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

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

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

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

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



Hood                    Expires 20 September 2026              [Page 42]

Internet-Draft                     ATP                        March 2026


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:

   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 — requires explicit grant; use     |
      |            | with caution                                   |
      +------------+------------------------------------------------+

                 Table 20: Reserved Authority-Scope Domains

Appendix B.  Example ATP 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
   ATP message bodies is application/atp+json.




Hood                    Expires 20 September 2026              [Page 43]

Internet-Draft                     ATP                        March 2026


B.1.  QUERY Request and Response

   ATP/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/atp+json

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

   ATP/1.0 200 OK
   Task-ID: task-0042
   Server-Agent-ID: srv-knowledge-01
   Attribution-Record: [signed attribution token]
   Content-Type: application/atp+json

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

B.2.  BOOK Request and Response












Hood                    Expires 20 September 2026              [Page 44]

Internet-Draft                     ATP                        March 2026


   ATP/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/atp+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
     }
   }

   ATP/1.0 200 OK
   Task-ID: task-0107
   Attribution-Record: [signed attribution token]
   Content-Type: application/atp+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 20 September 2026              [Page 45]

Internet-Draft                     ATP                        March 2026


   ATP/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/atp+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": "Contract value exceeds agent
                     authorization threshold"
       },
       "recipient": "usr-cfo",
       "deadline": "2026-03-19T09:00:00Z"
     }
   }

   ATP/1.0 202 Accepted
   Task-ID: task-0881
   Server-Agent-ID: srv-escalation-handler
   Content-Type: application/atp+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 20 September 2026              [Page 46]

Internet-Draft                     ATP                        March 2026


Appendix C.  Comparison Table

   +==============+================+=======+======+===================+
   |Criterion     | ATP            |HTTP/  |gRPC  | A2A / MCP         |
   |              |                |REST   |      |                   |
   +==============+================+=======+======+===================+
   |Agent-native  | Yes            |No     |No    | Partial           |
   |methods       |                |       |      |                   |
   +--------------+----------------+-------+------+-------------------+
   |Intent        | Native         |None   |None  | Messaging layer   |
   |semantics at  |                |       |      | only              |
   |protocol level|                |       |      |                   |
   +--------------+----------------+-------+------+-------------------+
   |Built-in agent| Yes            |No     |No    | No                |
   |identity      |                |       |      |                   |
   +--------------+----------------+-------+------+-------------------+
   |Authority     | Protocol-level |None   |None  | Application-layer |
   |scope         |                |       |      |                   |
   |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     | Proposed       |Mature |Mature| Emerging          |
   |maturity      |                |       |      |                   |
   +--------------+----------------+-------+------+-------------------+
   |Governance/   | Native         |Manual/|Manual| Limited           |
   |observability |                |bolt-on|      |                   |
   +--------------+----------------+-------+------+-------------------+
   |Method        | Yes (Expert    |Frozen |N/A   | N/A               |
   |registry      | Review)        |(IETF  |      |                   |
   |extensibility |                |Review)|      |                   |
   +--------------+----------------+-------+------+-------------------+
   |Open core /   | Yes            |Yes    |Yes   | Yes               |
   |royalty-free  |                |       |      |                   |
   +--------------+----------------+-------+------+-------------------+

              Table 21: ATP Compared to Existing Approaches





Hood                    Expires 20 September 2026              [Page 47]

Internet-Draft                     ATP                        March 2026


   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.  ATP'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 Transfer Protocol (ATP):  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 ATP request headers.  In the base spec, self-asserted.
      With [ATP-CERT], cryptographically bound to a verified identity.

   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 ATP 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.

   Intent Verb:  An ATP 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 ATP 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



Hood                    Expires 20 September 2026              [Page 48]

Internet-Draft                     ATP                        March 2026


      agent operates, present in all ATP request headers.

   Scope-Enforcement Point (SEP):  An ATP-aware infrastructure component
      — load balancer, gateway, proxy — that enforces Authority-Scope
      compliance on ATP requests without application-layer access.
      Requires [ATP-CERT].

   Scope Violation (451):  An ATP 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 ATP persistent connection context shared across multiple
      method invocations within a single agent workflow.

   551 Authority Chain Broken:  An ATP 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 20 September 2026              [Page 49]
