---
title: "Agent Ecosystem Protocol Binding (AEPB): Interop and Lifecycle"
abbrev: "AEPB"
category: std
docname: draft-aepb-agent-ecosystem-protocol-binding-00
submissiontype: IETF
number:
date:
v: 3
area: "ART"
workgroup: "DISPATCH"
keyword:
  - agent interoperability
  - protocol translation
  - lifecycle
  - agentic workflows

author:
  -
    fullname: TBD
    organization: Independent
    email: placeholder@example.com

normative:
  RFC2119:
  RFC8174:
  RFC8446:
  RFC8615:
  RFC9110:
  I-D.nennemann-wimse-ect:
    title: "Execution Context Tokens for Distributed Agentic Workflows"
    target: https://datatracker.ietf.org/doc/draft-nennemann-wimse-ect/
  I-D.nennemann-agent-dag-hitl-safety:
    title: "Agent Context Policy Token: DAG Delegation with Human Override"
    target: https://datatracker.ietf.org/doc/draft-nennemann-agent-dag-hitl-safety/

informative:

--- abstract

This document defines the Agent Ecosystem Protocol Binding (AEPB),
the interoperability and lifecycle layer of the agent ecosystem.
With over 90 competing A2A protocol drafts and no interoperability
standard, AEPB defines capability advertisement, protocol
negotiation, translation gateways, and agent lifecycle management
(versioning, graceful shutdown, retirement).  Translation hops
produce ECT nodes, preserving DAG continuity across protocol
boundaries.  Protocol constraints are expressed as ACP-DAG-HITL
node constraints.

--- middle

# Introduction

The IETF AI/agent landscape includes over 90 drafts proposing
agent-to-agent communication protocols.  No standard exists for
agents using different protocols to exchange messages, and no
standard exists for how agents evolve, get replaced, or retire
without disrupting dependent services.

AEPB addresses both gaps with a pragmatic approach: rather than
mandating a single protocol, it defines the minimum machinery for
agents to discover each other's protocol support, agree on a
common format, fall back to translation gateways, and manage their
lifecycle.

AEPB builds on ECT {{I-D.nennemann-wimse-ect}} for audit (every
translation hop is a DAG node) and ACP-DAG-HITL
{{I-D.nennemann-agent-dag-hitl-safety}} for policy (protocol
constraints as node constraints).

# Conventions and Definitions

{::boilerplate bcp14-tagged}

Agent Protocol:
: A communication protocol used by an AI agent for peer-to-peer
  message exchange (e.g., A2A, MCP, SLIM, uACP).

Capability Document:
: A JSON object describing the protocols an agent supports.

Translation Gateway:
: A service that converts messages between two agent protocols,
  recording each translation as an ECT DAG node.

# Capability Advertisement {#capability}

Each AEPB-compliant agent MUST serve a capability document at
`/.well-known/aepb` {{RFC8615}}:

