Agent Transfer Protocol (ATP)

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

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

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

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

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

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

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

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

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

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

• 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

atp://3a9f2c1d8b7e4a6f0c2d5e9b1a3f7c0d4e8b2a5f9c3d7e1b0a4f8c2d6e0b

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

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

{
  "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..."
}

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.3. Method Summary Table

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

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

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

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.5. Privacy Considerations

Agent identity headers carry information about agent behavior that may be sensitive:¶

• Agent-ID and Principal-ID together may reveal organizational structure¶

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

• Delegation-Chain reveals multi-agent architecture¶

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; 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.1. Port Assignment

Registration of the following service names in the IANA Service Name and Transport Protocol Port Number Registry:¶

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 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:¶

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

The following ATP-specific status codes — those with no HTTP equivalent — are registered with full 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.¶

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

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

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

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

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"
  }
}