Agent Transfer Protocol (AGTP)

1.1. Background

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

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

1.2. Limitations of HTTP for Agent Traffic

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

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

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

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

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

1.3. Why Not Evolve HTTP?

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

First, the HTTP method registry is effectively frozen for new semantics. [RFC9110] defines the HTTP method registry with IETF Review as the registration procedure, meaning new methods require a full IETF consensus process and must be backward-compatible with existing HTTP implementations. Adding intent-based verbs (SUMMARIZE, DELEGATE, ESCALATE) to HTTP would require every HTTP client, server, proxy, and middleware component to ignore or handle unknown methods gracefully, a compatibility constraint that limits how agent-specific semantics can be expressed at the protocol level.¶

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

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

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

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

1.4. Motivation for a Dedicated Protocol

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

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

1.5. Scope and Target Audience

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

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

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

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

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

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

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

The AGMP category term is introduced in this document to provide a stable collective reference for the class of protocols that AGTP serves as substrate. It is not a formal IETF term of art; it is a descriptive classification. Individual AGMP specifications retain their own names and development paths. AGTP does not govern, modify, or supersede any AGMP.¶

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

3.1. Problem 1: Undifferentiated Agent Traffic on HTTP

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

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

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

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

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

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

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

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

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 Group Messaging Protocols

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

Defines structured communication between AI models and tools/resources. Runs over HTTP. Addresses tool-calling semantics, 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. AGTP SHOULD prefer QUIC for new implementations. QUIC is a transport primitive; AGTP is the application-layer protocol above it.¶

4.4. The Critical Distinction: Messaging vs. Transport

The most important positioning principle for AGTP is the distinction between messaging protocols and transport protocols. MCP, ACP, A2A, and ANP are messaging protocols, they define what agents say. AGTP defines how agent traffic moves.¶

An analogy: SMTP is a messaging protocol that runs over TCP. SMTP does not replace TCP. Saying "TCP is unnecessary because SMTP exists" is a category error. The same logic applies here. MCP and its peers define agent messaging semantics. AGTP defines the transport environment those messages move through.¶

4.5. AGTP Positioning: The Proposed Stack

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

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

5.1. Stack Position

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

• SHOULD prefer QUIC [RFC9000] [RFC9001] for new deployments (lower latency, multiplexing without head-of-line blocking, 0-RTT connection establishment).¶

• MUST support TCP/TLS as a fallback for compatibility with existing infrastructure.¶

• MAY run over UDP where QUIC is not available, subject to implementor-defined reliability guarantees.¶

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

5.2. Design Principles

Minimalist core:

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

Extensible by design:

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

Agent-native:

Every design decision assumes the initiating party is an AI system, not a human.¶

Secure by default:

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

Observable by design:

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

Composable:

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

Runtime contract negotiation:

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

5.3. AGTP as a Runtime Contract Negotiation Substrate

AGTP is a runtime contract negotiation substrate (RCNS). The substrate fixes a small floor of eighteen protocol-level methods (the cognitive and mechanics verbs of Section 7.1); beyond that floor, the method and endpoint surface that any given AGTP server presents is not fixed in advance. It is negotiated at runtime between the agent and the server, in a single round-trip, governed by the AGTP-API companion specification [AGTP-API] which defines the curated method catalog, path grammar, endpoint primitive, semantic block, schemas, and synthesis semantics.¶

The negotiation loop is:¶

1. An agent encounters an AGTP server and inspects its endpoint surface via DESCRIBE or by retrieving the server manifest as defined in [AGTP-API].¶

2. If the endpoints the agent needs are not present, the agent submits a PROPOSE request carrying an AGTP-API endpoint specification: a verb (drawn from the AGTP-API approved verb list), a path (conforming to AGTP-API path grammar), a semantic block (intent, actor, outcome, capability classification, confidence guidance, impact tier, idempotency), input and output schemas, and declared error conditions.¶

3. The server evaluates the proposal against AGTP-API contract rules and against its own capability surface. The server determines whether the proposed endpoint can be synthesized from existing endpoints, what authority scope is required, and what governance constraints apply.¶

4. The server either instantiates the proposed endpoint as a session-scoped endpoint and returns 263 Proposal Approved with the AGTP-API endpoint definition, or refuses with 463 Proposal Rejected and a structured reason.¶

The full negotiation completes in a single PROPOSE → response round-trip. No registry update, no human-in-the-loop approval, no out-of-band coordination is required for an agent and a server to agree on a new endpoint, provided the endpoint is AGTP-API conformant and within the server's capability envelope.¶

This property distinguishes AGTP from protocols whose contract surface is fixed at design time. HTTP's method registry is effectively frozen (see Appendix E); proposing a new HTTP method requires IETF consensus over multi-year timelines. gRPC services expose a fixed service contract defined at compile time. Most agent frameworks built on HTTP inherit this constraint and work around it by overloading POST. AGTP treats the contract surface as dynamically negotiable, with AGTP-API as the contract layer that keeps negotiation safe.¶

The RCNS property is what makes composition with higher-level agent frameworks (Section 8) tractable. A server that wants to expose a framework-specific operation as a first-class AGTP endpoint does not need to wait for IANA registration; it negotiates the endpoint via PROPOSE at the moment an agent asks for it, governed by AGTP-API. The floor of eighteen methods provides interoperability; AGTP-API provides contract safety; PROPOSE provides expressivity.¶

Implementations MAY choose not to participate in runtime negotiation. A server that supports only the eighteen-method floor and returns 463 Proposal Rejected for every PROPOSE request is fully conformant with this specification. Runtime negotiation is a capability AGTP enables, not a behavior it requires.¶

5.4. Connection Model

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

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

5.5. Header Format

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

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

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

5.6. Status Codes

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

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

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

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

Status code 455 (Scope Violation) is a generic scope-violation signal for cases not covered by the dedicated scope codes (429 rate-limit, 456 budget, 457 zone, 262 authority). Typical applications include token-based scope violations and query-based scope violations, where an operator defines a scope dimension outside the standard set. Authority-Scope violations specifically are signaled with 262, not 455. Status code 456 (Budget Exceeded) is the dedicated code for resource-consumption scope violations: the agent's requested action would consume resources beyond what the principal authorized for this invocation. Status code 457 (Zone Violation) is returned by SEPs when a DELEGATE request would route to an agent outside the declared zone boundary. Status code 458 (Counterparty Unverified) is returned on PURCHASE invocations when the receiving server cannot verify that the requesting agent has performed valid merchant identity verification against the server's current Merchant Manifest Document, or when the merchant is in a non-Active lifecycle state; see [AGTP-MERCHANT].¶

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

5.7. Wire Format and Content-Type

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

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

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

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

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

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

