]>

fengchongllly@gmail.com

Applications and Real-Time 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.

Introduction

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

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

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.

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 (, ) when, and only when, they appear in all capitals, as shown here.

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.

Positioning in the Agent Communication Stack

Semantic Layer Agent communication requires several separable layers:

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.

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.

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

Agent Identity Agent Identity establishes the agent as a recognizable, accountable participant across communication and administrative domains. 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. 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 Class Taxonomy IDL defines a base taxonomy of agent classes. Implementations MAY extend this taxonomy with domain-specific subclasses. 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

Role Definitions An agent may assume one or more roles in intent interactions: 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

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) Each capability object: 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

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:

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.

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 . Field Required Description autonomy Yes Autonomy envelope object (see below) Autonomy envelope object: 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

Autonomy Levels 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

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:

Defined dimensions: 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.

Escalation Policy The escalation policy defines conditions under which the agent MUST yield control to a human operator or supervisory agent:

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. Field Required Description intent-participation Yes Intent participation object (see below)

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

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

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

Intent Lifecycle Participation An intent passes through a defined lifecycle. The agent declares in which phases it participates:

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)

Context Categories

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:

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 Each supported governance function is represented by a control binding: 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.

Illustrative JSON Representation

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.

Complete Example The following non-normative example describes a travel planning agent:

Integration with Agent Communication Protocols

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.

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.

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.

Relationship to Existing Protocols IDL complements rather than replaces existing agent protocols: Protocol artifact Possible IDL use Agent Card Reference or embed identity, capability, and interaction declarations 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.

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. is one example of such a framework for network-facing agents.

Example Mapping 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

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.

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.

Travel Planning Example

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

Multi-Agent Negotiation Example When an intent spans multiple domains, agents negotiate:

|<-------------------------| | | | | (Planner detects incompatible dates) | | | | | COUNTER_PROPOSE | COUNTER_PROPOSE | | dates=21-24 Jul | dates=21-24 Jul | |<------------------------|------------------------->| | | | | COMMIT | COMMIT | |------------------------>|<-------------------------| ]]>

Security Considerations

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.

Autonomy Envelope Enforcement IDL autonomy declarations are self-reported by the agent. A governance system () 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.

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.

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.

IANA Considerations This document has no IANA actions. A future IDL representation specification may request a media type or registries for extensible values.

&RFC2119; &RFC8174;

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.

Comparison with Existing Agent Description Approaches 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

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

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.