]> Nomotic, Inc.

chris@nomotic.ai https://nomotic.ai

Applications and Real-Time Independent Submission AI agents agentic systems protocol agent traffic agent transfer AI agents and agentic systems generate a growing volume of intent-driven, unstructured, and undifferentiated traffic that flows through HTTP indistinguishably from human-initiated requests. HTTP lacks the semantic vocabulary, observability primitives, and identity mechanisms required by agent systems operating at scale. Existing protocols described as "agent protocols" including MCP, ACP, A2A, and ANP, are messaging-layer constructs that presuppose HTTP as their transport. They do not address the underlying transport problem. This document defines the Agent Transfer Protocol (AGTP): a dedicated application-layer protocol for AI agent traffic. AGTP provides agent-native intent methods (QUERY, SUMMARIZE, BOOK, SCHEDULE, LEARN, DELEGATE, COLLABORATE, CONFIRM, ESCALATE, NOTIFY), protocol-level agent identity and authority headers, and a status code vocabulary designed for the conditions AI agent systems encounter. AGTP SHOULD prefer QUIC for new implementations and MUST support TCP/TLS for compatibility and fallback. It is designed to be composable with existing agent frameworks, not to replace them.

Introduction Note Regarding Intellectual Property: Implementers should be aware that extensions and certain mechanisms referenced in this document -- including the Agent Certificate extension (Section 7.2), the ACTIVATE method, the Agent Birth Certificate mechanism (Section 5.7), and the .agent and .nomo file format specifications (Section 2) -- may be subject to pending patent applications by the author. The core AGTP specification is intended for open implementation without royalty obligation. The licensor is prepared to grant a royalty-free license to implementers consistent with . IPR disclosures: https://datatracker.ietf.org/ipr/ -- see also Section 7.7.

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.

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 and HTTP/3 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.

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

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.

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: . That extension may be subject to pending intellectual property claims; see Section 7.7 and the IPR Notice preceding the Abstract. Target audience: AI agent developers, protocol designers, cloud and network infrastructure providers, enterprise security and compliance architects, and standards community participants.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals.

Agent:

An AI software system that executes tasks, makes decisions, and takes actions without continuous human supervision per transaction.

Principal:

The human, organization, or system that authorized an agent to act and is accountable for its actions.

Agent-ID:

A unique identifier for a specific agent instance, present in all AGTP request headers.

Principal-ID:

The identifier of the principal on whose behalf an agent operates.

Authority-Scope:

A declared set of permissions defining what actions an agent is authorized to take, in the format domain:action or domain:*.

Intent Method:

An AGTP method name expressing the agent's purpose, as distinguished from HTTP resource-operation verbs.

Delegation Chain:

An ordered record of Agent-IDs representing the sequence of delegations that produced the current request.

Escalation:

An agent's intentional deferral of a decision or action to a human principal or higher-authority agent.

Attribution Record:

A logged record of an agent action sufficient for audit and compliance purposes.

Session:

An AGTP persistent connection context shared across multiple method invocations within a single agent workflow.

SEP (Scope-Enforcement Point):

An AGTP-aware infrastructure component, load balancer, gateway, and proxy, that enforces Authority-Scope compliance without application-layer access. Requires the Agent Certificate extension ().

Agent Package (.agent):

A portable, open deployment artifact for an AI agent. An .agent file contains an embedded Agent Manifest, an integrity hash covering all package contents, and a behavioral trust score computed at packaging time. The .agent format is an open specification. It is analogous to a container image: a self-describing, portable unit of deployment. The .agent suffix is a file format designator and MUST NOT appear as a hostname component or top-level label in agtp:// URIs. Note: the .agent file format specification may be subject to pending patent claims by the author; see Section 7.7.

Governed Agent Package (.nomo):

A deployment artifact in the .nomo format, which extends the .agent format with a CA-signed certificate chain binding the package to a verified governance zone and issuing principal. The .nomo format is to .agent as HTTPS is to HTTP: the same structural foundation with an added layer of cryptographic trust. A .nomo package is required for agents operating at Trust Tier 1 (see Section 5.2). The .nomo suffix is a file format designator and MUST NOT appear as a hostname component in agtp:// URIs. The name derives from the Greek nomos (νόμος), meaning law, rule, or governance, the same root that underlies autonomy (self-law), nomocracy (rule of law), and onomastics. A .nomo package is literally an agent operating under law: its behavior is bounded by a cryptographically enforced governance context at the packaging layer. Note: the .nomo file format specification may be subject to pending patent claims by the author; see Section 7.7.

Agent Transfer Document (.agtp):

The wire-level manifest document format defined by this specification. An .agtp document is a signed JSON structure containing the fields defined in Section 5.5 (Agent Manifest Document). It is the output format returned by all AGTP URI resolution requests. Both .agent and .nomo packages produce .agtp documents when queried; the .agtp format is the protocol's canonical representation of agent identity and is independent of the underlying packaging format. The .agtp suffix MAY appear in filenames for stored manifest documents but MUST NOT appear in agtp:// URIs. The Content-Type for .agtp documents is application/agtp+json.

URI (AGTP):

An agtp:// scheme URI that identifies an agent or agent namespace. AGTP URIs are addresses, not filenames. File extensions (.agent, .nomo, .agtp) MUST NOT appear in canonical AGTP URIs. See Section 5.1 for the canonical URI forms and resolution semantics.

Agent Namespace Document:

A cryptographically signed application/agtp+json document returned in response to a request targeting an organization's agent registry root (e.g., agtp://acme.tld/agents). Lists all Active agents registered under the organization's governance zone. The document is generated and re-signed by the governance platform on any registry change. It is not a manually editable file. See Section 5.4.

Agent Manifest Document:

A cryptographically signed application/agtp+json document returned in response to a request targeting a specific agent (e.g., agtp://acme.tld/agents/customer-service). Contains the agent's birth certificate fields, lifecycle state, behavioral trust score, authority scope categories, supported methods, and governance zone. Derived directly from the agent's .agent or .nomo package; the package integrity hash is verified before the manifest is served. See Section 5.5.

Agent Birth Certificate:

A cryptographically signed identity document issued to an agent at registration time by a governance platform. The Birth Certificate is the genesis record of an agent's existence: it establishes the agent's identity, ownership, authorized scope, behavioral archetype, and governance zone before the agent takes any action. Authority is issued through the Birth Certificate; it is never self-assumed. The Birth Certificate is the source document from which the Agent Manifest Document (Section 5.5) is derived when an AGTP URI is resolved. The certificate_hash field of the Birth Certificate is the basis for the agent's canonical Agent-ID. In this sense the Birth Certificate functions as the agent's social security number: issued once at creation, permanently bound to the individual, and the authoritative identity record from which all other identity representations derive. Birth Certificate fields map directly to AGTP protocol headers: agent_id maps to the Agent-ID header; owner maps to the Principal-ID header; scope maps to the Authority-Scope header. See Section 5.7. Anonymous agents are ungovernable. Without a Birth Certificate, there is no mechanism to trace decisions to a responsible principal, enforce scope boundaries, or maintain a meaningful audit trail. Note: the Agent Birth Certificate mechanism may be subject to pending patent claims by the author; see Section 7.7.

Governance Token:

A signed, time-limited JWT artifact issued by a governance runtime that encodes a specific governance decision for a specific action. Governance tokens are the runtime companion to the static Birth Certificate: where the Birth Certificate establishes persistent identity, the Governance Token carries a bounded authorization for a single action or session. Tokens carry the governance verdict (ALLOW, DENY), the agent ID, action details, trust score dimensions, issuer identity, and expiry. Default TTL: 30 seconds. Tokens MUST NOT be reused across actions; each action requires a fresh evaluation and a fresh token.

Trust Tier:

A classification assigned to an agent based on the strength of identity verification backing its registration. Tier 1 (Verified): org anchor is a real DNS domain with confirmed ownership and a .nomo governed package. Tier 2 (Org-Asserted): org label is present but DNS ownership is unverified; .agent package acceptable. Tier 3 (Experimental): X- prefix required; not discoverable through the public AGTP registry. See Section 5.2.

Problem Statement AGTP is motivated by three distinct, compounding failures in how current internet infrastructure handles AI agent traffic.

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.

Problem 2: Semantic Mismatch Between Agent Intent and Available Methods AI agents operate on intent. HTTP's method vocabulary was designed to describe operations on resources, not purposeful action. When an agent intends to SUMMARIZE a document, BOOK a resource, and SCHEDULE a sequence, all three arrive as POST requests. The server receives identical verbs with meaningfully different intent buried in request bodies, invisible to any protocol-level handler. AGTP response: a vocabulary of agent-native methods that express intent at the protocol level.

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.

Problem Summary # Problem Current Failure AGTP Response 1 Undifferentiated traffic HTTP cannot separate agent traffic Dedicated protocol environment 2 Semantic mismatch HTTP verbs obscure agent intent Native intent-based method vocabulary 3 No protocol-level identity Attribution is untraceable Agent identity and scope in headers

Related Work and Existing Approaches

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.

Existing Agent Protocols

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 (Agent Communication Protocol, IBM):

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

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

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

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.

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 :

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.

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.

AGTP Positioning: The Proposed Stack

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.

Protocol Overview

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 for new deployments (lower latency, multiplexing without head-of-line blocking, 0-RTT connection establishment). MUST support TCP/TLS as a fallback for compatibility with existing infrastructure. MAY run over UDP where QUIC is not available, subject to implementor-defined reliability guarantees. Suggested port assignment (subject to IANA assignment. See Section 8): AGTP/QUIC: port 8443 (proposed) AGTP/TCP+TLS: port 8080 (proposed)

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.

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.

Header Format

Request Headers Field Required Description AGTP-Version MUST Protocol version. Current: AGTP/1.0 AGTP-Method MUST The agent intent method (see Section 6) Agent-ID MUST Opaque identifier for the requesting agent instance Principal-ID MUST Identifier of the human or system that authorized this agent Authority-Scope MUST Declared scope of actions this agent is authorized to take Session-ID SHOULD Identifies the current task/workflow context Task-ID SHOULD Unique identifier for this specific method invocation Delegation-Chain MAY Ordered list of Agent-IDs if this request was delegated Priority MAY Request priority hint: critical, normal, background TTL MAY Maximum acceptable response latency in milliseconds

Response Headers Field Required Description AGTP-Version MUST Protocol version AGTP-Status MUST Numeric status code (see Section 5.5) Task-ID MUST Echo of request Task-ID for correlation Server-Agent-ID SHOULD Identity of the responding server or agent Attribution-Record SHOULD Signed record of the action taken, for audit Continuation-Token MAY Token for retrieving additional results in streaming contexts Supported-Methods SHOULD (on session open) List of AGTP methods supported by this server

Status Codes AGTP defines its own status code space. Codes 451, 550, and 551 are AGTP-specific with no HTTP equivalent and are registered in the IANA AGTP Status Code Registry (see Section 8.3). Code Name Meaning 200 OK Method executed successfully 202 Accepted Method accepted; execution is asynchronous 204 No Content Method executed; no response body 400 Bad Request Malformed AGTP request 401 Unauthorized Agent-ID not recognized or not authenticated 403 Forbidden Agent lacks authority for requested action per Authority-Scope 404 Not Found Target resource or agent not found 408 Timeout TTL exceeded before method could execute 409 Conflict Method conflicts with current state (e.g., BOOK on unavailable resource) 410 Gone Agent has been Revoked or Deprecated; canonical ID is permanently retired 422 Unprocessable Request well-formed but semantically invalid 429 Rate Limited Agent is exceeding permitted request frequency 451 Scope Violation Requested action is outside declared Authority-Scope. AGTP-specific 500 Server Error Internal failure in the responding system 503 Unavailable Responding agent or system temporarily unavailable or Suspended 550 Delegation Failure A delegated sub-agent failed to complete the requested action. AGTP-specific 551 Authority Chain Broken Delegation chain contains an unverifiable or broken identity link. AGTP-specific Status code 451 (Scope Violation) is a governance signal: the agent attempted an action outside its declared Authority-Scope, caught at the protocol level. Status code 551 (Authority Chain Broken) indicates that one or more Agent-ID entries in the Delegation-Chain header cannot be verified as part of a valid delegation sequence. Status code 410 (Gone) is returned when an agent's Birth Certificate has been revoked or the agent deprecated; the canonical Agent-ID is permanently retired and MUST NOT be retried. All three are operational signals, not protocol errors, and MUST be logged for audit purposes.

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

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

And for all AGTP response bodies:

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

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

Implementers wishing to experiment before the formal IANA port assignment may use port 8443 (AGTP/QUIC) and port 8080 (AGTP/TCP+TLS) as working values. These values are subject to change upon final IANA assignment. The ACTIVATE method extension, which binds .nomo governed agent packages to AGTP as a first-class activation operation, is described in a companion document and is implemented as an optional extension. Core AGTP implementations need not support ACTIVATE to be compliant with this specification.

Agent Identity, URI Structure, and Registration

URI Structure and Resolution Mechanics

Foundational Principle AGTP URIs are addresses, not filenames. File format suffixes (.agent, .nomo, .agtp) MUST NOT appear in canonical agtp:// URIs. A URI resolves to an Agent Manifest Document or Agent Namespace Document derived from the underlying package; it does not expose or serve the package itself. Implementations MUST treat any URI containing a file extension in the path as non-canonical and SHOULD issue a 301 Moved Permanently redirect to the canonical form prior to resolution. The Canonical Agent-ID (256-bit cryptographic identifier) remains the authoritative identifier in all AGTP protocol operations. Human- readable URIs are aliases that resolve to a canonical identifier. In the event of any conflict between a human-readable URI and a canonical Agent-ID, the canonical Agent-ID MUST be treated as authoritative.

Canonical URI Forms AGTP defines the following canonical URI forms:

The following URI forms are explicitly invalid and MUST return 400 Bad Request with error code invalid-uri-form:

Note: .agent is claimed as a Web3 top-level domain by at least one blockchain naming system. URI forms that place .agent or .nomo in the hostname position are prohibited both for collision avoidance with Web3 naming systems and because they imply domain ownership without enforcing it. See Section 5.6 for Web3 guidance.

Non-Canonical Forms and Redirect Behavior The following non-canonical forms SHOULD be redirected to their canonical equivalents. Implementations MUST NOT serve package contents in response to any URI form. Received URI Canonical Redirect Target agtp://acme.tld/agents/customer-service.agent agtp://acme.tld/agents/customer-service agtp://acme.tld/agents/customer-service.nomo agtp://acme.tld/agents/customer-service agtp://acme.tld/agents/customer-service.agtp agtp://acme.tld/agents/customer-service

Query Parameters for Format Selection All AGTP URI resolution requests accept an optional format query parameter controlling the serialization of the returned document. Query Parameter Returned Representation (none) Agent Manifest Document, human-readable application/agtp+json ?format=manifest Agent Manifest Document, human-readable application/agtp+json ?format=json Agent Manifest Document, compact application/agtp+json ?format=certificate Birth certificate fields only, application/agtp+json ?format=status Lifecycle state and operational status only, application/agtp+json All format variants return signed application/agtp+json content. The ?format=json parameter is intended for programmatic consumers. The default returns the full human-readable manifest suitable for browser rendering by an AGTP-aware client.

Resolution Mechanics When an AGTP server receives a request targeting an agent URI, it MUST perform the following steps in order: Parse and validate the URI. If the URI is an invalid (prohibited) form, return 400 Bad Request with error code invalid-uri-form. Resolve the agent label to a canonical Agent-ID via the governance platform's registry lookup. If no matching agent is found, return 404 Not Found. Verify the registry record lifecycle state. If the agent is Suspended, return 503 Service Unavailable with lifecycle state in the response body. If the agent is Revoked or Deprecated, return 410 Gone with lifecycle state and revocation timestamp. Retrieve the agent's package (.agent or .nomo) from the package store. Verify the package integrity hash before proceeding. If integrity verification fails, return 500 Internal Error with error code package-integrity-failure. MUST be logged. Extract the embedded manifest from the verified package. Sign the manifest document using the governance platform's signing key. Return the signed application/agtp+json document in the format specified by the query parameter. The package's executable content, code, logic, and any fields not included in the manifest schema MUST NOT be returned at any step. URI resolution exposes identity and status exclusively.

Domain Anchor and Trust Tier Assignment The org anchor in a domain-anchored URI (Form 2 or Form 3) MUST be validated at registration time to determine the agent's Trust Tier.

Trust Tier 1 - Verified (DNS-anchored):

The org domain is validated by DNS challenge at ACTIVATE time per . The governance platform MUST verify that the registering party controls the DNS zone for the claimed domain before issuing a Tier 1 Birth Certificate. Requires a .nomo governed package. Trust Tier 1 agents MUST have the following DNS record published and verifiable at resolution time:

Trust Tier 2 - Org-Asserted:

The org label is present in the URI but DNS ownership has not been verified. An .agent package is acceptable. The Agent Manifest Document for Tier 2 agents MUST include a prominent trust_tier: 2 field and a trust_warning field with value "org-label-unverified". AGTP-aware browsers and clients MUST surface a visible trust indicator distinguishing Tier 2 from Tier 1. Tier 2 agents MUST NOT be granted authority scopes above documents:query and knowledge:query without AGTP-CERT cryptographic identity binding.

Trust Tier 3 - Experimental:

Agent label uses the X- prefix. Not discoverable through the public AGTP registry. For development and testing only. Implementations MUST NOT deploy Tier 3 agents in production.

Subdomain Deployment Pattern Organizations SHOULD deploy AGTP endpoints at a dedicated subdomain following the pattern agtp.[organization-domain.tld] (e.g., agtp.acme.tld). This is the recommended enterprise deployment pattern: it provides clean separation between web and agent infrastructure, allows independent certificate management for the AGTP endpoint, and is consistent with service-specific subdomain conventions. An organization with an AGTP subdomain SHOULD also configure their primary domain to redirect AGTP requests:

The /agents/ Reserved Path Prefix The path prefix /agents/ is reserved in all agtp:// URIs for agent namespace operations. Implementations MUST support this prefix. The registry root at /agents (no trailing label) resolves to the Agent Namespace Document (see Section 5.4).

Collision Prevention agtp://acme.tld/agents/customer-service and agtp://chrishood.tld/agents/customer-service are distinct and non-colliding because the domain component is the trust root. No two agents can share a canonical URI if their org domains differ. Within a single org domain, the governance platform enforces uniqueness of agent labels at registration time. Infrastructure MUST use the canonical Agent-ID for all routing, logging, and attribution operations. Human-readable URIs are a display and discovery layer only.

IANA Considerations for the agtp:// URI Scheme This document proposes registration of the agtp:// URI scheme with IANA per . Registration template:

URI scheme name:

agtp

Status:

Permanent

URI scheme syntax:

agtp://[canonical-agent-id] or agtp://[domain.tld]/agents/[label]

URI scheme semantics:

Identifies an AI agent or agent namespace operating over the Agent Transfer Protocol. The canonical form uses a 256-bit hex-encoded cryptographic identifier derived from the agent's Birth Certificate. The domain-anchored form uses a verified or asserted organization domain with a reserved /agents/ path prefix.

Applications/protocols that use this URI scheme:

Agent Transfer Protocol (this document)

Interoperability considerations:

Domain-anchored URIs are the recommended human-readable form. Implementations MUST accept canonical identifiers and SHOULD support domain-anchored resolution. File extensions MUST NOT appear in agtp:// URIs.

Contact:

Chris Hood, chris@nomotic.ai

References:

This document

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

Trust Tier Summary Trust Tier Verification Package Required DNS Record Required Registry Visible 1 - Verified DNS challenge per .nomo Yes (_agtp TXT) Yes 2 - Org-Asserted None .agent or .nomo No Yes (with warning) 3 - Experimental None Any No No

Agent Namespace Document

Purpose and Scope The Agent Namespace Document is the index of all Active agents registered under an organization's governance zone. It is returned in response to a request targeting the /agents path:

The Agent Namespace Document is not a manually editable file. It is generated and cryptographically signed by the governance platform each time the registry changes. Any Namespace Document that fails signature verification MUST be rejected by the requesting party.

Document Schema

The agents array MUST include only agents in Active lifecycle state. Suspended, Revoked, and Deprecated agents MUST NOT appear in the Namespace Document.

Integrity and Freshness The Namespace Document MUST include a generated_at timestamp. Implementations SHOULD treat Namespace Documents older than a configurable freshness threshold (default: 300 seconds) as stale and re-request. The governance platform MUST re-sign the Namespace Document within 60 seconds of any registry change. The signature covers the entire document including generated_at. Replaying an older signed Namespace Document to conceal a revocation event is a known attack vector; implementations MUST reject Namespace Documents with a generated_at timestamp older than the freshness threshold.

Agent Manifest Document and the .agtp Format

Purpose and Scope The Agent Manifest Document is the protocol's canonical representation of a specific agent's identity, status, and behavioral scope. It is returned in response to any AGTP URI resolution request targeting a specific agent:

The manifest is derived from the embedded manifest inside the agent's .agent or .nomo package. It is not a separate file that can be independently modified. The governance platform MUST verify the package integrity hash before extracting and serving the manifest.

The Three Document Formats and Their Relationship

The .agtp format is the protocol's own document type. It is what gets transmitted over the wire. The .agent and .nomo formats are what get deployed. An AGTP implementation is not required to understand .agent or .nomo packaging internals; it is only required to produce and consume .agtp manifest documents. Additional packaging formats MAY be defined by third parties, provided they can produce conformant .agtp manifest documents when queried. Such formats MUST implement the integrity verification requirement: the manifest MUST be derived from a verified package, not from an independently stored or editable file.

Agent Manifest Document Schema The following fields are REQUIRED in all Agent Manifest Documents:

The following fields are RECOMMENDED:

The following fields are REQUIRED when trust_tier is 2:

What the Manifest Exposes and Does Not Expose The Agent Manifest Document MUST expose: The agent's identity (canonical ID, label, org, governance zone) The agent's current operational status (lifecycle state) The agent's authority scope categories The agent's supported method vocabulary The agent's behavioral trust score The agent's birth certificate fields (activated_at, principal_org) The agent's trust tier and any associated trust warnings The Agent Manifest Document MUST NOT expose: Executable code, scripts, or logic Model weights or configurations Internal API keys or credentials Specific authority scope grant tokens Session history or prior action logs No AGTP URI resolution path, including any query parameter combination, MUST return package contents beyond the manifest schema defined in this section.

Manifest Tamper-Proofing The tamper-proof guarantee rests on two mechanisms: Package integrity hash: Any modification to the package or its embedded manifest invalidates the hash. The governance platform MUST verify this hash before extracting the manifest. Document signature: The governance platform signs the extracted manifest before serving it. The signature covers the full document including the package_integrity_hash field, creating a verifiable chain from the served document back to the registered package. A manifest document that fails either verification step MUST be rejected, MUST NOT be served, and the failure MUST be logged.

Browser and Human-Facing Interaction Model

The Separation of Discovery and Execution

The analogy to existing protocol conventions is direct. A mailto: URI surfaces an address and hands off to a mail client; SMTP carries the actual messages. Similarly, an agtp:// URI surfaces identity and status; AGTP carries agent traffic. Browsers do not become AGTP clients by following an agtp:// link.

Browser Behavior for agtp:// URIs Browsers that encounter an agtp:// URI SHOULD behave as follows: If a registered AGTP client is present (OS protocol handler), hand off the URI to that client. If the browser supports agtp:// natively or via extension, render the returned Agent Manifest Document as a structured human-readable page. The rendered view MUST surface the trust tier indicator prominently, following the visual convention established for TLS trust in the browser chrome. If neither condition applies, the browser MAY fall back to a gateway that translates between https:// and agtp://. The gateway MUST preserve all signature and trust tier fields.

Human-Readable Manifest View When an Agent Manifest Document is rendered for human consumption, the following fields MUST be prominently displayed: Agent label and org domain Trust tier indicator (visual distinction between Tier 1, 2, and 3) Lifecycle state (Active / Suspended / Revoked / Deprecated) Job description Principal organization Activation date Behavioral trust score Authority scope categories (in human-readable form)

AGTP Status Sub-Resource Implementations SHOULD support a status sub-path:

The active_session_count field SHOULD only be included if the requester has appropriate observability permissions for the governance zone.

Web3 Interaction Considerations

The .agent TLD Collision The string .agent is claimed as a Web3 top-level domain by at least one blockchain-based naming system. This creates an ambiguity risk: a URI of the form agtp://customer-service.agent could be interpreted as either an AGTP agent namespace or a Web3 name resolution request. This specification explicitly prohibits .agent and .nomo from appearing in the hostname position of agtp:// URIs (see Section 5.1).

Web3 Trust Anchors AGTP's default trust model is PKI-based: X.509 certificates, DNS ownership verification, and CA-anchored identity. Web3 naming systems provide an alternative identity model based on blockchain address ownership. A full Web3 interoperability specification is out of scope for this document. The following framework MAY be used by implementations wishing to bridge Web3 and AGTP identity. The resolution_layer field in the Agent Manifest Document declares the identity anchoring mechanism used for the agent's registration: Value Meaning dns Standard DNS ownership verification (default) pki PKI certificate chain without DNS challenge web3-ens Ethereum Name Service web3-unstoppable Unstoppable Domains agtp-registry Direct registration with AGTP governance platform Implementations that encounter a resolution_layer value of web3-ens or web3-unstoppable MUST treat the agent as Trust Tier 2 (Org-Asserted) unless a formal AGTP-Web3 Bridge specification has been published and implemented. Full Web3 interoperability is addressed in a future companion document .

Agent Registration Process

Overview An agent cannot participate in AGTP until it has been issued an Agent Birth Certificate by a governance platform and assigned a canonical Agent-ID derived from that certificate. Canonical Agent-IDs are issued through the ACTIVATE transaction; they are never self-declared. The Birth Certificate is the genesis record of an agent's legal existence within the AGTP ecosystem. Its relationship to the canonical Agent-ID is analogous to the relationship between a government-issued birth registration and a social security number: the birth event produces a permanent, authoritative identity record, and a durable identifier is derived from it. The identifier follows the agent for its entire lifecycle, including after revocation. It is never reissued to another agent. Any AGTP infrastructure component MUST reject requests carrying an Agent-ID that does not resolve to a Birth Certificate record in an Active lifecycle state in a reachable registry.

Birth Certificate Contents The Agent Birth Certificate is issued by the governance platform at ACTIVATE time and contains the following fields: Field Required Description agent_id MUST Unique identifier for the agent owner MUST Human or team responsible for this agent archetype MUST Behavioral category (see archetypes below) governance_zone MUST Environment context (development, staging, production) scope MUST Authorized action types issued_at MUST Timestamp of issuance certificate_hash MUST Cryptographic fingerprint - basis for canonical Agent-ID signature MUST Signed with the org's governance key package_ref SHOULD Reference to the .agent or .nomo package trust_tier MUST Registration tier (1, 2, or 3) org_domain MUST The verified or asserted org domain

Agent Archetypes The archetype field classifies the agent's behavioral category. Archetypes inform scope enforcement and observability tooling; an executor archetype agent exhibiting read-only query patterns, or a monitor archetype agent attempting booking operations, are anomaly signals. The archetype field does not restrict scope enforcement, Authority-Scope headers govern actual permissions at the protocol level. Archetypes are a classification and observability signal, not a security boundary. Archetype Description Typical Scope assistant Conversational agent, read-heavy documents:query, knowledge:query analyst Data analysis, read and aggregate data:read, data:aggregate executor Takes real-world actions, write-heavy booking:*, payments:confirm orchestrator Manages other agents delegation:*, agents:* monitor Observational only telemetry:read, logs:read

Birth Certificate to AGTP Header Mapping Birth Certificate fields map directly to AGTP protocol headers on every request. This mapping is the mechanism by which static identity (the Birth Certificate) becomes runtime identity (the protocol session): Birth Certificate Field AGTP Protocol Header agent_id Agent-ID owner Principal-ID scope Authority-Scope certificate_hash Basis for canonical Agent-ID The canonical Agent-ID is derived from the certificate_hash. This chain, package integrity hash → certificate hash → canonical Agent-ID, ensures that the identifier carried in the Agent-ID header on every AGTP request is traceable back to the original Birth Certificate and the human principal who authorized the agent's creation.

Registration Tiers Tier 1 Registration (Verified, DNS-anchored): Required for agents carrying Authority-Scope beyond read-only query operations, or participating in delegation chains, financial transactions, or multi-agent collaboration with external organizations.

Requirements:

Registrant demonstrates DNS control over the claimed org_domain via DNS challenge per Agent package must be in .nomo governed format Package must include a valid CA-signed certificate chain Governance platform issues Birth Certificate and canonical Agent-ID after verifying DNS challenge and validating the package cert chain

Tier 2 Registration (Org-Asserted): For agents operating within a single organization's internal infrastructure, or where DNS verification is not yet completed.

Requirements:

Org label is declared but DNS ownership is not verified Agent package may be .agent or .nomo format Governance platform issues Birth Certificate after validating package integrity hash Birth Certificate and Manifest MUST include trust_tier: 2 and trust_warning: "org-label-unverified" Authority scope MUST be restricted at the SEP layer until upgraded to Tier 1

Tier 3 Registration (Experimental): For development and testing environments only.

Requirements:

Agent label MUST carry X- prefix Not published to the public AGTP registry MUST NOT be deployed in production environments Governance platform issues a locally-scoped Birth Certificate

Registration Lifecycle

Governance Tokens and Runtime Authorization Following successful registration, the agent's Birth Certificate is the static identity anchor. Runtime authorization for specific actions is carried by Governance Tokens: signed, time-limited JWT artifacts issued by the governance platform encoding a specific governance verdict (ALLOW, DENY) for a specific action. Governance Tokens MUST NOT be reused. Each action requires a fresh evaluation and a fresh token. Default TTL is 30 seconds. The token's agent_id field MUST match the canonical Agent-ID from the Birth Certificate. Tokens that fail this validation MUST be rejected and the failure MUST be logged. The relationship between Birth Certificate and Governance Token parallels the relationship between a passport and a visa: the passport establishes persistent identity; the visa encodes a specific time-bounded permission. Holding a passport does not imply holding any particular visa.

Friendly Name Availability and Re-Registration An agent label becomes available for re-registration 90 days after its associated agent enters Revoked or Deprecated lifecycle state. The canonical Agent-ID and Birth Certificate are permanently archived. The canonical Agent-ID MUST NOT be reissued under any circumstances, including re-registration of the same label by the same organization. This policy prevents ID reuse attacks in which a newly registered agent inherits the trust history of a revoked predecessor.

Method Definitions

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 .

Core Methods

QUERY Purpose: Semantic data retrieval. The agent specifies what it needs to know, not where to find it. Distinguished from HTTP GET by expressing an information need rather than retrieving a known resource at a known location. Parameter Required Description intent MUST Natural language or structured expression of the information need scope SHOULD Data domains or sources to include or exclude format MAY Desired response format: structured, natural, raw confidence_threshold MAY Minimum confidence score for included results (0.0-1.0) context MAY Session context for disambiguation Response: Result set with confidence scores per item. Server SHOULD indicate provenance of each result. Idempotent: Yes.

SUMMARIZE Purpose: Request a concise synthesis of provided content or a referenced resource. The agent is requesting a cognitive operation on data, not retrieving data. Parameter Required Description source MUST Content inline (up to implementation limit) or URI reference length SHOULD Target summary length: brief, standard, detailed focus MAY Aspect to emphasize in the summary format MAY Output format: bullets, prose, structured audience MAY Intended reader context, for calibrating complexity Response: Summary content with a source_hash and a confidence score. Idempotent: Yes.

BOOK Purpose: Reserve a resource, time slot, seat, or allocation on behalf of the agent's principal. State-modifying. Notable error codes: 409 Conflict (resource unavailable), 451 Scope Violation (principal not authorized for this resource type). Parameter Required Description resource_id MUST Identifier of the resource to reserve principal_id MUST The human or system on whose behalf the booking is made time_slot MUST (if time-based) ISO 8601 datetime or range quantity MAY Number of units to reserve options MAY Resource-specific booking parameters confirm_immediately MAY Boolean; if false, creates a hold pending confirmation Response: Booking confirmation with booking_id, status (confirmed / held), and expiry timestamp if a hold. Idempotent: No.

SCHEDULE Purpose: Define a sequence of actions, method calls, or events to be executed at specified times or in response to specified triggers. Creates a durable plan, not an immediate execution. Parameter Required Description steps MUST Ordered list of AGTP method calls with parameters trigger MUST immediate, datetime, event, or condition trigger_value MUST (if not immediate) Datetime, event name, or condition expression on_failure SHOULD Behavior on step failure: abort, skip, retry, escalate notify MAY Notification targets on completion or failure Response: Schedule record with schedule_id, confirmed steps, and next execution timestamp. Idempotent: No.

LEARN Purpose: Update the agent's session context, knowledge state, or persistent memory. An explicit context write where the agent asserts that something should be retained. Parameter Required Description content MUST Information to be learned (structured or unstructured) scope MUST session (ephemeral), principal (persists for principal), global (shared) category SHOULD Semantic category for retrieval optimization confidence MAY Agent's confidence in the content (0.0-1.0) source MAY Provenance of the learned content ttl MAY Expiry for the learned content Response: Confirmation with learn_id and effective scope. Idempotent: No.

DELEGATE Purpose: Transfer execution of a task or method to a sub-agent or downstream system. Initiates a new AGTP session on behalf of the delegating agent, carrying forward authority lineage. Parameter Required Description target_agent_id MUST Identifier of the agent to delegate to task MUST AGTP method call (or sequence) to execute authority_scope MUST Scope granted to sub-agent MUST be a strict subset of delegating agent's scope delegation_token MUST Signed token proving delegation authority callback SHOULD AGTP endpoint for result delivery deadline MAY Maximum time for task completion Security note: the authority_scope in a DELEGATE request MUST NOT exceed the delegating agent's own Authority-Scope. Servers MUST enforce this and MUST return 451 Scope Violation if violated. This is the protocol-level defense against authority laundering. Idempotent: No.

COLLABORATE Purpose: Initiate a multi-agent coordinated task where two or more agents work in parallel or in defined roles toward a shared goal. Unlike DELEGATE (hierarchical), COLLABORATE is peer-to-peer. Parameter Required Description collaborators MUST List of Agent-IDs invited to collaborate objective MUST Shared goal expressed as a task description or structured specification role_assignments SHOULD Map of Agent-IDs to roles within the collaboration coordination_model SHOULD parallel, sequential, or consensus result_aggregation MAY How results from collaborators are combined Response: Collaboration session receipt with collaboration_id. Each collaborator receives an AGTP NOTIFY to join. Idempotent: No.

CONFIRM Purpose: Explicit acknowledgment of a prior action, state, or data item. Creates a signed attestation record. Parameter Required Description target_id MUST ID of the action, booking, schedule, or item being confirmed status MUST accepted, rejected, or deferred reason SHOULD (if rejected/deferred) Explanation of the decision attestation MAY Agent-signed confirmation payload for audit Response: Confirmation receipt with timestamp and attestation_id. Idempotent: Yes.

ESCALATE Purpose: Route a task, decision, or exception to a human principal or higher-authority agent when the current agent cannot or should not proceed. ESCALATE is the protocol-level expression of meaningful friction in AI systems as a first-class method. Parameter Required Description task_id MUST The task or method invocation triggering escalation reason MUST Structured reason: confidence_threshold, scope_limit, ethical_flag, ambiguous_instruction, resource_unavailable context MUST Full context needed for the escalation recipient to act priority SHOULD urgent, normal, or low recipient MAY Specific human or agent to escalate to; if absent, routes to default handler deadline MAY Time by which a response is needed Response: Escalation receipt with escalation_id and routing confirmation. The escalated task is paused until resolved via CONFIRM. Idempotent: Yes. An agent that escalates appropriately is functioning correctly. Governance frameworks built on AGTP can use escalation frequency and reason codes as observability signals for systemic issues.

NOTIFY Purpose: Asynchronous push of information from an agent to a recipient. Does not expect a response. Fire-and-forget. Delivery confirmation (if required) returned via a subsequent CONFIRM from the recipient. Parameter Required Description recipient MUST Target Agent-ID, human endpoint, or broadcast group content MUST Notification payload urgency SHOULD critical, informational, or background delivery_guarantee MAY at_most_once, at_least_once, or exactly_once expiry MAY Timestamp after which the notification should not be delivered Response: Delivery receipt with notification_id. Idempotent: No.

Method Summary Table Method Intent State-Modifying Idempotent Primary Error Codes QUERY Retrieve information No Yes 404, 422 SUMMARIZE Synthesize content No Yes 400, 422 BOOK Reserve a resource Yes No 409, 451 SCHEDULE Plan future actions Yes No 400, 409 LEARN Update agent context Yes No 400, 403 DELEGATE Transfer task to sub-agent Yes No 403, 451, 551 COLLABORATE Coordinate peer agents Yes No 404, 403 CONFIRM Attest to a prior action Yes Yes 404, 400 ESCALATE Defer to human/authority Yes Yes 404 NOTIFY Push information No No 400, 404

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: Have a unique uppercase ASCII name Define required and optional parameters Define expected response structure Specify idempotency behavior Specify applicable error codes Include a security considerations section Be accompanied by a published reference specification (Internet-Draft or RFC) Experimental methods MAY be used prior to registration using the X- prefix convention (e.g., X-NEGOTIATE). Experimental methods MUST NOT be used in production deployments without registration. Capability negotiation occurs during session establishment. The server returns a Supported-Methods header listing the methods it implements. Clients SHOULD check this list before invoking non-core methods.

Extended Method Vocabulary and Industry Profiles

Three-Tier Method Architecture The AGTP method vocabulary is organized into three tiers reflecting different levels of universality, specificity, and domain relevance.

Tier 1. Core Methods (defined in Section 6.2):

The baseline vocabulary required for AGTP compliance. Every conformant AGTP implementation MUST support all Tier 1 methods.

Tier 2. Standard Extended Methods:

Registered in the IANA AGTP Method Registry and available for use in any AGTP implementation. Not required for baseline compliance but SHOULD be implemented where their semantics apply. Defined in .

Tier 3. Industry Profile Methods:

Domain-specific method sets defined and registered by industry communities as named AGTP profiles. Valid within deployments that declare support for the relevant profile. Not required in general-purpose implementations.

Method Category Taxonomy All AGTP methods are organized into five categories:

ACQUIRE:

Retrieve data, resources, or state without modifying it. Typically idempotent; no state modification.

COMPUTE:

Process, transform, or analyze information and produce a derived result. Typically idempotent given the same input.

TRANSACT:

Perform state-changing operations with external systems, resources, or records. Not idempotent by default; subject to reversibility classification.

COMMUNICATE:

Send information, notifications, or signals to recipients. Fire-and- forget or confirm-receipt delivery models.

ORCHESTRATE:

Coordinate, sequence, or manage multiple agents, tasks, or workflows. May spawn sub-agents or sessions; delegation chain semantics apply.

Core Method Category QUERY Acquire SUMMARIZE Compute BOOK Transact SCHEDULE Orchestrate LEARN Compute DELEGATE Orchestrate COLLABORATE Orchestrate CONFIRM Transact ESCALATE Orchestrate NOTIFY Communicate

Standard Extended Methods (Tier 2) The following methods constitute the initial Tier 2 registration set, defined in . Listed here by category with brief semantic definitions; full parameter specifications are in the companion document. ACQUIRE category: FETCH, SEARCH, SCAN, PULL, IMPORT, FIND. COMPUTE category: EXTRACT, FILTER, VALIDATE, TRANSFORM, TRANSLATE, NORMALIZE, PREDICT, RANK, MAP. TRANSACT category: REGISTER, SUBMIT, TRANSFER, PURCHASE, SIGN, MERGE, LINK, LOG, SYNC, PUBLISH. COMMUNICATE category: REPLY, SEND, REPORT. ORCHESTRATE category: MONITOR, ROUTE, RETRY, PAUSE, RESUME, RUN, CHECK. Notable constraints: PURCHASE MUST carry explicit principal_id and scope enforcement; 451 Scope Violation applies if payments:purchase is not in the agent's Authority-Scope. RUN requires explicit procedure_id parameter; implementations MUST NOT accept free-form execution strings.

Short-Form and Industry-Inspired Methods A set of short-form verb methods, e.g., SET, TAKE, OPEN, START, CALL, MAKE, TURN, BREAK, are provisionally catalogued as candidates for Tier 2 registration. These verbs are highly context-dependent and their semantics vary significantly across deployment domains. Short-form methods will be registered individually only when a published companion specification provides unambiguous semantic definitions demonstrably distinct from existing registered methods. Provisional registrations using the X- prefix (e.g., X-SET, X-CALL) are encouraged during the experimentation period.

Industry Profile Method Sets AGTP recognizes that specific industries require method vocabularies reflecting domain-specific operations that would be inappropriate in a general-purpose standard. Industry profile method sets are defined and registered as named AGTP profiles. A profile is a published companion specification that: Declares a profile name (e.g., agtp-profile-healthcare, agtp-profile-financial, agtp-profile-legaltech) Defines one or more industry-specific methods with full parameter specifications, error codes, and security considerations Specifies which Tier 1 and Tier 2 methods are REQUIRED, RECOMMENDED, or NOT APPLICABLE within the profile Addresses regulatory or compliance considerations specific to the domain (e.g., HIPAA for healthcare, PCI-DSS for financial services) Illustrative examples of potential industry profile methods (not yet registered; listed for directional purposes only): Healthcare: PRESCRIBE, AUTHORIZE, REFER, DISPENSE, TRIAGE, CONSENT, REDACT Financial services: SETTLE, RECONCILE, HEDGE, CLEAR, UNDERWRITE, KYC, AML Legal and compliance: ATTEST, NOTARIZE, DISCLOSE, REDLINE, EXECUTE, PRESERVE Infrastructure: PROVISION, DEPROVISION, ROLLBACK, SNAPSHOT, FAILOVER Industry communities are encouraged to develop and submit profile specifications through the IETF process. The IANA AGTP Method Registry will maintain a profile index alongside the core and standard method registries.

Registration Path for New Methods

For Tier 2 Standard Methods:

Submit an Internet-Draft to the IETF providing full method specification per Section 6.4. The Designated Expert reviews for semantic uniqueness, clarity, and security considerations.

For Industry Profile Methods:

Submit a profile specification to the IETF (or a recognized domain standards body with an established AGTP registry liaison) covering all methods in the profile and profile compliance requirements.

For Experimental Methods:

Use the X- prefix without registration. Implementations MUST NOT deploy experimental methods in production without completing the registration process. Experimental method names do not reserve the unprefixed name.

The AGTP Method Registry is published at: https://www.iana.org/assignments/agtp-methods/

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

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 . Servers MUST present a valid certificate.

Agent Identity Headers and Agent Certificate Extension Every AGTP request MUST include Agent-ID and Principal-ID header fields. In the base specification, these fields are not cryptographically authenticated. They are self-asserted but logged mandatorily for auditability. Implementations SHOULD use logging and anomaly detection to identify inconsistencies. Full cryptographic verification of agent identity and Authority-Scope is provided by the AGTP Agent Certificate extension . That extension binds Agent-ID, Principal-ID, and Authority-Scope to an X.509 v3 certificate presented during TLS mutual authentication, enabling infrastructure-layer identity and scope verification without application-layer access. Implementers planning deployments that require verified agent identity SHOULD plan for the Agent Certificate extension.

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

Every AGTP server MUST log Agent-ID and Principal-ID fields for every request, creating an attributable audit trail even in deployments without the Certificate extension.

Authority Scope Enforcement The Authority-Scope header declares what actions the agent is authorized to take. Compliant AGTP servers MUST parse the Authority-Scope on every request, return 451 Scope Violation for any method that exceeds declared scope, and log all scope violations for audit purposes. Scope declarations are self-asserted in the base spec, analogous to scope assertions in OAuth 2.0 . Cryptographically signed and infrastructure-enforced scopes are defined in .

Threat Model

Agent Spoofing Threat: A malicious actor forges Agent-ID and Principal-ID headers to impersonate a trusted agent. Base spec mitigation: mandatory logging and anomaly detection. Full mitigation requires .

Authority Laundering Threat: An agent claims an Authority-Scope broader than what it was granted. Mitigation: server-side scope enforcement; 451 Scope Violation returned and logged. In DELEGATE chains, each hop's scope MUST be a strict subset of the delegating agent's scope.

Delegation Chain Poisoning Threat: A malicious agent inserts itself into a DELEGATE chain. Mitigation: Delegation-Chain headers are logged at each hop. 551 Authority Chain Broken is returned if any chain entry is unverifiable. Full mitigation requires for signed delegation tokens.

Denial of Service via High-Frequency Agent Traffic Threat: Agents that are compromised, misconfigured, or adversarial generate extremely high request volumes. Mitigation: 429 Rate Limited status code. Rate limiting SHOULD be applied per Agent-ID and per Principal-ID. When is deployed, per-Agent-ID quotas can be cryptographically tied to verified identity, preventing quota evasion through Agent-ID spoofing.

Session Hijacking Threat: An attacker intercepts or forges a Session-ID. Mitigation: mandatory TLS protects sessions in transit. Session-IDs MUST be cryptographically random with minimum 128 bits of entropy. Servers MUST validate that Session-ID, Agent-ID, and TLS client identity are consistent.

Escalation Suppression Threat: A compromised agent or intermediary suppresses ESCALATE requests, preventing human oversight. Mitigation: compliant implementations MUST route ESCALATE requests directly to the declared escalation handler without modification. Intermediaries MUST NOT drop, delay, or modify ESCALATE requests. Escalation handlers SHOULD implement independent receipt confirmation.

Birth Certificate Spoofing Threat: A malicious actor fabricates a Birth Certificate to claim a legitimate agent's identity or construct a false identity with elevated trust. Mitigation: Birth Certificates are issued only by governance platforms with verified ownership of the org_domain. In the base spec, mandatory logging provides auditability. Full mitigation requires for cryptographically bound Birth Certificate verification at the transport layer. Governance platforms MUST treat any ACTIVATE request that presents a certificate hash matching an existing registry record as a collision attack and MUST reject it.

Domain Transfer Identity Hijacking Threat: An attacker acquires an expired domain to inherit the agent registry and trust history of prior registrants. Mitigation: agents under an expired domain are automatically Suspended within 24 hours of domain expiry detection. A new owner of the domain MUST NOT inherit prior agent registrations. See Section 8.5 for the full domain expiry policy.

Privacy Considerations Agent identity headers carry information about agent behavior that may be sensitive: Agent-ID and Principal-ID together may reveal organizational structure Session-ID and Task-ID reveal workflow patterns Delegation-Chain reveals multi-agent architecture AGTP logs containing these fields MUST be treated as sensitive operational data. Operators MUST implement appropriate access controls, retention limits, and data minimization practices consistent with applicable privacy regulations. Where privacy-preserving attribution is required, implementations MAY use pseudonymous Agent-IDs with a separate trusted resolution service. The architecture for pseudonymous agent identity resolution is reserved for a future companion document.

Denial-of-Service Considerations AGTP's agent identity headers provide a mechanism for more precise denial-of-service mitigation than is possible with HTTP. Rate limiting SHOULD be applied per Agent-ID and per Principal-ID in addition to per-IP-address controls. When 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 as part of their denial-of-service mitigation strategy. Additional recommended mitigations: Priority header enforcement (Priority: background requests SHOULD have lower rate limit headroom than Priority: critical); per-governance-zone aggregate limits in multi-tenant deployments; and circuit breaker patterns for ESCALATE request floods.

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 , which provides cryptographic binding of agent identity and authority scope to AGTP header fields. The ACTIVATE method, which provides AGTP-native transmission and activation of governed agent packages. The Agent Birth Certificate mechanism (Section 5.7), which provides the genesis identity record and canonical Agent-ID derivation process for AGTP-registered agents. The .agent file format specification, an open packaging format for AI agents. The .nomo file format specification, a governed packaging format for AI agents with cryptographic governance binding. 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 . IPR disclosures have been filed with the IETF Secretariat and are available at: https://datatracker.ietf.org/ipr/

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

Port Assignment Registration of the following service names in the IANA Service Name and Transport Protocol Port Number Registry: Service Name Port Transport Description agtp TBD TCP Agent Transfer Protocol over TCP/TLS agtp-quic TBD UDP Agent Transfer Protocol over QUIC

AGTP Method Registry Establishment of a new IANA registry: Agent Transfer Protocol Methods.

Registry name:

Agent Transfer Protocol Methods

Registration procedure:

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

Reference:

This document

Initial registrations: Method Status Reference QUERY Permanent This document, Section 6.2 SUMMARIZE Permanent This document, Section 6.2 BOOK Permanent This document, Section 6.2 SCHEDULE Permanent This document, Section 6.2 LEARN Permanent This document, Section 6.2 DELEGATE Permanent This document, Section 6.2 COLLABORATE Permanent This document, Section 6.2 CONFIRM Permanent This document, Section 6.2 ESCALATE Permanent This document, Section 6.2 NOTIFY Permanent This document, Section 6.2

AGTP Status Code Registry Establishment of a new IANA registry: Agent Transfer Protocol Status Codes.

Registry name:

Agent Transfer Protocol Status Codes

Registration procedure:

Expert Review + published specification required.

The following AGTP-specific status codes are registered with full definitions: Code Name Definition Reference 451 Scope Violation The requested action is outside the Authority-Scope declared in the request headers. The server MUST log this event. The agent MUST NOT retry the same request without modifying its Authority-Scope declaration. This is a governance signal, not a protocol error. This document, Section 5.5 550 Delegation Failure A sub-agent to which a task was delegated via the DELEGATE method failed to complete the task within the declared deadline or returned an error. The response body SHOULD contain the sub-agent's error details. This document, Section 5.5 551 Authority Chain Broken One or more entries in the Delegation-Chain header cannot be verified as part of a valid and continuous delegation sequence. The specific unverifiable entry SHOULD be identified in the response body. The server MUST log this event. This document, Section 5.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): AGTP-Version, AGTP-Method, AGTP-Status, Agent-ID, Principal-ID, Authority-Scope, Session-ID, Task-ID, Delegation-Chain, Priority, TTL, Server-Agent-ID, Attribution-Record, Continuation-Token, Supported-Methods.

URI Scheme Registration Registration of the agtp:// URI scheme per , as described in Section 5.1.8 of this document.

Agent Registry Retention Policy The AGTP registry MUST retain records for all registered agents regardless of lifecycle state. The following minimum retention periods apply: Lifecycle State Minimum Retention Period Active Duration of Active state + 7 years Suspended Duration of Suspended state + 7 years Revoked 10 years from revocation date Deprecated 7 years from deprecation date 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 Birth Certificate (archived, not publicly accessible) All lifecycle state transitions with timestamps The retained record MUST NOT contain package executable contents, active session data, or Authority-Scope grant tokens.

Domain Name Expiry Interaction If an organization's org_domain expires or transfers to a new owner: All Active agents registered under the expired domain MUST be automatically Suspended within 24 hours of domain expiry detection. The governance platform MUST notify the registered principal contact before suspension takes effect, with a minimum notice period of 30 days if domain expiry was predictable. Suspended agents under an expired domain transition to Deprecated state after 90 days if the domain has not been renewed. A new owner of the domain MUST NOT inherit prior agent registrations. New ACTIVATE transactions are required. This policy prevents domain-transfer-based identity hijacking in which an attacker acquires an expired domain to claim the trust history of agents that operated under it.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This document describes how Transport Layer Security (TLS) is used to secure QUIC. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information as possible about any IPR constraints on a technical proposal as early as possible in the development process. The policies are intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This document sets out the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This document updates RFC 2026 and, with RFC 5378, replaces Section 10 of RFC 2026. This document also obsoletes RFCs 3979 and 4879. Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3. This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients. This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes. It obsoletes RFC 4395. Linux Foundation IBM Research Anthropic

Authority-Scope Format Authority-Scope values are expressed as a space-separated list of scope tokens following the pattern: [domain]:[action] or [domain]:* for full domain access. Tokens MUST be lowercase ASCII with a single colon separator. Examples:

Reserved domains (initial set): Domain Description calendar Scheduling and time-based resource management documents Document access, summarization, and annotation knowledge Agent context and memory operations booking Reservation and resource allocation payments Financial transactions and confirmations agents Delegation and collaboration with other agents escalation Escalation routing and handler management activation Governed agent package activation (ACTIVATE method extension) * All domains require explicit grant; use with caution

Example AGTP Wire Formats The following examples use a human-readable pseudo-wire format with HTTP-style headers followed by a JSON body. The Content-Type for all AGTP message bodies is application/agtp+json.

QUERY Request and Response

BOOK Request and Response

ESCALATE Request and Response

Comparison Table Criterion AGTP HTTP/REST gRPC A2A / MCP Agent-native methods Yes No No Partial Intent semantics at protocol level Native None None Messaging layer only Built-in agent identity Yes No No No Authority scope enforcement Protocol-level None None Application-layer Built-in attribution/audit Yes No No Varies by impl. Transport flexibility TCP/UDP/QUIC TCP/TLS HTTP/2 HTTP Escalation as first-class primitive Yes No No No Ecosystem maturity Proposed Mature Mature Emerging Governance/observability Native Manual/bolt-on Manual Limited Method registry extensibility Yes (Expert Review) Frozen (IETF Review) N/A N/A Open core / royalty-free Yes Yes Yes Yes Agent Manifest Document Native (.agtp format) None None None Tamper-proof identity surface Yes (hash + signature) No No No Browser-accessible agent identity Yes (read-only) No No No URI collision prevention Domain-anchored N/A N/A N/A Agent Birth Certificate Yes (genesis record) No No No Domain-expiry lifecycle handling Specified N/A N/A N/A HTTP's method registry (registered with IETF Review per ) is effectively frozen for new semantic methods because any new HTTP method must be backward-compatible with existing HTTP infrastructure globally. AGTP's Expert Review + published spec procedure enables the protocol to evolve its method vocabulary as the agent ecosystem develops, without the backward-compatibility constraints of the HTTP method space.

Glossary

Agent:

A software system that executes tasks, makes decisions, and takes actions without continuous human supervision per transaction.

Agent Birth Certificate:

A cryptographically signed identity document issued to an agent at registration time by a governance platform. The genesis record of the agent's existence; the source from which the canonical Agent-ID is derived. Functions as the agent's social security number: issued once, permanently bound, never reissued. See Section 5.7.

Agent Transfer Protocol (AGTP):

The application-layer protocol defined in this document, providing a dedicated transport environment for agent traffic.

Agent-ID:

A unique identifier for a specific agent instance, present in all AGTP request headers. In the base spec, derived from the Birth Certificate hash. With , cryptographically bound to a verified identity.

Agent Manifest Document:

A signed application/agtp+json document returned when an agtp:// URI is resolved. Derived from the agent's .agent or .nomo package. Contains identity, lifecycle state, trust tier, behavioral scope, and birth certificate fields. Never contains executable content.

Attribution Record:

A signed, logged record of an agent action, sufficient for audit and compliance purposes.

Authority-Scope:

A declared set of permissions defining what actions an agent is authorized to take, expressed as space-separated domain:action tokens.

Delegation Chain:

An ordered record of Agent-IDs representing the sequence of delegations that led to the current request.

ESCALATE:

An AGTP method representing an agent's intentional deferral of a decision or action to a human principal or higher-authority agent. A first-class method, not a failure code.

Governance Token:

A signed, time-limited JWT artifact encoding a specific governance verdict for a specific action. The runtime companion to the Birth Certificate. Default TTL: 30 seconds. Must not be reused.

Intent Verb:

An AGTP method name expressing the agent's purpose, as distinguished from HTTP resource-operation verbs (GET, POST, PUT, DELETE).

Method Registry:

The IANA-maintained registry of valid AGTP method names and their specifications. Registration requires Expert Review and a published specification.

Principal:

The human, organization, or system that authorized an agent to act and is accountable for its actions.

Principal-ID:

The identifier of the principal on whose behalf an agent operates, present in all AGTP request headers.

Scope-Enforcement Point (SEP):

An AGTP-aware infrastructure component, load balancer, gateway, proxy, that enforces Authority-Scope compliance on AGTP requests without application-layer access. Requires .

Scope Violation (451):

An AGTP status code returned when an agent requests an action outside its declared Authority-Scope. A governance signal, not a protocol error. MUST be logged.

Session:

An AGTP persistent connection context shared across multiple method invocations within a single agent workflow.

Trust Tier:

A classification (1, 2, or 3) assigned to an agent at registration based on the strength of identity verification. Tier 1 requires DNS-anchored domain verification and a .nomo governed package. Tier 2 is org-asserted without DNS verification. Tier 3 is experimental, not production-eligible.

551 Authority Chain Broken:

An AGTP status code returned when one or more entries in the Delegation-Chain header cannot be verified as part of a valid and continuous delegation sequence. MUST be logged.