And for AGTP method-level response bodies:¶

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

5.8. Early Implementations

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

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

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

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

6.1. URI Structure and Resolution Mechanics

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

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

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

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

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

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

agtp://7f3a9c2d...e1f8b0a4

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

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

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

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

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

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

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

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

6.2. Agent Namespace Document

agtp://acme.tld/agents
agtp://agtp.acme.tld/agents

{
  "document_type": "agtp-namespace",
  "schema_version": "1.0",
  "org_domain": "acme.tld",
  "governance_zone": "zone:acme-internal",
  "generated_at": "2026-03-20T14:00:00Z",
  "signature": {
    "algorithm": "ES256",
    "key_id": "agtp-gov-key-acme-01",
    "value": "[base64-encoded-signature]"
  },
  "agents": [
    {
      "agent_label": "customer-service",
      "canonical_id": "3a9f2c1d8b7e4a6f...",
      "lifecycle_state": "Active",
      "trust_tier": 1,
      "cert_status": "Active",
      "manifest_uri": "agtp://agtp.acme.tld/agents/customer-service",
      "activated_at": "2026-01-15T09:00:00Z",
      "last_updated": "2026-03-01T11:30:00Z"
    }
  ],
  "total_active": 1,
  "namespace_cert_fingerprint": "b2c4d6e8..."
}

6.3. Agent Identity Document and the .agtp Format

agtp://[canonical-agent-id]
agtp://acme.tld/agents/customer-service
agtp://acme.tld/agents/customer-service?format=json

.agent   ──── open packaging format (patent pending, Chris Hood)
  │           Contains: manifest + integrity hash + behavioral
  │           trust score + executable content
  │
.nomo    ──── governed packaging format (patent pending, Chris Hood)
  │           Contains: .agent contents + CA-signed cert chain
  │           + governance zone binding
  │
  Both produce ↓ when queried via agtp:// URI
  │
.agtp    ──── wire-level Identity Document (this spec)
              Contains: identity fields, lifecycle state, trust
              tier, trust score, behavioral scope, methods,
              capabilities, verification anchors
              Open format defined by AGTP specification
              Content-Type: application/vnd.agtp.identity+json

{
  "agtp_version": "0.7",
  "document_type": "agtp-identity",
  "document_version": "1.0",
  "agent_id": "3a9f2c1d8b7e4a6f0c2d5e9b1a3f7c0d...",
  "name": "customer-service",
  "description": "Handles customer service requests.",
  "principal": "Acme Corporation",
  "principal_id": "acme.tld",
  "issuer": "https://ca.acme.tld",
  "issued_at": "2026-01-15T09:00:00Z",
  "updated_at": "2026-03-01T11:30:00Z",
  "status": "Active",
  "methods": [
    "QUERY", "DESCRIBE", "SUMMARIZE",
    "EXECUTE", "ESCALATE", "CONFIRM", "NOTIFY"
  ],
  "capabilities": [
    "customer-service:tier-1",
    "knowledge-base:read",
    "ticket-system:create"
  ],
  "scopes_accepted": [
    "documents:query",
    "knowledge:query",
    "calendar:book",
    "escalation:route"
  ],
  "trust_score": 0.94
}

{
  "trust_tier": 1,
  "verification_path": "dns-anchored",
  "owner_id": "nomotic.inc",
  "role": "agent",
  "org_domain": "acme.tld",
  "governance_zone": "zone:acme-internal",
  "cert_fingerprint": "b2c4d6e8...",
  "cert_status": "Active",
  "dns_anchor_record": "_agtp.acme.tld TXT agtp-zone=...",
  "log_inclusion_proof": null,
  "package_format": "nomo",
  "package_integrity_hash": "sha256:[hash]",
  "audit_log_uri": "agtp://agtp.acme.tld/audit/customer-service",
  "escalation_policy": "route-to-human-on-scope-limit",
  "delegation_permitted": false,
  "max_delegation_depth": 0,
  "manifest_issuer": "registrar.acme.tld",
  "manifest_issuer_public_key": "<base64url-encoded 32 bytes>",
  "manifest_signature": "<base64url-encoded Ed25519 signature>"
}

6.4. Browser and Human-Facing Interaction Model

agtp:// URI in a browser
  │
  └─→ Returns Agent Identity Document
        Human-readable view of identity and status
        Read-only. No execution. No code exposed.

agtp:// session initiated by an agent or AGTP client
  │
  └─→ Establishes authenticated AGTP session
        Method invocations (QUERY, EXECUTE, ESCALATE, etc.)
        Full protocol operation - not visible to browsers

agtp://acme.tld/agents/customer-service/status

{
  "document_type": "agtp-status",
  "canonical_id": "3a9f2c1d8b7e4a6f...",
  "agent_label": "customer-service",
  "org_domain": "acme.tld",
  "lifecycle_state": "Active",
  "cert_status": "Active",
  "last_action_method": "QUERY",
  "last_action_timestamp": "2026-03-20T13:58:22Z",
  "active_session_count": 3,
  "pending_escalations": 0,
  "generated_at": "2026-03-20T14:00:00Z"
}

6.5. Agent Registration Process

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

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

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

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

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

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

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

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

7.1. Design Philosophy

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

7.2. Core Methods

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

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

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

7.3. Method Summary Table

7.4. Method Registry and Extensibility

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

1. Have a unique uppercase ASCII name¶

2. Define required and optional parameters¶

3. Define expected response structure¶

4. Specify idempotency behavior¶

5. Specify applicable error codes¶

6. Include a security considerations section¶

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

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

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

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

7.5. Dynamic Endpoint Negotiation

Step 1:  Pre-auth discovery
         Agent issues unauthenticated GET to agtp://service.example.com
         Service returns server manifest + data_manifest block
         No credentials required at this step

Step 2:  Agent evaluates data_manifest
         Agent determines the service has relevant data
         Agent assesses whether `negotiable: true` is declared
         Agent constructs an AGTP-API-conformant endpoint proposal

Step 3:  PROPOSE request
         Agent sends PROPOSE with AGTP-API endpoint definition in body
         Request MAY be unauthenticated if data sensitivity is low
         Request MUST include AGTP-API/1.0 contract validation

Step 4a: Authorization required (262)
         Service returns 262 with required authorization mechanism
         Agent establishes credentials via specified mechanism
         Agent resubmits PROPOSE with credentials
         Negotiation-ID issued by service in 262 response

Step 4b: Negotiation in progress (261)
         Service evaluates proposal asynchronously
         Service returns 261 with Negotiation-ID
         Agent polls or awaits outcome

Step 5a: Proposal approved (263)
         Service returns 263 with complete AGTP-API endpoint definition,
         synthesis_id, and expires_at
         Instantiated endpoint is session-scoped by default
         Agent MAY call the endpoint immediately

