A Dimensional Model for Characterizing AI Agent Protocol Proposals and Their Substrates

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 22 April 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

2. Terminology

The following terms are used with these meanings:¶

Dimension:

A protocol-visible property of an agent-protocol exchange, with a small fixed value domain.¶

Extension:

A named protocol augmentation that does not warrant a new dimension value but does introduce distinct protocol primitives.¶

Substrate:

The layer below the agent protocol from which specific properties of the exchange are inherited. Substrate facets include transport, identity and authorization carriage, discovery, audit format, and security channel.¶

Agentic protocol proposal:

A body of protocol work, standardized or proposed, whose primary subject is agent-to-agent or agent-to-tool interaction. A2A, MCP, the ACP invocation surface of the AGNTCY stack, and AGTP are examples used throughout this document.¶

Layer boundary contract:

The narrow interface exposed between two adjacent layers, comprising only the artifacts and signals each layer exposes to the other.¶

Exchange:

A single agent-protocol interaction between two endpoints, from initiation through completion or termination. The dimensions of Section 5 are properties of an exchange.¶

Association:

A transport-level connection or session between two endpoints within which one or more messages of an exchange are conveyed. In current practice, an association is opened by the caller.¶

Substrate realization:

The way a dimensional value is carried on the wire by a given substrate binding (for example, a header versus a field in the message body, or a first-class wire verb versus a body field). A change of substrate realization does not change the dimensional value.¶

Role:

The position a proposal occupies in a given usage: substrate role (carrying another agent protocol) or agent-protocol role (its own primitives form the exchange). Role is a property of usage, not of the proposal; one proposal may occupy both roles in different usages.¶

Evidence object:

A protocol-visible artifact produced or carried by an exchange that attests to an authorization decision or to an action taken (for example, an authorization record or an invocation record).¶

Verification root:

That which a relying party must trust in order to verify an evidence object (for example, a key, a certificate anchor, or a transparency service).¶

Relying party:

An entity that verifies an evidence object. A relying party may or may not be a participant in the exchange.¶

Substrate profile:

A specification that binds an agent protocol to a substrate mechanism by constraining which of the substrate's features and parameters are used, and how agent-protocol semantics map onto substrate constructs.¶

3. Layered View

Each dimension in this document is a property of an agent-protocol exchange. Not all dimensions are satisfied by the agent protocol itself; several are sourced from adjacent substrate layers. Figure 1 shows the three layers of interest and, within each, the substrates the layer consumes.¶

+===================================================================+
|                    ORCHESTRATION / CONTROL LAYER                  |
|                       (above agent protocol)                      |
|                                                                   |
|   holds: workflow composition, cross-domain admission,            |
|          delegation lineage across trust domains, persistent      |
|          user/session memory, delegation governance (scope        |
|          validation, contract negotiation, budget approval)       |
|                                                                   |
|   substrates it consumes:                                         |
|     - schedulers / workflow engines                               |
|     - orchestrator frameworks                                     |
|     - broker subscriptions                                        |
+==================================^================================+
                                   |
           layer boundary contract | (task/session requests,
                                   |  bounded work delegations)
                                   v
+===================================================================+
|                     AGENT PROTOCOL LAYER                          |
|                    (A2A, MCP, ACP, ...)                           |
|                                                                   |
|   holds: bounded tasks, capability advertisement, delegated       |
|          authorization carriage, referenceable artifacts,         |
|          within-association server-initiated messages, bounded-   |
|          task re-attach, per-action evidence (authorization and   |
|          accountability records)                                  |
|                                                                   |
|   substrates it consumes:                                         |
|     identity:      OAuth 2.0 / 2.1, WIMSE, chainable capabilities |
|     discovery:     Well-Known URI, Agent Directory + OASF         |
|     transport:     HTTP/1.1, HTTP/2, HTTP/3, SSE, WebSocket, SLIM,|
|                    AGTP                                           |
|     content ref:   HTTP GET + signed URLs                         |
|     audit format:  CloudEvents                                    |
+==================================^================================+
                                   |
           layer boundary contract | (bytes on the wire, connection
                                   |  lifecycle, integrity, identity
                                   |  material, delivery guarantees)
                                   v
+===================================================================+
|                        SUBSTRATE LAYER                            |
|                    (below agent protocol)                         |
|                                                                   |
|   holds: connection lifecycle, encryption, delivery semantics,    |
|          workload identity attestation, name resolution,          |
|          broker durability                                        |
|                                                                   |
|   substrates and standards:                                       |
|     transport:    TCP, UDP, QUIC                                  |
|     security:     TLS 1.3, mTLS                                   |
|     naming:       DNS, DNS-SD, DIDs                               |
|     broker:       AMQP, Kafka, MQTT                               |
|     identity fed: OIDC federations, X.509 chains                  |
+===================================================================+

