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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 10.2. Informative References [AIPROTO-FRAMEWORK] "Framework, Use Cases and Requirements for AI Agent Protocols", 2025, . [AIN-ARCH] "Agentic Intent Network (AIN) Architecture", 2026, . 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, . [RAIM] "RAIM: REST AI Interface Modeling — Core Semantic Layer, v1.0", 2026, . [ICON] "Requirements for Indicators for Controllability of Network-Facing AI Agents", 2026, . [MCP] "Model Context Protocol Specification", 2024, . [A2A] "Agent-to-Agent Protocol", 2026, . 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]