Step 5b: Proposal rejected (463)
         Service returns 463 with structured reason (`out-of-scope`,
         `policy-refused`, `composition-impossible`, `ambiguous`,
         `synthesis-disabled`) and optional counter_proposal
         Agent MAY modify proposal and retry (maximum 3 turns)
         After 3 rejections agent MUST ESCALATE

{
  "negotiation_id": "550e8400-e29b-41d4-a716-446655440000",
  "instantiated_endpoint": {
    "method": "LOCATE",
    "path": "/customer/{id}/location",
    "semantic": {
      "intent": "Returns the last known location for a customer",
      "actor": "agent",
      "outcome": "Location coordinates and address are returned",
      "capability": "retrieval",
      "confidence": 0.70,
      "impact": "informational",
      "is_idempotent": true
    },
    "input": { "required": ["id"] },
    "output": { "coordinates": "object", "address": "string" },
    "errors": ["customer_not_found", "location_not_available"],
    "proposed": true,
    "scope_required": "location:read",
    "expires": "session"
  }
}

7.6. Extended Method Vocabulary and Industry Profiles

AGTP-API-Version: 1.2.4

Adaptation flow:
  Agent calls EXECUTE for reserve-action
  Response includes AGTP-API-Version: 1.2.5 (was 1.2.4)
  Agent re-fetches agtp://service.example.com
  Service returns updated server manifest (new endpoint added)
  Agent updates service map
  Agent resumes operation with updated capability knowledge

8.1. Substrate Model

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

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

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

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

4. Delegation chain at the protocol level. Multi-hop agent workflows carry their lineage in the Delegation-Chain header, independent of framework-level concepts of "session" or "task."¶

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

8.2. EXECUTE as the Generic Carrier

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

The EXECUTE invocation supplies:¶

• The framework identifier (via payload_type).¶

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

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

• An optional idempotency_key enabling safe retry.¶

The AGTP envelope (status, task_id, attribution) wraps the framework's response. A framework that wishes to expose a particular operation as a first-class AGTP method (rather than carrying it through EXECUTE) MAY define a Tier 4 AGTP-API-validated method per Section 7.1; this is reserved for frameworks whose operations are widely used enough to justify a dedicated verb.¶

8.3. Precedence Rule

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

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

8.4. Canonical Mapping

A wire example showing EXECUTE carrying an MCP tool invocation is provided in Appendix D. Additional examples for A2A and ACP are in the appendix-level composition section (Appendix G) and in [AGTP-COMPOSITION].¶

8.5. HTTP Gateway Sidecar

Operators that need to accept inbound HTTP/REST traffic on the same agent surface that serves AGTP MAY deploy an HTTP gateway sidecar alongside the AGTP daemon. The gateway is a parallel listener that accepts HTTP requests, translates them into AGTP method invocations, and dispatches them through the same response-finalization path as native AGTP traffic. The gateway is not part of the AGTP wire protocol; it is a deployment-time adoption ramp specified here so the translation contract is interoperable across implementations.¶

Translation rules:¶

1. HTTP method → AGTP method. The HTTP method is run through the server's policies.methods.aliases map per [AGTP-API]; the resolved canonical AGTP method is used for dispatch. The default alias seed (GET → FETCH, POST → CREATE, PUT → REPLACE, DELETE → REMOVE, PATCH → MODIFY) handles the five common verbs. The original HTTP method is preserved on the Attribution- Record as requested_method per [AGTP-IDENTIFIERS].¶

2. HTTP path → AGTP path. The path is forwarded verbatim, subject to the path grammar in [AGTP-API].¶

3. HTTP headers → AGTP headers. The gateway MAY forward selected headers (e.g., Authorization mapped to AGTP authentication context); the specific header forwarding policy is operator-defined.¶

4. Response. The AGTP response (status, headers, body) is translated into an HTTP response. The gateway MUST invoke the standard response-finalization path so the AGTP response carries a valid Attribution-Record; the resulting Audit-ID and Server-ID participate in the same per-agent chain as native AGTP responses.¶

Constraints:¶

• The gateway **MUST strip the Allow-RCNS header from inbound HTTP requests before dispatch.** HTTP callers cannot opt into RCNS through the gateway by design; runtime contract negotiation is a substrate feature for AGTP-native callers whose identity, trust tier, and scope are bound at the AGTP layer. Operators that want to expose RCNS to HTTP callers MUST layer AGTP-native authentication on top of the gateway, in which case the gateway is no longer the right abstraction.¶

• The gateway is a translation surface, not a transport protocol. Two AGTP servers exchanging traffic with one another MUST NOT use the gateway as their hop; AGTP is its own transport, and gateway-mediated AGTP-to-AGTP flows would lose the wire-level identity, attribution, and trust-posture guarantees this specification defines.¶

The reference implementation pattern is an operational module distributed as mod_http_gateway or equivalent, listening on a separate port from the AGTP listener (default 127.0.0.1:8080 for the gateway, port 4480 for AGTP), so the two protocols never share a socket.¶

8.6. Composition with External Identity Providers

AGTP identity (Agent-ID, Agent Certificate, Authority-Scope) and external identity-provider credentials (OAuth bearer tokens, OIDC id_tokens, SPIFFE SVIDs, enterprise IdP session tokens) answer different questions and MUST be treated as orthogonal axes:¶

• AGTP identity answers "which agent is making this call." Hash-anchored on the Agent Genesis (Section 6.5.2), presented via the Agent-ID header, optionally bound to a client certificate per [AGTP-CERT], scoped by Authority-Scope. The trust root is the Genesis-issuer registrar.¶

• External IdP credentials answer "on whose behalf is the agent acting." A human principal, a service account, or a workload identity in an enterprise identity stack. The trust root is the IdP.¶

The two axes compose. AGTP places no constraints on how external credentials are validated; servers MAY require external credentials on specific methods, MAY lift a named claim from the validated credential into the Attribution-Record, and MUST treat the failure modes of the two axes as independent.¶

9.1. Overview

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

Version 04 of AGTP introduces normative integration hooks for the AGTP Merchant Identity and Agentic Commerce Binding specification [AGTP-MERCHANT], which defines the merchant-side identity model. The integration is hook-based: this document registers the required headers, status code, and Authority-Scope domains; the detailed semantics, Merchant Manifest Document schema, Merchant Birth Certificate structure, and counterparty verification procedure are specified in the companion.¶

9.2. Merchant Identity Headers (Summary)

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

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

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

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

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

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

9.3. 458 Counterparty Unverified (Summary)

