A Dimensional Model for Characterizing AI Agent Protocol Proposals and Their Substrates
draft-foroughi-agent-protocol-dimensions-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Parisa Foroughi | ||
| Last updated | 2026-10-19 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-foroughi-agent-protocol-dimensions-01
Individual Submission P. Foroughi
Internet-Draft Nokia
Intended status: Informational 19 October 2026
Expires: 22 April 2027
A Dimensional Model for Characterizing AI Agent Protocol Proposals and
Their Substrates
draft-foroughi-agent-protocol-dimensions-01
Abstract
Discussions about agent protocols are frequently muddied by
overloaded terms; asks such as "we need a session protocol" or "we
need cross-domain support" bundle several distinct concerns across
transport, agent protocol, and orchestration layers. This document
offers a dimensional model that routes each concern to its proper
layer.
The document defines a small set of protocol-visible dimensions for
characterizing AI agent protocol interactions and applies them to
representative agentic protocol proposals (A2A, MCP, the ACP
invocation surface of the AGNTCY stack, and AGTP) alongside their
substrate bindings, making explicit which dimensions each proposal
owns at the protocol layer and which it inherits from its substrate.
The document does not rank proposals and does not prescribe an
architecture. It is standalone: it neither depends on nor prescribes
any use-case or requirements document.
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.
Foroughi Expires 22 April 2027 [Page 1]
Internet-Draft Agent Protocol Dimensions October 2026
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
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Non-goals . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Standalone character . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Layered View . . . . . . . . . . . . . . . . . . . . . . . . 5
4. The Protocol's Substrate . . . . . . . . . . . . . . . . . . 7
5. Dimensions . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Dimension 1 (D1): Message Origination Within an
Association . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Dimension 2 (D2): Output Cadence . . . . . . . . . . . . 9
5.3. Dimension 3 (D3): Lifecycle Control . . . . . . . . . . . 9
5.4. Dimension 4 (D4): Authorization Derivation . . . . . . . 10
5.5. Dimension 5 (D5): Endpoint Binding . . . . . . . . . . . 11
5.6. Dimension 6 (D6): State Locality . . . . . . . . . . . . 11
5.7. Dimension 7 (D7): Result Addressability . . . . . . . . . 11
5.8. Dimension 8 (D8): Evidence Verifiability . . . . . . . . 12
6. Applying the Model to Representative Agentic Protocol
Proposals . . . . . . . . . . . . . . . . . . . . . . . . 13
7. What the Model Enables . . . . . . . . . . . . . . . . . . . 17
8. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Deployment-Context Modifier: Cross-Domain Operation . . . . . 19
10. Recognizable Patterns . . . . . . . . . . . . . . . . . . . . 19
11. Dimensions Considered but Not Adopted . . . . . . . . . . . . 20
12. Open Questions . . . . . . . . . . . . . . . . . . . . . . . 22
13. Security Considerations . . . . . . . . . . . . . . . . . . . 23
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction
Foroughi Expires 22 April 2027 [Page 2]
Internet-Draft Agent Protocol Dimensions October 2026
1.1. Scope
Discussions about agent protocols are frequently muddied by
overloaded terms. A single ask -- "we need a session protocol" or
"we need cross-domain support" -- typically bundles several distinct
concerns spread across transport, agent protocol, and orchestration
layers, and the conversation loses precision fast. This document
offers a dimensional model that routes such statements to their
proper layer: which piece is a concrete agent-protocol choice, which
piece is substrate, and which piece belongs to broader-scope work
outside the model.
The model has three outputs:
* A small set of protocol-visible dimensions with fixed value
domains, independently characterizable at the exchange level,
sufficient to describe an agent protocol exchange (Section 5).
* A comparison table placing representative agentic protocol
proposals (A2A, MCP, the ACP invocation surface of the AGNTCY
stack, and AGTP) in the dimensional space, together with the
substrates they bind to (Section 6).
* A statement of what the model enables analytically (Section 7).
1.2. Non-goals
* This document does not rank protocol proposals. Different
proposals occupy different regions of the dimensional space and
may serve complementary purposes at the exchange level.
* This document does not define a new agent protocol or wire format.
* This document does not define an architectural framework.
* This document does not enumerate use cases and does not derive
requirements. The dimensional model is independent of any
specific use-case corpus; the comparison table in Section 6 is
offered as a starting point that the authors and the community
will iterate on. Similarly, the set of proposals covered in the
comparison table may be expanded in subsequent revisions.
* This document characterizes single exchanges between two
endpoints. Multi-party protocols, whose properties are not
reducible to a set of two-endpoint exchanges, are out of scope of
this draft.
Foroughi Expires 22 April 2027 [Page 3]
Internet-Draft Agent Protocol Dimensions October 2026
* This document does not characterize the internals of substrates.
The substrate columns of Section 6 anchor each of the proposals to
the respective substrates it binds to and it does not describe the
full model of those substrates. A substrate-side model would be
complementary, and the two are expected to cross-reference each
other.
1.3. Standalone character
This document does not depend on and does not prescribe any use-case
document, requirements document, or architectural framework. Where a
dimensional value or extension is illustrated with an example of
practical use, the example is included for orientation only, not as a
normative reference.
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.
Foroughi Expires 22 April 2027 [Page 4]
Internet-Draft Agent Protocol Dimensions October 2026
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 |
Foroughi Expires 22 April 2027 [Page 5]
Internet-Draft Agent Protocol Dimensions October 2026
| - 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 |
+===================================================================+
Foroughi Expires 22 April 2027 [Page 6]
Internet-Draft Agent Protocol Dimensions October 2026
Figure 1: Three layers of interest for exchange-level analysis of
agentic protocol interactions. Substrates are shown inside the
layer that consumes them.
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.
Foroughi Expires 22 April 2027 [Page 7]
Internet-Draft Agent Protocol Dimensions October 2026
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.
5.1. Dimension 1 (D1): Message Origination Within an Association
In current practice, the transport-level association between two
agent endpoints is opened by the caller in essentially all agentic
protocol proposals. This dimension does not capture who opens the
association; rather, it captures whether the callee is permitted to
originate messages _within_ an already-open association, without
waiting for a fresh caller request.
Values:
* none: the callee may only produce messages in response to a caller
message. The interaction is strict request-response.
Foroughi Expires 22 April 2027 [Page 8]
Internet-Draft Agent Protocol Dimensions October 2026
* within-association: the callee may originate messages to the
caller after the association is established, supporting streamed
intermediate results, notifications, and pause-or-resume
signalling.
Contemporary agentic protocol proposals uniformly expose within-
association origination as a first-class primitive (for example,
streamed task updates and server-sent notifications). Where an
agentic protocol proposal declines to expose this and restricts
itself to strict request-response, the value is none.
The mechanism by which within-association callee origination is
realized -- SSE, WebSocket, HTTP/2 server push, HTTP/3 server-
initiated streams, stdio bidirectionality -- is a substrate choice.
The decision to expose within-association callee origination as a
semantic primitive of the protocol (for example, named notification
messages or streamed status events with defined semantics) is a
protocol-layer choice.
5.2. Dimension 2 (D2): Output Cadence
The temporal shape of a task's output. Values:
* atomic: a single request yields a single response.
* streamed: a single request yields a sequence of partial outputs
over time.
Contemporary agent-to-agent interfaces default to streamed. Atomic
is the degenerate substrate-layer case (for example, a simple tool
call) and is retained here for completeness.
5.3. Dimension 3 (D3): Lifecycle Control
Whether and how a task may pause or persist beyond a single
association. Values:
* none: the task runs to completion within the originating exchange
without pause or reattachment.
* suspend-resume: the task may pause awaiting an out-of-band input
(such as an authorization decision) and resume.
* durable-reattach: the task survives transport interruption and may
be reattached using a persistent task identifier.
Foroughi Expires 22 April 2027 [Page 9]
Internet-Draft Agent Protocol Dimensions October 2026
Interactions with an approval or human-in-the-loop step exercise
suspend-resume. Interactions whose task outlives the transport
association exercise durable-reattach; an alternative realization
maintains state at the application layer with repeated independent
exchanges, in which case D3 is none and the multi-round structure is
invisible at the protocol layer.
5.4. Dimension 4 (D4): Authorization Derivation
The source of the authority under which an agent acts. Values:
* direct: the agent acts under authority granted directly to it by
the request originator.
* derived-1hop: the credential presented at this crossing expresses
authority derived from a single prior authorization, with scope
narrowing.
* derived-chain: the credential presented at this crossing expresses
authority derived through two or more derivation steps, each with
scope narrowing.
* local-policy: the agent acts under its own standing authority
granted by its operator, applying local rules upon authentication
of the requester.
Tool-using agents typically exercise derived-1hop. Multi-hop
delegation across administrative boundaries exercises derived-chain.
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 (yielding a derived-*
value on the outbound leg) or terminate the chain at the mediator and
present its own credentials downstream (yielding local-policy). The
two options have materially different audit, trust, and compromise-
blast-radius implications. This document does not prescribe a
choice: the model records which value each proposal or deployment
realizes, and treats the reasoning behind the choice as broader-
scope.
D4 describes what is presented at a given crossing. A derived-*
value at that crossing does not establish uninterrupted delegation
continuity back to the originator. Where the delegation information
is carried (for example, protocol headers versus a token in the
message body) is a substrate-realization choice and does not change
the D4 value. What the receiving agent can verify independently
about the presented credential is a distinct property captured by D8
(Section 5.8), not by D4.
Foroughi Expires 22 April 2027 [Page 10]
Internet-Draft Agent Protocol Dimensions October 2026
Accordingly, the value derived-chain describes the credential form
carried at a single crossing. It does not by itself model lineage
continuity across the delegation chain, cumulative behavior across
hops, or revocation propagation with bounded freshness. Those
properties have a scope broader than a single exchange and are
therefore outside the scope of this model.
5.5. Dimension 5 (D5): Endpoint Binding
How the calling party comes to know the addressable identifier of its
counterpart. Values:
* pre-bound: the endpoint is known to the caller before the exchange
begins, by configuration or out-of-band agreement.
* registry-resolved: the caller queries a third-party registry at
runtime to obtain the endpoint and its advertised capabilities.
Most current agentic-protocol deployments proceed pre-bound, with
per-agent capability self-description published at a Well-Known URI.
Federated agent directories exercise registry-resolved. Mediator
patterns may internalize the discovery step, performing registry-
resolved dispatch on behalf of pre-bound callers.
5.6. Dimension 6 (D6): State Locality
Where the state required to continue a task across messages is
maintained. Values:
* caller-held: the caller carries the necessary context on each
message; the callee is stateless across messages.
* callee-held: the callee maintains task state keyed by an
identifier; the caller references the state by that identifier.
Current agentic protocols implicitly assume callee-held, which
combines naturally with D3 durable-reattach. REST-style and tool-
call-oriented protocols realize the caller-held alternative; D6
admits both values.
5.7. Dimension 7 (D7): Result Addressability
How the output of a task is exposed. Values:
* inline-only: the result is contained in the response.
Foroughi Expires 22 April 2027 [Page 11]
Internet-Draft Agent Protocol Dimensions October 2026
* referenceable-artifact: the result is produced as a named artifact
with an identifier; the artifact can be fetched, shared with a
third party, or referenced in subsequent calls, and may outlive
the producing task.
Contemporary agentic interfaces default to inline-only. Consensus
outcomes, long-running artifacts, and structured audit records are
natural candidates for referenceable-artifact semantics.
In this document, the term "artifact" in the value name
referenceable-artifact refers to the addressability of a task result
at the agent protocol layer. It is used in a distinct sense from any
use of "artifact" as a control-plane carriage object in adjacent
work.
5.8. Dimension 8 (D8): Evidence Verifiability
The verification root that an exchange offers for its evidence
objects, characterized by whom a relying party must trust in order to
verify them. D8 is readable per exchange from what the exchange
presents. It grades the offered root, not whether verification later
succeeds; log liveness, key availability, and retention are substrate
properties (Section 4) and are outside the model.
For the purposes of D8, the participants in an exchange include the
caller, the callee, and any platform that operates the exchange on
behalf of either. Values:
* none: the exchange offers no evidence object, or offers one
without an independently identifiable verification root.
* participant-verifiable: the evidence object can be verified only
by trusting one or more participants.
* third-party-verifiable: a non-participant can verify the evidence
object by pinning its verification root independently of every
participant.
The grading turns on who a non-participant must trust, not on whether
the evidence object is self-contained. Self-contained and self-
rooted are different properties: a signed, self-contained object
whose signing key is vouched for only by a participant grades
participant-verifiable, and an artifact with no independently
identifiable root grades none.
Presence of an evidence object is implicit in D8 rather than an
explicit value. Absence collapses to none, but presence alone does
not lift an exchange above none. Whether a given record is present,
Foroughi Expires 22 April 2027 [Page 12]
Internet-Draft Agent Protocol Dimensions October 2026
absent, or "not found in this evidence set" is a matter for the
protocol mechanism of the extension that carries the record
(Section 8), not a value of this dimension.
The top value is mechanism-agnostic. It is realized through a
substrate (for example, a transparency service, a publicly anchored
certificate chain, or an independently resolvable identifier), but no
specific path is implied by the value.
Non-inference. Verification reach and the strength of the attested
claim are orthogonal. D8 grades how far an evidence object can be
verified, not what it proves. A third-party-verifiable invocation
record remains evidence of invocation only; it does not establish
that the invoked action was authorized, correct, or completed.
The value applies independently to each evidence object. Where an
exchange carries several kinds of evidence (for example,
authorization evidence and post-action evidence), each may be graded
separately and the per-kind value reported.
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
Foroughi Expires 22 April 2027 [Page 13]
Internet-Draft Agent Protocol Dimensions October 2026
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.
+==============+===============+==============+===========+============+
|Dimension |A2A |MCP |ACP |AGTP [note |
| | | |(AGNTCY) |2] |
| | | |[note 1] | |
+==============+===============+==============+===========+============+
|D1 Message |within- |within- |within- |none |
|origination |association |association |association|(request- |
| | | | |response per|
| | | | |method |
| | | | |invocation) |
+--------------+---------------+--------------+-----------+------------+
|D2 Output |streamed |streamed |streamed |unclear |
|cadence | | | | |
+--------------+---------------+--------------+-----------+------------+
|D3 Lifecycle |supports |none (session-|supports |supports |
|control |suspend-resume |scoped; no |none and |suspend- |
| |and durable- |task-level |suspend- |resume |
| |reattach |pause or |resume |(SUSPEND |
| |(input-required|reattach) |(stateless |method) |
| |state; tasks/ | |runs; | |
| |resubscribe on | |thread runs| |
| |taskId) | |with | |
| | | |interrupt | |
| | | |semantics) | |
+--------------+---------------+--------------+-----------+------------+
|D4 |not specified |not specified |not |unclear |
|Authorization |(deployment |(OAuth 2.1 |specified |(DELEGATE |
|derivation |defines via |profile |by ACP |method) |
| |AgentCard |evolving) | | |
| |authentication)| | | |
+--------------+---------------+--------------+-----------+------------+
|D5 Endpoint |pre-bound |pre-bound |registry- |supports |
|binding |(Agent Card at |(out-of-band |resolved |pre-bound |
| |Well-Known URI)|configuration)|(Agent |(agtp:// |
| | | |Directory +|direct |
| | | |OASF) |addressing) |
| | | | |and |
| | | | |registry- |
| | | | |resolved |
| | | | |(DISCOVER, |
Foroughi Expires 22 April 2027 [Page 14]
Internet-Draft Agent Protocol Dimensions October 2026
| | | | |Agent Naming|
| | | | |System, |
| | | | |Presence) |
+--------------+---------------+--------------+-----------+------------+
|D6 State |callee-held |callee-held |callee-held|callee-held |
|locality |(taskId) |(sessionId) |(thread_id,|(Session-ID,|
| | | |run_id) |Task-ID) |
+--------------+---------------+--------------+-----------+------------+
|D7 Result |supports |inline-only |inline-only|unclear |
|addressability|inline-only and| | | |
| |referenceable- | | | |
| |artifact | | | |
| |(Artifact | | | |
| |objects) | | | |
+--------------+---------------+--------------+-----------+------------+
|D8 Evidence |unclear |unclear |unclear |supports |
|verifiability | | | |none, |
| | | | |participant-|
| | | | |verifiable, |
| | | | |and third- |
| | | | |party- |
| | | | |verifiable |
| | | | |(by trust |
| | | | |tier and |
| | | | |verification|
| | | | |path) |
+--------------+---------------+--------------+-----------+------------+
Table 1: Dimensional signature per proposal.
Foroughi Expires 22 April 2027 [Page 15]
Internet-Draft Agent Protocol Dimensions October 2026
+========+==========================+================+==============+
|Proposal| Transport substrate |Identity |Discovery |
| | |substrate |substrate |
+========+==========================+================+==============+
|A2A | HTTP with SSE or |OAuth 2.1 with |Well-Known URI|
| | Streamable HTTP; SLIM or |resource |(Agent Card) |
| | AGTP available as |indicators | |
| | alternative | | |
+--------+--------------------------+----------------+--------------+
|MCP | stdio; HTTP with SSE or |OAuth 2.1 |not specified |
| | Streamable HTTP; SLIM or |(profile |(out-of-band) |
| | AGTP available as |evolving) | |
| | alternative | | |
+--------+--------------------------+----------------+--------------+
|ACP | HTTP; SLIM (draft-mpsb- |pluggable |Agent |
|(AGNTCY)| agntcy-slim) or AGTP |(AGNTCY |Directory |
| | available as alternative |Identity: |Service (OASF |
| | |verifiable |records) |
| | |credentials, | |
| | |agent badges) | |
+--------+--------------------------+----------------+--------------+
|AGTP | TCP/TLS, QUIC (agtp://) |Agent-ID |Agent Naming |
| | |derived from |System; |
| | |Agent Genesis; |Presence |
| | |trust tiers |overlay (AGTP |
| | |anchored in DNS |companion |
| | |(ACME), a |specification)|
| | |transparency | |
| | |log, DNS plus | |
| | |blockchain, or | |
| | |organizational | |
| | |assertion (AGTP | |
| | |companion | |
| | |specification) | |
+--------+--------------------------+----------------+--------------+
Table 2: Substrate bindings per proposal.
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
Foroughi Expires 22 April 2027 [Page 16]
Internet-Draft Agent Protocol Dimensions October 2026
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.
Foroughi Expires 22 April 2027 [Page 17]
Internet-Draft Agent Protocol Dimensions October 2026
* *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.
Foroughi Expires 22 April 2027 [Page 18]
Internet-Draft Agent Protocol Dimensions October 2026
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:
Foroughi Expires 22 April 2027 [Page 19]
Internet-Draft Agent Protocol Dimensions October 2026
* 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.
Foroughi Expires 22 April 2027 [Page 20]
Internet-Draft Agent Protocol Dimensions October 2026
* 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.
Foroughi Expires 22 April 2027 [Page 21]
Internet-Draft Agent Protocol Dimensions October 2026
* 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
Foroughi Expires 22 April 2027 [Page 22]
Internet-Draft Agent Protocol Dimensions October 2026
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.
Foroughi Expires 22 April 2027 [Page 23]
Internet-Draft Agent Protocol Dimensions October 2026
* 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
Parisa Foroughi
Nokia
Email: parisa.foroughi@nokia.com
Foroughi Expires 22 April 2027 [Page 24]