~~~json
{
  "aepb_version": "1.0",
  "agent_id": "spiffe://example.com/agent/pricing",
  "protocols": [
    {
      "id": "a2a-v1",
      "version": "1.0",
      "endpoint": "https://agent.example.com/a2a",
      "priority": 10
    },
    {
      "id": "mcp-v1",
      "version": "2025-03-26",
      "endpoint": "https://agent.example.com/mcp",
      "priority": 20
    }
  ],
  "translation_gateways": [
    "https://gateway.example.com/aepb/translate"
  ],
  "ect_assurance_level": "L2",
  "lifecycle": {
    "status": "active",
    "version": "2.1.0",
    "deprecated_at": null,
    "sunset_at": null,
    "successor": null
  }
}
~~~
{: #fig-capability title="Capability Document"}

The `protocols` array MUST contain at least one entry.  `priority`
is OPTIONAL; lower values indicate higher preference.

The `lifecycle` object (see {{lifecycle}}) provides versioning and
deprecation metadata.

Agents SHOULD advertise via DNS SVCB records (`_aepb._tcp`).

# Protocol Negotiation {#negotiation}

When Agent A wants to communicate with Agent B:

1. Agent A fetches B's capability document over HTTPS.

2. Agent A computes the intersection of protocol lists.  If
   non-empty, the protocol with the lowest combined priority is
   selected.  Communication proceeds directly.

3. If no common protocol exists, Agent A checks translation
   gateways listed by either agent:

~~~
GET /.well-known/aepb/gateway?from=a2a-v1&to=slim-v1
~~~

   The gateway responds 200 if it supports the pair, 404 if not.

4. If a suitable gateway is found, Agent A sends its message to
   the gateway, which translates and forwards.

5. If no gateway supports the pair, Agent A returns error
   `no_translation_path`.

Negotiation is stateless and cacheable (Cache-Control, default
3600s).

# Translation as ECT DAG Nodes {#translation-ect}

Every translation hop produces an ECT:

- `exec_act`: `"aepb:translate"`
- `par`: the source agent's ECT
- `inp_hash`: SHA-256 of source protocol message
- `out_hash`: SHA-256 of translated message

~~~json
{
  "exec_act": "aepb:translate",
  "par": ["source-agent-ect-uuid"],
  "inp_hash": "sha256-of-source-message",
  "out_hash": "sha256-of-translated-message",
  "ext": {
    "aepb.source_protocol": "a2a-v1",
    "aepb.dest_protocol": "slim-v1",
    "aepb.gateway_id": "spiffe://gw.example.com/aepb",
    "aepb.translation_warnings": []
  }
}
~~~
{: #fig-translate-ect title="Translation ECT"}

This creates a three-node subgraph:

~~~
Source ECT → Gateway ECT (aepb:translate) → Dest ECT
~~~

The Execution-Context HTTP header survives protocol translation:
the gateway includes the translation ECT in the header of the
forwarded request.

## Translation Policy

Protocol constraints are ACP-DAG-HITL node constraints:

~~~json
{
  "constraints": {
    "aepb.allowed_source_protocols": ["a2a-v1", "mcp-v1"],
    "aepb.allowed_dest_protocols": ["slim-v1"],
    "aepb.max_translation_hops": 2
  }
}
~~~
{: #fig-policy title="Translation Policy"}

Agents receiving a message SHOULD reject it if the ECT DAG
contains more translation hops than `aepb.max_translation_hops`.

# Translation Gateway Requirements {#gateway}

A gateway MUST:

1. Serve a capability document at `/.well-known/aepb/gateway`.
2. Accept messages via HTTP POST at its translate endpoint.
3. Produce an ECT per {{translation-ect}} for every translation.
4. Preserve message semantics.  Fields without a destination
   equivalent are carried in an extension field or dropped with
   a warning in `aepb.translation_warnings`.
5. Require TLS 1.3 {{RFC8446}} for all connections.
6. Implement rate limiting per source agent.

A gateway MUST NOT modify payload semantics.

# Agent Lifecycle Management {#lifecycle}

## Lifecycle States

An agent's `lifecycle.status` MUST be one of:

- `active`: Normal operation.  Default state.
- `deprecated`: Agent is functional but will be retired.
  `deprecated_at` MUST be set.  Clients SHOULD migrate to
  `successor` if provided.
- `draining`: Agent is rejecting new workflows but completing
  in-progress ones.  New delegation requests return HTTP 503
  with `Retry-After` header pointing to `successor`.
- `retired`: Agent is offline.  Capability document returns
  HTTP 410 Gone with `successor` for redirect.

## Versioning

The `lifecycle.version` field uses semantic versioning.  Agents
MUST increment the major version when breaking changes occur
(incompatible protocol or behavior changes).

Capability documents MUST include the version.  Agents SHOULD
include version in ECT `ext` claims (`aepb.agent_version`) so
the audit trail records which version performed each action.

## Graceful Shutdown

When an agent transitions to `draining`:

1. Update capability document: `status: "draining"`,
   set `sunset_at` timestamp.
2. Reject new workflow delegations with HTTP 503.
3. Complete all in-progress workflows.
4. Emit a final ECT: `exec_act: "aepb:shutdown"`.
5. Transition to `retired`.

Agents SHOULD provide at least 24 hours between `deprecated`
and `draining` to allow clients to discover the change via
cached capability documents.

## Successor Discovery

When `successor` is set, it MUST be the URI of the replacement
agent's capability document.  Clients SHOULD transparently
redirect to the successor after verifying its capability
document.

# Security Considerations

Capability documents are served over HTTPS.  Agents SHOULD verify
TLS certificates before trusting capability documents.

Gateways are trusted intermediaries with access to message content.
For end-to-end confidentiality, agents MAY encrypt message payloads
with a shared key established out of band.

The ECT audit trail enables detection of unauthorized gateways,
content tampering (mismatched `inp_hash`/`out_hash`), and routing
loops (repeated gateway IDs in DAG ancestry).

Lifecycle transitions (especially `draining` and `retired`) can be
exploited for denial of service.  Only the agent operator (verified
via identity binding) SHOULD be able to update lifecycle status.

# IANA Considerations

This document requests:

1. A "AEPB Protocol Identifier" registry under Expert Review.
   Initial entries: `a2a-v1`, `mcp-v1`, `slim-v1`, `uacp-v1`,
   `ainp-v1`.

2. Well-known URI registrations for `aepb` and `aepb/gateway`
   per {{RFC8615}}.

3. Registration of `exec_act` values: `aepb:translate`,
   `aepb:shutdown` in a future ECT action type registry.

--- back

# Acknowledgments
{:numbered="false"}

AEPB builds on ECT {{I-D.nennemann-wimse-ect}} for translation
audit trails and ACP-DAG-HITL
{{I-D.nennemann-agent-dag-hitl-safety}} for protocol policy.
