{"slug": "agtp-a-transport-protocol-built-for-agents", "title": "AGTP: A Transport Protocol Built for Agents", "summary": "The Agent Transfer Protocol (AGTP), a new transport protocol designed specifically for AI agent traffic, operates on its own port (4480) and uses mandatory headers like `Agent-ID` and `Owner-ID` to identify the agent and its accountable principal directly on the wire. Developed as an open standard at the IETF, AGTP replaces HTTP's generic POST requests with intent-aligned methods such as `QUERY`, `BOOK`, and `PROPOSE`, which a 7,200-trial benchmark showed improve model endpoint selection accuracy by 10 to 29 percentage points for frontier models. The protocol adds an identity layer beneath existing OAuth and OIDC authentication, enabling loggers, gateways, and audit systems to read agent identity without parsing payloads.", "body_md": "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.\n\nThe 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.\n\nThis 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.\n\nEvery non-anonymous AGTP request carries a handful of mandatory headers, and they answer the questions intermediaries actually need to answer.\n\n`Agent-ID`\n\nis 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.\n\n`Owner-ID`\n\nidentifies the principal accountable for the agent. A registered org, a legal entity, the human who has to answer when something goes wrong.\n\n`Authority-Scope`\n\nis a comma-separated declaration of what the agent is asking to do on this request, in `domain:action`\n\nform. Servers enforce it. Gateways can read it. Audit systems can verify it.\n\n`Request-ID`\n\n, `Server-ID`\n\n, `Task-ID`\n\n, `Session-ID`\n\nround out the correlation surface, so every request can be traced and every response can be matched back to its origin.\n\nHere is what one looks like on the wire:\n\n```\nAGTP/1.0 BOOK /reservation\nAgent-ID: a3f8b91e7c2d4a6f8e1c5b9d3a2f7e4c8b6d1a5f9e3c7b2d6a4f8e1c5b9d3a2f\nOwner-ID: org:acme-travel-corp\nAuthority-Scope: booking, payment:up-to-2500usd\nSession-ID: sess-trip-2026-04\nTask-ID: task-0107\nRequest-ID: 01HQ7K3M8X9YBNCD2EVZ5F1WGT\nAuthorization: Bearer eyJhbGciOiJSUzI1NiIs...\nContent-Type: application/agtp+json\n\n{\n  \"task_id\": \"task-0107\",\n  \"parameters\": {\n    \"resource_id\": \"flight-AA2847\",\n    \"time_slot\": \"2026-04-15T08:00:00Z\",\n    \"options\": {\"seat_preference\": \"aisle\"}\n  }\n}\n```\n\nThis 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.\n\nOAuth and OIDC still ride on top. The standard `Authorization: Bearer`\n\nheader 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.\n\nAGTP has a small set of methods named after what agents actually do: `QUERY`\n\n, `BOOK`\n\n, `DELEGATE`\n\n, `PROPOSE`\n\n, `DISCOVER`\n\n, `EXECUTE`\n\n, `DESCRIBE`\n\n, `SUSPEND`\n\n, and a few more. There is also an IANA registry where additional semantic verbs get registered with documented semantics.\n\nThis 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.\n\n`PROPOSE`\n\ndeserves 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.\n\nThe negotiation looks like this on the wire:\n\n```\nAGTP/1.0 PROPOSE /audit\nAgent-ID: a3f8b91e...c40f2d7a\nOwner-ID: org:acme-finance\nAuthority-Scope: audit:request, payment:up-to-5000usd\nTask-ID: task-0042\nContent-Type: application/agtp+json\n\n{\n  \"intent\": \"Audit a Solidity smart contract for reentrancy and overflow\",\n  \"constraints\": {\n    \"deadline\": \"PT48H\",\n    \"budget_max_usd\": 5000\n  }\n}\n```\n\nThe server evaluates and responds with one of four terminal status codes:\n\n```\nAGTP/1.0 463 Proposal Rejected\nTask-ID: task-0042\nContent-Type: application/agtp+json\n\n{\n  \"reason\": \"composition-impossible\",\n  \"detail\": \"48-hour SLA unavailable at requested price\",\n  \"counter_proposal\": {\n    \"deadline\": \"PT72H\",\n    \"budget_max_usd\": 5000\n  }\n}\n```\n\nThe buyer's agent refines, resubmits, and receives:\n\n```\nAGTP/1.0 263 Proposal Approved\nTask-ID: task-0042\nContent-Type: application/agtp+json\n\n{\n  \"synthesis_id\": \"syn-7f3a9c1d\",\n  \"endpoint\": {\n    \"method\": \"EXECUTE\",\n    \"path\": \"/audit/synthesized/syn-7f3a9c1d\",\n    \"parameters\": [\"contract_address\", \"callback_uri\"]\n  },\n  \"expires_at\": \"2026-04-17T08:00:00Z\"\n}\n```\n\nThe other two response codes are `261 Negotiation In Progress`\n\n(async evaluation, poll the proposal_id) and `262 Authorization Required`\n\n(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.\n\nThe Agent Name Service, ANS, is AGTP's DNS-equivalent. An AGTP-aware queryable registry of agents and their capabilities. You issue `DISCOVER`\n\nwith a capability description, the ANS returns a signed, ranked list of Agent Manifest Documents, and you pick one and proceed.\n\n```\nAGTP/1.0 DISCOVER /agents\nAgent-ID: a3f8b91e...c40f2d7a\nAuthority-Scope: discovery:query\nTask-ID: task-disc-001\nContent-Type: application/agtp+json\n\n{\n  \"intent\": \"audit Solidity smart contracts\",\n  \"capability_domains\": [\"audit\", \"code:analyze\"],\n  \"min_trust_tier\": 1,\n  \"limit\": 5\n}\n```\n\nThe ANS server returns a signed result set:\n\n```\nAGTP/1.0 200 OK\nContent-Type: application/agtp+json\n\n{\n  \"query_id\": \"qry-7f3a9c\",\n  \"total_matches\": 23,\n  \"results\": [\n    {\n      \"rank\": 1,\n      \"canonical_id\": \"7c2f9a3e1b8d4f6a...\",\n      \"manifest_uri\": \"agtp://agtp.auditor.tld/agents/contract-auditor\",\n      \"trust_tier\": 1,\n      \"behavioral_trust_score\": 0.97,\n      \"capability_match_score\": 0.94,\n      \"required_scope\": \"audit:read, code:analyze\"\n    }\n  ],\n  \"ans_signature\": {\n    \"algorithm\": \"ES256\",\n    \"key_id\": \"ans-key-public-01\",\n    \"value\": \"[base64-encoded-signature]\"\n  }\n}\n```\n\nResults 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.\n\nThis 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.\n\nEvery 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).\n\n```\n{\n  \"agent_id\": \"a3f8b91e...c40f2d7a\",\n  \"owner_id\": \"org:acme-travel-corp\",\n  \"acting_principal_id\": \"user:chris.hood\",\n  \"request_hash\": \"sha256:e1c5b9d3a2f7e4c8b6d1a5f9e3c7b2d6...\",\n  \"response_status\": 200,\n  \"timestamp\": \"2026-04-15T08:23:11Z\",\n  \"previous_audit_id\": \"audit-2026-04-15-08-22-58\",\n  \"signature\": {\n    \"algorithm\": \"ES256\",\n    \"key_id\": \"agent-cert-a3f8b91e\",\n    \"value\": \"[base64-encoded-signature]\"\n  }\n}\n```\n\nUnder composition with OAuth, the Attribution-Record carries an `acting_principal_id`\n\n, 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.\n\nIf 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.\n\nThe Python reference implementation lets you issue an AGTP request in a few lines:\n\n``` python\nfrom agtp import AgentClient\n\nclient = AgentClient(\n    agent_id=\"a3f8b91e...c40f2d7a\",\n    owner_id=\"org:acme-travel-corp\",\n    cert_path=\"./agent-cert.pem\",\n)\n\nresponse = client.request(\n    method=\"BOOK\",\n    target=\"agtp://agtp.travel.tld/reservation\",\n    authority_scope=[\"booking\", \"payment:up-to-2500usd\"],\n    body={\"resource_id\": \"flight-AA2847\",\n          \"time_slot\": \"2026-04-15T08:00:00Z\"},\n    bearer_token=user_oauth_token,  # composes alongside, untouched by AGTP\n)\n\nif response.status == 200:\n    booking = response.body[\"result\"]\n    audit_id = response.attribution[\"audit_id\"]\n```\n\nServer-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:\n\n``` python\nfrom agtp import AgentServer\n\nserver = AgentServer(agent_id=\"...\", cert_path=\"./server-cert.pem\")\n\n@server.method(\"BOOK\", path=\"/reservation\")\ndef book(request):\n    # Wire-level identity is already validated by the AGTP layer.\n    if \"booking\" in request.authority_scope:\n        result = process_booking(request.body, request.acting_principal_id)\n        return server.respond(200, result=result)\n    return server.respond(455, reason=\"scope-violation\")\n\nserver.listen(port=4480)\n```\n\nAn 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.\n\nSpecs are at `github.com/nomoticai/agtp`\n\n, with the core draft at `agtp.io`\n\nand companion drafts for trust, identifiers, logging, identity certificates, discovery, composition, and session. A live registry runs at `registry.agtp.io`\n\n. Port 4480 is reserved for both TCP and QUIC.\n\nThe 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.", "url": "https://wpnews.pro/news/agtp-a-transport-protocol-built-for-agents", "canonical_source": "https://dev.to/chrishood/agtp-a-transport-protocol-built-for-agents-2j7p", "published_at": "2026-05-30 22:41:36+00:00", "updated_at": "2026-05-30 23:11:14.750811+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "artificial-intelligence", "ai-research"], "entities": ["AGTP", "IETF", "IANA", "SMTP", "DNS", "TLS"], "alternates": {"html": "https://wpnews.pro/news/agtp-a-transport-protocol-built-for-agents", "markdown": "https://wpnews.pro/news/agtp-a-transport-protocol-built-for-agents.md", "text": "https://wpnews.pro/news/agtp-a-transport-protocol-built-for-agents.txt", "jsonld": "https://wpnews.pro/news/agtp-a-transport-protocol-built-for-agents.jsonld"}}