IDL: A Semantic Information Model for Agent Communication
draft-feng-agentproto-idl-info-model-00
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 | Chong Feng | ||
| Last updated | 2026-07-27 | ||
| 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-feng-agentproto-idl-info-model-00
Network Working Group C. Feng
Internet-Draft 28 July 2026
Intended status: Informational
Expires: 29 January 2027
IDL: A Semantic Information Model for Agent Communication
draft-feng-agentproto-idl-info-model-00
Abstract
This document defines the information model for IDL (Intent
Description Language), a protocol-independent semantic model for
communication among autonomous AI agents and between agents and
tools.
Autonomous agents are fundamentally different. An agent possesses
its own reasoning, may negotiate parameters, may refuse or modify
requests, and may initiate interactions on its own behalf.
Describing an agent as if it were a deterministic endpoint loses
exactly the properties that make it an agent.
IDL answers: "what can this autonomous participant contribute to an
intent, under what constraints, and through what interaction
patterns?" IDL is not a transport, session, discovery, or messaging
protocol. It is a semantic model that enables heterogeneous agents
to describe identity, capabilities, autonomy boundaries, context
requirements, governance interfaces, and intent participation before
and during collaboration.
This document defines the IDL information model and its relationship
to agent communication protocols and governance frameworks. It does
not define a normative JSON representation or a serialization-level
conformance language. Protocol-specific mappings, including an AIN/
CDL profile, are informative.
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/.
Feng Expires 29 January 2027 [Page 1]
Internet-Draft IDL Semantic Information Model July 2026
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 29 January 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.2. Design Principles . . . . . . . . . . . . . . . . . . . . 5
1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Requirements Language . . . . . . . . . . . . . . . . . . 6
1.5. Key Terminology . . . . . . . . . . . . . . . . . . . . . 6
2. Positioning in the Agent Communication Stack . . . . . . . . 7
2.1. Semantic Layer . . . . . . . . . . . . . . . . . . . . . 7
2.2. What Makes an Agent Description Different . . . . . . . . 7
3. IDL Information Model . . . . . . . . . . . . . . . . . . . . 8
3.1. Agent Identity . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. Agent Class Taxonomy . . . . . . . . . . . . . . . . 10
3.1.2. Role Definitions . . . . . . . . . . . . . . . . . . 11
3.2. Capability Declarations . . . . . . . . . . . . . . . . . 12
3.2.1. Backing Interfaces . . . . . . . . . . . . . . . . . 14
3.3. Autonomy Envelope . . . . . . . . . . . . . . . . . . . . 14
3.3.1. Autonomy Levels . . . . . . . . . . . . . . . . . . . 15
3.3.2. Scope Constraints . . . . . . . . . . . . . . . . . . 15
3.3.3. Escalation Policy . . . . . . . . . . . . . . . . . . 17
3.4. Intent Participation Model . . . . . . . . . . . . . . . 17
3.4.1. Supported Intent Classes . . . . . . . . . . . . . . 18
3.4.2. Interaction Patterns . . . . . . . . . . . . . . . . 19
3.4.3. Negotiation Capabilities . . . . . . . . . . . . . . 19
3.4.4. Intent Lifecycle Participation . . . . . . . . . . . 20
3.5. Context Model . . . . . . . . . . . . . . . . . . . . . . 21
Feng Expires 29 January 2027 [Page 2]
Internet-Draft IDL Semantic Information Model July 2026
3.5.1. Context Categories . . . . . . . . . . . . . . . . . 21
3.5.2. Context Gaps and Requests . . . . . . . . . . . . . . 22
3.6. Governance Interface Model . . . . . . . . . . . . . . . 23
4. Illustrative JSON Representation . . . . . . . . . . . . . . 24
4.1. Top-Level Structure . . . . . . . . . . . . . . . . . . . 24
4.2. Complete Example . . . . . . . . . . . . . . . . . . . . 25
5. Integration with Agent Communication Protocols . . . . . . . 32
5.1. Integration Modes . . . . . . . . . . . . . . . . . . . . 32
5.2. Capability Identification and Selection . . . . . . . . . 32
5.3. Session Use . . . . . . . . . . . . . . . . . . . . . . . 32
5.4. Relationship to Existing Protocols . . . . . . . . . . . 33
6. Relationship to Governance Frameworks . . . . . . . . . . . . 33
6.1. Example Mapping . . . . . . . . . . . . . . . . . . . . . 34
6.2. Governance as a First-Class Property . . . . . . . . . . 35
7. Illustrative Intent Interaction Patterns . . . . . . . . . . 35
7.1. Travel Planning Example . . . . . . . . . . . . . . . . . 35
7.2. Multi-Agent Negotiation Example . . . . . . . . . . . . . 36
8. Security Considerations . . . . . . . . . . . . . . . . . . . 37
8.1. Identity and Trust . . . . . . . . . . . . . . . . . . . 37
8.2. Autonomy Envelope Enforcement . . . . . . . . . . . . . . 37
8.3. Context Sharing . . . . . . . . . . . . . . . . . . . . . 38
8.4. Negotiation Integrity . . . . . . . . . . . . . . . . . . 38
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.1. Normative References . . . . . . . . . . . . . . . . . . 38
10.2. Informative References . . . . . . . . . . . . . . . . . 38
Appendix A. Requirements for a Future IDL Representation . . . . 39
Appendix B. Comparison with Existing Agent Description
Approaches . . . . . . . . . . . . . . . . . . . . . . . 39
Appendix C. AIN/CDL Profile (Informative) . . . . . . . . . . . 40
Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 41
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction
1.1. Problem Statement
Software systems are shifting from deterministic API-driven
automation to autonomous agent-based collaboration. This shift
introduces entities that do not fit the traditional service or API-
endpoint model:
* A *travel planning agent* that collaborates with airline, hotel,
and payment agents while observing a traveler's budget and
approval policy.
* A *procurement agent* that negotiates terms with supplier agents
and escalates commitments above its delegated financial authority.
Feng Expires 29 January 2027 [Page 3]
Internet-Draft IDL Semantic Information Model July 2026
* An *incident response agent* that correlates evidence across
domains, delegates investigations, and recommends or executes
remediation.
These agents share a common characteristic: they are not passive
tools waiting for invocation. They have objectives, reasoning
capabilities, context models, and autonomy boundaries. They may
initiate interactions, request information, negotiate constraints,
and refuse requests that violate their policies.
Current interface description approaches do not capture these
properties:
+===========+================+====================================+
| Approach | What It | What It Misses for Agents |
| | Describes | |
+===========+================+====================================+
| OpenAPI | HTTP endpoints | Agent collaboration is not limited |
| | and payloads | to request-response operations |
+-----------+----------------+------------------------------------+
| MCP tool | Tool name, | A tool does not declare agency, |
| schema | description, | autonomy, or intent participation |
| | input schema | |
+-----------+----------------+------------------------------------+
| A2A Agent | Agent name, | Limited semantics for autonomy, |
| Card | skills, | context, negotiation, and |
| | endpoint | governance |
+-----------+----------------+------------------------------------+
| Service | Location and | Does not describe how an |
| discovery | protocol | autonomous participant |
| | metadata | collaborates |
+-----------+----------------+------------------------------------+
Table 1
The missing piece is an information model for describing *autonomous
participants* — entities that contribute to intents through
reasoning, negotiation, and adaptive behavior rather than
deterministic execution.
The communication framework described in [AIPROTO-FRAMEWORK]
identifies agent selection, capability exchange, context transfer,
and negotiation as important concerns for interoperable agent
communication. IDL provides a shared semantic model for expressing
those concerns independently of the protocol that transports them.
Feng Expires 29 January 2027 [Page 4]
Internet-Draft IDL Semantic Information Model July 2026
1.2. Design Principles
IDL is designed around the following principles:
*Agent, not Server.* Traditional interface descriptions adopt a
server model: the described entity waits for requests and executes
them. IDL describes an autonomous participant that has identity,
delegated authority, obligations, and the ability to initiate action,
negotiate, or refuse.
*Intent-centric, not Operation-centric.* Interface descriptions
describe operations an entity can perform. IDL describes the intents
an agent can participate in, the roles it can play, and how it
interacts with other participants throughout an intent lifecycle.
*Governable by design.* IDL incorporates observability,
controllability, and intervention semantics used by agent governance
frameworks. Every IDL description includes the agent's declared
autonomy boundaries, decision transparency commitments, and
intervention interfaces. [ICON] provides one domain-specific example
of these requirements.
*Protocol-independent.* IDL semantics do not depend on a particular
discovery, transport, session, or messaging protocol. A protocol can
carry an IDL representation, reference one by URI and digest, or map
native fields to the IDL information model.
*Composable with tools and APIs.* An agent capability can reference
the deterministic tools and interfaces that support it without
reducing the agent itself to a tool endpoint.
1.3. Scope
This document defines:
* The IDL information model (Section 3).
* An illustrative JSON representation of the information model
(Section 4).
* Integration principles for agent communication protocols
(Section 5).
* The relationship to agent governance frameworks (Section 6).
* Illustrative intent interaction patterns (Section 7).
This document does not define:
Feng Expires 29 January 2027 [Page 5]
Internet-Draft IDL Semantic Information Model July 2026
* Agent implementation architecture (how an agent is built
internally).
* Agent discovery, transport, session establishment, or message
framing.
* Agent behavior, decision-making, planning, or reasoning
algorithms. IDL declarations are descriptive metadata for
participant selection and protocol interaction; they do not
prescribe or require internal behavior.
* A normative serialization, JSON Schema, canonicalization
algorithm, or media type. These are expected to be defined by a
separate IDL representation specification.
1.4. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 ([RFC2119],
[RFC8174]) when, and only when, they appear in all capitals, as shown
here.
1.5. Key Terminology
* *IDL*: Intent Description Language. The semantic information
model defined by this document for autonomous agent communication.
* *IDL Description*: An instance of the information model defined in
this document. Section 4 illustrates one possible JSON
representation but is not a serialization-level conformance
definition.
* *Agent*: An autonomous software participant with identity,
capabilities, delegated authority, autonomy boundaries, and the
ability to initiate, join, negotiate, or execute intents.
* *Capability URI*: A globally unique identifier for a capability.
IDL treats the URI as an opaque identifier and does not require a
specific URI scheme.
* *Intent Class URI*: A globally unique identifier for a class of
intent. It is also opaque to IDL and independent of protocol
message names.
* *Intent Lifecycle*: The sequence of phases an intent passes
through: discovery, understanding, negotiation, commitment,
execution, verification.
Feng Expires 29 January 2027 [Page 6]
Internet-Draft IDL Semantic Information Model July 2026
* *Autonomy Envelope*: The declared boundaries within which an agent
may act without external approval.
* *Intervention Hook*: A defined interface through which a human or
supervisory system can observe, constrain, or override agent
behavior.
2. Positioning in the Agent Communication Stack
2.1. Semantic Layer
Agent communication requires several separable layers:
Agent collaboration semantics
Identity, capability, intent participation
Context, autonomy, governance
^
| IDL
v
Agent communication protocols
Discovery, session establishment, messaging
Task exchange, streaming
^
v
Internet application transports
HTTP, WebTransport, WebRTC, QUIC, MoQ, and other transports
IDL occupies the semantic layer. Communication protocols can use IDL
to support agent selection, compatibility checks, context planning,
negotiation, authorization decisions, and governance before
exchanging task-specific messages. IDL does not replace those
protocols.
2.2. What Makes an Agent Description Different
API and tool descriptions specify *what an endpoint does when
invoked*. The endpoint itself normally has no discretion: given a
valid input and operation, the contract determines the expected
behavior.
An agent is different in five ways that IDL must capture:
1. *Agency*: The agent can initiate actions, not merely respond.
IDL must describe what the agent may initiate.
2. *Discretion*: The agent may interpret, negotiate, or refuse
requests. IDL must describe the conditions under which these
behaviors occur.
Feng Expires 29 January 2027 [Page 7]
Internet-Draft IDL Semantic Information Model July 2026
3. *Context dependence*: The agent's behavior depends on accumulated
context, not just the current request. IDL must describe the
agent's context model.
4. *Autonomy boundaries*: The agent operates within declared limits.
IDL must describe these boundaries in a form that an external
policy or governance system can evaluate and enforce.
5. *Collaboration patterns*: The agent participates in multi-step,
multi-party intent processes. IDL must describe the interaction
patterns the agent supports.
3. IDL Information Model
The IDL information model consists of six components. Together they
answer: "Who is this agent, what can it contribute, within what
limits, and how does it interact?"
IDL Description
|
+-- 3.1 Agent Identity
+-- 3.2 Capability Declarations
+-- 3.3 Autonomy Envelope
+-- 3.4 Intent Participation Model
+-- 3.5 Context Model
+-- 3.6 Governance Interface Model
3.1. Agent Identity
Agent Identity establishes the agent as a recognizable, accountable
participant across communication and administrative domains.
Feng Expires 29 January 2027 [Page 8]
Internet-Draft IDL Semantic Information Model July 2026
+=====================+==========+==================================+
| Field | Required | Description |
+=====================+==========+==================================+
| agent-id | Yes | Globally unique URI for |
| | | this agent instance |
+---------------------+----------+----------------------------------+
| agent-class | Yes | Agent type classification |
| | | (see Section 3.1.1) |
+---------------------+----------+----------------------------------+
| display-name | Yes | Human-readable name |
+---------------------+----------+----------------------------------+
| description | Yes | Natural language |
| | | description of the agent's |
| | | purpose and behavior |
+---------------------+----------+----------------------------------+
| provider | Yes | Organization or system |
| | | that deploys this agent |
+---------------------+----------+----------------------------------+
| version | Yes | Semantic version of this |
| | | agent's capability |
| | | description |
+---------------------+----------+----------------------------------+
| roles | Yes | Roles this agent can |
| | | assume (see Section 3.1.2) |
+---------------------+----------+----------------------------------+
| trust-domain | No | Administrative trust |
| | | domain this agent belongs |
| | | to |
+---------------------+----------+----------------------------------+
| delegation-chain | No | Chain of authority from |
| | | which this agent derives |
| | | its permissions |
+---------------------+----------+----------------------------------+
| credential-bindings | Yes | Non-empty array of |
| | | bindings between agent-id |
| | | and authenticated session |
| | | principals |
+---------------------+----------+----------------------------------+
Table 2
The credential-bindings array contains one or more authentication
bindings that can associate the agent with an authenticated
communication session. Each binding identifies an authentication
scheme and the subject identifier expected for that scheme; it does
not carry credentials. A protocol mapping selects the applicable
bindings that it supports. Before accepting the identity, provider,
trust-domain, or delegated authority asserted by the IDL description,
Feng Expires 29 January 2027 [Page 9]
Internet-Draft IDL Semantic Information Model July 2026
a receiver MUST compare the authenticated session principal with at
least one applicable binding. If no binding is applicable and
supported, or if none of the applicable bindings matches, the
receiver MUST reject the description or treat it as untrusted for
that session.
+=========+==========+====================================+
| Field | Required | Description |
+=========+==========+====================================+
| scheme | Yes | Authentication subject scheme used |
| | | by the communication protocol |
+---------+----------+------------------------------------+
| subject | Yes | Exact authenticated subject |
| | | identifier expected for the agent |
+---------+----------+------------------------------------+
| issuer | No | Expected credential issuer or |
| | | trust anchor identifier |
+---------+----------+------------------------------------+
Table 3
{
"agent": {
"credential-bindings": [
{
"scheme": "authenticated-workload-identity",
"subject": "spiffe://travel.example/agent/planner",
"issuer": "travel-example-production-ca"
},
{
"scheme": "oauth-client",
"subject": "travel-planner",
"issuer": "https://auth.travel.example"
}
]
}
}
3.1.1. Agent Class Taxonomy
IDL defines a base taxonomy of agent classes. Implementations MAY
extend this taxonomy with domain-specific subclasses.
Feng Expires 29 January 2027 [Page 10]
Internet-Draft IDL Semantic Information Model July 2026
+===============+=============================+=====================+
| Class | Description | Example |
+===============+=============================+=====================+
| diagnostic | Investigates and analyzes | Incident diagnosis |
| | system state | agent |
+---------------+-----------------------------+---------------------+
| optimization | Continuously improves | Logistics |
| | outcomes within constraints | optimization agent |
+---------------+-----------------------------+---------------------+
| assurance | Monitors and enforces | Compliance |
| | objectives | assurance agent |
+---------------+-----------------------------+---------------------+
| orchestration | Coordinates multi-agent | Intent |
| | workflows | orchestration |
| | | agent |
+---------------+-----------------------------+---------------------+
| advisory | Provides analysis and | Security advisory |
| | recommendations without | agent |
| | direct action | |
+---------------+-----------------------------+---------------------+
| execution | Performs specific | Order fulfillment |
| | operations under delegated | agent |
| | authority | |
+---------------+-----------------------------+---------------------+
Table 4
3.1.2. Role Definitions
An agent may assume one or more roles in intent interactions:
Feng Expires 29 January 2027 [Page 11]
Internet-Draft IDL Semantic Information Model July 2026
+=============+==================================================+
| Role | Description |
+=============+==================================================+
| initiator | Can create new intents and solicit participation |
+-------------+--------------------------------------------------+
| contributor | Can join intents initiated by others and |
| | contribute capabilities |
+-------------+--------------------------------------------------+
| negotiator | Can engage in parameter negotiation during |
| | intent establishment |
+-------------+--------------------------------------------------+
| executor | Can perform actions as part of intent |
| | fulfillment |
+-------------+--------------------------------------------------+
| verifier | Can validate that intent outcomes meet declared |
| | objectives |
+-------------+--------------------------------------------------+
| observer | Can monitor intent progress without active |
| | participation |
+-------------+--------------------------------------------------+
Table 5
3.2. Capability Declarations
Capability declarations describe what the agent can contribute.
Unlike tool or API operations, IDL capabilities describe *domains of
competence*, *types of contribution*, and the context and constraints
that apply when the capability participates in an intent.
+==============+==========+=========================================+
| Field | Required | Description |
+==============+==========+=========================================+
| capabilities | Yes | Array of capability |
| | | objects (see below) |
+--------------+----------+-----------------------------------------+
Table 6
Each capability object:
+====================+=============+==============================+
| Field | Required | Description |
+====================+=============+==============================+
| capability-uri | Yes | Globally unique URI for |
| | | discovery, selection, and |
| | | matching |
+--------------------+-------------+------------------------------+
Feng Expires 29 January 2027 [Page 12]
Internet-Draft IDL Semantic Information Model July 2026
| capability-id | Yes | Stable, machine-readable |
| | | identifier unique within the |
| | | IDL description |
+--------------------+-------------+------------------------------+
| name | Yes | Human-readable capability |
| | | name |
+--------------------+-------------+------------------------------+
| description | Yes | Natural language description |
+--------------------+-------------+------------------------------+
| domain | Yes | Capability domain (e.g., |
| | | travel, |
| | | commerce.procurement) |
+--------------------+-------------+------------------------------+
| contribution-type | Yes | What the agent contributes: |
| | | analysis, decision, action, |
| | | validation, information |
+--------------------+-------------+------------------------------+
| schema-dialect | Conditional | Schema language and version |
| | | for input-context and |
| | | output-schema; required when |
| | | either field is present |
+--------------------+-------------+------------------------------+
| input-context | No | Schema describing context |
| | | the agent needs to exercise |
| | | this capability |
+--------------------+-------------+------------------------------+
| output-schema | No | Schema describing what the |
| | | agent produces |
+--------------------+-------------+------------------------------+
| prerequisites | No | Conditions that must hold |
| | | before this capability can |
| | | be engaged |
+--------------------+-------------+------------------------------+
| constraints | No | Limits on when/how this |
| | | capability may be exercised |
+--------------------+-------------+------------------------------+
| delegation-targets | No | Capability URIs this agent |
| | | may invoke on other agents |
+--------------------+-------------+------------------------------+
| backing-interface | No | References to tools, APIs, |
| | | or protocol operations |
| | | supporting the capability |
+--------------------+-------------+------------------------------+
Table 7
Feng Expires 29 January 2027 [Page 13]
Internet-Draft IDL Semantic Information Model July 2026
3.2.1. Backing Interfaces
An agent capability often builds on deterministic tools or API
operations. The backing-interface field connects the high-level
capability to those operational semantics without treating the agent
itself as a tool:
IDL Capability: https://example.org/c/travel-plan
|
backing-interface:
+-- MCP tool: search-flights
+-- OpenAPI operation: reserve-hotel
This allows: - A peer agent to understand the semantic chain from an
agent capability to an underlying deterministic operation. - A
governance system to validate that the agent's declared capabilities
are consistent with the operations it can actually invoke.
3.3. Autonomy Envelope
The Autonomy Envelope declares the boundaries within which an agent
reports that it is prepared to act without external approval. It is
not a grant of authority. Effective autonomy is the intersection of
the declared envelope, the permissions bound to the authenticated
principal, and external policy or session constraints. The most
restrictive applicable limit governs. This component directly
addresses the controllability requirements of [ICON].
+==========+==========+======================================+
| Field | Required | Description |
+==========+==========+======================================+
| autonomy | Yes | Autonomy envelope object (see below) |
+----------+----------+--------------------------------------+
Table 8
Autonomy envelope object:
Feng Expires 29 January 2027 [Page 14]
Internet-Draft IDL Semantic Information Model July 2026
+===================+==========+=================================+
| Field | Required | Description |
+===================+==========+=================================+
| level | Yes | Autonomy level: advisory, |
| | | supervised, bounded, autonomous |
+-------------------+----------+---------------------------------+
| scope-constraints | Yes | Array of scope constraint |
| | | objects |
+-------------------+----------+---------------------------------+
| escalation-policy | Yes | Conditions under which the |
| | | agent MUST escalate to human or |
| | | supervisor |
+-------------------+----------+---------------------------------+
| max-impact | No | Maximum blast radius the agent |
| | | may cause without approval |
+-------------------+----------+---------------------------------+
| time-constraints | No | Time windows within which the |
| | | agent may/may not act |
+-------------------+----------+---------------------------------+
| resource-budget | No | Resource consumption limits |
+-------------------+----------+---------------------------------+
Table 9
3.3.1. Autonomy Levels
+============+========================+======================+
| Level | Agent Declares It Can | Declared Restriction |
+============+========================+======================+
| advisory | Analyze, recommend | Take any action |
+------------+------------------------+----------------------+
| supervised | Propose actions, | Act without approval |
| | execute after approval | |
+------------+------------------------+----------------------+
| bounded | Act within declared | Exceed scope |
| | scope constraints | constraints |
+------------+------------------------+----------------------+
| autonomous | Act within full | Violate escalation |
| | capability range | policy |
+------------+------------------------+----------------------+
Table 10
3.3.2. Scope Constraints
Each scope constraint limits the agent's autonomous action along one
dimension. dimension and operator select the semantics and type of
value; they are not arbitrary labels:
Feng Expires 29 January 2027 [Page 15]
Internet-Draft IDL Semantic Information Model July 2026
{
"dimension": "resource-scope",
"operator": "within",
"value": ["urn:travel:account:alice"],
"description": "Limited to resources owned by this account"
}
Defined dimensions:
+===================+==========+=============================+
| Dimension | Allowed | Value type and semantics |
| | operator | |
+===================+==========+=============================+
| resource-scope | within | Non-empty array of |
| | | resource, account, tenant, |
| | | or domain identifiers |
+-------------------+----------+-----------------------------+
| operation-type | allow, | Non-empty array of |
| | deny | operation-class identifiers |
+-------------------+----------+-----------------------------+
| data-scope | within | Non-empty array of dataset, |
| | | object, field-set, or |
| | | subtree identifiers |
+-------------------+----------+-----------------------------+
| impact-level | max | One of none, low, medium, |
| | | high, critical, in that |
| | | ascending order |
+-------------------+----------+-----------------------------+
| action-magnitude | max | Object containing a non- |
| | | negative numeric amount and |
| | | a domain-defined unit |
+-------------------+----------+-----------------------------+
| transaction-value | max | Object containing a non- |
| | | negative numeric amount and |
| | | an ISO 4217 currency code |
+-------------------+----------+-----------------------------+
Table 11
Constraints on different dimensions are combined by logical AND.
Multiple constraints on the same dimension are intersected; a deny
constraint takes precedence over an allow constraint. An empty
intersection denies the action. An implementation that does not
recognize a dimension, operator, value type, or referenced identifier
MUST treat the action as outside the autonomy envelope and apply the
escalation policy. Absence of a constraint does not grant authority
beyond the permissions established by the authenticated session and
its external policy.
Feng Expires 29 January 2027 [Page 16]
Internet-Draft IDL Semantic Information Model July 2026
3.3.3. Escalation Policy
The escalation policy defines conditions under which the agent MUST
yield control to a human operator or supervisory agent:
{
"escalation-policy": {
"conditions": [
{
"trigger": "impact-exceeds",
"threshold": "medium",
"action": "pause-and-notify",
"target": "supervising-agent"
},
{
"trigger": "confidence-below",
"threshold": 0.7,
"action": "request-approval",
"target": "human-operator"
},
{
"trigger": "scope-boundary",
"action": "halt",
"target": "orchestration-agent"
}
],
"default-action": "halt-and-report"
}
}
3.4. Intent Participation Model
The Intent Participation Model describes how the agent engages in
intent lifecycles. This is the core differentiator between IDL and
traditional capability descriptions: it captures the *interaction
semantics* of an autonomous participant, not just its callable
operations.
These declarations describe advertised participation capabilities and
protocol-visible expectations. They do not prescribe internal
reasoning, planning algorithms, decision-making behavior, or a
required strategy for fulfilling an intent. Conformance to this
information model does not imply conformance to any standardized
agent behavior.
Feng Expires 29 January 2027 [Page 17]
Internet-Draft IDL Semantic Information Model July 2026
+======================+==========+======================+
| Field | Required | Description |
+======================+==========+======================+
| intent-participation | Yes | Intent participation |
| | | object (see below) |
+----------------------+----------+----------------------+
Table 12
3.4.1. Supported Intent Classes
The agent declares which classes of intent it can participate in:
+====================+==========+==============================+
| Field | Required | Description |
+====================+==========+==============================+
| intent-class-uri | Yes | Globally unique URI |
| | | identifying the intent class |
+--------------------+----------+------------------------------+
| roles | Yes | Roles the agent can assume |
| | | for this intent class |
+--------------------+----------+------------------------------+
| participation-mode | Yes | Whether the agent leads, |
| | | collaborates, or supports |
| | | the intent |
+--------------------+----------+------------------------------+
Table 13
{
"supported-intents": [
{
"intent-class-uri": "https://example.org/i/travel-plan",
"roles": ["contributor", "executor"],
"participation-mode": "collaborative"
},
{
"intent-class-uri": "https://example.org/i/travel-replan",
"roles": ["initiator", "contributor", "verifier"],
"participation-mode": "lead-or-collaborate"
}
]
}
Feng Expires 29 January 2027 [Page 18]
Internet-Draft IDL Semantic Information Model July 2026
3.4.2. Interaction Patterns
IDL defines the interaction patterns an agent supports. These are
not transport protocols — they describe the *semantic phases* of
agent-to- agent collaboration:
+====================+===========================================+
| Pattern | Description |
+====================+===========================================+
| request-contribute | Another agent requests this agent's |
| | contribution to an intent; agent responds |
| | with analysis, action, or information |
+--------------------+-------------------------------------------+
| negotiate-commit | Multi-round negotiation of intent |
| | parameters before commitment |
+--------------------+-------------------------------------------+
| delegate-report | This agent delegates sub-intents to other |
| | agents and aggregates results |
+--------------------+-------------------------------------------+
| observe-advise | This agent monitors intent progress and |
| | provides advisory input |
+--------------------+-------------------------------------------+
| co-execute | Multiple agents execute coordinated |
| | actions within a shared intent |
+--------------------+-------------------------------------------+
Table 14
3.4.3. Negotiation Capabilities
When an agent supports negotiate-commit, it MUST declare its
negotiation model:
Feng Expires 29 January 2027 [Page 19]
Internet-Draft IDL Semantic Information Model July 2026
{
"negotiation": {
"negotiable-parameters": [
{
"parameter": "planning-objective",
"type": "enum",
"values": ["lowest-cost", "shortest-duration", "balanced"],
"default": "balanced",
"priority": "required"
},
{
"parameter": "travel-window",
"type": "date-range",
"flexibility": "adjustable",
"constraints": {
"minimum-days": 2,
"maximum-days": 7
}
}
],
"max-rounds": 5,
"timeout": "PT10M",
"fallback": "accept-defaults"
}
}
3.4.4. Intent Lifecycle Participation
An intent passes through a defined lifecycle. The agent declares in
which phases it participates:
Discovery "Can I help?"
|
Understanding "Do I understand the goal?"
|
Negotiation "Are the terms acceptable?"
|
Commitment "I accept these terms"
|
Execution "Performing my part"
|
Verification "Did the outcome match?"
Feng Expires 29 January 2027 [Page 20]
Internet-Draft IDL Semantic Information Model July 2026
{
"lifecycle-participation": {
"discovery": { "active": true, "advertise": true },
"understanding": {
"active": true,
"may-request-clarification": true
},
"negotiation": { "active": true },
"commitment": { "active": true, "binding": true },
"execution": {
"active": true,
"progressive-reporting": true
},
"verification": {
"active": true,
"self-verify": true,
"peer-verify": true
}
}
}
3.5. Context Model
Agents operate on context — accumulated state, knowledge, and
situational awareness that influences their reasoning. The Context
Model describes what context the agent maintains, requires, and can
share.
+===============+==========+==================================+
| Field | Required | Description |
+===============+==========+==================================+
| context-model | No | Context model object (see below) |
+---------------+----------+----------------------------------+
Table 15
3.5.1. Context Categories
Feng Expires 29 January 2027 [Page 21]
Internet-Draft IDL Semantic Information Model July 2026
{
"context-model": {
"maintained-context": [
{
"category": "traveler-preferences",
"source": "user-profile-service",
"freshness": "real-time",
"scope": "current-user"
},
{
"category": "booking-history",
"source": "travel-record-service",
"freshness": "PT5M",
"scope": "current-user"
}
],
"required-context": [
{
"category": "travel-policy",
"description": "Current budget and travel restrictions",
"required-before": "commitment"
}
],
"shareable-context": [
{
"category": "itinerary-options",
"format": "structured-json",
"access-control": "intent-participants-only"
}
]
}
}
3.5.2. Context Gaps and Requests
A critical difference between agents and deterministic endpoints: an
agent may discover that it lacks sufficient context to proceed. IDL
declares how the agent handles context gaps:
Feng Expires 29 January 2027 [Page 22]
Internet-Draft IDL Semantic Information Model July 2026
{
"context-model": {
"context-gap-behavior": {
"strategy": "request-then-proceed",
"request-mechanism": "intent-clarification",
"max-clarification-rounds": 3,
"proceed-with-partial": true,
"partial-confidence-declaration": true
}
}
}
3.6. Governance Interface Model
The Governance Interface Model declares how an authorized supervisory
system can observe, constrain, and intervene in agent behavior. A
boolean claim of support is insufficient: every supported control
MUST include an invocation binding.
+=================+==========+================================+
| Field | Required | Description |
+=================+==========+================================+
| governance | Yes | Governance interface |
| | | declaration |
+-----------------+----------+--------------------------------+
| observability | Yes | Bindings for decision logs, |
| | | reasoning export, state query, |
| | | and metrics |
+-----------------+----------+--------------------------------+
| controllability | Yes | Bindings for pause/resume, |
| | | parameter override, scope |
| | | restriction, and policy reload |
+-----------------+----------+--------------------------------+
| intervention | Yes | Bindings for takeover, |
| | | emergency halt, rollback, and |
| | | declared intervention latency |
+-----------------+----------+--------------------------------+
Table 16
Each supported governance function is represented by a control
binding:
Feng Expires 29 January 2027 [Page 23]
Internet-Draft IDL Semantic Information Model July 2026
+=======================+=============+========================+
| Field | Required | Description |
+=======================+=============+========================+
| supported | Yes | Whether the function |
| | | is available |
+-----------------------+-------------+------------------------+
| mechanism | Conditional | Protocol or interface |
| | | type used to invoke |
| | | the function; required |
| | | when supported |
+-----------------------+-------------+------------------------+
| reference | Conditional | Stable URI for the |
| | | interface description |
| | | or endpoint; required |
| | | when supported |
+-----------------------+-------------+------------------------+
| operation | Conditional | Operation within the |
| | | referenced interface; |
| | | required when |
| | | supported |
+-----------------------+-------------+------------------------+
| authorization-profile | Conditional | Required authorization |
| | | role or policy |
| | | profile; required when |
| | | supported |
+-----------------------+-------------+------------------------+
Table 17
The referenced interface defines request, response, error, and
completion semantics. Declaring supported: true without a complete
binding is invalid. supported: false MUST NOT include invocation
fields.
4. Illustrative JSON Representation
4.1. Top-Level Structure
The following JSON object illustrates how the information-model
components can be represented. This section is informative. It does
not define a canonical serialization, JSON Schema, field
extensibility rules, or wire conformance. A separate IDL
representation specification is expected to define those details.
Feng Expires 29 January 2027 [Page 24]
Internet-Draft IDL Semantic Information Model July 2026
{
"idl-version": "1.0",
"agent": {},
"capabilities": [],
"autonomy": {},
"intent-participation": {},
"context-model": {},
"governance": {}
}
4.2. Complete Example
The following non-normative example describes a travel planning
agent:
{
"idl-version": "1.0",
"agent": {
"agent-id": "https://agents.travel.example/planner/v2",
"agent-class": "orchestration",
"display-name": "Example Travel Planner",
"description": "Plans and books travel within user constraints.",
"provider": "travel.example",
"version": "2.1.0",
"roles": ["initiator", "contributor", "negotiator", "executor"],
"trust-domain": "travel.example",
"credential-bindings": [
{
"scheme": "authenticated-workload-identity",
"subject": "spiffe://travel.example/agent/planner",
"issuer": "travel-example-production-ca"
},
{
"scheme": "oauth-client",
"subject": "travel-planner",
"issuer": "https://auth.travel.example"
}
]
},
"capabilities": [
{
"capability-uri": "https://example.org/c/travel-plan",
"capability-id": "itinerary.plan",
"name": "Constraint-Aware Itinerary Planning",
"description": "Plans and reserves authorized travel.",
"domain": "travel",
Feng Expires 29 January 2027 [Page 25]
Internet-Draft IDL Semantic Information Model July 2026
"contribution-type": "decision",
"schema-dialect": "JSON Schema 2020-12",
"input-context": {
"type": "object",
"properties": {
"objective": {
"type": "string",
"enum": ["lowest-cost", "shortest-duration", "balanced"]
},
"destination": { "type": "string" },
"departure-date": { "type": "string", "format": "date" },
"return-date": { "type": "string", "format": "date" },
"budget": {
"type": "object",
"properties": {
"amount": { "type": "number", "minimum": 0 },
"currency": { "type": "string" }
},
"required": ["amount", "currency"]
},
"constraints": {
"type": "object",
"properties": {
"refundable-only": { "type": "boolean" },
"maximum-stops": { "type": "integer", "minimum": 0 }
}
}
},
"required": [
"objective",
"destination",
"departure-date",
"budget"
]
},
"output-schema": {
"type": "object",
"properties": {
"itinerary-options": { "type": "array" },
"total-price": { "type": "number" },
"currency": { "type": "string" },
"confidence": {
"type": "number",
"minimum": 0,
"maximum": 1
},
"reasoning-summary": { "type": "string" }
}
Feng Expires 29 January 2027 [Page 26]
Internet-Draft IDL Semantic Information Model July 2026
},
"prerequisites": [
"Traveler preferences are available",
"Payment authorization is available before commitment"
],
"backing-interface": [
{
"interface-type": "mcp",
"reference": "https://tools.travel.example/mcp",
"operations": ["search-flights", "search-hotels"]
},
{
"interface-type": "openapi",
"reference": "https://booking.travel.example/openapi.json",
"operations": ["reserve-itinerary", "cancel-reservation"]
}
]
}
],
"autonomy": {
"level": "bounded",
"scope-constraints": [
{
"dimension": "resource-scope",
"operator": "within",
"value": ["urn:travel:account:alice"]
},
{
"dimension": "operation-type",
"operator": "allow",
"value": ["search", "reserve", "book", "cancel"]
},
{
"dimension": "transaction-value",
"operator": "max",
"value": {
"amount": 1000,
"currency": "USD"
}
},
{
"dimension": "impact-level",
"operator": "max",
"value": "medium"
}
],
"escalation-policy": {
Feng Expires 29 January 2027 [Page 27]
Internet-Draft IDL Semantic Information Model July 2026
"conditions": [
{
"trigger": "transaction-value-exceeds",
"threshold": { "amount": 1000, "currency": "USD" },
"action": "request-approval",
"target": "user"
},
{
"trigger": "confidence-below",
"threshold": 0.8,
"action": "request-approval",
"target": "human-operator"
},
{
"trigger": "cross-trust-domain-commitment",
"action": "negotiate-with-peer",
"target": "policy-agent"
}
],
"default-action": "halt-and-report"
},
"max-impact": {
"description": "Refundable travel up to USD 1000"
}
},
"intent-participation": {
"supported-intents": [
{
"intent-class-uri": "https://example.org/i/travel-plan",
"roles": [
"initiator",
"contributor",
"negotiator",
"executor"
],
"participation-mode": "lead-or-collaborate"
},
{
"intent-class-uri": "https://example.org/i/travel-replan",
"roles": ["initiator", "contributor", "negotiator"],
"participation-mode": "collaborative"
}
],
"interaction-patterns": [
"negotiate-commit",
"co-execute",
"delegate-report"
Feng Expires 29 January 2027 [Page 28]
Internet-Draft IDL Semantic Information Model July 2026
],
"negotiation": {
"negotiable-parameters": [
{
"parameter": "planning-objective",
"type": "enum",
"values": ["lowest-cost", "shortest-duration", "balanced"],
"default": "balanced"
},
{
"parameter": "travel-window",
"type": "date-range",
"flexibility": "adjustable"
},
{
"parameter": "maximum-total-price",
"type": "money",
"currency": "USD",
"range": [500, 1000],
"default": 800
}
],
"max-rounds": 3,
"timeout": "PT5M",
"fallback": "accept-defaults"
},
"lifecycle-participation": {
"discovery": { "active": true, "advertise": true },
"understanding": {
"active": true,
"may-request-clarification": true
},
"negotiation": { "active": true },
"commitment": { "active": true, "binding": true },
"execution": {
"active": true,
"progressive-reporting": true
},
"verification": { "active": true, "self-verify": true }
}
},
"context-model": {
"maintained-context": [
{
"category": "traveler-preferences",
"source": "user-profile-service",
"freshness": "PT24H",
Feng Expires 29 January 2027 [Page 29]
Internet-Draft IDL Semantic Information Model July 2026
"scope": "current-user"
},
{
"category": "inventory-snapshot",
"source": "supplier-agents",
"freshness": "PT5M",
"scope": "current-search"
},
{
"category": "booking-history",
"source": "self",
"freshness": "persistent",
"scope": "current-user"
}
],
"required-context": [
{
"category": "travel-policy",
"description": "Current budget and travel restrictions",
"required-before": "execution"
},
{
"category": "payment-authorization",
"description": "Token scoped to the selected reservation",
"required-before": "commitment"
}
],
"shareable-context": [
{
"category": "itinerary-options",
"format": "structured-json",
"access-control": "intent-participants-only"
},
{
"category": "price-summary",
"format": "structured-json",
"access-control": "same-trust-domain"
}
],
"context-gap-behavior": {
"strategy": "request-then-proceed",
"max-clarification-rounds": 3,
"proceed-with-partial": true,
"partial-confidence-declaration": true
}
},
"governance": {
Feng Expires 29 January 2027 [Page 30]
Internet-Draft IDL Semantic Information Model July 2026
"observability": {
"decision-logging": {
"supported": true,
"mechanism": "https",
"reference": "https://agents.example/governance",
"operation": "query-decisions",
"authorization-profile": "auditor"
},
"reasoning-export": { "supported": false },
"state-query": {
"supported": true,
"mechanism": "https",
"reference": "https://agents.example/governance",
"operation": "query-state",
"authorization-profile": "operator"
},
"metrics": { "supported": false }
},
"controllability": {
"pause-resume": {
"supported": true,
"mechanism": "https",
"reference": "https://agents.example/governance",
"operation": "set-execution-state",
"authorization-profile": "supervisor"
},
"parameter-override": { "supported": false },
"scope-restriction-runtime": { "supported": false },
"policy-hot-reload": { "supported": false }
},
"intervention": {
"human-takeover": { "supported": false },
"emergency-halt": {
"supported": true,
"mechanism": "https",
"reference": "https://agents.example/governance",
"operation": "emergency-halt",
"authorization-profile": "incident-commander"
},
"rollback": {
"supported": true,
"mechanism": "https",
"reference": "https://agents.example/governance",
"operation": "cancel-last-reservation",
"authorization-profile": "supervisor"
},
"intervention-latency": "PT5S"
}
Feng Expires 29 January 2027 [Page 31]
Internet-Draft IDL Semantic Information Model July 2026
}
}
5. Integration with Agent Communication Protocols
5.1. Integration Modes
IDL is independent of protocol framing. An agent communication
protocol can integrate the information model in one or more ways:
* Carry an IDL representation directly in discovery or session
messages.
* Carry a URI and integrity digest that reference an IDL
representation.
* Map native protocol metadata to equivalent IDL components.
* Negotiate or refresh selected IDL components during a long-lived
session.
A protocol mapping MUST identify which IDL components it carries, how
their integrity and freshness are protected, and how unsupported or
conflicting semantics are handled.
5.2. Capability Identification and Selection
capabilities[].capability-uri is the authoritative identifier for a
capability. It MUST be globally unique and stable across display-
name or description changes. IDL treats the URI as opaque; matching
based on URI prefixes or string segments is not implied.
capability-id is unique only within one IDL description and supports
local references. Receivers MUST reject duplicate capability URIs or
duplicate capability-id values within one description.
Discovery and routing systems can use capability URIs, supported
intent classes, roles, context requirements, and autonomy constraints
to select a candidate agent. Natural-language descriptions can
assist semantic search but MUST NOT override machine-readable
authorization or autonomy limits.
5.3. Session Use
Before committing work, peers SHOULD obtain the IDL components needed
to:
* Determine what each agent can contribute.
Feng Expires 29 January 2027 [Page 32]
Internet-Draft IDL Semantic Information Model July 2026
* Establish which intent parameters are negotiable.
* Identify required and shareable context.
* Check whether autonomy and governance declarations are compatible
with the intended action.
* Locate intervention and observability interfaces.
Long-lived sessions SHOULD support refreshing mutable declarations
and identifying the version or digest used for each commitment. A
change to an autonomy boundary or credential binding MUST NOT
silently broaden authority for an existing commitment.
5.4. Relationship to Existing Protocols
IDL complements rather than replaces existing agent protocols:
+===================+==========================================+
| Protocol artifact | Possible IDL use |
+===================+==========================================+
| [A2A] Agent Card | Reference or embed identity, capability, |
| | and interaction declarations |
+-------------------+------------------------------------------+
| [MCP] server/tool | Supply backing interfaces for agent |
| metadata | capabilities |
+-------------------+------------------------------------------+
| Agent session | Exchange or reference IDL during |
| protocols | discovery and session establishment |
+-------------------+------------------------------------------+
| Domain-specific | Index agents using capability URIs and |
| registries | supported intent classes |
+-------------------+------------------------------------------+
Table 18
The exact field mappings and wire encodings are outside the scope of
this information-model document.
6. Relationship to Governance Frameworks
Governance frameworks commonly require observability,
controllability, and intervention for autonomous agents. IDL
provides a protocol-independent declarative foundation for those
requirements. [ICON] is one example of such a framework for network-
facing agents.
Feng Expires 29 January 2027 [Page 33]
Internet-Draft IDL Semantic Information Model July 2026
6.1. Example Mapping
+=============+=========================================+===========+
|ICON |IDL Component |How IDL |
|Requirement | |Supports It|
+=============+=========================================+===========+
|Agent |governance.observability |Agent |
|behavior must| |declares |
|be observable| |logging, |
| | |reasoning |
| | |export, |
| | |state query|
| | |interfaces |
+-------------+-----------------------------------------+-----------+
|Agent must |autonomy.scope-constraints |Agent |
|operate | |declares |
|within | |dimensions |
|defined | |and limits |
|boundaries | |of |
| | |autonomous |
| | |action |
+-------------+-----------------------------------------+-----------+
|Agent must be|governance.controllability |Agent |
|constrainable| |declares |
|at runtime | |support for|
| | |pause, |
| | |parameter |
| | |override, |
| | |scope |
| | |restriction|
+-------------+-----------------------------------------+-----------+
|Human must be|governance.intervention |Agent |
|able to | |declares |
|intervene | |takeover, |
| | |halt, and |
| | |rollback |
| | |interfaces |
+-------------+-----------------------------------------+-----------+
|Agent |governance.observability.decision-logging|Agent |
|decisions | |declares |
|must be | |decision |
|auditable | |logging and|
| | |a binding |
| | |through |
| | |which |
| | |authorized |
| | |auditors |
| | |can query |
Feng Expires 29 January 2027 [Page 34]
Internet-Draft IDL Semantic Information Model July 2026
| | |it |
+-------------+-----------------------------------------+-----------+
|Agent must |autonomy.escalation-policy |Agent |
|escalate | |declares |
|beyond its | |triggers, |
|competence | |thresholds,|
| | |and |
| | |escalation |
| | |targets |
+-------------+-----------------------------------------+-----------+
Table 19
6.2. Governance as a First-Class Property
Unlike approaches that bolt governance onto agents after deployment,
IDL makes governance declarations part of the agent's description.
An agent that cannot describe its autonomy boundaries and provide
complete bindings for its supported intervention functions does not
satisfy the required IDL information model and cannot be advertised
as a governable participant.
This is a deliberate design choice: an agent that cannot expose the
controls required by a governance policy is not eligible for
collaboration governed by that policy.
7. Illustrative Intent Interaction Patterns
This section is informative. It illustrates how IDL-described agents
might interact during intent fulfillment. These patterns are
semantic examples, not required agent behavior; a communication
protocol provides the transport and message framing. Message labels
in the examples are illustrative semantic events, not wire-message
definitions or IANA registration requests.
7.1. Travel Planning Example
Feng Expires 29 January 2027 [Page 35]
Internet-Draft IDL Semantic Information Model July 2026
Travel Planner Airline Agent
| |
| 1. INTENT_PROPOSE |
| intent: travel.itinerary.plan |
| objective: balanced |
| destination: VIE |
|------------------------------------->|
| |
| 2. INTENT_CLARIFY |
| missing-context: traveler-policy |
|<-------------------------------------|
| |
| 3. CONTEXT_PROVIDE |
| budget: USD 800 |
| refundable-only: true |
|------------------------------------->|
| |
| 4. INTENT_NEGOTIATE |
| proposed-flight: ... |
| price: USD 640 |
| confidence: 0.92 |
|<-------------------------------------|
| |
| 5. INTENT_COMMIT |
| accepted-option: ... |
|------------------------------------->|
| |
| 6. EXECUTION_COMPLETE |
| result: reserved |
| reservation-id: ... |
|<-------------------------------------|
7.2. Multi-Agent Negotiation Example
When an intent spans multiple domains, agents negotiate:
Feng Expires 29 January 2027 [Page 36]
Internet-Draft IDL Semantic Information Model July 2026
Airline Agent Travel Planner Hotel Agent
| | |
| OPTION: flight | OPTION: room |
| dates=20-23 Jul | dates=21-24 Jul |
|------------------------>|<-------------------------|
| | |
| (Planner detects incompatible dates) |
| | |
| COUNTER_PROPOSE | COUNTER_PROPOSE |
| dates=21-24 Jul | dates=21-24 Jul |
|<------------------------|------------------------->|
| | |
| COMMIT | COMMIT |
|------------------------>|<-------------------------|
8. Security Considerations
8.1. Identity and Trust
IDL descriptions declare agent identity, but this specification does
not define an authentication mechanism. Agent identity MUST be
verified through the authentication mechanism of the communication
protocol. The authenticated principal MUST match at least one
applicable entry in agent.credential-bindings; a receiver MUST reject
the description for that session when no supported binding is
applicable or none of the applicable bindings matches. The provider,
trust-domain, and delegation-chain fields MUST NOT be treated as
authenticated solely because they appear in the description. An IDL
description received outside an authenticated session SHOULD be
treated as untrusted.
An agent-id, capability-uri, or intent-class-uri is an identifier,
not proof that the presenting agent owns the URI or is authorized to
exercise the identified capability. Protocol mappings MUST bind
retrieved or exchanged IDL representations to an authenticated
principal and integrity mechanism. Dereferenced content MUST be
subject to the same validation as content carried directly in a
session.
8.2. Autonomy Envelope Enforcement
IDL autonomy declarations are *self-reported* by the agent. A
governance system ([ICON]) MUST NOT rely solely on IDL declarations
for enforcement. IDL provides the declared contract; the governance
system independently enforces and verifies compliance. Effective
authority MUST be no broader than the intersection of the IDL
autonomy envelope, permissions bound to the authenticated principal,
and applicable external policy and session constraints. If those
Feng Expires 29 January 2027 [Page 37]
Internet-Draft IDL Semantic Information Model July 2026
sources conflict or required authority information is missing, an
implementation MUST apply the most restrictive result or deny or
escalate the action.
8.3. Context Sharing
The context-model.shareable-context declarations include access-
control fields, but IDL does not define the access control mechanism
itself. Implementations MUST enforce context access control through
the underlying transport and session security mechanisms. Before
sharing context across a trust-domain boundary, an implementation
MUST apply data-minimization, purpose, and user-consent policies
appropriate to the context category.
8.4. Negotiation Integrity
Intent negotiation involves agents proposing and counterproposing
parameters. Implementations MUST ensure that negotiation messages
are integrity-protected and that an agent cannot repudiate a
commitment made during negotiation.
9. IANA Considerations
This document has no IANA actions. A future IDL representation
specification may request a media type or registries for extensible
values.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References
[AIPROTO-FRAMEWORK]
"Framework, Use Cases and Requirements for AI Agent
Protocols", 2025, <draft-rosenberg-aiproto-framework-00>.
[AIN-ARCH] "Agentic Intent Network (AIN) Architecture", 2026, <draft-
feng-nmrg-ain-architecture-01>.
Feng Expires 29 January 2027 [Page 38]
Internet-Draft IDL Semantic Information Model July 2026
[NAIM] "NAIM: A Canonical Semantic Representation for AI-Assisted
YANG Modeling and Validation", 2026, <draft-feng-netmod-
naim-01>.
[RAIM] "RAIM: REST AI Interface Modeling — Core Semantic Layer,
v1.0", 2026,
<https://github.com/agentic-intent-network/raim-spec>.
[ICON] "Requirements for Indicators for Controllability of
Network-Facing AI Agents", 2026, <draft-mcw-opsawg-icon-
requirements-01>.
[MCP] "Model Context Protocol Specification", 2024,
<https://modelcontextprotocol.io/specification>.
[A2A] "Agent-to-Agent Protocol", 2026,
<https://a2a-protocol.org/latest/>.
Appendix A. Requirements for a Future IDL Representation
A separate representation specification is expected to define the
wire format for this information model. At minimum, it needs to
define:
* A complete schema and schema-language version.
* Required, optional, conditional, and extension fields.
* Canonical serialization and content-digest input bytes.
* Version negotiation and backward-compatibility behavior.
* Registry or extension rules for enumerated values and identifiers.
* Conformance requirements and positive and negative test vectors.
The JSON examples in Section 4 are illustrative input to that work
and are not a substitute for the representation specification.
Appendix B. Comparison with Existing Agent Description Approaches
+=============+==========+==================+======================+
| Aspect |A2A Agent | MCP Tool Schema | IDL |
| |Card | | |
+=============+==========+==================+======================+
| Identity |Name, | Tool name, | Agent identity with |
| model |skills | description | class, roles, trust |
| |list | | domain, delegation |
Feng Expires 29 January 2027 [Page 39]
Internet-Draft IDL Semantic Information Model July 2026
| | | | chain, and |
| | | | credential binding |
+-------------+----------+------------------+----------------------+
| Capability |Skill | Input JSON | Structured |
| description |names | Schema per tool | capabilities with |
| |(string | | URI, domain, |
| |list) | | contribution type, |
| | | | prerequisites, and |
| | | | backing interfaces |
+-------------+----------+------------------+----------------------+
| Autonomy |None | None | Full autonomy |
| declaration | | | envelope with |
| | | | levels, scope |
| | | | constraints, |
| | | | escalation policy |
+-------------+----------+------------------+----------------------+
| Interaction |Task-based| Request-response | Intent lifecycle |
| model |(send/ | tool call | with negotiation, |
| |receive) | | commitment, |
| | | | progressive |
| | | | execution |
+-------------+----------+------------------+----------------------+
| Context |None | None | Maintained/required/ |
| handling | | | shareable context |
| | | | with gap behavior |
+-------------+----------+------------------+----------------------+
| Governance |None | None | Observability, |
| support | | | controllability, and |
| | | | intervention |
| | | | declarations with |
| | | | invocation bindings |
+-------------+----------+------------------+----------------------+
| Negotiation |None | None | Negotiable |
| | | | parameters with |
| | | | ranges, rounds, |
| | | | timeout, fallback |
+-------------+----------+------------------+----------------------+
Table 20
Appendix C. AIN/CDL Profile (Informative)
AIN deployments can profile the IDL information model without making
AIN a dependency of the core model:
* An IDL representation can be carried in the machine_readable
component of a CDL record with cdl_type equal to idl.
Feng Expires 29 January 2027 [Page 40]
Internet-Draft IDL Semantic Information Model July 2026
* The CDL hash and exchange procedures are defined by [AIN-ARCH].
* An AIN profile can map each capability-uri and intent-class-uri to
an IC-OID used by an Intent Routing Point. The mapping MUST be
explicit and MUST NOT be inferred from display names.
* backing-interface can reference [NAIM] or [RAIM] descriptions when
an agent capability depends on deterministic network or REST
operations.
These mappings are optional. A non-AIN agent can implement the
complete IDL information model without CDL, IC-OID, AIN-SEP, NAIM, or
RAIM.
Appendix D. Acknowledgements
The IDL concept emerged from discussions on the shift from server-
oriented interface descriptions to intent-oriented semantic
descriptions for autonomous participants in multi-agent systems.
Author's Address
Chong Feng
Email: fengchongllly@gmail.com
Feng Expires 29 January 2027 [Page 41]