Receiving servers MUST return 458 Counterparty Unverified on PURCHASE invocations that fail merchant identity verification: missing Merchant-ID or Merchant-Manifest-Fingerprint headers, fingerprint mismatch, Merchant-ID mismatch, or a target merchant in any lifecycle state other than Active. 455 is a governance signal, parallel in role to 455 Scope Violation and 457 Zone Violation: MUST be logged; MUST NOT be retried without re-running counterparty verification.¶

9.4. Integration with PURCHASE, DISCOVER, and Attribution-Record

Three existing AGTP primitives interact with merchant identity:¶

• PURCHASE: Counterparty verification runs before PURCHASE is sent on the wire. A verified PURCHASE produces an Attribution- Record naming both the agent and the merchant cryptographically.¶

• DISCOVER: The DISCOVER method defined in [AGTP-DISCOVER] is extended by [AGTP-MERCHANT] to return Merchant Manifest Documents when the query carries result_type: "merchant", and to return mixed agent/merchant result sets when result_type: "any". The existing DISCOVER signature model, ranking model, and governance-zone enforcement apply unchanged.¶

• Attribution-Record: The Attribution-Record returned on PURCHASE includes merchant_id, merchant_fingerprint, and intent_assertion_jti fields when merchant identity binding is in effect. This produces a dual-party cryptographic record consumable by downstream audit and dispute-resolution processes without requiring those processes to speak AGTP.¶

9.5. Relationship to Payment Networks

The merchant identity model defined in this document is payment-rail neutral. It does not define payment credential handling, tokenized card-on-file representations, authorization messaging to card networks, or settlement. Payment networks wishing to extend protection, fraud coverage, or dispute handling to agent-initiated transactions consume the Intent-Assertion JWT and the Attribution- Record as verifiable inputs to their own authorization and dispute flows; no AGTP-layer integration is required on the payment-network side. The specific mapping between AGTP merchant identity artifacts and payment-network message formats is expected to be defined bilaterally between governance platforms and individual networks and is out of scope for this document.¶

10.1. Mandatory TLS

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

10.2. Agent Identity Verification: Three Levels

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

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

Level 2 - Application-layer cryptographic verification (signed Agent Identity Document). A canonical Agent-ID resolves to a signed Agent Identity Document (Section 5.5) that carries the Birth Certificate's Authority-Scope grant and is signed by the governance platform that issued it. A verifier (including a stranger with no prior relationship to the agent's organization) can cryptographically verify identity and scope at the application layer by performing the following steps:¶

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

2. Verify the governance platform's signature on the manifest against the platform's published key.¶

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

4. Read the Authority-Scope grant from the verified manifest.¶

Level 2 verification is available in base AGTP without the Agent Certificate extension. It is the identity mechanism the protocol depends on. Self-asserted headers (Level 1) are bound to verified identity (Level 2) by the resolver's retrieval of the signed manifest for the declared canonical Agent-ID.¶

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

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

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

10.3. Authority Scope Enforcement

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

10.4. Threat Model

10.5. Privacy Considerations

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

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

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

• Delegation-Chain (reserved for future revisions) would reveal multi-agent architecture¶

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

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

10.6. Denial-of-Service Considerations

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

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

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

10.7. Intellectual Property Considerations

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

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

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

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

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

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

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

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

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

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

11.1. Port Assignment

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

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

Contact:

Chris Hood, chris@nomotic.ai¶

Reference:

This document¶

11.2. AGTP Method Registry

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

Registry name:

Agent Transfer Protocol Methods¶

Registration procedure:

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

Reference:

This document¶

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

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

11.3. AGTP Status Code Registry

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

Registry name:

Agent Transfer Protocol Status Codes¶

Registration procedure:

Expert Review + published specification required.¶

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

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

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

11.4. Media Type Registry

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

"Vendor-tree registration submitted" indicates that the registration application has been filed with IANA against the application/vnd.* vendor tree and is awaiting processing. "Planned (this document)" and "Planned (AGTP-API)" indicate types for which registration applications will be filed concurrent with publication of the defining document. Standards-tree promotion of the full set is anticipated at RFC publication of the AGTP family.¶

11.5. Header Field Registry

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

Registry name:

Agent Transfer Protocol Header Fields¶

Registration procedure:

Expert Review + published specification required.¶

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

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

The four merchant-related headers are defined in [AGTP-MERCHANT] and registered concurrently with this document. The three API-related headers (AGTP-API-Version, AGTP-Catalog-Warning, and AGTP-Endpoint-Warning) are defined in [AGTP-API] and registered concurrently.¶

Headers reserved for future revisions (Priority, TTL, Budget-Limit, AGTP-Zone-ID, Content-Schema, Telemetry-Export) are not registered in this revision. They will be registered alongside the future revision that specifies their normative semantics.¶

11.6. URI Scheme Registration

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

11.7. AGTP Budget Unit Registry

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

Registry name:

Agent Transfer Protocol Budget Units¶

Registration procedure:

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

Reference:

This document¶

Initial registrations:¶

11.8. Agent Registry Retention Policy

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

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

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

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

• Agent label and org domain at time of registration¶

• Trust tier at time of registration¶

• Activation date and activating principal¶

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

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

• Full Agent Genesis (archived, not publicly accessible)¶

• All lifecycle state transitions with timestamps¶

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

12.1. Normative References

[AGTP-API]

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

[AGTP-IDENTIFIERS]

Hood, C., "AGTP Identifier Stack: Identifiers and Per-Agent Audit Chain", Work in Progress, Internet-Draft, draft-hood-agtp-identifiers-01, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-identifiers-01>.

[RFC2119]

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

[RFC3986]

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

[RFC5280]

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

[RFC6335]

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

[RFC7515]

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

[RFC8126]

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

[RFC8174]

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

[RFC8179]

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

[RFC8555]

Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, <https://www.rfc-editor.org/rfc/rfc8555>.

[RFC8615]

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

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

[RFC9334]

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

12.2. Informative References

[A2A]

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

[ACP]

IBM Research, "Agent Communication Protocol", 2025.

[AGTP-CERT]

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

[AGTP-COMPOSITION]

Hood, C., "AGTP Composition with Agent Group Messaging Protocols", Work in Progress, Internet-Draft, draft-hood-agtp-composition-00, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-composition-00>.

[AGTP-DISCOVER]

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

[AGTP-LOG]

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

[AGTP-MERCHANT]

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

[AGTP-TRUST]

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

[AGTP-WEB3]

Hood, C., "AGTP Web3 Bridge Specification", Work in Progress, Internet-Draft, draft-hood-agtp-web3-bridge-00, 2026, <https://datatracker.ietf.org/doc/html/draft-hood-agtp-web3-bridge-00>.

[ANP]

"Agent Network Protocol", 2025.

[HOOD2026]

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

[MCP]

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

[RFC6749]

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

