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

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

parisa.foroughi@nokia.com

Applications and Real-Time Individual Submission agent agent protocol dimensional model substrate AI 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, and the ACP invocation surface of the AGNTCY stack) 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.

Introduction

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 ().
A comparison table placing representative agentic protocol proposals (A2A, MCP, and the ACP invocation surface of the AGNTCY stack) in the dimensional space, together with the substrates they bind to ().
A statement of what the model enables analytically ().

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

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.

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, and the ACP invocation surface of the AGNTCY stack 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 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 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.

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. shows the three layers of interest and, within each, the substrates the layer consumes.

Three layers of interest for exchange-level analysis of agentic protocol interactions. Substrates are shown inside the layer that consumes them. 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.

The Protocol's Substrate Several of the dimensions in 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.

Dimensions The model identifies seven 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 () and an optional deployment-context modifier (). Additional dimensions were considered and set aside; these are recorded in to make the boundary of the adopted model explicit.

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

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.

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.

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.

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 agent acts under authority derived from a single prior authorization, with verifiable derivation and scope narrowing.
derived-chain: the agent acts under authority derived through two or more derivation steps, each cryptographically verifiable and progressively narrowed back to the originator.
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. 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.

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.

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.

Dimension 7 (D7): Result Addressability How the output of a task is exposed. Values:

inline-only: the result is contained in the response.
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.

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. The dimensional signature per proposal is given in . The substrate bindings per proposal are given in . Dimensional signature per proposal.

Dimension	A2A	MCP	ACP (AGNTCY) [note 1]
D1 Message origination	within-association	within-association	within-association
D2 Output cadence	streamed	streamed	streamed
D3 Lifecycle control	supports suspend-resume and durable-reattach (input-required state; tasks/resubscribe on taskId)	none (session-scoped; no task-level pause or reattach)	supports none and suspend-resume (stateless runs; thread runs with interrupt semantics)
D4 Authorization derivation	not specified (deployment defines via AgentCard authentication)	not specified (OAuth 2.1 profile evolving)	not specified by ACP
D5 Endpoint binding	pre-bound (Agent Card at Well-Known URI)	pre-bound (out-of-band configuration)	registry-resolved (Agent Directory + OASF)
D6 State locality	callee-held (taskId)	callee-held (sessionId)	callee-held (thread_id, run_id)
D7 Result addressability	supports inline-only and referenceable-artifact (Artifact objects)	inline-only	inline-only

Substrate bindings per proposal.

Proposal	Transport substrate	Identity substrate	Discovery substrate
A2A	HTTP with SSE or Streamable HTTP; SLIM available as alternative	OAuth 2.1 with resource indicators	Well-Known URI (Agent Card)
MCP	stdio; HTTP with SSE or Streamable HTTP; SLIM available as alternative	OAuth 2.1 (profile evolving)	not specified (out-of-band)
ACP (AGNTCY)	HTTP; SLIM available as alternative (`draft-mpsb-agntcy-slim`)	pluggable (AGNTCY Identity: verifiable credentials, agent badges)	Agent Directory Service (OASF records)

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. The substrate columns anchor the layered view of . 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.

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.

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-AUDIT: structured audit record exchange describing actions taken on behalf of requesting parties.
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.

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

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.

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-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 ) and partially surfaces concerns whose scope is broader than a single exchange (as noted in ). 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 seven 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.

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 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 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 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 , are not substrate binding questions in the sense of , and are not extensions in the sense of . 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.

Security Considerations To be completed in future revisions of this document.

IANA Considerations This document has no IANA actions.

Acknowledgements The author thanks colleagues at Nokia and the wider agent-protocol community for early discussions that shaped this model.