AGTP: A Transport Protocol Built for Agents

Chris Hood Posted on May 30 AGTP: A Transport Protocol Built for Agents # ai # networking # agents # architecture 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. Identity that lives on the wire 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 respons