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

Methods that mean what they say

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.

Discovery without bilateral integration

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.

Transparency built in

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.

What this looks like in your code

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:

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:

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.

Where to look

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.