| Internet-Draft | \nAIDIP | \nFebruary 2026 | \n
| Cui, et al. | \nExpires 16 August 2026 | \n[Page] | \n
This document proposes a standardized protocol for discovery and invocation of AI agents. It defines a common metadata format for describing AI agents (including capabilities, I/O specifications, supported languages, tags, authentication methods, etc.), a capability-based discovery mechanism, and a unified RESTful invocation interface.¶
\nThis revision additionally specifies an optional extension that enables intent-based agent selection prior to discovery and invocation, without changing existing discovery or invocation semantics.¶
\nThe goal is to enable cross-platform interoperability among AI agents by providing a discover-and-match mechanism and a unified invocation entry point. Security considerations, including authentication and trust measures, are also discussed. This specification aims to facilitate the formation of multi-agent systems by making it easy to find the right agent for a task and invoke it in a consistent manner across different vendors and platforms.¶
\nThis note is to be removed before publishing as an RFC.¶
\n\n The latest revision of this draft can be found at https://example.com/LATEST.\n Status information for this document may be found at https://datatracker.ietf.org/doc/draft-cui-ai-agent-discovery-invocation/.¶
\n\n Discussion of this document takes place on the\n WG Working Group mailing list (mailto:WG@example.com),\n which is archived at https://example.com/WG.¶
\nSource for this draft and an issue tracker can be found at\n https://github.com/USER/REPO.¶
\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 Task\n Force (IETF). Note that other groups may also distribute working\n documents as Internet-Drafts. The list of current Internet-Drafts is\n 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\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\n (https://trustee.ietf.org/license-info) in effect on the date of\n publication of this document. Please review these documents\n carefully, as they describe your rights and restrictions with\n respect to this document. Code Components extracted from this\n document must include Revised BSD License text as described in\n Section 4.e of the Trust Legal Provisions and are provided without\n warranty as described in the Revised BSD License.¶
\nAs artificial intelligence technologies advance rapidly, AI agents—autonomous software components capable of perceiving their environment, reasoning, and taking actions to achieve goals—have emerged as a powerful paradigm for task execution. Today, many organizations develop specialized AI agents for various purposes: from text translation and summarization, to code generation, to data analysis and beyond. These agents are often offered as services, accessible over the network and may be integrated into larger systems. However, despite the proliferation of AI agents, there is currently no standard protocol for discovering available agents and invoking their capabilities in a uniform way.¶
\nExisting agent frameworks and platforms facilitate building agents but typically operate in isolated ecosystems, making cross-platform or cross-organization agent interoperability difficult. Each platform tends to define its own APIs for agent description and invocation, which means a client wishing to use agents from multiple sources must adapt to disparate interfaces. This lack of standardization creates friction, increases integration costs, and hampers the development of multi-agent collaborative systems.¶
\nThis document addresses these issues by proposing a standardized AI Agent Discovery and Invocation Protocol. The protocol provides:¶
\nAgent Metadata Specification: A structured JSON Schema for describing an agent's identity, capabilities, inputs, outputs, authentication requirements, and other attributes. This enables agents to publish their specifications in a machine-readable form.¶
\nDiscovery Mechanism: A registry-based approach where agents register themselves and clients can search for agents by capability, tags, or semantic queries. The registry is language and platform agnostic, facilitating cross-platform discovery.¶
\nInvocation Interface: A RESTful API that enables a client (which could be a human user application, another agent, or an orchestration system) to invoke an agent's capabilities through a standard endpoint and JSON payloads.¶
\nSecurity Considerations: Guidelines for authentication, authorization, encrypted transport (TLS), and trust establishment, ensuring that discovery and invocation happen securely.¶
\nInteroperability with Existing Standards: This specification references existing standards such as JSON Schema, OAuth 2.0 [RFC6749], and OpenAPI concepts, and leverages established web technologies for broad compatibility.¶
\nThe primary audience for this specification includes developers of AI agent platforms, providers of AI agent services, and system architects building AI-enabled applications or multi-agent systems. By adopting this protocol, an AI agent developer can make their agent accessible to a wide ecosystem, and a client application can integrate AI agents from multiple vendors without custom integration for each.¶
\nThis revision extends the base protocol with an optional Agent Semantic Resolution layer that enables intent-based agent selection. This extension allows a Host Agent or coordinator to describe a task intent and receive candidate agents without predetermining which agent to invoke. ASR does not replace discovery; it adds a semantic matching phase that can precede or augment the capability-based search defined in earlier sections.¶
\nThe key words \"MUST\", \"MUST NOT\", \"REQUIRED\", \"SHALL\", \"SHALL NOT\", \"SHOULD\", \"SHOULD NOT\", \"RECOMMENDED\", \"NOT RECOMMENDED\",\n\"MAY\", and \"OPTIONAL\" in this document are to be interpreted as\ndescribed in BCP 14 [RFC2119] [RFC8174] when, and only when, they\nappear in all capitals, as shown here.¶
\nAI Agent: An autonomous software component that can perform tasks using artificial intelligence capabilities. Agents may wrap language models, specialized ML models, or reasoning engines, exposing their abilities via defined interfaces.¶
\nAgent Metadata: A structured description of an agent, including name, description, capabilities, input/output schemas, authentication requirements, and endpoint information.¶
\nAgent Registry (Discovery Service): A service that maintains a directory of registered agents and supports queries for discovering agents by attributes or semantic search.¶
\nGateway: (Optional) An intermediary service that routes client requests to appropriate agents. In some deployments, the registry or another service acts as a gateway to simplify client-to-agent connections.¶
\nInvocation Endpoint: The URL provided by an agent (or gateway) where clients send requests to invoke the agent's capabilities.¶
\nCapability: A high-level function an agent can perform, identified by a string (e.g., \"translation\", \"summarization\", \"image_classification\").¶
\nOperation: A specific action supported by an agent. Some agents may have multiple operations; for example, an agent offering both translation and language detection could list these as separate operations, each with its own input/output schema.¶
\nThe Agent Metadata Specification defines a standard JSON document that describes an agent. All agents that wish to be discoverable and invocable through this protocol MUST provide a metadata document conforming to the schema below. This metadata is used for agent registration and returned to clients during discovery.¶
\nThe following are the core fields of an agent metadata document:¶
\nid (string): A globally unique identifier for the agent. This could be a UUID or a similarly unique value, assigned by the registry upon registration or by the agent provider in advance. This ID is used to refer to the agent in all subsequent operations (e.g., retrieval, invocation routing).¶
\nname (string): A human-readable name for the agent (e.g., \"Chinese-English Translator Agent\"). Names need not be unique but should be descriptive.¶
\ndescription (string): A detailed description of the agent, its purpose, and capabilities in natural language. This helps both human users and semantic search algorithms understand what the agent does.¶
\nversion (string): The version of the agent or its metadata (e.g., \"1.0.0\"). This allows tracking of agent updates over time.¶
\npublisher (string): The name or identifier of the entity publishing the agent (e.g., an organization name or developer name).¶
\ncapabilities (array of strings): A list of capabilities the agent supports. Capabilities are high-level descriptors (like tags or categories) that clients can filter by. Examples: [\"translation\", \"summarization\", \"text_generation\"].¶
tags (array of strings): Additional tags for search and categorization (e.g., [\"nlp\", \"chinese\", \"transformer_model\", \"cloud\"]). Tags differ from capabilities in that they can include broader or orthogonal categories (like domain, language support, deployment model, etc.).¶
endpoint (string): The URL of the agent's invocation endpoint. If the agent is behind a gateway, this could be either the direct endpoint or, if direct access is not allowed, a gateway path (e.g., the gateway might provide a unified endpoint like /agents/{id}/invoke and internally route to the actual agent endpoint).¶
supported_languages (array of strings, optional): A list of languages the agent supports (e.g., [\"en\", \"zh\", \"fr\"]). For agents dealing with natural language tasks, this field indicates which languages are handled. If omitted, the agent is either language-agnostic or should not be filtered by language.¶
authentication (object, optional): Describes the authentication mechanism required to invoke the agent. This object may include:¶
\ntype (string): e.g., \"api_key\", \"oauth2_bearer\", \"mtls\" (mutual TLS), \"none\".¶
\ninstructions (string): Human-readable note or URL for obtaining credentials.¶
\nscopes (array of strings): If OAuth 2.0 is used, the OAuth scopes required.¶
\n\nIf no authentication is required, this field can be omitted or set with type: \"none\".¶
status (string, optional): Operational status of the agent (e.g., \"active\", \"inactive\", \"deprecated\"). The registry may use this to filter out agents that are not currently available.¶
additional fields: Additional fields may include metadata about rate limits (e.g., max calls per minute), pricing info (if the agent charges per use), or links to documentation. These are not standardized here but can be included in agent metadata as needed.¶
\nEach agent MUST describe its input and output formats. This is done using the operations field:¶
\noperations (array of objects): A list of operations the agent supports. Each operation object has:¶
\nname (string): The operation name/identifier (e.g., \"translateText\", \"summarize\").¶
\ndescription (string): A description of what the operation does.¶
\ninputs (object): A JSON Schema describing the expected input. This allows clients to understand what data to send. The JSON Schema can specify required fields, types, enums, etc.¶
\noutputs (object): A JSON Schema describing the output format.¶
\nexamples (array of objects, optional): Example input/output pairs. Each example is an object {\"input\": {...}, \"output\": {...}} showing a sample invocation.¶
If an agent has a single operation, this array will have one element. If it can do multiple distinct tasks, each is listed here. Some agents may not have structured operations (e.g., a general-purpose language model that just produces text). In that case, the operations field might include a generic operation like {\"name\": \"generate\", ...}.¶
If an agent has a single operation, this array will have one element. If it can do multiple distinct tasks, each is listed here. For simple agents with one primary function, an alternative is to use top-level inputs and outputs fields directly (instead of an operations array). In that case, the whole agent effectively has one implied operation. This spec allows both styles, but using operations is recommended for future extensibility.¶
Below is an example metadata JSON for a translation agent:¶
\njson\n{\n \"id\": \"agent-12345\",\n \"name\": \"Chinese-English Translator\",\n \"description\": \"Translates text between Chinese and English with high accuracy using a fine-tuned model.\",\n \"version\": \"1.2.0\",\n \"publisher\": \"ExampleAI Inc.\",\n \"capabilities\": [\"translation\"],\n \"tags\": [\"nlp\", \"chinese\", \"english\", \"cloud\"],\n \"endpoint\": \"https://api.example.com/agents/translate\",\n \"supported_languages\": [\"en\", \"zh\"],\n \"authentication\": {\n \"type\": \"api_key\",\n \"instructions\": \"Include 'X-API-Key' header with your API key.\"\n },\n \"status\": \"active\",\n \"operations\": [\n {\n \"name\": \"translateText\",\n \"description\": \"Translates text from source language to target language.\",\n \"inputs\": {\n \"type\": \"object\",\n \"properties\": {\n \"text\": {\"type\": \"string\"},\n \"source_language\": {\"type\": \"string\", \"enum\": [\"en\", \"zh\"]},\n \"target_language\": {\"type\": \"string\", \"enum\": [\"en\", \"zh\"]}\n },\n \"required\": [\"text\", \"source_language\", \"target_language\"]\n },\n \"outputs\": {\n \"type\": \"object\",\n \"properties\": {\n \"translated_text\": {\"type\": \"string\"}\n }\n },\n \"examples\": [\n {\n \"input\": {\"text\": \"你好世界\", \"source_language\": \"zh\", \"target_language\": \"en\"},\n \"output\": {\"translated_text\": \"Hello World\"}\n }\n ]\n }\n ]\n}\n¶
This metadata tells us the agent is an active translation agent for Chinese and English, requires an API key for authentication, and has one operation translateText with a clear input/output schema.¶
The discovery mechanism allows clients to find agents that meet certain criteria. Discovery is provided by an Agent Registry (or Discovery Service) that aggregates metadata from multiple agents.¶
\nThe Agent Registry is a network-accessible service that:¶
\nAllows agents (or their administrators) to register metadata about the agent.¶
\nStores and indexes these metadata entries for efficient search.¶
\nProvides endpoints for clients to query and retrieve agent information.¶
\nA registry may be operated by an organization for its internal agents, or by a third party acting as a directory of agents across multiple providers. Multiple registries can coexist; interoperability between registries is facilitated by consistent metadata formats, though formal registry federation is out of scope for this draft.¶
\nAn agent (or its administrator) registers with the registry by sending its metadata to a registration endpoint:¶
\nEndpoint: POST /agents¶
Request Body: The agent metadata JSON document.¶
\nResponse: On success, the registry returns 201 Created (if a new agent was added) or 200 OK (if an existing agent was updated), with the stored agent metadata (including the assigned id if the agent did not provide one). If validation fails (e.g., missing required fields), the registry returns a 400 Bad Request with error details.¶
The registry MUST validate the metadata against the schema. Registration may require authentication (for example, the registry only allows verified publishers to register agents).¶
\nUpdates to an agent's metadata (e.g., a new version, changed endpoint, etc.) can be done via a PUT request to the agent's entry:¶
\n\nClients query the registry using the search endpoint. The protocol supports two types of queries:¶
\nClients can specify criteria to filter agents by capabilities, tags, supported languages, etc.¶
\nEndpoint: GET /agents?capabilities=X&tags=Y&language=Z¶
or a structured query via POST /agents/search with a JSON body.¶
\nFor simplicity, POST /agents/search is recommended for more complex queries. The body might look like:¶
\njson\n{\n \"filters\": {\n \"capabilities\": [\"translation\"],\n \"supported_languages\": [\"en\", \"zh\"],\n \"tags\": [\"nlp\"]\n },\n \"top\": 10\n}\n¶
This returns up to 10 agents that match all the specified filters. Filters are combined with AND logic (the agent must satisfy all conditions). Capabilities and tags are matched by set intersection (the agent must have at least the ones listed).¶
\nThe response is a JSON array of agent summary objects:¶
\njson\n[\n {\n \"id\": \"agent-12345\",\n \"name\": \"Chinese-English Translator\",\n \"description\": \"...\",\n \"endpoint\": \"https://api.example.com/agents/translate\",\n \"capabilities\": [\"translation\"]\n },\n ...\n]\n¶
Summary objects include essential fields to help the client decide which agent to use, without returning the full detailed metadata. A client can retrieve full metadata via the single-agent endpoint.¶
\nIn addition to attribute-based search, the registry MAY support semantic search where the client describes a need in natural language, and the registry uses AI techniques (embeddings, LLM-based matching) to find relevant agents. This is an optional feature for registries.¶
\nEndpoint: POST /agents/search¶
Request Body:\n json\n{\n \"query\": \"I need an agent that can summarize long legal documents in Chinese.\",\n \"top\": 5\n}\n¶
The registry returns a ranked list of agents whose descriptions match the query semantically, possibly including a match score. For example:¶
\njson\n[\n {\n \"id\": \"agent-67890\",\n \"name\": \"Legal Document Summarizer\",\n \"description\": \"...\",\n \"score\": 0.93\n },\n ...\n]\n¶
Semantic search enables flexible discovery beyond exact filter matching, aligning with how users or orchestrating agents might reason about tasks. Registries not supporting semantic search simply ignore the query text and rely on provided filters.¶
Once a client discovers a suitable agent, it invokes the agent by sending a request to the agent's endpoint. This section defines the interface for invocation.¶
\nTo invoke an agent, the client sends an HTTP POST request to the agent's invocation endpoint with a JSON body containing the input data for the agent's task.¶
\nMethod: POST¶
\nURL: The endpoint URL from the agent's metadata (e.g., https://api.example.com/agents/translate). If a gateway is used, the URL might be a gateway-provided path.¶
Headers:¶
\n\nBody: A JSON object containing input data as per the agent's input schema.¶
\nFor example, invoking the translation agent:¶
\njson\n{\n \"text\": \"Hello, how are you?\",\n \"source_language\": \"en\",\n \"target_language\": \"fr\"\n}\n¶
This corresponds to the agent's expected input fields. If the agent had multiple operations and a unified endpoint, there might be an additional field to specify which operation or capability to use. For instance, the JSON could include something like \"operation\": \"translateText\" if needed. Alternatively, different operations could be exposed at different URLs (e.g., /agents/xyz/translate vs /agents/xyz/summarize), in which case the operation is selected by the URL and no extra field is required.¶
The protocol does not fix a specific parameter naming; it defers to the agent's published schema. The only requirement is that the client's JSON must conform to what the agent expects. For interoperability, using clear field names and standard data types (strings, numbers, booleans, or structured objects) is encouraged. Binary data (like images for an image-processing agent) should be handled carefully: typically, binary inputs can be provided either as URLs (pointing to where the data is stored), or as base64-encoded strings within the JSON, or by using a multipart request. This specification suggests that if agents need to receive large binary payloads, they either use URL references or out-of-scope mechanisms (like a separate upload and then an ID in the JSON). The core invocation remains JSON-based for simplicity and consistency.¶
\nHeaders: If authentication is required (see Security section), the client must also include the appropriate headers (e.g., Authorization: Bearer <token> or an API key header) as dictated by the agent's metadata. The invocation request may also include optional headers for correlation or debugging, such as a request ID, but those are not standardized here.¶
The agent (or gateway) will process the request and return a response. The status code and JSON body of the response follow these guidelines:¶
\nSuccess (2xx status): If the agent successfully performed its task and produced a result, the status SHOULD be 200 OK (or 201 Created if a new resource was created as a result, though usually for these actions 200 is fine). The response body will contain the output data in JSON. Ideally, the output JSON conforms to the agent's advertised output schema.¶
\n\nFor example, for the translation request above, a success response might be:¶
\njson\n{\n \"translated_text\": \"Bonjour, comment êtes-vous?\"\n}\n¶
\nHere the JSON structure matches what was described in the agent metadata's outputs. If the output is complex (e.g., multiple fields or nested objects), those should appear accordingly. The response can include other informational fields if necessary (for example, some agents might return usage metrics, like tokens used or time taken, or a trace id for debugging, but these are optional and out of scope of the core spec).¶
Client Error (4xx status): If the request was malformed or invalid, the agent returns a 4xx status code. The most common would be 400 Bad Request for a JSON that doesn't conform to the expected schema or missing required fields. For example, if the client omitted a required field target_language, the agent might respond with 400. The response body SHOULD include an error object explaining what went wrong. We define a simple standard for error objects:¶
json\n{\n \"error\": {\n \"code\": \"InvalidInput\",\n \"message\": \"Required field 'target_language' is missing.\"\n }\n}\n¶
\nHere, \"code\" is a short string identifier for the error type (e.g., InvalidInput, Unauthorized, NotFound), and \"message\" is a human-readable description. The agent can include additional details if available (e.g., a field name that is wrong, etc.). If the error is due to unauthorized access, 401 Unauthorized or 403 Forbidden should be used (with an appropriate error message indicating credentials are missing or insufficient). If the agent ID is not found (perhaps the client used an outdated reference), 404 Not Found is appropriate.¶
Server/Agent Error (5xx status): If something goes wrong on the agent's side during processing (an exception, a timeout while executing the task, etc.), the agent (or gateway) returns a 5xx status (most likely 500 Internal Server Error or 502/504 if there are upstream issues). The response should again include an error object. For example:¶
\njson\n{\n \"error\": {\n \"code\": \"AgentError\",\n \"message\": \"The agent encountered an unexpected error while processing the request.\"\n }\n}\n¶
\nThe agent might log the detailed error internally, but only convey a generic message to the client for security. A 503 Service Unavailable might be returned if the agent is temporarily overloaded or offline, indicating the client could retry later.¶
\nStatus Codes Summary: In short, this protocol expects the use of standard status codes to reflect outcome (200 for success, 4xx for client-side issues, 5xx for server-side issues). Agents should avoid using 2xx if the operation did not semantically succeed (even if technically a response was generated). For example, if an agent is a composite that calls other services and one of those calls fails, it should propagate an error rather than returning 200 with an error in the data.¶
\nStreaming Responses: Some agents (especially those wrapping large language models) may produce results that are streamed (for example, token-by-token outputs). While this base protocol assumes a request-response pattern with the full result delivered at once, it can be extended to support streaming by using chunked responses or WebSockets. For instance, an agent might accept a parameter like stream: true and then send partial outputs as they become available. This is an advanced use case and not elaborated in this draft, but implementers should consider compatibility with streaming if real-time responsiveness is needed.¶
Batch Requests: If a client wants to send multiple independent requests to an agent in one go (for efficiency), the protocol can support that by allowing an array of input objects in the POST body instead of a single object. The response would then be an array of output results. This is optional and depends on agent support.¶
\nIdempotency and Retries: Most agent invocations are not strictly idempotent (since an agent might perform an action or have side effects), but many are pure functions (e.g., translate text). Clients and gateways should design with retry logic carefully — if a network failure happens, a retry might re-run an operation. It's best to ensure that agents' operations are either idempotent or have safeguards (for example, an operation that sends an email might have an idempotency key).¶
\nOperation Metadata: In cases where the agent defines multiple operations in its metadata, the invocation interface might allow a generic endpoint that accepts an operation name. Alternatively, each operation could be a sub-resource. This draft leaves the exact mechanism flexible: an implementation could choose one of these approaches. The key is that the invocation uses POST and a JSON body following the agent's schema.¶
Agent Semantic Resolution (ASR) is an optional extension to the discovery mechanism defined in this document. ASR enables a client to resolve a task intent into one or more candidate agents prior to invoking any specific agent.¶
\nASR operates on the following conceptual model:¶
\n\n(Intent, Context, Policy) → (Agent Endpoint(s), Invocation Metadata)\n¶
The intent represents the task to be performed, while context and policy may include domain constraints, trust requirements, or performance considerations.¶
\nASR explicitly does not provide:¶
\nName-to-address resolution¶
\nGlobal or persistent agent identifiers¶
\nReplacement for DNS, ANS, or URI-based registries¶
\nASR answers the question \"Which agent(s) should handle this task now?\" rather than \"Where is agent X located?\".¶
\n\nA Semantic Routing Platform (SRP) is a control-plane service that implements ASR. An SRP assists a Host Agent in selecting appropriate agents before standard discovery and invocation procedures are used.¶
\nAn SRP MAY perform semantic matching, ranking, and policy-based filtering of candidate agents. The SRP does not participate in task execution and does not alter the invocation semantics defined in this document.¶
\nInteraction with an SRP is OPTIONAL. Clients that do not support ASR continue to operate using the discovery and invocation mechanisms defined in earlier sections.¶
\n\nAll discovery and invocation mechanisms defined in previous revisions of this document remain valid and unchanged.¶
\nAgent Semantic Resolution is an optional extension. Implementations MAY support ASR incrementally, and registries MAY provide semantic resolution capabilities without affecting existing clients.¶
\nSecurity is a critical aspect of this protocol. All discovery and invocation traffic MUST be protected with TLS [RFC8446], and authentication mechanisms such as OAuth 2.0 [RFC6749] bearer tokens, API keys, or mutual TLS are required except for public discovery endpoints. Registries MUST enforce per-client entitlements, ensuring that both search results and invocation access respect permissions and scopes. Gateways forwarding requests should authenticate themselves to agents, and agents should maintain stable identifiers and use signed responses when integrity is essential. All communication MUST be encrypted, and agents are encouraged to disclose data-retention or logging practices, while sensitive data is best handled by on-premises or certified agents. To mitigate abuse, registries and agents MUST implement rate limiting and quotas, particularly in semantic search scenarios. Trust mechanisms such as certification, test harnesses, or reputation systems may be used to validate agent claims, and metadata fields like \"certification\" or \"quality_score\" can inform client trust decisions. Systems SHOULD also provide audit and logging with privacy-aware retention, while clients must treat agent outputs as untrusted until verified, using sandboxing and validation before executing code or commands.¶
\nWhen Agent Semantic Resolution is used, security considerations extend to the pre-invocation phase. Resolution services SHOULD validate agent capability claims, apply policy constraints, and exclude agents that do not meet trust or reputation requirements. Agents deemed unsafe SHOULD NOT be returned as resolution candidates.¶
\nSearch: Client POST /agents/search with {\"query\":\"summarize an English document\",\"filters\":{\"capabilities\":[\"summarization\"],\"supported_language\":\"en\"},\"top\":3}.¶
Select: Registry returns candidate agents with id, name, description, and score. Client retrieves full metadata via GET /agents/{id} if needed.¶
Invoke: Client POST to the agent's endpoint (or gateway path) with inputs conforming to agent schema and required auth header.¶
Handle Response: Client processes success or error response; may log usage and optionally rate/feedback the agent.¶
\nThis document has no IANA actions.¶
\nTODO acknowledge.¶
\n| Internet-Draft | \nAI Agent Internet Architecture | \nAugust 2026 | \n
| Park | \nExpires 15 February 2027 | \n[Page] | \n
Autonomous AI agents are evolving from interactive assistants into networked software workloads that discover services, invoke tools, delegate authority, transact, communicate with other agents, and act asynchronously on behalf of humans and organizations. Existing Internet protocols provide strong foundations, but agent autonomy, dynamic delegation, machine-speed execution, and cross-domain interaction create requirements that span multiple protocol families.¶
\nThis document describes architectural requirements for supporting AI agents on the Internet across naming and discovery, HTTP, authentication, authorization and delegation, TLS and workload identity, asynchronous messaging, capability and intent-based resolution, payments, provenance, auditability, revocation, security, and privacy. It favors profiling and extending existing Internet protocols over defining a monolithic new agent protocol, and identifies the need for IETF-wide architectural coordination.¶
\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 Task\n Force (IETF). Note that other groups may also distribute working\n documents as Internet-Drafts. The list of current Internet-Drafts is\n 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 15 February 2027.¶
\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\n (https://trustee.ietf.org/license-info) in effect on the date of\n publication of this document. Please review these documents\n carefully, as they describe your rights and restrictions with\n respect to this document. Code Components extracted from this\n document must include Revised BSD License text as described in\n Section 4.e of the Trust Legal Provisions and are provided without\n warranty as described in the Revised BSD License.¶
\nAI agents are becoming autonomous Internet participants rather than merely user-interface features. An agent can interpret a goal, discover remote services, acquire or present delegated authority, select another agent, invoke tools, initiate payments, maintain state, and continue work without a human being present for each network transaction.¶
\nApplication protocols and frameworks can address important agent interaction patterns, but they do not by themselves solve Internet-wide problems of naming, discovery, identity, delegated authorization, trust, payment negotiation, asynchronous delivery, provenance, and accountability across administrative domains.¶
\nAI-agent-related Internet-Drafts are already emerging across authentication and authorization, discovery, agent-to-agent and agent-to-tool communication, transport, and related areas. This breadth indicates that supporting AI agents is not a single application-protocol problem. It also creates a coordination risk if common concepts such as agent identity, capability, delegation, discovery metadata, intent, and transaction context are defined independently.¶
\nThis document defines architectural requirements for supporting AI agents on the Internet. It does not define a separate Internet, a new network layer, or a universal agent protocol. The preferred direction is coordinated evolution of existing Internet mechanisms and new mechanisms only where demonstrated gaps remain.¶
\nThe key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, 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.¶
\nAgent: An autonomous or semi-autonomous software entity that can take network actions based on goals, policies, delegated authority, and contextual state.¶
\nPrincipal: A human, organization, workload, service, or agent whose identity or authority is relevant to an action.¶
\nDelegation: A grant of authority from one principal to another, including scope, time, value, context, or re-delegation constraints.¶
\nCapability: A machine-readable description of an operation or service that an agent can provide.¶
\nIntent: The desired outcome or declared purpose associated with an agent action. Intent is not, by itself, an authorization signal.¶
\nAgent Descriptor: Machine-readable metadata describing an agent's identity, capabilities, endpoints, protocols, security requirements, and related operational properties.¶
\nAI Agent Internet Architecture: The set of Internet protocol mechanisms and coordinated extensions needed to support autonomous AI agents across administrative and trust boundaries. This term does not imply replacement of the existing Internet architecture.¶
\nThis document focuses on protocol-layer interoperability across independently administered Internet domains. It covers discovery, identity, authorization and delegation, trust establishment, HTTP interaction, payment negotiation, asynchronous communication, capability resolution, provenance, auditability, revocation, and privacy.¶
\nThis document does not standardize model behavior, prompt formats, reasoning traces, agent planning algorithms, model evaluation, or a universal agent runtime. It does not select a single application framework as the interaction protocol for all agents.¶
\nExisting Internet protocols can transport agent traffic, but they do not consistently expose the semantics required when autonomous software acts as a principal. A server can authenticate a TLS peer or validate an OAuth access token without necessarily knowing which agent is acting, which human or organization delegated the action, whether re-delegation was permitted, or whether the transaction remains within a spending or operational limit.¶
\nDNS can locate hosts and services, but Internet-wide agent discovery can require resolution by organization, agent name, capability, supported protocol, security profile, or intent. Long-running agent tasks can also require asynchronous delivery and correlation beyond a single synchronous request/response exchange.¶
\nAn interoperable architecture therefore needs machine-processable answers to: who is acting; who operates the agent; on whose behalf it acts; what it is authorized to do; whether that authority may be delegated; what the counterparty can do; how the counterparty is discovered and authenticated; what protocol and security profile to use; what payment is required; and what evidence remains after the action.¶
\nEvolution Before Replacement: Agent-related mechanisms SHOULD reuse deployed Internet protocols and registries where practical. A new protocol SHOULD be introduced only when existing mechanisms cannot provide the required semantics, security properties, deployment model, or scale.¶
\nSeparation of Concerns: Identity, authentication, authorization, delegation, capability, intent, trust, payment, and audit are distinct concepts and MUST NOT be implicitly conflated.¶
\nCross-Domain Operation: Mechanisms MUST assume that agents, principals, authorization services, resource servers, and discovery infrastructure can belong to different administrative domains.¶
\nLeast Authority: Delegated authority SHOULD be narrowly scoped by operation, audience, resource, time, value, and context. Re-delegation SHOULD be explicit rather than assumed.¶
\nHuman and Organizational Accountability: When an agent acts for a human or organization, protocols SHOULD preserve sufficient verifiable evidence to identify the accountable principal without exposing unnecessary personal data.¶
\nDecentralized Deployability: The architecture SHOULD NOT require a single global agent registry, identity provider, payment provider, or trust-score operator.¶
\nA representative transaction can involve a User Principal, a User Agent, one or more Specialist Agents, an Agent Service, an Authorization Server, a Discovery Service, and a Resource Server. These roles can be co-located or distributed across domains.¶
\nA typical sequence is: the principal delegates a constrained task; the agent discovers candidate services or agents; discovery returns endpoints, capabilities, supported protocols, and security metadata; the agent authenticates and presents delegated authority; a specialist agent may receive a bounded re-delegation; a resource may advertise payment or policy requirements; the agent verifies those requirements against its authority; the action is completed; and material authorization, payment, and provenance evidence is retained for audit.¶
\nDNS is a natural component of agent discovery because it provides globally delegated naming, caching, service discovery, and security extensions. DNS for AI Discovery (DNS-AID) is one example of current IETF work in this space.¶
\nREQ-DISC-1: An agent discovery mechanism MUST support discovery when an organization and agent identifier are known.¶
\nREQ-DISC-2: It SHOULD support discovery when the organization is known but the specific agent is not, using capability or service metadata.¶
\nREQ-DISC-3: The architecture SHOULD define how capability-only or intent-assisted discovery can be federated without requiring a mandatory centralized registry.¶
\nREQ-DISC-4: Discovery results SHOULD be able to express endpoint, protocol, protocol version, capability identifiers, authentication requirements, authorization metadata, payment support, and relevant trust material.¶
\nREQ-DISC-5: Discovery metadata MUST have a mechanism for authenticity and integrity protection.¶
\nREQ-DISC-6: Discovery mechanisms SHOULD define caching, freshness, negative caching, key rotation, endpoint mobility, and downgrade behavior.¶
\nHTTP is expected to remain a primary substrate for agent interactions. Agent requirements should preferentially use existing HTTP extensibility mechanisms, including status codes, fields, authentication schemes, content negotiation, HTTP Message Signatures, and Well-Known URIs.¶
\nProgrammatic Payment: HTTP 402 Payment Required and x402-style flows demonstrate a machine-operable payment challenge model. Generic standardization should remain independent of a particular currency, ledger, wallet, or settlement provider.¶
\nREQ-HTTP-1: A payment challenge SHOULD identify the payment scheme, amount or pricing rule, asset or unit, recipient, expiration, replay constraints, and verification method in machine-readable form.¶
\nREQ-HTTP-2: Payment authorization SHOULD be bindable to the agent's delegated spending authority, request target, and transaction context.¶
\nREQ-HTTP-3: Payment mechanisms SHOULD support receipts and SHOULD define failure, retry, duplicate-payment, cancellation, and refund semantics.¶
\nAgent Authentication: HTTP Message Signatures provide a relevant primitive for cryptographically authenticating selected message components.¶
\nREQ-HTTP-4: An agent authentication profile SHOULD define how an agent identifier, signing key, operator identity, request freshness, and key-discovery mechanism are bound to a signed request.¶
\nIntent and Policy Signaling: Any standardized intent or purpose signal MUST be treated as a declaration rather than proof of authorization, and SHOULD be cryptographically bound to the authenticated request when relied upon for policy.¶
\nCapability Negotiation: HTTP-based agent protocols SHOULD reuse standard content negotiation and extensibility patterns rather than creating incompatible negotiation mechanisms for every framework.¶
\nTLS protects channels and authenticates endpoints, but an agentic system can require additional bindings among endpoint identity, workload identity, agent identity, operator, and delegating principal.¶
\nREQ-ID-1: Agent identity SHOULD be verifiably bound to a key or workload identity that supports rotation and short lifetimes.¶
\nREQ-ID-2: The architecture SHOULD support proof that an agent is authorized to represent a domain or organization.¶
\nREQ-ID-3: Endpoint authentication and agent authentication SHOULD be independently verifiable where they represent different principals.¶
\nREQ-ID-4: Trust decisions MUST NOT be inferred solely from successful authentication.¶
\nREQ-ID-5: Designs SHOULD avoid globally stable identifiers when a scoped or pairwise identifier can satisfy the use case.¶
\nLong-running research, procurement, orchestration, and offline workflows do not always fit synchronous HTTP request/response. Current individual proposals explore asynchronous store-and-forward semantics for agents.¶
\nREQ-MSG-1: An asynchronous agent messaging mechanism SHOULD support globally unique message identifiers, correlation identifiers, expiration, retry, delivery status, and duplicate detection.¶
\nREQ-MSG-2: It SHOULD provide end-to-end integrity and SHOULD allow confidentiality independent of relay hops.¶
\nREQ-MSG-3: Relay infrastructure MUST be able to apply abuse controls without requiring access to unnecessary private task content.¶
\nREQ-MSG-4: The mechanism SHOULD define how authorization and delegation evidence is carried or referenced across delayed delivery.¶
\nREQ-MSG-5: The IETF should first evaluate whether profiles of existing HTTP, messaging, event, or mail technologies can meet these requirements before defining a new transport.¶
\nAI-agent systems add a resolution problem above IP routing: selecting a service or agent because it can satisfy a requested capability under policy constraints. This is service selection and resolution at a higher layer, not a replacement for IP routing.¶
\nREQ-CAP-1: Capability identifiers SHOULD have stable semantics independent of a single vendor or agent framework.¶
\nREQ-CAP-2: Capability descriptions SHOULD be separable from endpoint location.¶
\nREQ-CAP-3: Query and matching mechanisms SHOULD support constraints such as language, protocol, security profile, jurisdiction, price, latency, and policy.¶
\nREQ-CAP-4: Ranking and reputation information MUST NOT be treated as authoritative identity or authorization evidence.¶
\nREQ-CAP-5: Intent-based discovery SHOULD minimize disclosure because the query itself can reveal sensitive user goals.¶
\nAutonomous agents can purchase API calls, data, compute, content, reservations, or other services. Payment must compose with discovery, authorization, spending policy, identity, and audit rather than exist as an isolated wallet operation.¶
\nREQ-PAY-1: A principal MUST be able to constrain an agent's spending by amount, currency or asset class, recipient or category, time, and transaction type.¶
\nREQ-PAY-2: A payment proof SHOULD be bound to the resource request sufficiently to prevent replay for a different resource or amount.¶
\nREQ-PAY-3: The protocol architecture SHOULD permit multiple payment schemes and SHOULD NOT require a particular blockchain or settlement network.¶
\nREQ-PAY-4: Services SHOULD provide machine-readable receipts that can be correlated with authorization and audit records.¶
\nAgent actions can have financial, operational, legal, or security consequences. Protocols should preserve evidence of consequential actions without requiring disclosure of model chain-of-thought or unnecessary private content.¶
\nREQ-AUD-1: Audit evidence SHOULD support correlation of agent identity, operator or accountable principal, authorization context, request identifier, timestamp, material policy constraints, result status, and payment reference when applicable.¶
\nREQ-AUD-2: Audit evidence SHOULD be tamper-evident and SHOULD support selective disclosure.¶
\nREQ-AUD-3: Protocols MUST NOT require collection of private reasoning traces as a condition of accountability.¶
\nREQ-AUD-4: Audit identifiers SHOULD be scoped to reduce cross-service tracking.¶
\nAutonomy and machine-speed execution make revocation a first-order protocol requirement.¶
\nREQ-REV-1: Credentials and delegated authority SHOULD support short validity periods and explicit revocation where risk requires it.¶
\nREQ-REV-2: Revocation of a parent delegation SHOULD invalidate or constrain dependent re-delegations according to explicit semantics.¶
\nREQ-REV-3: Services SHOULD support rapid suspension of compromised agents or keys without requiring deletion of historical audit evidence.¶
\nREQ-REV-4: Emergency controls SHOULD be fail-safe and SHOULD avoid a single globally privileged kill switch.¶
\nApplication-layer agent protocols and frameworks are complementary to the Internet mechanisms described here. They can benefit from standardized discovery, authentication, delegated authorization, payment, and trust mechanisms.¶
\nThe architectural objective is composability: discovery identifies a candidate endpoint; identity authenticates it; authorization determines permitted actions; an interaction protocol carries the task; payment settles economic requirements; and provenance or audit mechanisms retain evidence. No single layer should be expected to solve all of these functions.¶
\nCandidate cross-area work includes an agent identity profile; an OAuth-compatible multi-hop delegation profile; DNS and Well-Known based agent discovery profiles; a framework-neutral capability vocabulary and discovery metadata model; an HTTP Message Signatures profile for agents; authenticated intent and policy metadata; generic HTTP payment negotiation and receipt semantics; asynchronous agent messaging requirements; privacy-preserving provenance and audit evidence; and revocation semantics for delegation chains.¶
\nProtocol-specific wire work should remain with established expert Working Groups where appropriate. Cross-area work is needed for common terminology, architecture, gap analysis, and composability.¶
\nAs of August 2026, AI-agent-related Internet-Drafts span several protocol domains. Examples include DNS for AI Discovery (DNS-AID); AI Agent Authentication and Authorization; Agentic AI Use Cases and Requirements; and individual proposals addressing agent discovery, invocation, transport, and authorization.¶
\nThis activity is evidence of a broad protocol problem, but it also exposes a coordination gap. The drafts do not necessarily share a common model for agent identity, operator identity, capability identifiers, delegation, discovery metadata, intent, transaction context, or trust. Similar functions can therefore be specified independently at different layers or by different communities.¶
\nThe architectural requirement is not that every proposal use the same wire protocol. It is that common concepts have clear ownership and composable semantics. Discovery should be able to reference an authorization profile without redefining authorization; payment should be bindable to delegated authority without defining a new identity system; and agent interaction protocols should be able to consume common discovery and security metadata.¶
\nA cross-IETF gap analysis and terminology effort is therefore needed before multiple overlapping mechanisms become widely deployed.¶
\nThe requirements in this document cut across several existing IETF Areas and protocol families. Naming and discovery touch DNS and Internet-area work; authentication, authorization, delegation, and provenance touch Security and OAuth or workload-identity work; HTTP semantics and messaging touch Applications and Real-Time and transport-related communities; and deployment and lifecycle management touch Operations and Management.¶
\nWithout explicit coordination, independently developed solutions risk duplicating functions, defining incompatible identity or capability models, creating overlapping discovery mechanisms, and placing agent-specific semantics at inconsistent layers of the Internet architecture.¶
\nThis document RECOMMENDS that the IETF initiate a community-wide discussion on a dedicated coordination structure for AI-agent-related Internet protocol work. If the scope, volume, and persistence of the work justify Area-level organization, the IETF should consider a new AI Agents Area. The purpose would not be to standardize AI models or relocate every AI-related specification. Its purpose would be to coordinate Internet protocol evolution required to support autonomous AI agents and maintain architectural consistency across affected protocol families.¶
\nA dedicated coordination structure could cover agent naming and discovery; agent and operator identity; authentication; delegated and multi-hop authorization; capability and intent representation; agent-to-agent and asynchronous communication; HTTP agent semantics; payment negotiation; provenance and auditability; revocation and lifecycle management; privacy; abuse prevention; and interoperability with application-layer agent protocols.¶
\nThe coordination structure SHOULD follow an extend-before-invent principle. Work should remain in an established Working Group when an existing protocol clearly owns the mechanism and the required expertise exists there.¶
\nAs an incremental path, the IETF could first convene a BOF or other community discussion, establish a directorate or cross-area design team, publish an architectural gap analysis, and then determine whether a permanent Area and one or more Working Groups are justified.¶
\nThe success criterion is not creation of a new Area itself. The success criterion is that Internet standards for autonomous agents evolve as a coherent architecture: reusable across vendors and agent frameworks, decentralized where appropriate, secure by design, and compatible with the existing Internet.¶
\nAI-agent protocols amplify existing Internet threats because actions can be chained and executed at machine speed. Threats include agent impersonation, compromised credentials, confused-deputy behavior, malicious or poisoned discovery metadata, unauthorized re-delegation, replay of payment or authorization proofs, prompt- or tool-induced privilege escalation, downgrade attacks, trust manipulation, denial-of-wallet attacks, recursive agent loops, and automated abuse.¶
\nImplementations MUST apply least privilege, audience restriction, freshness and replay defenses, secure key management, explicit re-delegation policy, and strong separation between untrusted content and authorization decisions. Discovery results SHOULD be authenticated where feasible. High-impact actions SHOULD support policy-enforced limits and, where appropriate, explicit human approval.¶
\nAgent descriptors and capability advertisements are untrusted input until authenticated and authorized. Authenticated descriptive text still MUST NOT be interpreted as executable authorization policy.¶
\nAgent identity, discovery queries, capability requirements, delegation chains, payment metadata, and audit records can reveal sensitive behavior and relationships. Designs SHOULD minimize globally visible metadata, support selective disclosure, and avoid stable cross-context identifiers where unnecessary.¶
\nCapability-only and intent-based discovery deserves particular scrutiny because a query can reveal user goals. Personal-agent presence SHOULD NOT be made globally discoverable by default.¶
\nMulti-hop delegation SHOULD permit a resource server to verify sufficient authority without automatically learning every upstream intermediary or unrelated user attribute.¶
\nAgent discovery and authorization infrastructure will be highly dynamic. Specifications should define cache lifetimes, stale-data behavior, key rotation, clock-skew tolerance, endpoint migration, retry policy, rate limits, and failure modes.¶
\nInteroperability profiles should support incremental deployment. A conventional API client should remain able to use a service when optional agent metadata is absent, unless the service explicitly requires an agent-specific security profile.¶
\nOperators should be able to distinguish protocol failures from policy denials and from agent-level task failures without exposing sensitive internal policy details.¶
\nThis document requests no IANA actions. Future specifications may require registrations for HTTP fields, Well-Known URI suffixes, OAuth metadata, DNS service labels or SVCB parameters, media types, capability namespaces, or agent messaging parameters.¶
\nOpen issues include whether an agent should become a distinct Internet security principal or remain a workload or application identity profile; whether capability-only discovery can be decentralized at Internet scale; how much of a delegation chain a resource server must see; where generic agent semantics belong relative to application-layer frameworks; whether a dedicated asynchronous transport is justified; how payment authorization should bind to delegated authority; and what minimum audit evidence provides accountability without enabling pervasive tracking.¶
\nThis is the initial -00 submission. Earlier working copies were not submitted to the IETF.¶
\n\n \n draft-daniel-ai-agent-internet-architecture-00\n \n
\n \n\n\n\n\n\n\n\n
| Document | \nDocument type | \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\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
|---|---|---|---|
| \n | Select version | \n\n | \n \n\n\n\n \n\n | \n
| \n | Compare versions | \n\n | \n \n\n\n\n\n | \n
| \n | Author | \n\n \n | \n\n \n \n Soohong Daniel Park \n \n \n \n | \n
| \n | \n RFC stream\n | \n\n \n | \n\n \n (None)\n \n | \n
| \n | \n Other formats\n | \n\n | \n\n \n \n \n\n \n | \n