Figure 1 is not intended as an exhaustive account of layers that may exist in agent systems; other layers not shown may hold concerns whose scope is neither a single exchange nor a substrate facet. Concerns that do not cross a depicted layer boundary do not affect the adjacent depicted layer.¶

Pre- and post-action governance events such as scope validation, contract negotiation, and budget approval are delegation concerns whose meaning extends beyond a single exchange. They are placed at the orchestration layer. The agent protocol layer carries and preserves the per-action evidence those events produce; such evidence remains gradable on D8 (Section 5.8), while the governance decision itself lives above the exchange.¶

4. The Protocol's Substrate

Several of the dimensions in Section 5 have values that are not defined by the agent protocol itself but are inherited from the layers to which the agent protocol binds. Collectively these adjacent layers are referred to as the protocol's substrate. Substrate facets relevant to the dimensional model include:¶

• Transport: how bytes are moved, how connections persist, how callee-originated messages are supported within an established association, and how reattachment after interruption is handled.¶

• Identity and authorization: how credentials are issued, narrowed, carried across hops, and verified.¶

• Discovery: how endpoints and their advertised capabilities are located.¶

• Audit: how actions taken on behalf of others are recorded for accountability.¶

• Security: how confidentiality, integrity, and group trust are established for the exchange.¶

Where an existing standard provides the needed substrate behaviour in a given facet, the path forward is binding specification or profile, not protocol invention. Where none does, the gap is named where relevant.¶

Three properties of the relationship between substrate and dimensions are used throughout this document:¶

• Reachability. The substrate binding determines which dimensional values are reachable. For example, a transport binding that cannot convey callee-originated messages within an association forces D1 = none, regardless of what the agent protocol would otherwise expose.¶

• Realization does not move values. Where a value is carried (for example, a delegation chain in protocol headers versus an authorization token in the message body, or intent expressed as a first-class wire verb versus a field in the body) is a substrate-realization choice. It may be consequential for implementation and interoperability, but it does not change the dimensional value and does not constitute a separate dimension.¶

• Verification outcome is substrate-held. Whether an offered verification root can actually be exercised at a later time (log liveness, key availability, retention) is a substrate property. The model grades the root an exchange offers (Section 5.8), not the outcome of later verification.¶

5. Dimensions

The model identifies eight dimensions. Each dimension is defined over a small value domain. An agent protocol exchange is described by selecting one value from each dimension, together with zero or more extensions (Section 8) and an optional deployment-context modifier (Section 9). Additional dimensions were considered and set aside; these are recorded in Section 11 to make the boundary of the adopted model explicit.¶

6. Applying the Model to Representative Agentic Protocol Proposals

This section applies the dimensional model to representative agentic protocol proposals. The purpose is descriptive, not evaluative: to show which dimensional values are realized at the agent-protocol layer and which capabilities are inherited from substrate.¶

Dimension cells use only values from the corresponding dimension. Parenthesized text identifies a specific realization.¶

supports X and Y:

The proposal explicitly supports more than one valid dimensional value.¶

not specified:

The proposal does not commit to a value for that dimension at the agent-protocol layer. The function may be provided by deployment policy or by an underlying substrate.¶

unclear:

The available specification text does not allow the authors to determine the value with confidence.¶

n/a:

The dimension is not applicable because the proposal does not define the relevant agent-protocol-layer exchange.¶

The mapping in this revision is a starting point and is expected to evolve with community feedback. Cells are intended as neutral readings of published specification text rather than self-descriptions by proposal authors. A mapping is proposed with a reference to the specification text that supports it and is confirmed when that reading is not contested; where specification text does not support a confident reading, the cell is recorded as unclear. The detailed process for proposing and confirming mappings is an open question (Section 12).¶

The dimensional signature per proposal is given in Table 1. The substrate bindings per proposal are given in Table 2.¶

Note 1: The AGNTCY collective publishes a stack of components including the Agent Connect Protocol (ACP) as the agent-protocol-layer invocation surface, Agent Directory Service (federated discovery), OASF (Open Agentic Schema Framework, the data model behind agent descriptors), SLIM (Secure Low-Latency Interactive Messaging, a substrate-layer secure messaging protocol also submitted as an IETF individual Internet-Draft draft-mpsb-agntcy-slim), and Identity (verifiable credentials and agent badges). This row characterizes the ACP invocation surface at the agent-protocol layer together with the substrate components (Agent Directory + OASF for discovery, SLIM for transport, Identity for identity carriage) that constitute the rest of the stack. The ACP repository was archived by its maintainers on 11 April 2026, pending a successor invocation specification; the other components of the AGNTCY stack remain active. SLIM is explicitly positioned by its authors as a substrate available to A2A, MCP, and other agent protocols as well.¶

