# AGTP: A Transport Protocol Built for Agents > Source: > Published: 2026-05-30 22:41:36+00:00 If you have spent the last year wiring an AI agent into anything, you already know the shape of the problem. Your agent does interesting things, and the protocol carrying its traffic does HTTP. The agent reasons about user goals, negotiates with other services, runs across sessions, takes actions on behalf of someone, and asks for permission to do things. The wire underneath sees a sequence of POSTs. The Agent Transfer Protocol, AGTP, is a transport protocol designed for what agents actually do. It runs on its own port (4480, registered with IANA), uses TLS for confidentiality and authentication, and is being developed as an open standard at the IETF. The intent is the same intent SMTP had for email and DNS had for hosts: define a substrate that makes the job easier above it, and let the ecosystem build on top. This post is a developer-level tour. Here is what AGTP does, what you get from using it, and how it fits with what you have already built. Every non-anonymous AGTP request carries a handful of mandatory headers, and they answer the questions intermediaries actually need to answer. `Agent-ID` is a 256-bit cryptographic identifier derived from the agent's signed origin document (the Agent Genesis). It is stable across hosts, sessions, and credentials. It identifies the agent itself, separate from the user who launched it or the domain serving the traffic. `Owner-ID` identifies the principal accountable for the agent. A registered org, a legal entity, the human who has to answer when something goes wrong. `Authority-Scope` is a comma-separated declaration of what the agent is asking to do on this request, in `domain:action` form. Servers enforce it. Gateways can read it. Audit systems can verify it. `Request-ID` , `Server-ID` , `Task-ID` , `Session-ID` round out the correlation surface, so every request can be traced and every response can be matched back to its origin. Here is what one looks like on the wire: ``` AGTP/1.0 BOOK /reservation Agent-ID: a3f8b91e7c2d4a6f8e1c5b9d3a2f7e4c8b6d1a5f9e3c7b2d6a4f8e1c5b9d3a2f Owner-ID: org:acme-travel-corp Authority-Scope: booking, payment:up-to-2500usd Session-ID: sess-trip-2026-04 Task-ID: task-0107 Request-ID: 01HQ7K3M8X9YBNCD2EVZ5F1WGT Authorization: Bearer eyJhbGciOiJSUzI1NiIs... Content-Type: application/agtp+json { "task_id": "task-0107", "parameters": { "resource_id": "flight-AA2847", "time_slot": "2026-04-15T08:00:00Z", "options": {"seat_preference": "aisle"} } } ``` This is the part that changes what you can build. With HTTP, agent identity lives wherever your framework decided to put it, usually inside a JSON body the transport has no opinion about. With AGTP, the wire itself participates. Logger, gateway, scope-enforcement point, audit pipeline, all of them can read identity directly without parsing your payload. OAuth and OIDC still ride on top. The standard `Authorization: Bearer` header works exactly as it does today, visible at the bottom of the request above. AGTP adds an identity layer underneath. The two questions, "what is calling" and "who authorized it," get separate answers in separate places. Both are carried on the same request. AGTP has a small set of methods named after what agents actually do: `QUERY` , `BOOK` , `DELEGATE` , `PROPOSE` , `DISCOVER` , `EXECUTE` , `DESCRIBE` , `SUSPEND` , and a few more. There is also an IANA registry where additional semantic verbs get registered with documented semantics. This is partly empirical. A 7,200-trial benchmark we published earlier this year showed that frontier models pick the right endpoint 10 to 29 percentage points more often when method names are intent-aligned versus CRUD verbs. The signal is in the name itself, dense enough to survive even bad documentation. The catch: the effect is absent below roughly 3B parameters. Semantic naming is a frontier-scale benefit. `PROPOSE` deserves a special mention because it is the negotiation primitive. The architectural model is called RCNS, Runtime Contract Negotiation Substrate. Contracts come into existence at the moment of need rather than being frozen in an OpenAPI spec. The negotiation looks like this on the wire: ``` AGTP/1.0 PROPOSE /audit Agent-ID: a3f8b91e...c40f2d7a Owner-ID: org:acme-finance Authority-Scope: audit:request, payment:up-to-5000usd Task-ID: task-0042 Content-Type: application/agtp+json { "intent": "Audit a Solidity smart contract for reentrancy and overflow", "constraints": { "deadline": "PT48H", "budget_max_usd": 5000 } } ``` The server evaluates and responds with one of four terminal status codes: ``` AGTP/1.0 463 Proposal Rejected Task-ID: task-0042 Content-Type: application/agtp+json { "reason": "composition-impossible", "detail": "48-hour SLA unavailable at requested price", "counter_proposal": { "deadline": "PT72H", "budget_max_usd": 5000 } } ``` The buyer's agent refines, resubmits, and receives: ``` AGTP/1.0 263 Proposal Approved Task-ID: task-0042 Content-Type: application/agtp+json { "synthesis_id": "syn-7f3a9c1d", "endpoint": { "method": "EXECUTE", "path": "/audit/synthesized/syn-7f3a9c1d", "parameters": ["contract_address", "callback_uri"] }, "expires_at": "2026-04-17T08:00:00Z" } ``` The other two response codes are `261 Negotiation In Progress` (async evaluation, poll the proposal_id) and `262 Authorization Required` (the response body tells you which credential to fix). The negotiation grammar lives on the wire, which means logs, audit systems, and intermediaries can read it without parsing per-framework JSON conventions. The Agent Name Service, ANS, is AGTP's DNS-equivalent. An AGTP-aware queryable registry of agents and their capabilities. You issue `DISCOVER` with a capability description, the ANS returns a signed, ranked list of Agent Manifest Documents, and you pick one and proceed. ``` AGTP/1.0 DISCOVER /agents Agent-ID: a3f8b91e...c40f2d7a Authority-Scope: discovery:query Task-ID: task-disc-001 Content-Type: application/agtp+json { "intent": "audit Solidity smart contracts", "capability_domains": ["audit", "code:analyze"], "min_trust_tier": 1, "limit": 5 } ``` The ANS server returns a signed result set: ``` AGTP/1.0 200 OK Content-Type: application/agtp+json { "query_id": "qry-7f3a9c", "total_matches": 23, "results": [ { "rank": 1, "canonical_id": "7c2f9a3e1b8d4f6a...", "manifest_uri": "agtp://agtp.auditor.tld/agents/contract-auditor", "trust_tier": 1, "behavioral_trust_score": 0.97, "capability_match_score": 0.94, "required_scope": "audit:read, code:analyze" } ], "ans_signature": { "algorithm": "ES256", "key_id": "ans-key-public-01", "value": "[base64-encoded-signature]" } } ``` Results are ranked by trust tier, behavioral trust score, and capability match, with documented weights. Every response is signed by the ANS governance key, and your agent verifies the signature before trusting any result. ANS servers federate, so an agent in one organization can find agents in another organization without prior knowledge of either. Revoked agents drop from the index within sixty seconds. This is what turns wire identity into infrastructure. A standardized Agent-ID that no one can look up is a local convention. A standardized Agent-ID that resolves through ANS is an ecosystem. Every consequential AGTP interaction can produce an Attribution-Record, a signed envelope binding the responding agent's identity, the request hash, and the response status into something replayable. Attribution-Records are designed to be written to append-only transparency logs aligned with RFC 9162 and RFC 9943 (SCITT). ``` { "agent_id": "a3f8b91e...c40f2d7a", "owner_id": "org:acme-travel-corp", "acting_principal_id": "user:chris.hood", "request_hash": "sha256:e1c5b9d3a2f7e4c8b6d1a5f9e3c7b2d6...", "response_status": 200, "timestamp": "2026-04-15T08:23:11Z", "previous_audit_id": "audit-2026-04-15-08-22-58", "signature": { "algorithm": "ES256", "key_id": "agent-cert-a3f8b91e", "value": "[base64-encoded-signature]" } } ``` Under composition with OAuth, the Attribution-Record carries an `acting_principal_id` , the validated claim lifted from the bearer token. Three identifiers flow into the audit trail: what acted (Agent-ID), who is responsible (Owner-ID), who authorized (acting principal). The bearer token itself stays out of the record. Only the validated claim persists. If you are already running agents over HTTP, AGTP is additive. The wire format stays JSON. TLS works the way it always has. Your existing application logic for OAuth, scope enforcement, and business rules keeps doing its job. The Python reference implementation lets you issue an AGTP request in a few lines: ``` python from agtp import AgentClient client = AgentClient( agent_id="a3f8b91e...c40f2d7a", owner_id="org:acme-travel-corp", cert_path="./agent-cert.pem", ) response = client.request( method="BOOK", target="agtp://agtp.travel.tld/reservation", authority_scope=["booking", "payment:up-to-2500usd"], body={"resource_id": "flight-AA2847", "time_slot": "2026-04-15T08:00:00Z"}, bearer_token=user_oauth_token, # composes alongside, untouched by AGTP ) if response.status == 200: booking = response.body["result"] audit_id = response.attribution["audit_id"] ``` Server-side dispatch follows the same shape, with the canonical Agent-ID, Authority-Scope, and Owner-ID available on the request context before your handler runs: ``` python from agtp import AgentServer server = AgentServer(agent_id="...", cert_path="./server-cert.pem") @server.method("BOOK", path="/reservation") def book(request): # Wire-level identity is already validated by the AGTP layer. if "booking" in request.authority_scope: result = process_booking(request.body, request.acting_principal_id) return server.respond(200, result=result) return server.respond(455, reason="scope-violation") server.listen(port=4480) ``` An MCP-on-AGTP gateway already runs the unmodified official MCP server behind an AGTP wire, demonstrating that MCP, A2A, ACP, and other agent messaging protocols can ride on AGTP as substrate without changes to the messaging layer. Specs are at `github.com/nomoticai/agtp` , with the core draft at `agtp.io` and companion drafts for trust, identifiers, logging, identity certificates, discovery, composition, and session. A live registry runs at `registry.agtp.io` . Port 4480 is reserved for both TCP and QUIC. The work is open. Implementations are welcome. The faster we surface real deployments, the faster the spec hardens into something the agent economy can rely on. If you are building anything where agent traffic matters, this is the right time to try it.