[RFC7519]

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

[RFC7540]

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

[RFC7595]

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

[RFC9114]

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

[RFC9162]

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

[RFC9943]

"*** BROKEN REFERENCE ***".

A.1. Substantive Changes

The following substantive changes were made:¶

1. Agent-ID echoed on responses. The Response Headers table (Section 5.5.4) now documents the Agent-ID response header. When a request carries an Agent-ID header, the server's response SHOULD echo that value to correlate the response with the requesting agent. This parallels the existing Task-ID echo behavior and reflects the contract that deployed implementations have provided since v07. Server-ID and Agent-ID remain semantically distinct on responses: Server-ID names the host that produced the response, Agent-ID (when echoed) names the agent the response is being returned to.¶

2. Attribution-Record tightened to JWS Compact and always emitted. The Attribution-Record row in Section 5.5.4 now specifies the JWS Compact serialization per [RFC7515] normatively, calls out the extended payload (identifier-chain fields and previous_audit_id) by reference to [AGTP-IDENTIFIERS], and changes the emission contract from "SHOULD when manifest signing is configured" to "MUST," with an explicit alg: none fallback when no signing key is configured. The fallback preserves wire format and Audit-ID chain construction; it carries no anti-forgery claim and is addressed in the Attribution Forgery security consideration.¶

3. Audit-ID, Response-ID, Owner-ID, and Request-ID response headers added to the table. These headers were stamped by deployed implementations since v07 and defined normatively in [AGTP-IDENTIFIERS]; the base draft's Response Headers table now lists them with their emission contracts. Audit-ID is required when Attribution-Record is present; Response-ID is required on every response; Owner-ID is SHOULD on every response; Request-ID echoes the request's value when present.¶

4. Normative reference to RFC 7515 added. Required by the tightened Attribution-Record description. Informative reference to [AGTP-IDENTIFIERS] (draft-hood-agtp-identifiers) added; the identifier stack and extended Attribution-Record schema are specified in that companion draft.¶

5. Agent Genesis schema cleaned up. The Agent Genesis Contents table (Section 6.5.2) drops the certificate_hash field that no longer exists under the locked taxonomy. The canonical Agent-ID is defined explicitly as sha256(canonical_form(Agent_Genesis_without_signature)); the agent_id field in the Genesis is populated for relying-party convenience and verifiers MUST independently recompute the hash before trusting it. The signature field is described normatively as a detached Ed25519 signature over the canonical form (with the signature field excluded). The canonical-form requirement is stated explicitly: deterministic serialization, sorted keys, no insignificant whitespace, UTF-8, identical bytes across implementations. The Agent Genesis to AGTP Protocol Mapping table drops the certificate_hash row; the chain prose is rewritten to name the document-itself-hashes-itself model. References to certificate_hash in the ISSUE flow and in the collision-attack security consideration are updated to refer to the recomputed canonical Agent-ID. These changes align the spec with the [AGTP-IDENTIFIERS] definition of the canonical Agent-ID and with deployed implementations.¶

6. Agent Identity Document trust-posture surfacing. The owner_id field is added to the RECOMMENDED fields of the Agent Identity Document. The trust_tier, verification_path, and owner_id field descriptions now reference the trust-posture loading precedence rule defined in [AGTP-TRUST] (explicit declaration > Genesis- derived fallback > conservative default). The verification_path field description is corrected to include org-asserted as the Tier 2 value (earlier text listed only the three Tier 1 paths). The cross-reference to the Owner-ID response header (Section 5.5.4) is added. These changes document the wire surface and the loading contract that v07-conformant implementations have shipped.¶

7. INSPECT promoted to the protocol-level method floor. The protocol floor expands from twelve methods to thirteen with the addition of INSPECT, a cognitive method that retrieves stored Attribution-Records (by Audit-ID), per-agent chain heads, or lifecycle log entries from the responding server. INSPECT is specified in Section 7.2.4 and registered in the IANA AGTP Method Registry. INSPECT is the standardized lookup interface for Audit-IDs referenced in [AGTP-IDENTIFIERS]: a chain walker that holds an Audit-ID invokes INSPECT target=audit audit_id={hex} to retrieve the underlying JWS and walk the chain by previous_audit_id. The floor count is updated in the protocol-surface descriptions throughout the abstract, terminology, methods section, and IANA Method Registry table.¶

8. role field added to Agent Identity Document. A new RECOMMENDED role field is added to the Agent Identity Document with values agent (default) or merchant. Capability roles ride on the Agent Identity Document rather than the Agent Genesis: identity is permanent (hash-anchored on Genesis), capability is mutable (editable on the Identity Document between server restarts). The merchant value is the normative trigger for PURCHASE counterparty verification per [AGTP-MERCHANT]; future revisions may define additional role values. Implementations encountering an unknown role value MUST treat the agent as the default agent role. AGTP-MERCHANT seriesinfo updated to v02, which retires the v01 Merchant Genesis as a separate document type in favor of this unified model.¶

9. Lifecycle methods promoted to the protocol-level floor. The protocol floor expands from thirteen methods to sixteen with the addition of three Lifecycle methods: ACTIVATE (Section 7.2.14), DEACTIVATE (Section 7.2.15), and REVOKE (Section 7.2.16). The floor is now organized as three groups (Cognitive, Mechanics, Lifecycle) rather than two; the cognitive / mechanics / lifecycle distinction is informational, not normative. The Method Category Taxonomy gains a sixth category, LIFECYCLE, alongside Acquire, Compute, Transact, Communicate, and Orchestrate. The stale paragraph describing ACTIVATE as an optional method extension in a separate companion is withdrawn; ACTIVATE, DEACTIVATE, and REVOKE are core methods that any conformant AGTP implementation MUST support. Each Lifecycle method produces a signed lifecycle event in the agent's per-agent lifecycle stream and the event is retrievable via INSPECT target=lifecycle. The AGTP-LOG seriesinfo is updated to v02, which aligns the event-type triggering methods with the v08 Lifecycle group. Already-target-state transitions are no-ops with 200 OK and a noop: true flag; servers MUST NOT emit duplicate lifecycle events.¶

10. Lifecycle group expanded with REINSTATE and DEPRECATE; Trust-Tier response headers added. The protocol floor expands from sixteen to eighteen with the addition of two further Lifecycle methods: REINSTATE (Section 7.2.17), the explicit reversal path for DEACTIVATE, and DEPRECATE (Section 7.2.18), the controlled end-of-life signal that keeps the agent serving traffic while clients migrate. The Lifecycle group now contains five methods. Three new response headers are added to the Response Headers table: Trust- Tier, Verification-Path, and Trust-Warning, stamped on every response per the trust-posture loading rule in [AGTP-TRUST]. The headers allow relying parties to apply trust-tier-conditional policy on every exchange without consulting the Agent Identity Document. The AgentDocument status enum is updated to the four-state lowercase vocabulary the Lifecycle methods produce: active, suspended, retired, deprecated; the earlier capitalized Pending state and the inconsistent Revoked/retired vocabulary are retired. The AGTP-LOG seriesinfo is updated to v02's revision which finalizes the lifecycle event triggering methods to the eighteen- method floor.¶

