\n \n
\n \n \n \n \n \n \n\n\n\n\n AI Agent Discovery and Invocation Protocol\n
\n\n \n\n\n\n\n\n\n\n\n
\n \n \n
\n \n AI Agent Discovery and Invocation Protocol\n
\n draft-cui-ai-agent-discovery-invocation-01\n
\n- \n \n
- \n \n Status\n \n \n \n
- \n \n Email expansions\n \n \n \n
- \n \n History\n \n \n \n
\n This document is an Internet-Draft (I-D).\n Anyone may submit an I-D to the IETF.\n This I-D is not endorsed by the IETF and has no formal standing in the\n IETF standards process.\n
\n\n\n \n \n The information below is for an old version of the document.
\n \n | Document | \nType | \n\n | \n \n\n\n\n\n\n\n\n This is an older version of an Internet-Draft whose latest revision state is \"Active\". \n\n \n \n \n | \n
|---|---|---|---|
| \n | Authors | \n\n \n | \n\n \n \n Yong Cui \n ,\n \n Yihan Chao \n ,\n \n Chenguang Du \n \n \n \n | \n
| \n | Last updated | \n\n | \n 2026-02-12\n \n (Latest revision 2025-10-15)\n \n | \n
| \n | \n RFC stream\n | \n\n \n | \n\n \n (None)\n \n | \n
| \n | \n Formats\n | \n\n | \n\n \n \n \n\n \n | \n
| \n Stream\n | \n \n\n Stream state\n | \n\n | \n\n (No stream defined)\n | \n \n
| \n | \n Consensus boilerplate\n | \n\n \n | \n\n \n Unknown\n \n | \n
| \n | \n RFC Editor Note\n | \n\n \n | \n\n \n \n (None)\n \n \n | \n
| \n IESG\n | \n\n \n IESG state\n \n | \n\n \n | \n\n \n \n I-D Exists\n \n \n | \n
| \n | \n Telechat date\n | \n\n \n | \n\n \n \n (None)\n \n \n \n | \n
| \n | \n Responsible AD\n | \n\n \n | \n\n \n \n (None)\n \n \n | \n
| \n | \n Send notices to\n | \n\n \n | \n\n \n \n (None)\n \n \n | \n
\n
\n \n \n \n \n \n \n draft-cui-ai-agent-discovery-invocation-01\n \n
\n \n
\n Network Working Group Y. Cui\nInternet-Draft Tsinghua University\nIntended status: Informational Y. Chao\nExpires: 16 August 2026 C. Du\n Zhongguancun Laboratory\n 12 February 2026\n\n AI Agent Discovery and Invocation Protocol\n draft-cui-ai-agent-discovery-invocation-01\n\nAbstract\n\n This document proposes a standardized protocol for discovery and\n invocation of AI agents. It defines a common metadata format for\n describing AI agents (including capabilities, I/O specifications,\n supported languages, tags, authentication methods, etc.), a\n capability-based discovery mechanism, and a unified RESTful\n invocation interface.\n\n This revision additionally specifies an optional extension that\n enables intent-based agent selection prior to discovery and\n invocation, without changing existing discovery or invocation\n semantics.\n\n The goal is to enable cross-platform interoperability among AI agents\n by providing a discover-and-match mechanism and a unified invocation\n entry point. Security considerations, including authentication and\n trust measures, are also discussed. This specification aims to\n facilitate the formation of multi-agent systems by making it easy to\n find the right agent for a task and invoke it in a consistent manner\n across different vendors and platforms.\n\nAbout This Document\n\n This note is to be removed before publishing as an RFC.\n\n The latest revision of this draft can be found at\n https://example.com/LATEST. Status information for this document may\n be found at https://datatracker.ietf.org/doc/draft-cui-ai-agent-\n discovery-invocation/.\n\n Discussion of this document takes place on the WG Working Group\n mailing list (mailto:WG@example.com), which is archived at\n https://example.com/WG.\n\n Source for this draft and an issue tracker can be found at\n https://github.com/USER/REPO.\n\nCui, et al. Expires 16 August 2026 [Page 1]\nInternet-Draft AIDIP February 2026\n\nStatus of This Memo\n\n This Internet-Draft is submitted in full conformance with the\n provisions of BCP 78 and BCP 79.\n\n Internet-Drafts are working documents of the Internet Engineering\n Task Force (IETF). Note that other groups may also distribute\n working documents as Internet-Drafts. The list of current Internet-\n Drafts is at https://datatracker.ietf.org/drafts/current/.\n\n Internet-Drafts are draft documents valid for a maximum of six months\n and may be updated, replaced, or obsoleted by other documents at any\n time. It is inappropriate to use Internet-Drafts as reference\n material or to cite them other than as "work in progress."\n\n This Internet-Draft will expire on 16 August 2026.\n\nCopyright Notice\n\n Copyright (c) 2026 IETF Trust and the persons identified as the\n document authors. All rights reserved.\n\n This document is subject to BCP 78 and the IETF Trust's Legal\n Provisions Relating to IETF Documents (https://trustee.ietf.org/\n license-info) in effect on the date of publication of this document.\n Please review these documents carefully, as they describe your rights\n and restrictions with respect to this document. Code Components\n extracted from this document must include Revised BSD License text as\n described in Section 4.e of the Trust Legal Provisions and are\n provided without warranty as described in the Revised BSD License.\n\nTable of Contents\n\n 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3\n 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4\n 3. Agent Metadata Specification . . . . . . . . . . . . . . . . 5\n 3.1. Core Fields . . . . . . . . . . . . . . . . . . . . . . . 5\n 3.2. Operations and I/O Schema . . . . . . . . . . . . . . . . 7\n 3.3. Example Agent Metadata . . . . . . . . . . . . . . . . . 8\n 4. Agent Discovery Mechanism . . . . . . . . . . . . . . . . . . 8\n 4.1. Registry Overview . . . . . . . . . . . . . . . . . . . . 8\n 4.2. Agent Registration . . . . . . . . . . . . . . . . . . . 9\n 4.3. Querying Agents . . . . . . . . . . . . . . . . . . . . . 9\n 4.3.1. Attribute-Based Query (Filter) . . . . . . . . . . . 10\n 4.3.2. Semantic Query (Natural Language Search) . . . . . . 10\n 4.3.3. Retrieve Single Agent . . . . . . . . . . . . . . . . 11\n 5. Agent Invocation . . . . . . . . . . . . . . . . . . . . . . 11\n 5.1. Invocation Request . . . . . . . . . . . . . . . . . . . 11\n\nCui, et al. Expires 16 August 2026 [Page 2]\nInternet-Draft AIDIP February 2026\n\n 5.2. Invocation Response . . . . . . . . . . . . . . . . . . . 12\n 5.3. Additional Considerations for Invocation . . . . . . . . 14\n 6. Agent Semantic Resolution . . . . . . . . . . . . . . . . . . 15\n 6.1. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 15\n 7. Semantic Routing Platform . . . . . . . . . . . . . . . . . . 15\n 8. Backward Compatibility . . . . . . . . . . . . . . . . . . . 16\n 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16\n 10. Example Interaction Flow . . . . . . . . . . . . . . . . . . 16\n 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17\n 12. Normative References . . . . . . . . . . . . . . . . . . . . 17\n Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17\n Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17\n\n1. Introduction\n\n As artificial intelligence technologies advance rapidly, AI\n agents—autonomous software components capable of perceiving their\n environment, reasoning, and taking actions to achieve goals—have\n emerged as a powerful paradigm for task execution. Today, many\n organizations develop specialized AI agents for various purposes:\n from text translation and summarization, to code generation, to data\n analysis and beyond. These agents are often offered as services,\n accessible over the network and may be integrated into larger\n systems. However, despite the proliferation of AI agents, there is\n currently no standard protocol for discovering available agents and\n invoking their capabilities in a uniform way.\n\n Existing agent frameworks and platforms facilitate building agents\n but typically operate in isolated ecosystems, making cross-platform\n or cross-organization agent interoperability difficult. Each\n platform tends to define its own APIs for agent description and\n invocation, which means a client wishing to use agents from multiple\n sources must adapt to disparate interfaces. This lack of\n standardization creates friction, increases integration costs, and\n hampers the development of multi-agent collaborative systems.\n\n This document addresses these issues by proposing a standardized AI\n Agent Discovery and Invocation Protocol. The protocol provides:\n\n 1. *Agent Metadata Specification:* A structured JSON Schema for\n describing an agent's identity, capabilities, inputs, outputs,\n authentication requirements, and other attributes. This enables\n agents to publish their specifications in a machine-readable\n form.\n\nCui, et al. Expires 16 August 2026 [Page 3]\nInternet-Draft AIDIP February 2026\n\n 2. *Discovery Mechanism:* A registry-based approach where agents\n register themselves and clients can search for agents by\n capability, tags, or semantic queries. The registry is language\n and platform agnostic, facilitating cross-platform discovery.\n\n 3. *Invocation Interface:* A RESTful API that enables a client\n (which could be a human user application, another agent, or an\n orchestration system) to invoke an agent's capabilities through a\n standard endpoint and JSON payloads.\n\n 4. *Security Considerations:* Guidelines for authentication,\n authorization, encrypted transport (TLS), and trust\n establishment, ensuring that discovery and invocation happen\n securely.\n\n 5. *Interoperability with Existing Standards:* This specification\n references existing standards such as JSON Schema, OAuth 2.0\n [RFC6749], and OpenAPI concepts, and leverages established web\n technologies for broad compatibility.\n\n The primary audience for this specification includes developers of AI\n agent platforms, providers of AI agent services, and system\n architects building AI-enabled applications or multi-agent systems.\n By adopting this protocol, an AI agent developer can make their agent\n accessible to a wide ecosystem, and a client application can\n integrate AI agents from multiple vendors without custom integration\n for each.\n\n This revision extends the base protocol with an optional Agent\n Semantic Resolution layer that enables intent-based agent selection.\n This extension allows a Host Agent or coordinator to describe a task\n intent and receive candidate agents without predetermining which\n agent to invoke. ASR does not replace discovery; it adds a semantic\n matching phase that can precede or augment the capability-based\n search defined in earlier sections.\n\n2. Conventions and Definitions\n\n The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",\n "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and\n "OPTIONAL" in this document are to be interpreted as described in\n BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all\n capitals, as shown here.\n\n * *AI Agent:* An autonomous software component that can perform\n tasks using artificial intelligence capabilities. Agents may wrap\n language models, specialized ML models, or reasoning engines,\n exposing their abilities via defined interfaces.\n\nCui, et al. Expires 16 August 2026 [Page 4]\nInternet-Draft AIDIP February 2026\n\n * *Agent Metadata:* A structured description of an agent, including\n name, description, capabilities, input/output schemas,\n authentication requirements, and endpoint information.\n\n * *Agent Registry (Discovery Service):* A service that maintains a\n directory of registered agents and supports queries for\n discovering agents by attributes or semantic search.\n\n * *Gateway:* (Optional) An intermediary service that routes client\n requests to appropriate agents. In some deployments, the registry\n or another service acts as a gateway to simplify client-to-agent\n connections.\n\n * *Invocation Endpoint:* The URL provided by an agent (or gateway)\n where clients send requests to invoke the agent's capabilities.\n\n * *Capability:* A high-level function an agent can perform,\n identified by a string (e.g., "translation", "summarization",\n "image_classification").\n\n * *Operation:* A specific action supported by an agent. Some agents\n may have multiple operations; for example, an agent offering both\n translation and language detection could list these as separate\n operations, each with its own input/output schema.\n\n3. Agent Metadata Specification\n\n The Agent Metadata Specification defines a standard JSON document\n that describes an agent. All agents that wish to be discoverable and\n invocable through this protocol MUST provide a metadata document\n conforming to the schema below. This metadata is used for agent\n registration and returned to clients during discovery.\n\n3.1. Core Fields\n\n The following are the core fields of an agent metadata document:\n\n * *id (string):* A globally unique identifier for the agent. This\n could be a UUID or a similarly unique value, assigned by the\n registry upon registration or by the agent provider in advance.\n This ID is used to refer to the agent in all subsequent operations\n (e.g., retrieval, invocation routing).\n\n * *name (string):* A human-readable name for the agent (e.g.,\n "Chinese-English Translator Agent"). Names need not be unique but\n should be descriptive.\n\nCui, et al. Expires 16 August 2026 [Page 5]\nInternet-Draft AIDIP February 2026\n\n * *description (string):* A detailed description of the agent, its\n purpose, and capabilities in natural language. This helps both\n human users and semantic search algorithms understand what the\n agent does.\n\n * *version (string):* The version of the agent or its metadata\n (e.g., "1.0.0"). This allows tracking of agent updates over time.\n\n * *publisher (string):* The name or identifier of the entity\n publishing the agent (e.g., an organization name or developer\n name).\n\n * *capabilities (array of strings):* A list of capabilities the\n agent supports. Capabilities are high-level descriptors (like\n tags or categories) that clients can filter by. Examples:\n ["translation", "summarization", "text_generation"].\n\n * *tags (array of strings):* Additional tags for search and\n categorization (e.g., ["nlp", "chinese", "transformer_model",\n "cloud"]). Tags differ from capabilities in that they can include\n broader or orthogonal categories (like domain, language support,\n deployment model, etc.).\n\n * *endpoint (string):* The URL of the agent's invocation endpoint.\n If the agent is behind a gateway, this could be either the direct\n endpoint or, if direct access is not allowed, a gateway path\n (e.g., the gateway might provide a unified endpoint like\n /agents/{id}/invoke and internally route to the actual agent\n endpoint).\n\n * *supported_languages (array of strings, optional):* A list of\n languages the agent supports (e.g., ["en", "zh", "fr"]). For\n agents dealing with natural language tasks, this field indicates\n which languages are handled. If omitted, the agent is either\n language-agnostic or should not be filtered by language.\n\n * *authentication (object, optional):* Describes the authentication\n mechanism required to invoke the agent. This object may include:\n\n - *type (string):* e.g., "api_key", "oauth2_bearer", "mtls"\n (mutual TLS), "none".\n\n - *instructions (string):* Human-readable note or URL for\n obtaining credentials.\n\n - *scopes (array of strings):* If OAuth 2.0 is used, the OAuth\n scopes required.\n\nCui, et al. Expires 16 August 2026 [Page 6]\nInternet-Draft AIDIP February 2026\n\n If no authentication is required, this field can be omitted or set\n with type: "none".\n\n * *status (string, optional):* Operational status of the agent\n (e.g., "active", "inactive", "deprecated"). The registry may use\n this to filter out agents that are not currently available.\n\n * *additional fields:* Additional fields may include metadata about\n rate limits (e.g., max calls per minute), pricing info (if the\n agent charges per use), or links to documentation. These are not\n standardized here but can be included in agent metadata as needed.\n\n3.2. Operations and I/O Schema\n\n Each agent MUST describe its input and output formats. This is done\n using the *operations* field:\n\n * *operations (array of objects):* A list of operations the agent\n supports. Each operation object has:\n\n - *name (string):* The operation name/identifier (e.g.,\n "translateText", "summarize").\n\n - *description (string):* A description of what the operation\n does.\n\n - *inputs (object):* A JSON Schema describing the expected input.\n This allows clients to understand what data to send. The JSON\n Schema can specify required fields, types, enums, etc.\n\n - *outputs (object):* A JSON Schema describing the output format.\n\n - *examples (array of objects, optional):* Example input/output\n pairs. Each example is an object {"input": {...}, "output":\n {...}} showing a sample invocation.\n\n If an agent has a single operation, this array will have one element.\n If it can do multiple distinct tasks, each is listed here. Some\n agents may not have structured operations (e.g., a general-purpose\n language model that just produces text). In that case, the\n operations field might include a generic operation like {"name":\n "generate", ...}.\n\nCui, et al. Expires 16 August 2026 [Page 7]\nInternet-Draft AIDIP February 2026\n\n If an agent has a single operation, this array will have one element.\n If it can do multiple distinct tasks, each is listed here. For\n simple agents with one primary function, an alternative is to use\n top-level inputs and outputs fields directly (instead of an\n operations array). In that case, the whole agent effectively has one\n implied operation. This spec allows both styles, but using\n operations is recommended for future extensibility.\n\n3.3. Example Agent Metadata\n\n Below is an example metadata JSON for a translation agent:\n\n json { "id": "agent-12345", "name": "Chinese-English Translator",\n "description": "Translates text between Chinese and English with high\n accuracy using a fine-tuned model.", "version": "1.2.0", "publisher":\n "ExampleAI Inc.", "capabilities": ["translation"], "tags": ["nlp",\n "chinese", "english", "cloud"], "endpoint":\n "https://api.example.com/agents/translate", "supported_languages":\n ["en", "zh"], "authentication": { "type": "api_key", "instructions":\n "Include 'X-API-Key' header with your API key." }, "status":\n "active", "operations": [ { "name": "translateText", "description":\n "Translates text from source language to target language.", "inputs":\n { "type": "object", "properties": { "text": {"type": "string"},\n "source_language": {"type": "string", "enum": ["en", "zh"]},\n "target_language": {"type": "string", "enum": ["en", "zh"]} },\n "required": ["text", "source_language", "target_language"] },\n "outputs": { "type": "object", "properties": { "translated_text":\n {"type": "string"} } }, "examples": [ { "input": {"text": "你好世界",\n "source_language": "zh", "target_language": "en"}, "output":\n {"translated_text": "Hello World"} } ] } ] }\n\n This metadata tells us the agent is an active translation agent for\n Chinese and English, requires an API key for authentication, and has\n one operation translateText with a clear input/output schema.\n\n4. Agent Discovery Mechanism\n\n The discovery mechanism allows clients to find agents that meet\n certain criteria. Discovery is provided by an Agent Registry (or\n Discovery Service) that aggregates metadata from multiple agents.\n\n4.1. Registry Overview\n\n The Agent Registry is a network-accessible service that:\n\n 1. Allows agents (or their administrators) to register metadata\n about the agent.\n\nCui, et al. Expires 16 August 2026 [Page 8]\nInternet-Draft AIDIP February 2026\n\n 2. Stores and indexes these metadata entries for efficient search.\n\n 3. Provides endpoints for clients to query and retrieve agent\n information.\n\n A registry may be operated by an organization for its internal\n agents, or by a third party acting as a directory of agents across\n multiple providers. Multiple registries can coexist;\n interoperability between registries is facilitated by consistent\n metadata formats, though formal registry federation is out of scope\n for this draft.\n\n4.2. Agent Registration\n\n An agent (or its administrator) registers with the registry by\n sending its metadata to a registration endpoint:\n\n * *Endpoint:* POST /agents\n\n * *Request Body:* The agent metadata JSON document.\n\n * *Response:* On success, the registry returns *201 Created* (if a\n new agent was added) or *200 OK* (if an existing agent was\n updated), with the stored agent metadata (including the assigned\n id if the agent did not provide one). If validation fails (e.g.,\n missing required fields), the registry returns a *400 Bad Request*\n with error details.\n\n The registry MUST validate the metadata against the schema.\n Registration may require authentication (for example, the registry\n only allows verified publishers to register agents).\n\n Updates to an agent's metadata (e.g., a new version, changed\n endpoint, etc.) can be done via a PUT request to the agent's entry:\n\n * *Endpoint:* PUT /agents/{id}\n\n * *Request Body:* Updated metadata.\n\n * *Response:* *200 OK* on success; *404 Not Found* if no agent with\n that ID exists; *403 Forbidden* if the requester is not authorized\n to update that agent.\n\n4.3. Querying Agents\n\n Clients query the registry using the search endpoint. The protocol\n supports two types of queries:\n\nCui, et al. Expires 16 August 2026 [Page 9]\nInternet-Draft AIDIP February 2026\n\n4.3.1. Attribute-Based Query (Filter)\n\n Clients can specify criteria to filter agents by capabilities, tags,\n supported languages, etc.\n\n * *Endpoint:* GET /agents?capabilities=X&tags=Y&language=Z\n\n * or a structured query via *POST /agents/search* with a JSON body.\n\n For simplicity, *POST /agents/search* is recommended for more complex\n queries. The body might look like:\n\n json { "filters": { "capabilities": ["translation"],\n "supported_languages": ["en", "zh"], "tags": ["nlp"] }, "top": 10 }\n\n This returns up to 10 agents that match all the specified filters.\n Filters are combined with AND logic (the agent must satisfy all\n conditions). Capabilities and tags are matched by set intersection\n (the agent must have at least the ones listed).\n\n The response is a JSON array of agent summary objects:\n\n json [ { "id": "agent-12345", "name": "Chinese-English Translator",\n "description": "...", "endpoint": "https://api.example.com/agents/\n translate", "capabilities": ["translation"] }, ... ]\n\n Summary objects include essential fields to help the client decide\n which agent to use, without returning the full detailed metadata. A\n client can retrieve full metadata via the single-agent endpoint.\n\n4.3.2. Semantic Query (Natural Language Search)\n\n In addition to attribute-based search, the registry MAY support\n semantic search where the client describes a need in natural\n language, and the registry uses AI techniques (embeddings, LLM-based\n matching) to find relevant agents. This is an optional feature for\n registries.\n\n * *Endpoint:* POST /agents/search\n\n * *Request Body:* json { "query": "I need an agent that can\n summarize long legal documents in Chinese.", "top": 5 }\n\n The registry returns a ranked list of agents whose descriptions match\n the query semantically, possibly including a match score. For\n example:\n\nCui, et al. Expires 16 August 2026 [Page 10]\nInternet-Draft AIDIP February 2026\n\n json [ { "id": "agent-67890", "name": "Legal Document Summarizer",\n "description": "...", "score": 0.93 }, ... ]\n\n Semantic search enables flexible discovery beyond exact filter\n matching, aligning with how users or orchestrating agents might\n reason about tasks. Registries not supporting semantic search simply\n ignore the query text and rely on provided filters.\n\n4.3.3. Retrieve Single Agent\n\n * *Endpoint:* GET /agents/{id}\n\n * *Response:* Full metadata JSON for the specified agent, or *404*\n if not found.\n\n5. Agent Invocation\n\n Once a client discovers a suitable agent, it invokes the agent by\n sending a request to the agent's endpoint. This section defines the\n interface for invocation.\n\n5.1. Invocation Request\n\n To invoke an agent, the client sends an HTTP POST request to the\n agent's invocation endpoint with a JSON body containing the input\n data for the agent's task.\n\n * *Method:* POST\n\n * *URL:* The endpoint URL from the agent's metadata (e.g.,\n https://api.example.com/agents/translate). If a gateway is used,\n the URL might be a gateway-provided path.\n\n * *Headers:*\n\n - Content-Type: application/json\n\n - Authentication header as required (e.g., Authorization: Bearer\n <token> or X-API-Key: <key>).\n\n * *Body:* A JSON object containing input data as per the agent's\n input schema.\n\n For example, invoking the translation agent:\n\n json { "text": "Hello, how are you?", "source_language": "en",\n "target_language": "fr" }\n\nCui, et al. Expires 16 August 2026 [Page 11]\nInternet-Draft AIDIP February 2026\n\n This corresponds to the agent's expected input fields. If the agent\n had multiple operations and a unified endpoint, there might be an\n additional field to specify which operation or capability to use.\n For instance, the JSON could include something like "operation":\n "translateText" if needed. Alternatively, different operations could\n be exposed at different URLs (e.g., /agents/xyz/translate vs\n /agents/xyz/summarize), in which case the operation is selected by\n the URL and no extra field is required.\n\n The protocol does not fix a specific parameter naming; it defers to\n the agent's published schema. The only requirement is that the\n client's JSON must conform to what the agent expects. For\n interoperability, using clear field names and standard data types\n (strings, numbers, booleans, or structured objects) is encouraged.\n Binary data (like images for an image-processing agent) should be\n handled carefully: typically, binary inputs can be provided either as\n URLs (pointing to where the data is stored), or as base64-encoded\n strings within the JSON, or by using a multipart request. This\n specification suggests that if agents need to receive large binary\n payloads, they either use URL references or out-of-scope mechanisms\n (like a separate upload and then an ID in the JSON). The core\n invocation remains JSON-based for simplicity and consistency.\n\n *Headers:* If authentication is required (see Security section), the\n client must also include the appropriate headers (e.g.,\n Authorization: Bearer <token> or an API key header) as dictated by\n the agent's metadata. The invocation request may also include\n optional headers for correlation or debugging, such as a request ID,\n but those are not standardized here.\n\n5.2. Invocation Response\n\n The agent (or gateway) will process the request and return a\n response. The status code and JSON body of the response follow these\n guidelines:\n\n * *Success (2xx status):* If the agent successfully performed its\n task and produced a result, the status SHOULD be *200 OK* (or *201\n Created* if a new resource was created as a result, though usually\n for these actions 200 is fine). The response body will contain\n the output data in JSON. Ideally, the output JSON conforms to the\n agent's advertised output schema.\n\n For example, for the translation request above, a success response\n might be:\n\n json { "translated_text": "Bonjour, comment êtes-vous?" }\n\nCui, et al. Expires 16 August 2026 [Page 12]\nInternet-Draft AIDIP February 2026\n\n Here the JSON structure matches what was described in the agent\n metadata's outputs. If the output is complex (e.g., multiple\n fields or nested objects), those should appear accordingly. The\n response can include other informational fields if necessary (for\n example, some agents might return usage metrics, like tokens used\n or time taken, or a trace id for debugging, but these are optional\n and out of scope of the core spec).\n\n * *Client Error (4xx status):* If the request was malformed or\n invalid, the agent returns a *4xx* status code. The most common\n would be *400 Bad Request* for a JSON that doesn't conform to the\n expected schema or missing required fields. For example, if the\n client omitted a required field target_language, the agent might\n respond with 400. The response body SHOULD include an error\n object explaining what went wrong. We define a simple standard\n for error objects:\n\n json { "error": { "code": "InvalidInput", "message": "Required\n field 'target_language' is missing." } }\n\n Here, "code" is a short string identifier for the error type\n (e.g., InvalidInput, Unauthorized, NotFound), and "message" is a\n human-readable description. The agent can include additional\n details if available (e.g., a field name that is wrong, etc.). If\n the error is due to unauthorized access, *401 Unauthorized* or\n *403 Forbidden* should be used (with an appropriate error message\n indicating credentials are missing or insufficient). If the agent\n ID is not found (perhaps the client used an outdated reference),\n *404 Not Found* is appropriate.\n\n * *Server/Agent Error (5xx status):* If something goes wrong on the\n agent's side during processing (an exception, a timeout while\n executing the task, etc.), the agent (or gateway) returns a *5xx*\n status (most likely *500 Internal Server Error* or *502/504* if\n there are upstream issues). The response should again include an\n error object. For example:\n\n json { "error": { "code": "AgentError", "message": "The agent\n encountered an unexpected error while processing the request." } }\n\n The agent might log the detailed error internally, but only convey\n a generic message to the client for security. A *503 Service\n Unavailable* might be returned if the agent is temporarily\n overloaded or offline, indicating the client could retry later.\n\n * *Status Codes Summary:* In short, this protocol expects the use of\n standard status codes to reflect outcome (200 for success, 4xx for\n client-side issues, 5xx for server-side issues). Agents should\n\nCui, et al. Expires 16 August 2026 [Page 13]\nInternet-Draft AIDIP February 2026\n\n avoid using 2xx if the operation did not semantically succeed\n (even if technically a response was generated). For example, if\n an agent is a composite that calls other services and one of those\n calls fails, it should propagate an error rather than returning\n 200 with an error in the data.\n\n5.3. Additional Considerations for Invocation\n\n * *Streaming Responses:* Some agents (especially those wrapping\n large language models) may produce results that are streamed (for\n example, token-by-token outputs). While this base protocol\n assumes a request-response pattern with the full result delivered\n at once, it can be extended to support streaming by using chunked\n responses or WebSockets. For instance, an agent might accept a\n parameter like stream: true and then send partial outputs as they\n become available. This is an advanced use case and not elaborated\n in this draft, but implementers should consider compatibility with\n streaming if real-time responsiveness is needed.\n\n * *Batch Requests:* If a client wants to send multiple independent\n requests to an agent in one go (for efficiency), the protocol can\n support that by allowing an array of input objects in the POST\n body instead of a single object. The response would then be an\n array of output results. This is optional and depends on agent\n support.\n\n * *Idempotency and Retries:* Most agent invocations are not strictly\n idempotent (since an agent might perform an action or have side\n effects), but many are pure functions (e.g., translate text).\n Clients and gateways should design with retry logic carefully — if\n a network failure happens, a retry might re-run an operation.\n It's best to ensure that agents' operations are either idempotent\n or have safeguards (for example, an operation that sends an email\n might have an idempotency key).\n\n * *Operation Metadata:* In cases where the agent defines multiple\n operations in its metadata, the invocation interface might allow a\n generic endpoint that accepts an operation name. Alternatively,\n each operation could be a sub-resource. This draft leaves the\n exact mechanism flexible: an implementation could choose one of\n these approaches. The key is that the invocation uses POST and a\n JSON body following the agent's schema.\n\nCui, et al. Expires 16 August 2026 [Page 14]\nInternet-Draft AIDIP February 2026\n\n6. Agent Semantic Resolution\n\n Agent Semantic Resolution (ASR) is an optional extension to the\n discovery mechanism defined in this document. ASR enables a client\n to resolve a task intent into one or more candidate agents prior to\n invoking any specific agent.\n\n ASR operates on the following conceptual model:\n\n (Intent, Context, Policy) → (Agent Endpoint(s), Invocation Metadata)\n\n The intent represents the task to be performed, while context and\n policy may include domain constraints, trust requirements, or\n performance considerations.\n\n6.1. Non-Goals\n\n ASR explicitly does not provide:\n\n * Name-to-address resolution\n\n * Global or persistent agent identifiers\n\n * Replacement for DNS, ANS, or URI-based registries\n\n ASR answers the question "Which agent(s) should handle this task\n now?" rather than "Where is agent X located?".\n\n7. Semantic Routing Platform\n\n A Semantic Routing Platform (SRP) is a control-plane service that\n implements ASR. An SRP assists a Host Agent in selecting appropriate\n agents before standard discovery and invocation procedures are used.\n\n An SRP MAY perform semantic matching, ranking, and policy-based\n filtering of candidate agents. The SRP does not participate in task\n execution and does not alter the invocation semantics defined in this\n document.\n\n Interaction with an SRP is OPTIONAL. Clients that do not support ASR\n continue to operate using the discovery and invocation mechanisms\n defined in earlier sections.\n\nCui, et al. Expires 16 August 2026 [Page 15]\nInternet-Draft AIDIP February 2026\n\n8. Backward Compatibility\n\n All discovery and invocation mechanisms defined in previous revisions\n of this document remain valid and unchanged.\n\n Agent Semantic Resolution is an optional extension. Implementations\n MAY support ASR incrementally, and registries MAY provide semantic\n resolution capabilities without affecting existing clients.\n\n9. Security Considerations\n\n Security is a critical aspect of this protocol. All discovery and\n invocation traffic MUST be protected with TLS [RFC8446], and\n authentication mechanisms such as OAuth 2.0 [RFC6749] bearer tokens,\n API keys, or mutual TLS are required except for public discovery\n endpoints. Registries MUST enforce per-client entitlements, ensuring\n that both search results and invocation access respect permissions\n and scopes. Gateways forwarding requests should authenticate\n themselves to agents, and agents should maintain stable identifiers\n and use signed responses when integrity is essential. All\n communication MUST be encrypted, and agents are encouraged to\n disclose data-retention or logging practices, while sensitive data is\n best handled by on-premises or certified agents. To mitigate abuse,\n registries and agents MUST implement rate limiting and quotas,\n particularly in semantic search scenarios. Trust mechanisms such as\n certification, test harnesses, or reputation systems may be used to\n validate agent claims, and metadata fields like "certification" or\n "quality_score" can inform client trust decisions. Systems SHOULD\n also provide audit and logging with privacy-aware retention, while\n clients must treat agent outputs as untrusted until verified, using\n sandboxing and validation before executing code or commands.\n\n When Agent Semantic Resolution is used, security considerations\n extend to the pre-invocation phase. Resolution services SHOULD\n validate agent capability claims, apply policy constraints, and\n exclude agents that do not meet trust or reputation requirements.\n Agents deemed unsafe SHOULD NOT be returned as resolution candidates.\n\n10. Example Interaction Flow\n\n 1. *Search:* Client POST /agents/search with {"query":"summarize an\n English document","filters":{"capabilities":["summarization"],"su\n pported_language":"en"},"top":3}.\n\n 2. *Select:* Registry returns candidate agents with id, name,\n description, and score. Client retrieves full metadata via GET\n /agents/{id} if needed.\n\nCui, et al. Expires 16 August 2026 [Page 16]\nInternet-Draft AIDIP February 2026\n\n 3. *Invoke:* Client POST to the agent's endpoint (or gateway path)\n with inputs conforming to agent schema and required auth header.\n\n 4. *Handle Response:* Client processes success or error response;\n may log usage and optionally rate/feedback the agent.\n\n11. IANA Considerations\n\n This document has no IANA actions.\n\n12. Normative References\n\n [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate\n Requirement Levels", BCP 14, RFC 2119,\n DOI 10.17487/RFC2119, March 1997,\n <https://www.rfc-editor.org/rfc/rfc2119>.\n\n [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",\n RFC 6749, DOI 10.17487/RFC6749, October 2012,\n <https://www.rfc-editor.org/rfc/rfc6749>.\n\n [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC\n 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,\n May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.\n\n [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data\n Interchange Format", STD 90, RFC 8259,\n DOI 10.17487/RFC8259, December 2017,\n <https://www.rfc-editor.org/rfc/rfc8259>.\n\n [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol\n Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,\n <https://www.rfc-editor.org/rfc/rfc8446>.\n\n [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,\n Ed., "HTTP Semantics", STD 97, RFC 9110,\n DOI 10.17487/RFC9110, June 2022,\n <https://www.rfc-editor.org/rfc/rfc9110>.\n\nAcknowledgments\n\n TODO acknowledge.\n\nAuthors' Addresses\n\nCui, et al. Expires 16 August 2026 [Page 17]\nInternet-Draft AIDIP February 2026\n\n Yong Cui\n Tsinghua University\n Beijing, 100084\n China\n Email: cuiyong@tsinghua.edu.cn\n URI: http://www.cuiyong.net/\n\n Yihan Chao\n Zhongguancun Laboratory\n Beijing, 100094\n China\n Email: chaoyh@zgclab.edu.cn\n\n Chenguang Du\n Zhongguancun Laboratory\n Beijing, 100094\n China\n Email: ducg@zgclab.edu.cn\n\nCui, et al. Expires 16 August 2026 [Page 18]\n\n