IDL: A Semantic Information Model for Agent Communication

Internet-Draft	IDL Semantic Information Model	July 2026
Feng	Expires 29 January 2027	[Page]

Status of This Memo

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

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

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

This Internet-Draft will expire on 29 January 2027.¶

Copyright Notice

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

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

Table 1
Approach	What It Describes	What It Misses for Agents
OpenAPI	HTTP endpoints and payloads	Agent collaboration is not limited to request-response operations
MCP tool schema	Tool name, description, input schema	A tool does not declare agency, autonomy, or intent participation
A2A Agent Card	Agent name, skills, endpoint	Limited semantics for autonomy, context, negotiation, and governance
Service discovery	Location and protocol metadata	Does not describe how an autonomous participant collaborates

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

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:¶

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

Agency: The agent can initiate actions, not merely respond. IDL must describe what the agent may initiate.¶
Discretion: The agent may interpret, negotiate, or refuse requests. IDL must describe the conditions under which these behaviors occur.¶
Context dependence: The agent's behavior depends on accumulated context, not just the current request. IDL must describe the agent's context model.¶
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.¶
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.¶

Table 2
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

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

Table 3
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

{
  "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.¶

Table 4
Class	Description	Example
`diagnostic`	Investigates and analyzes system state	Incident diagnosis agent
`optimization`	Continuously improves outcomes within constraints	Logistics optimization agent
`assurance`	Monitors and enforces objectives	Compliance assurance agent
`orchestration`	Coordinates multi-agent workflows	Intent orchestration agent
`advisory`	Provides analysis and recommendations without direct action	Security advisory agent
`execution`	Performs specific operations under delegated authority	Order fulfillment agent

3.1.2. Role Definitions

An agent may assume one or more roles in intent interactions:¶

Table 5
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

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

Table 6
Field	Required	Description
`capabilities`	Yes	Array of capability objects (see below)

Each capability object:¶

Table 7
Field	Required	Description
`capability-uri`	Yes	Globally unique URI for discovery, selection, and matching
`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

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

Table 8
Field	Required	Description
`autonomy`	Yes	Autonomy envelope object (see below)

Autonomy envelope object:¶

Table 9
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

3.3.1. Autonomy Levels

Table 10
Level	Agent Declares It Can	Declared Restriction
`advisory`	Analyze, recommend	Take any action
`supervised`	Propose actions, execute after approval	Act without approval
`bounded`	Act within declared scope constraints	Exceed scope constraints
`autonomous`	Act within full capability range	Violate escalation policy

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:¶

{
  "dimension": "resource-scope",
  "operator": "within",
  "value": ["urn:travel:account:alice"],
  "description": "Limited to resources owned by this account"
}

Defined dimensions:¶

Table 11
Dimension	Allowed operator	Value type and semantics
`resource-scope`	`within`	Non-empty array of resource, account, tenant, or domain identifiers
`operation-type`	`allow`, `deny`	Non-empty array of 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

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

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

Table 12
Field	Required	Description
`intent-participation`	Yes	Intent participation object (see below)

3.4.1. Supported Intent Classes

The agent declares which classes of intent it can participate in:¶

Table 13
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

{
  "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"
    }
  ]
}

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:¶

Table 14
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

3.4.3. Negotiation Capabilities

When an agent supports negotiate-commit, it MUST declare its negotiation model:¶

{
  "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?"

{
  "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.¶

Table 15
Field	Required	Description
`context-model`	No	Context model object (see below)

3.5.1. Context Categories

{
  "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:¶

{
  "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.¶

Table 16
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

Each supported governance function is represented by a control binding:¶

Table 17
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

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

{
  "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",
      "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" }
        }
      },
      "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": {
      "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"
    ],
    "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",
        "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": {
    "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"
    }
  }
}

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

Table 18
Protocol artifact	Possible IDL use
[A2A] Agent Card	Reference or embed identity, capability, and interaction declarations
[MCP] server/tool metadata	Supply backing interfaces for agent capabilities
Agent session protocols	Exchange or reference IDL during discovery and session establishment
Domain-specific registries	Index agents using capability URIs and supported intent classes

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

6.1. Example Mapping

Table 19
ICON Requirement	IDL Component	How IDL Supports It
Agent behavior must be observable	`governance.observability`	Agent declares logging, reasoning export, state query interfaces
Agent must operate within defined boundaries	`autonomy.scope-constraints`	Agent declares dimensions and limits of autonomous action
Agent must be constrainable at runtime	`governance.controllability`	Agent declares support for pause, parameter override, scope restriction
Human must be able to intervene	`governance.intervention`	Agent declares takeover, halt, and rollback interfaces
Agent decisions must be auditable	`governance.observability.decision-logging`	Agent declares decision logging and a binding through which authorized auditors can query it
Agent must escalate beyond its competence	`autonomy.escalation-policy`	Agent declares triggers, thresholds, and escalation targets

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

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:¶

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 sources conflict or required authority information is missing, an implementation MUST apply the most restrictive result or deny or escalate the action.¶

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

Table 20
Aspect	A2A Agent Card	MCP Tool Schema	IDL
Identity model	Name, skills list	Tool name, description	Agent identity with class, roles, trust domain, delegation chain, and credential binding
Capability description	Skill names (string list)	Input JSON Schema per tool	Structured capabilities with URI, domain, contribution type, prerequisites, and backing interfaces
Autonomy declaration	None	None	Full autonomy envelope with levels, scope constraints, escalation policy
Interaction model	Task-based (send/receive)	Request-response tool call	Intent lifecycle with negotiation, commitment, progressive execution
Context handling	None	None	Maintained/required/shareable context with gap behavior
Governance support	None	None	Observability, controllability, and intervention declarations with invocation bindings
Negotiation	None	None	Negotiable parameters with ranges, rounds, timeout, fallback

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