11. INSPECT read-access modes and lifecycle-method authorization specified normatively. The INSPECT method definition (Section 7.2.4) now defines three normative read-access modes: public (default, unrestricted reads), agent_only (a caller authenticated as Agent-ID X may read only records whose subject is X), and operator_only (only operator-allowlisted client certificates may read). Access-control failures return 401 Unauthorized for unauthenticated callers and 403 Forbidden for authenticated callers whose identity is not permitted. A new Lifecycle Method Authorization subsection (Section 7.2.19) defines two authorization modes for ACTIVATE, DEACTIVATE, REINSTATE, REVOKE, and DEPRECATE: open (any caller; default for development only) and genesis_issuer (only the registrar whose key issued the agent's Agent Genesis, identified by mTLS certificate public-key fingerprint matching sha256(raw_ed25519_public_key_bytes(Agent_Genesis .issuer_public_key))). Lifecycle authorization failures return 401 / 403 by the same rules as INSPECT. Authorization for reads and writes is independent; operators MAY layer them (e.g., public reads with issuer-only writes). The Agent Genesis schema gains a new MUST-required field issuer_public_key carrying the Ed25519 public key of the signing issuer (32 raw bytes, base64url-encoded); verifiers re-verify signature against this key, and the SHA-256 fingerprint of the raw bytes is the Genesis-issuer fingerprint used for lifecycle-method authorization. The Method Summary table is updated to include 401 and 403 in the primary error codes for INSPECT and all five Lifecycle methods.¶

12. Inline manifest signature on Agent Identity Document. Three new RECOMMENDED fields are added to the Agent Identity Document: manifest_issuer (registrar identifier), manifest_issuer_public_key (Ed25519 public key, base64url), and manifest_signature (detached Ed25519 signature over the canonical document with manifest_signature excluded). Together they form a signed manifest. Conforming AGTP servers MUST verify the signature before serving the document. Verification confirms byte integrity; trust in the issuer key is a deployment policy (trusted-registrars list, CA trust anchors). The earlier stale forward reference to a signature envelope in [AGTP-CERT] is withdrawn — [AGTP-CERT] defines transport-layer cert binding, not a separate Identity Document envelope; inline signature fields fill the gap. The Identity Document Tamper-Proofing section (Section 6.3.5) is rewritten to describe the inline-signature model and to require registrars to strip operator-supplied signature fields before signing, preventing forged issuance. Unsigned manifests remain permitted for development and for deployments using transport-layer cert binding as the sole attestation path; production deployments SHOULD sign.¶

13. DISCOVER built-in surface and lifecycle envelope format normatively settled. Two changes that together finalize the eight-phase build's read-side surface:¶

    (a) DISCOVER built-in endpoints are documented in [AGTP-API] as a path-keyed dispatch surface (DISCOVER /methods, /agents, /genesis, plus the new DISCOVER / directory and the optional /tools and /apis inventories). The reserved-paths rule forbids operator-authored endpoints from shadowing the built-in paths or registering under their first-segment prefixes. The legacy body-keyed DISCOVER target= form is now formally deprecated, with one-shot deprecation warning behavior and 400 Bad Request for path-versus-body conflicts. AGTP-API seriesinfo continues to be tracked from v08 normative refs.¶

    (b) INSPECT target=lifecycle response shape is tightened: each entry carries an explicit format field with value "jws" or "cose" reflecting the envelope used to sign the lifecycle event; servers MAY emit mixed-format streams; the configured envelope is selected by operator policy with jws as default and cose for SCITT-aligned deployments. The Lifecycle method specs are updated to specify that the signed envelope is either JWS Compact per [RFC7515] or COSE_Sign1 per [RFC9943], both normatively conformant. [AGTP-LOG] v02 gains a new Per-Agent Local Lifecycle Stream section specifying the envelope choice, the line-prefix disambiguation rule (jws: vs cose:), and the Audit-ID derivation for each envelope.¶

14. Status codes 461 and 464 assigned. The reserved codes 461 and 464 are assigned meanings to support the Runtime Contract Negotiation Substrate (RCNS) specified in [AGTP-API]: 461 RCNS Contract Available (confirm-first synthesis preview, response body carries a contract preview the caller may accept by re-issuing with the Contract-Synthesized header) and 464 RCNS No Contract (synthesis was attempted but no contract could be delivered, response body carries a structured reason from the vocabulary rcns-disabled, trust-tier-insufficient, composition-impossible, synthesis-error, contract-not-yours, contract-revoked). The reservations are made in this revision so that companion-draft RCNS work can target stable wire signatures; the full substrate specification (delivery modes, dispatcher gate, contract scoping, headers, Attribution-Record extensions) is in [AGTP-API]. Both the in-text status code table and the IANA Status Code Registry table are updated.¶

15. RCNS dispatcher gate, observability, and lifecycle surfaces specified normatively. Three new request headers are added to the Request Headers table: Allow-RCNS (caller opt-in to runtime negotiation), Contract-Synthesized (presentation of a previously- issued contract by synthesis_id), and Idempotency-Key (per-agent idempotency scope). Two new response headers are added: Contract-Synthesized (notification of optimistic-mode RCNS dispatch) and RCNS-Attempt-Id (handle for diagnostic INSPECT). The INSPECT method gains two new targets: target=contract (full record for a synthesized contract by synthesis_id) and target=rcns-attempt (diagnostic detail for failed synthesis attempts; the RCNS-Attempt-Id header on every 464 response names the attempt record). The REVOKE method gains a target=contract subsection (Section 7.2.16.1) for operator and originating-agent contract revocation with rcns_revoke lifecycle event emission. The SUSPEND method gains a synthesis_id parameter subsection (Section 7.2.12.1) for originating-agent self-release with rcns_release event emission. A new Contract-Related Lifecycle Events section (Section 6.5.7) reserves three RCNS event types on the per-agent lifecycle stream: rcns_propose_accepted, rcns_revoke, and rcns_release; these ride the same signed envelope stream as agent-state lifecycle events and are retrievable via INSPECT target=lifecycle. The complete RCNS specification — four-lock dispatcher gate, delivery modes, contract scoping, configuration knobs, observability surfaces — lives in [AGTP-API].¶

16. Method aliases and HTTP gateway sidecar. The Method Policy in [AGTP-API] gains an aliases field declaring a single-hop method-name translation map resolved ahead of catalog matching; the default seed maps the five legacy HTTP verbs to their canonical AGTP counterparts (GET→FETCH, POST→CREATE, PUT→REPLACE, DELETE→REMOVE, PATCH→MODIFY). The original wire method is preserved on the Attribution-Record as requested_method per [AGTP-IDENTIFIERS]. A new HTTP Gateway Sidecar section (Section 8.5) specifies the translation contract for operators deploying a parallel HTTP listener alongside the AGTP daemon: HTTP method runs through the alias map, HTTP path is forwarded verbatim, the AGTP response is finalized through the standard path so attribution and audit chain hold, and Allow-RCNS is MUST-stripped at the gateway so HTTP callers cannot trigger runtime contract negotiation. The gateway is an adoption ramp, not part of the AGTP wire protocol; AGTP servers speaking to each other MUST NOT use the gateway as a transport hop.¶

17. REVOKE target=stale-contracts subsection added; RCNS policy-change sweep wired through. The REVOKE method gains a third parameter set (Section 7.2.16.2) for sweeping contracts whose captured recipe_version has drifted from the current loaded recipe version, pointing at the normative sweep semantics in [AGTP-API]. The Contract-Related Lifecycle Events table is updated: rcns_release is now triggered by either SUSPEND synthesis_id=... (agent self-release) or REVOKE target=stale-contracts (operator-fired eviction). When emitted by the sweep, the event payload MUST carry reason: policy-change-invalidation and the operator's identifier so audit consumers can distinguish operator- fired invalidations from agent self-releases.¶

18. Composition with External Identity Providers specified. A new section (Section 8.6) documents three normative composition patterns for AGTP identity and external IdP credentials: Pattern 1 (AGTP identity only; closed-ecosystem default), Pattern 2 (AGTP identity plus an Authorization header carrying an OAuth bearer, OIDC id_token, or other IdP credential identifying the principal on whose behalf the agent acts), and Pattern 3 (OIDC-federated Genesis-issuer trust; specified in [AGTP-TRUST]). The Authorization request header is added to the request headers table with semantics referencing [RFC9110]. The 401 Unauthorized status code description is extended with a structured reason vocabulary that disambiguates external-credential failures (oauth-required, oauth-invalid) from AGTP-side authentication failures. The composition surface is opt-in via operator policy ([policies. oauth]); servers without OAuth configuration behave identically to pre-revision behavior. The raw Authorization header value and any token it carries MUST NOT appear on the Attribution-Record; only the validated, lifted claim (the acting_principal_id per [AGTP-IDENTIFIERS]) appears, preventing credential disclosure through audit-chain replay.¶

A.2. Wire Format Compatibility

The Agent-ID echo on responses was the deployed behavior in v07-conformant implementations; documenting it is editorial. The Attribution-Record change from "SHOULD when signing configured" to "MUST, with alg: none fallback" expands what v07-conformant servers without a signing key emit on the wire (they previously omitted the header; they now emit an alg: none JWS). v07 clients that ignored unsigned Attribution-Records continue to interoperate; clients that require cryptographic attestation MUST reject alg: none records per the updated security consideration.¶

B.1. Substantive Changes

The following substantive changes were made:¶

1. IANA registrations confirmed. The agtp:// URI scheme is registered under IANA per [RFC7595]; port 4480 is registered under unified service names agtp (TCP/TLS) and agtp-quic (QUIC) per [RFC6335]. The IANA Considerations section (Section 11.1) and Stack Position section now state the registered values rather than "TBD." The pre-publication prohibition language has been removed.¶

2. AGIS deprecated; AGTP-API introduced. The Agentic Grammar and Interface Specification (AGIS) and the previously-proposed Agent Method Grammar (AMG) and AGTP-Methods drafts are deprecated and replaced by a single unified companion specification, AGTP-API [AGTP-API]. AGTP-API consolidates the method catalog, path grammar, endpoint primitive, semantic block, schema validation, server manifest format, per-server method policy (carried as the manifest's policies.methods sub-block), PROPOSE and synthesis semantics, and structural rejection codes (404, 405, 459, 460) into a single document because they describe a single concept: what makes a valid agent-server contract. The Method-Grammar header is removed; servers validate inbound method names against the AGTP-API approved verb list directly. The 454 Grammar Violation status code from earlier draft language is removed; method violations now return 459 (verb not in approved list) or 460 (path violates path grammar). The grammar-validation pathway is replaced by the AGTP-API contract validation pathway.¶

3. Status code renumbering and new contract-level codes. AGTP-specific status codes have been moved out of HTTP-assigned numeric ranges to avoid semantic collision with HTTP status codes that may appear in carried payloads. The mapping from v06: 451 → 455 (Scope Violation), 452 → 456 (Budget Exceeded), 453 → 457 (Zone Violation), 455 → 458 (Counterparty Unverified). New codes added per the AGTP-API contract model: 261 (Negotiation In Progress), 262 (Authorization Required; consolidates PROPOSE-time authorization, missing scope at endpoint dispatch, wildcards refused, and anonymous-discovery blocked), 263 (Proposal Approved), 405 (Method Not Allowed; method+path policy reject), 459 (Method Violation; method not in AGTP-API catalog), 460 (Endpoint Violation; path violates AGTP-API path grammar), 463 (Proposal Rejected). 408 (Timeout) and 410 (Gone) retain their HTTP code numbers and are registered with AGTP-specific semantics. The 461, 462, 464, 465, and 552-555 ranges are reserved for future AGTP expansion.¶

4. Form 1a URI grammar. A new canonical URI form agtp://{agent-id}@{host}[:{port}] (Form 1a) is introduced for direct addressing where the resolver does not yet have a path from canonical Agent-ID to endpoint. The Agent-ID identifies; the hostname is a resolution hint. Form 3 (path-style domain anchored) is retained as a compatibility form but deprioritized for new deployments.¶

5. Port portion of URIs is OPTIONAL. When the port is omitted from any AGTP URI, clients MUST use the IANA-assigned default port 4480.¶

6. Wire-format framing. A new normative subsection (Section 5.4.1) requires explicit Content-Length framing on every AGTP message and prohibits TLS socket-level half-close (shutdown(SHUT_WR)). This addresses a deployment-level gap surfaced by early implementations.¶

7. Agent Manifest Document renamed to Agent Identity Document. The artifact now matches the IANA-registered media type application/vnd.agtp.identity+json. The schema is enumerated in §5.5 with field-by-field semantics: 16 REQUIRED fields, 14 RECOMMENDED fields, and 2 CONDITIONAL fields. The previous v06 schema is preserved in substance; the rename and the explicit field-level enumeration are the changes. The signature field is relocated to an envelope specified in [AGTP-CERT].¶

8. Twelve-method protocol floor. The core method set has been redesigned as a twelve-method floor organized into six cognitive verbs (QUERY, DISCOVER, DESCRIBE, SUMMARIZE, PLAN, PROPOSE) and six mechanics verbs (EXECUTE, DELEGATE, ESCALATE, CONFIRM, SUSPEND, NOTIFY). DISCOVER, PLAN, and EXECUTE are new core methods in v07. The v06 core methods BOOK, SCHEDULE, LEARN, and COLLABORATE are demoted to Tier 2 standard extended methods and are now catalogued in the AGTP-API method catalog ([AGTP-API]) rather than this document. EXECUTE absorbs the role earlier discussed for an INVOKE method: it is the generic carrier for application-layer payloads when higher-level frameworks are composed over AGTP.¶

9. Composition with higher-level frameworks promoted to body text. A new normative section (Section 8) establishes AGTP as a substrate for MCP, A2A, ACP, and ANP carried as content types inside AGTP method invocations. The substrate model, EXECUTE-as-carrier rule, precedence rule between AGTP headers and framework payloads, and canonical mapping table are normative in the body. The pre-existing AGMP composition appendix supplements the body section with worked wire examples.¶

10. Trust score scoping. The trust_score field (renamed from behavioral_trust_score) remains in the Identity Document REQUIRED schema. Computation methodology, freshness requirements, and signature binding are forward-referenced to a new companion specification, AGTP-TRUST [AGTP-TRUST], which will be developed separately.¶

11. .well-known/agtp bootstrap convention. A new subsection under §5.1 specifies that organizations operating an AGTP namespace under a DNS domain SHOULD publish a bootstrap document at https://{domain}/.well-known/agtp per [RFC8615], declaring the organization's AGTP presence, endpoint, and verification anchors.¶

12. Media type alignment. The wire content type has been updated from application/agtp+json to application/vnd.agtp+json (vendor-tree pending standards-tree promotion at RFC publication). The Agent Identity Document uses application/vnd.agtp.identity+json. YAML variants are registered for both.¶

13. Agent Genesis taxonomy clarification. The permanent signed governance-layer origin document that establishes an agent's identity is named "Agent Genesis" throughout the specification. The taxonomy is: Agent Genesis (permanent signed origin document) → canonical Agent-ID (256-bit hash, used in all protocol operations) → Agent Certificate (optional X.509 v3 credential for TLS mutual authentication; see [AGTP-CERT]). The cross-layer relationship between Agent Genesis, canonical Agent-ID, and Agent Certificate has been clarified relative to earlier drafts where the origin document carried a different name.¶

14. Runtime Contract Negotiation Substrate (RCNS) framing. A new section (Section 5.3) makes explicit a property that earlier versions implied but did not name: AGTP fixes the protocol surface at twelve methods and negotiates any additional endpoint surface at runtime via PROPOSE governed by AGTP-API, completing in a single round-trip. The RCNS framing is added to the abstract and to Design Principles. The mechanism (PROPOSE method, AGTP-API contract validation, dynamic endpoint negotiation) was present in v06; v07 names the property and exposes it as a defining characteristic of the protocol.¶

B.2. Wire Format Compatibility

The status code renumbering and the rename from "Agent Manifest Document" to "Agent Identity Document" are wire-format-visible changes from v06. Implementations of v06 will require updates to emit and consume v07 codes and document type identifiers. Implementations following v06 may continue to interoperate with v07 servers that operate in a backward-compatibility mode that recognizes both old and new code numbers, but conformant v07 implementations MUST emit only the v07 codes.¶

B.3. Rationale

The v06 specification was prepared concurrently with IANA filings. v07 closes the loop on those filings (URI scheme, port, media types in evaluation) and propagates the architectural decisions that the filings made permanent. The status code renumbering is conservative: keeping 451 collided with RFC 7725 (Unavailable for Legal Reasons), which is an HTTP code that may legitimately appear in payloads carried over AGTP. The collision was harmless in v06 because no production implementations existed; it would not remain harmless as deployment grows.¶

The twelve-method floor reflects roughly two years of accumulated experience with the v00 through v06 method sets. The cognitive / mechanics organization is informational rather than normative, but provides a stable mental model that constrains future additions to the floor and guides extended-method design. EXECUTE absorbing INVOKE removes a naming ambiguity: EXECUTE is the clearer verb for the operation, and avoiding two methods in the carrier role simplifies composition with higher-level frameworks.¶

D.1. QUERY Request and Response

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

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

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

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

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

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

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

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

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

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

D.3. EXECUTE Carrying an MCP Tool Invocation

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

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

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

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

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

D.4. ESCALATE Request and Response

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

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

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

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

G.1. Wire Example: A2A Task over AGTP

The following example shows an A2A task carried over AGTP DELEGATE. A2A task identity, message, and artifacts ride in the body; AGTP identity, authority, delegation chain, and attribution ride at the wire level.¶

AGTP/1.0 DELEGATE
Agent-ID: agtp://agtp.acme.tld/agents/orchestrator
Authority-Scope: agents:delegate, documents:query
Delegation-Chain: agtp://agtp.acme.tld/agents/orchestrator
Session-ID: sess-a1b2c3d4
Task-ID: task-0099
Content-Type: application/vnd.agtp+json

{
  "method": "DELEGATE",
  "task_id": "task-0099",
  "parameters": {
    "target_agent_id": "agtp://agtp.acme.tld/agents/analyst",
    "authority_scope": "documents:query",
    "delegation_token": "[signed token]",
    "task": {
      "a2a_task_id": "a2a-task-7f3a",
      "message": "Summarize Q1 financial reports",
      "artifacts": []
    }
  }
}

G.2. Wire Example: MCP Resource Fetch over AGTP

The following example shows an MCP resource fetch carried over AGTP QUERY. The fetch is read-only and naturally maps onto QUERY (rather than EXECUTE) because no application-side action is performed.¶

AGTP/1.0 QUERY
Agent-ID: agtp://agtp.acme.tld/agents/assistant
Authority-Scope: documents:query, knowledge:query
Session-ID: sess-mcp-b2c3d4
Task-ID: task-0100
Content-Type: application/vnd.agtp+json

{
  "method": "QUERY",
  "task_id": "task-0100",
  "parameters": {
    "intent": "fetch document corpus for Q1 financial analysis",
    "scope": ["documents:financial"],
    "modality": "mcp.resource",
    "mcp_resource_uri": "mcp://corpus/financial/q1-2026"
  }
}

For an MCP tool-call example using EXECUTE as the dispatch method, see the wire-format examples in Appendix D.¶