Note 2: AGTP is listed in two roles. As a substrate, it carries A2A, MCP, or ACP as content types inside AGTP method invocations (Table 2, transport column). As an agent protocol, its own methods form the exchange and it binds to TCP/TLS or QUIC; Table 1 characterizes this usage. Unlike the other rows of Table 2, AGTP specifies its own identity and discovery substrates in companion specifications; its D5 and D8 values therefore follow from its own discovery and trust-tier design rather than from an external binding. Values are read from the AGTP core and companion specifications; unclear cells await review of the normative method definitions.¶

The substrate columns anchor the layered view of Section 3. Convergence in a substrate column indicates a substrate-binding question rather than a primary protocol-design question. Divergence indicates a candidate area for coordination or profiling.¶

7. What the Model Enables

• Requirement routing. Requirements expressed in dimensional terms can be mapped to proposals that already realize them, require extensions, or delegate them to substrate.¶

• Identification of substrate-owned dimensions. When proposals converge on the same value realized through the same substrate, the remaining question is substrate binding or profiling rather than protocol design.¶

• Complementarity as observation. Proposals may cover different regions of the dimensional space and remain useful side by side. The comparison table makes similarities and differences explicit without ranking proposals.¶

• Substrate portability analysis. Separating dimensions from substrates enables analysis of which properties remain stable when a proposal is rebound to a different substrate.¶

• Evaluation of extensions. Extensions can be compared using a shared vocabulary of dimensions, values, and substrate assumptions.¶

• Scoping community work. The model helps distinguish protocol-layer work from substrate profiling and other adjacent concerns.¶

• Surfacing broader-scope concerns. Requirements that do not fit any exchange-level dimension are made visible and can be routed to companion work rather than folded into agent-protocol design.¶

8. Extensions

An extension augments the baseline dimensional tuple with primitives the baseline does not require. Extensions are used when an additional behaviour does not warrant a new dimension value but does require a named protocol augmentation.¶

• EXT-CHKPT: authorization checkpoint primitives (pause, resume, timeout) supporting D3 = suspend-resume.¶

• EXT-REATTACH: persistent task identifier and reattachment message supporting D3 = durable-reattach when realized at the protocol layer.¶

• EXT-CAPREG: capability registration and discovery messages, with integrity protection of advertised capabilities, supporting D5 = registry-resolved.¶

• EXT-AUTHEV: exchange of authorization evidence, describing the authorization decision under which an action is admitted, produced at or before the enforcement point.¶

• EXT-AUDIT: exchange of post-action accountability evidence, describing actions taken on behalf of requesting parties, produced after the action.¶

• EXT-XLATE: error vocabulary for protocol translation failure and request validation failure, distinct from authorization failure.¶

• EXT-MODNEG: modality negotiation at session setup, supporting multimodal exchanges where the active modalities are agreed between the caller and the callee.¶

EXT-AUTHEV and EXT-AUDIT are kept distinct. Authorization evidence and post-action accountability evidence arise at potentially different enforcement points and may therefore be provided by different protocols; a single extension would hide that boundary. Each kind of record is graded independently on D8 (Section 5.8). The representation of record presence or absence, including results such as "not found in this evidence set", is defined by the respective extension and does not surface as a D8 value.¶

9. Deployment-Context Modifier: Cross-Domain Operation

Cross-administrative-domain deployment is not modelled as a dimension. It interacts with the exchange-level dimensions of this model in two distinct ways.¶

First, cross-domain deployment tightens the practical value sets on existing exchange-level dimensions:¶

• D4: local-policy becomes insufficient where the receiver does not recognise the caller's operator as authoritative for the receiver's resources; direct or derived authorization is required.¶

• D5: pre-bound binding does not scale across organisations; federated registry-resolved discovery becomes attractive.¶

• D8: participant-verifiable becomes weaker in practice, because relying parties are more often outside the domain that operates the exchange; third-party-verifiable becomes attractive.¶

• D4 (chain depth): transitive delegation across organisations places the strongest demands on credential chainability, pointing to derived-chain.¶

The substrate options for globally meaningful identity (verifiable identifier formats, federated identity providers, publicly anchored certificate chains) are a binding question rather than a dimensional value.¶

Second, cross-domain deployment surfaces concerns whose scope is not a single exchange and which are therefore not captured by any exchange-level dimension. Examples include cumulative behavioral bounds accumulated across a delegation chain, source-asserted constraints carried with data across subsequent crossings, and revocation or invalidation freshness applied consistently across artifacts of different lifetimes. These concerns are neither properties of the substrate below nor properties of a single exchange at the agent protocol layer; they are properties of the delegation lineage as a whole. This model does not define these concerns, does not exclude them, and does not assign them to any specific layer.¶

10. Recognizable Patterns

For orientation, several combinations of dimensional values correspond to patterns that readers may already recognise. The following are illustrative, not exhaustive:¶

• Simple tool call: strict request-response (D1), atomic output (D2), local-policy authorization (D4), and pre-bound endpoint (D5). Recognisable as a REST API call or a simple tool invocation.¶

• Tool-using agent: within-association origination (D1), streamed output (D2), derived one-hop authority (D4), and pre-bound endpoint (D5). Recognisable as an LLM with function calling.¶

• Approval-gated job: within-association origination (D1), streamed output (D2), suspend-resume lifecycle (D3), local-policy authorization (D4), and pre-bound endpoint (D5). Recognisable as a continuous-integration pipeline awaiting manual approval.¶

• Async submit-and-poll: strict request-response (D1), atomic output (D2), no lifecycle continuity within a single exchange (D3), and callee-held state (D6). Asynchrony is realized above the exchange level as multiple independent exchanges keyed by a callee-held identifier. Recognisable as the ACP POST /runs and GET /runs/{id} pattern, or an OpenAPI job-submission API.¶

• Async streamed-updates: within-association origination (D1), streamed output (D2), no or durable-reattach lifecycle (D3), and callee-held state (D6). Recognisable as A2A tasks/sendSubscribe or MCP notifications during a task.¶

11. Dimensions Considered but Not Adopted

During the construction of this model, additional candidate dimensions were considered and set aside. They are recorded here so that the boundaries of the adopted model are explicit and so that future revisions can revisit them if new evidence motivates doing so.¶

• Communication cardinality. Candidate values: one-to-one, one-to-many, many-to-many. In current agentic-protocol practice, one-to-many is realised as repeated one-to-one exchanges and does not introduce protocol-distinct primitives. Many-to-many would require group identity, dynamic membership, and replicated delivery semantics; no present protocol proposal requires this as a first-class exchange primitive.¶

• Delegation transitivity. Candidate values: none, single-hop, transitive. At a single exchange the protocol-visible distinction lies in the credential shape and is captured by D4. Chain-scoped properties -- lineage continuity, cumulative behavior across hops, and per-lineage invalidation propagation -- have a scope broader than a single exchange and are therefore not captured by any dimension in this model, nor by any extension of D4.¶

• Mediation role. Candidate values: none, forwarding, translating, validating. The distinguishing behaviours of a mediator describe what the mediator does on its two interfaces taken together rather than a property of a single exchange. The protocol-layer needs of mediation are captured by extensions (EXT-AUTHEV, EXT-AUDIT, EXT-XLATE) on the baseline.¶

• Modality profile. Candidate values: single, negotiated-multi. Only negotiated-multi is exercised distinctly, and the negotiation primitive is captured as an extension (EXT-MODNEG).¶

• Failure and delivery semantics. Candidate values: at-most-once, at-least-once, idempotent-keyed. In current practice the agent layer is uniformly at-most-once and stronger guarantees, where needed, are provided by the substrate.¶

• Trust domain span. Candidate values: intra-domain, cross-domain. Cross-domain operation partially interacts with exchange-level dimensions (via the deployment-context modifier of Section 9) and partially surfaces concerns whose scope is broader than a single exchange (as noted in Section 9). The former is captured by the modifier. The latter is not addressed by this document.¶

• Callback / reverse-initiation. Candidate values: none, callback-endpoint. Patterns where the callee opens a fresh association back to the caller (webhook or callback URL) reverse the roles between exchanges rather than expose a new value within an exchange. The protocol-visible surface of such patterns is a pair of exchanges (submit + callback) each of which is separately characterizable by the eight dimensions. The pattern is therefore represented in this model as two exchanges, not as a new dimension. A separate dimension may be warranted if future proposals introduce callback semantics that the pair-of-exchanges representation cannot capture cleanly.¶

• Operation semantics. Candidate values: query, execute, delegate, discover, and similar verb classes. Distinctions that are protocol-visible in exchange shape are already captured (delegation under D4, discovery under D5, output shape under D2). The remaining distinction, such as query versus execute, is a semantic label on the operation that does not change the shape of the exchange, and is therefore not graded by this model.¶

• Intent placement. Candidate values: wire-primitive, body-field. Whether intent is expressed as a first-class wire verb or as a field in the message body is consequential but is a substrate-realization choice (Section 4), in the same way that the realization of D1 is a substrate choice.¶

• Evidence presence. Candidate values: present, absent. Presence of a record is a primitive used by an extension to establish a D8 value, not a separate property; absence collapses to D8 = none (Section 5.8).¶

12. Open Questions

The following questions are surfaced by the model but are not resolved by this document. They are recorded here so that reviewers and subsequent revisions can address them explicitly. This document does not attempt to answer them; it treats them as inputs to future revisions, to companion documents, or to community discussion.¶

• Mediator behaviour on D4. A mediator receiving an inbound request and issuing an outbound request on the caller's behalf may either preserve the originator's authorization chain to the downstream target, or terminate the chain at the mediator and present its own credentials downstream. The two options have materially different audit, trust, and compromise-blast-radius implications.¶

• Realization of long-running interactions on D3. A long-running task can be realized as durable-reattach with a persistent task identifier at the protocol layer, or as repeated independent exchanges above the protocol layer. The choice affects interoperability of the reattach primitive across substrates and determines whether the multi-round structure is visible at the agent-protocol layer.¶

• Boundary between baseline and extension. Several extensions in Section 8 may warrant cross-proposal standardisation rather than per-proposal treatment. Where the boundary sits will be revisited as evidence accumulates on which extensions are broadly needed.¶

• Substrate profiling scope. The substrate facets in Section 4 each admit multiple existing binding candidates. Which bindings this work profiles, and which it leaves to implementations, will shape the scope of any subsequent standardisation effort.¶

• Candidate dimensions pending evidence. Several candidates in Section 11 were set aside because current deployments do not exercise them distinctively. Operators or implementers with deployments that exercise those candidates are encouraged to surface them so that the model can evolve.¶

• Broader-scope concerns. Concerns whose natural scope is a delegation lineage, a cross-crossing behavioral aggregate, or a data-use policy persisting across multiple exchanges are not modelled by the dimensions of Section 5, are not substrate binding questions in the sense of Section 4, and are not extensions in the sense of Section 8. Whether they are best addressed by extending existing agent protocol proposals, by defining a distinct layer above the agent protocol, or by profiling substrates, is not addressed here. This document treats such concerns as work belonging to a companion effort or to a future revision that adopts a broader scope.¶

• Delegation governance. Scope validation, contract negotiation, budget approval, and similar pre- and post-action events are placed at the orchestration layer (Section 3). How their per-action evidence is bound to the governance decision above the exchange is not addressed here.¶

• Populating the comparison table. The process by which mappings are proposed, evidenced against specification text, and confirmed is to be defined, so that the table remains a neutral reading rather than a set of self-descriptions.¶

• Substrate-side companion model. A model of substrate internals (for example, which transports support callee-originated messages, or which identity substrates offer independently pinnable roots) would complement this one; the cross-referencing between the two is to be defined.¶

13. Security Considerations

This document defines a descriptive model and no protocol mechanism; it introduces no new attack surface of its own. Misreading the model can, however, lead to incorrect security conclusions:¶

• Overreading D8. A third-party-verifiable value describes how far an evidence object can be verified, not what it proves (Section 5.8). Treating invocation evidence as evidence of authorization or correct execution is an error.¶

• Offered root versus verified evidence. D8 grades the root an exchange offers. An offered root may be unusable later (log unavailable, key revoked or lost, records not retained). Relying parties must perform verification and must not infer it from the D8 value.¶

• Self-contained versus self-rooted. A signed, self-contained object whose verification root is vouched for only by a participant, including an operating platform, is participant-verifiable. Presenting such an object as third-party-verifiable overstates the trust a non-participant can place in it.¶

• Per-crossing reading of D4. A derived-* value at a crossing does not establish uninterrupted delegation continuity to the originator (Section 5.4). Security decisions that depend on lineage continuity require mechanisms outside this model.¶

14. IANA Considerations

This document has no IANA actions.¶

Acknowledgements

The author thanks the wider agent-protocol community for early discussions that shaped this model. The author thanks Iman Schrock, Blake Morrison, Mikhail Sergeev, Chris Hood, Sumit Ahuja, and Steven Mih for discussions that shaped the evidence-verifiability dimension, the clarification of D4, and the separation of authorization and accountability evidence, and thanks Iman in particular for sharpening the definitions and sharing refined draft.¶

Author's Address