



Network Working Group                                          H. Moussa
Internet-Draft                                               A. Akhavain
Intended status: Informational                             Huawei Canada
Expires: 25 September 2026                                      R. Pioli
                                                             Independent
                                                           24 March 2026


                   Task discovery in agentic networks
                     draft-mapmw-task-discovery-01

Abstract

   This document defines an architectural framework for an open,
   interoperable ecosystem in which task owners publish
   tasks—represented as structured task cards—to a task-posting
   platform, enabling autonomous agents to discover tasks, negotiate
   execution terms, and coordinate multi-agent collaboration.  The
   architecture introduces a set of functional layers—including the Task
   Owner Layer, Task Owner Access Layer, Task-Posting Platform, Agentic
   Layer, Agent Access Layer, and an optional Communication Link—that
   collectively support secure task publication, agent discovery,
   capability evaluation, and bilateral negotiation.  The framework is
   designed to accommodate heterogeneous agents with diverse skill sets,
   trust requirements, and operational models, while ensuring consistent
   interaction patterns across platforms and vendors.

   The document also surveys existing agent-discovery approaches, such
   as A2A, agntcy/OASF, ARDP, and DNS-AID, and identifies gaps that
   motivate a unified, interoperable model for task-centric and
   agent-initiated discovery and interaction.  It also explores possible
   ways by which the current approached can enhance the proposed
   framework.  The goal of this architecture is not to replace existing
   mechanisms but to provide a complementary framework that enables
   agent–task interactions in scenarios that are difficult to support
   using traditional agent-to-agent or platform-centric interaction
   models.  The document is concluded with some potential
   standardization venues for the IETF.

Status of This Memo

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

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



Moussa, et al.          Expires 25 September 2026               [Page 1]

Internet-Draft               Task-discovery                   March 2026


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

   This Internet-Draft will expire on 25 September 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Task Discovery: an Agent initiated engagement . . . . . . . .   4
   3.  Traditional agent-task discovery approaches . . . . . . . . .   8
     3.1.  Approach 1 Agent-to-Agent protocol (A2A)  . . . . . . . .   8
       3.1.1.  General description of the approach . . . . . . . . .   8
       3.1.2.  Components, interfaces, and protocols . . . . . . . .   8
       3.1.3.  Known implementations / ecosystem . . . . . . . . . .   9
       3.1.4.  Shortcomings and limitations (expected or
               reported) . . . . . . . . . . . . . . . . . . . . . .   9
     3.2.  Approach 2 Agntcy by Cisco  . . . . . . . . . . . . . . .   9
       3.2.1.  General description of the approach . . . . . . . . .   9
       3.2.2.  Components, interfaces, and protocols . . . . . . . .   9
       3.2.3.  Known implementations / ecosystem . . . . . . . . . .  10
       3.2.4.  Shortcomings and limitations (expected or
               reported) . . . . . . . . . . . . . . . . . . . . . .  10
     3.3.  Approach 3 DNS for AI Discovery (DNS-AID) . . . . . . . .  10
     3.4.  Approach 4: Agent Registration and Discovery Protocol
           (ARDP)  . . . . . . . . . . . . . . . . . . . . . . . . .  12
       3.4.1.  General Description of the Approach . . . . . . . . .  12
       3.4.2.  Core Characteristics  . . . . . . . . . . . . . . . .  13
   4.  Our approach: task cards and task discovery . . . . . . . . .  13
     4.1.  Task Discovery Ecosystem  . . . . . . . . . . . . . . . .  14
     4.2.  Task cards  . . . . . . . . . . . . . . . . . . . . . . .  16
     4.3.  Task discovery  . . . . . . . . . . . . . . . . . . . . .  17
     4.4.  Interaction between task owners and agents  . . . . . . .  17



Moussa, et al.          Expires 25 September 2026               [Page 2]

Internet-Draft               Task-discovery                   March 2026


   5.  Complementary operations format . . . . . . . . . . . . . . .  18
     5.1.  A2A and Agntcy role in task discovery . . . . . . . . . .  18
     5.2.  DNS-AID role in task discovery  . . . . . . . . . . . . .  18
     5.3.  ARDP role in task discovery . . . . . . . . . . . . . . .  18
   6.  Conclusion and Discussions  . . . . . . . . . . . . . . . . .  19
     6.1.  Summary of advantages of the proposed Task Discovery
           Ecosystem . . . . . . . . . . . . . . . . . . . . . . . .  19
     6.2.  IETF work required to realize the vision  . . . . . . . .  20
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  21
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
   9.  Informative References  . . . . . . . . . . . . . . . . . . .  22
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

1.  Introduction

   To date, both industry and academic communities have shown strong
   interest in the problem of agent discovery, in which a task owner
   seeks to identify the most suitable agent or group of agents to
   perform a given task.  Several frameworks have been proposed such as
   A2A, Agntcy, DNS-AID, ARDP, and DNA which we will examine in detail
   in later sections.

   It is important to note that, although these methods offer valuable
   insights and each has distinct strengths and limitations, they share
   a common design principle that creates several challenges.  They all
   assume agents are represented by identification records stored in a
   registry and made discoverable to task owners, who must then sift
   through piles of agent IDs to find suitable providers and assign
   tasks.  This reliance on ID-card–based discovery introduces several
   limitations within the broader framework, including:

   *  Agent capabilities must be made discoverable to task initiators,
      and that information often needs to remain visible for the agent’s
      lifetime; as the number of agents grows, this requirement
      increases the network’s storage footprint.  Ensuring global
      visibility typically requires geographic replication or federation
      of registries, which multiplies storage and synchronization costs
      and also raises additional operational burdens: increased
      bandwidth for replication and queries, higher indexing and lookup
      overhead, greater CPU and memory use for maintaining searchable
      indexes, and stronger consistency or reconciliation mechanisms to
      keep records correct and up to date.  These costs together drive
      latency, operational complexity, and monetary expense as the agent
      population and geographic scope scale.






Moussa, et al.          Expires 25 September 2026               [Page 3]

Internet-Draft               Task-discovery                   March 2026


   *  In traditional agent discovery, task owners must sift through many
      agent identification records to find a suitable provider.  This
      process assumes owners know the precise skills or requirements
      needed for a task—a strong and often unrealistic assumption.  As a
      result, non-expert owners face high search friction, increased
      mismatch risk, and longer resolution times; these effects worsen
      for complex, multi-domain tasks

   *  Traditional discovery often funnels work to a few visible
      providers, creating task magnets: top-ranked agents get most jobs,
      newcomers struggle to get any, and reputation feedback loops
      reinforce the imbalance.  This reduces competition, slows
      innovation, and may lead to missed opportunity to match with the
      best agent for the given task.

   *  Task initiators need intelligent search controls—stoppage criteria
      and efficient search methods—because agent populations grow
      continuously and exhaustive discovery is impractical; deciding
      when to stop expanding the search space and how to explore
      promising candidates efficiently is therefore a core design
      challenge.

2.  Task Discovery: an Agent initiated engagement

   Given the above foreseeable potential challenges to traditional
   approaches, we propose an alternative and complimentary framework
   where agents take active role in task to agent matching.  In this
   framework, we consider what we refer to as task discovery, as
   follows:

   *  Consider a system in which task owners can post their tasks on
      some type of a platform (e.g., social media, internet, websites,
      ebillboards…etc).

   *  Also consider that agents are equipped with means and intelligence
      that enable them to access this platform.

   *  Agents can then discover tasks posted to this platform.

   *  Agents can select the tasks that suit their skillset and
      capabilities.

   *  Agents can then send necessary information (e.g. agent card,
      history, make, model, ratings...etc) to task owners and present
      themselves as potential candidates capable of fulfilling the
      posted task.





Moussa, et al.          Expires 25 September 2026               [Page 4]

Internet-Draft               Task-discovery                   March 2026


   *  Task owners can employ a contention resolution mechanism to assign
      the task to a candidate and provide permission to the selected
      agent to complete the task.  Essentially, compared to traditional
      methods, in this propose approach, task discovery helps decreases
      the number of comparison processes needed to select the best
      matching agent.

   *  Agents can form coalitions (pre-organized or dynamically formed
      upon discovering posted tasks) to appear more capable than they
      would in their individual forms.  These are teams of agents where
      each team has an overall team capability and skillset that is an
      aggregate of the capabilities and skillsets of the team members.

   *  In scenarios where multi-agent collaboration is needed, team
      formations enables the task owner to have the full knowledge of
      all different agents involved in fulfillment of the task from the
      onset.  This is in contrast to the traditional task fulfillment
      where dynamically recruited downstream agents need to be
      continuously announced and approved by the task owner.
      Essentially, the propose approach can help ease up the need for
      chain of permission requests.

   *  Similarly, upon discovering posted tasks, agents can acquire
      additional agentic skills to augment their capabilities before
      submitting applications to task owners and becoming candidates.

   The above proposed complimentary architecture can help facilitate
   various services, including:

   *  Increase agent visibility: Idle agents who hold identification
      cards but are not being selected by task owners can use the
      proposed architecture to increase their visibility.  In this
      design, agents are allowed to actively approach task owners and
      offer their services, rather than remaining passive and waiting to
      be chosen.

   *  Reputation Building and fair selection: Reputation is a key factor
      that differentiates agents and influences their likelihood of
      being selected, typically based on task-owner ratings, accuracy,
      completion time, and overall performance.  Because reputation
      reflects an agent’s history of completed tasks, newly added agents
      face a cold-start problem in traditional discovery models where
      agents remain passive and must wait to be chosen, making it
      difficult to compete with established agents.  The proposed
      platform mitigates this challenge by allowing agents to actively
      seek out tasks and offer their services, giving them opportunities
      to build or strengthen their reputation rather than relying solely
      on being selected.



Moussa, et al.          Expires 25 September 2026               [Page 5]

Internet-Draft               Task-discovery                   March 2026


   *  Guided Agent improvement: Agents are expected to be self-evolving
      entities that continuously learn new skills.  In traditional
      passive discovery methods, organizations develop agents and are
      responsible for improving the quality of their published agents;
      to do this efficiently they conduct extensive market analyses to
      identify the skills their agents lack and evolve them accordingly.
      However, because discovery is passive, such analyses assume access
      to records showing which agent performed which task and why it was
      chosen; information that is often proprietary or confidential in
      competitive markets.  In the proposed approach, agents can inspect
      task postings directly: they can infer required skills from task
      descriptions and metadata, compare those requirements to their own
      capabilities, and determine which skills to develop so they are
      better positioned to handle the tasks most commonly submitted by
      task owners.

   *  Improve agent-task matching: Selecting the right agent for a task
      is not straightforward.  Traditional methods assume task owners
      know enough about a domain to specify the exact skills required,
      but that is often false: a car owner who reports “weird noise when
      braking” may not know whether the problem is tires, brakes, or
      suspension, so they will search for a generic “mechanic,” yielding
      either too many matches or none if they must be more specific.
      Under the proposed approach, task owners can post a general
      request (e.g., “fix car making noise when braking”) and agents can
      proactively query for clarifications—asking about recent brake
      work, symptom duration, or offering to run a diagnostic—thereby
      shifting the diagnostic intelligence from the owner to service
      providers and improving match quality.






















Moussa, et al.          Expires 25 September 2026               [Page 6]

Internet-Draft               Task-discovery                   March 2026


   *  Improved complex task handling: Tasks vary in complexity: some
      require a single agent (e.g., “translate this text from French to
      English”), while others need multiple agents (e.g., “help build a
      bicycle” — one agent to purchase parts, another to deliver them, a
      third to guide assembly).  In traditional discovery models,
      complex tasks must be split into subtasks, but that process
      assumes the task owner can (1) decompose the task to the right
      level of granularity and (2) know what agents exist to handle each
      subtask; if the available agent landscape is unknown, splitting
      can be counterproductive (for example, designating a “purchase
      parts” subtask is useless if no purchasing agent exists).  The
      proposed approach lets task owners post raw, unsplit tasks to the
      billboard, relieving them of the burden of decomposition; agents
      discover those postings, use their internal knowledge and
      awareness of other agents to form coalitions, and split and assign
      subtasks among themselves, thereby shifting the complexity to the
      service-providing side and enabling tasks to be partitioned in
      ways that match actual agent capabilities.  Also, this provides a
      means by which agents can form coalitions with trusted parties to
      handle tasks together.

   *  Mechanisms for authentication and trust establishment: task owners
      generally need to interact with authenticated, registered agents,
      and traditional discovery models place the burden of vetting on
      owners—reviewing credentials, certifications, provenance, and
      other trust signals—which assumes owners have the expertise and
      resources to perform reliable vetting.  Prior proposals (for
      example, DNS-AID and ARDP) shift parts of that responsibility to
      third parties such as DNS-based certification systems, but they
      still depend on standardized, often rigid trust criteria and
      centralized records that may be proprietary or vulnerable to
      compromise.  To increase flexibility and usability, the proposed
      approach lets task owners define their own authentication and
      trust requirements (for example, accepting agents by origin and
      publisher, or requiring background checks, tests, or cryptographic
      attestations); agents apply for tasks by connecting to the owner,
      and the owner admits only those agents that meet its chosen
      criteria.  The billboard used for posting tasks can also enforce
      admission policies, allowing only authenticated and trusted agents
      to submit proposals.  It would be appreciated to mention that
      under this approach, various grounding mechanisms would be needed
      so that proposed flexibility non-standardized design does not lead
      to fragmentation, spoofing, or unscalable manual vetting.

   It should be clear from the above that the primary advantage of the
   proposed architecture is to shift part of the discovery burden from
   task owners to service-providing agents rather than to replace
   existing registry-based discovery.  Task owners retain the option to



Moussa, et al.          Expires 25 September 2026               [Page 7]

Internet-Draft               Task-discovery                   March 2026


   search agent registries, but the complementary billboard model lets
   owners post raw, unsplit tasks and lets agents perform decomposition,
   diagnostics, and coalition formation.  Agents still rely on discovery
   to assemble teams, but their team formation is driven by objectives
   inferred from the task posting and by agents’ own knowledge of
   capabilities and trust relationships.  To make this shift practical
   and secure, the platform should combine owner-configurable trust
   policies with policy profiles, machine-readable credentials,
   standardized task posting mechanisms, standardized task metadata
   formatting, billboard admission controls, and budgeted search/stop
   rules so owner flexibility does not produce fragmentation, spoofing,
   or unscalable manual vetting.  All of these aspects can benefit from
   discussions and developments within the IETF as will be discussed
   later.

3.  Traditional agent-task discovery approaches

   This section aims at providing a brief high level collective
   description of traditional known agent discovery mechanisms (i.e.,
   some form of a summary for the different approaches that outlines the
   general theme)

3.1.  Approach 1 Agent-to-Agent protocol (A2A)

3.1.1.  General description of the approach

   A2A uses Agent Cards (structured JSON metadata) plus registry servers
   and discovery clients so that agents and clients can retrieve
   machine-readable descriptions of remote agents’ capabilities and
   endpoints.  Discovery is tightly coupled with the A2A messaging and
   lifecycle model.

3.1.2.  Components, interfaces, and protocols

   *  Agent Card: the primary discovery artifact (JSON schema)
      describing name, capabilities, endpoints, and interaction hints.

   *  AgentRegistry / DiscoveryClient: servers that host Agent Cards and
      clients that query registries or use local discovery strategies.

   *  A2A transport and security stack: discovery is integrated with the
      protocol’s authentication and session establishment flows so that
      discovery leads directly into authenticated communication.








Moussa, et al.          Expires 25 September 2026               [Page 8]

Internet-Draft               Task-discovery                   March 2026


3.1.3.  Known implementations / ecosystem

   Google published A2A and maintains a public GitHub repository and
   documentation; multiple SDKs and language bindings (including a
   Python discovery module) implement the Agent Card and registry
   patterns.

3.1.4.  Shortcomings and limitations (expected or reported)

   *  Registry and card freshness: Agent Cards must be kept up to date;
      stale cards can misrepresent runtime capabilities.

   *  Owner specification burden: discovery via structured cards assumes
      owners or publishers can accurately enumerate capabilities; vague
      tasks still require additional negotiation or diagnostics.

   *  Interoperability gaps without profiles: different deployments may
      extend Agent Cards or discovery strategies; without standardized
      profiles, cross-domain behavior can vary.

3.2.  Approach 2 Agntcy by Cisco

3.2.1.  General description of the approach

   AGNTCY provides a registry-and-messaging stack for agent
   interoperability: agents publish metadata and capability records to
   discoverable services, use secure messaging for interaction, and rely
   on observability/attestation components to verify behavior.
   Discovery within Agntcy centers on a registry-style directory that
   indexes agent metadata and capability schemas; agents publish
   machine-readable schema-backed records (built on the Open Agentic
   Schema Framework (OASF)) and discovery queries retrieve matching
   entries.

3.2.2.  Components, interfaces, and protocols

   *  OASF schema server and schema repository for capability and
      metadata definitions.

   *  Agent Directory / Agent Directory Service (ADS) that indexes
      signed agent records and maps capability descriptors to content
      locations.

   *  Secure low-latency messaging (SLIM) and transport bindings for
      agent-to-agent communication that integrate discovery with secure
      agent-to-agent messaging and observability pipelines.





Moussa, et al.          Expires 25 September 2026               [Page 9]

Internet-Draft               Task-discovery                   March 2026


   *  Identity, observability, and evaluation subsystems for provenance,
      runtime telemetry, and capability assessment.

3.2.3.  Known implementations / ecosystem

   AGNTCY code and reference components are available on GitHub from
   Outshift/Cisco and collaborators; the project has been adopted into a
   Linux Foundation initiative with multiple industry participants.

3.2.4.  Shortcomings and limitations (expected or reported)

   *  Registry-centric bias: relies on owners or agents to keep registry
      entries current; static entries can become stale relative to
      runtime capability.

   *  Operational complexity: full stack (registry, messaging,
      observability) increases deployment and integration effort for
      platforms.

   *  Cold-start for newcomers: while registries provide authoritative
      identity, newcomers still need paths to earn visibility and
      reputation unless additional onboarding flows are defined.

3.3.  Approach 3 DNS for AI Discovery (DNS-AID)

   DNS-AID, as described in [I-D.draft-mozleywilliams-dnsop-dnsaid] is a
   means of utilizing the Domain Name System (DNS) to facilitate
   scalable and interoperable discovery between AI agents that can also
   be applied to tasks.  It provides a well-known entry point to
   facilitate discovery and automation, in much the same way as the
   defacto label www does for web sites.  This could be used on internal
   or external networks.

   An agent might discover tasks it could process directly, or do this
   via another agent that brokers communication, for instance ensuring
   authentication and authorization to perform a task and a token to
   allow direct interaction with the task itself.

   *  DNS AID creates a well-known entry point to an organization's
      agents.  Currently, many agents and capabilities are listed in
      host files accessed through gateways (MCP, for example).  By
      moving the capability descriptors closer to the clients (in this
      case we assume there are many types of clients dispersed
      throughout an organization looking for agents and vice versa), you
      improve scalability, performance, and federate discovery to
      control plane that is natively integrated to the current existing
      network stack.




Moussa, et al.          Expires 25 September 2026              [Page 10]

Internet-Draft               Task-discovery                   March 2026


   *  Facilitated through a leaf-attribute zone (e.g.
      _agents.example.com) containing SVCB records which embed metadata
      within the record: IPv4/6 hint, alpn (h2, h3, a2a, mcp1, etc),
      port, and any other key value pair (e.g. model card URL, token
      bundle input, modalities, etc) without recommending any changes to
      existing DNS protocols.

   *  It's likely that for particularly volatile workloads, ephemeral
      and others that the propagation time for AXFR/IXFR may exceed the
      lifetime of the task.  It's better to consider two approaches: use
      SVCB-param-key to signify tasks (e.g. tasks = true or false) which
      then tasks are exchanged through the application protocol itself
      between workers, or embed task metadata within the specific agents
      as a subzone (e.g. tasks.chat._agents.example.com).  Either
      provide a mechanism to be listed in a centralized location for
      federated task discovery and completion.

   The key components and principles of DNS-AID that could be applied to
   task discovery include:

   *  use of the “feature rich” DNS SVCB record type to indicate task
      protocols and IP connectivity for efficiency with a defined
      structure (as opposed to an unstructured TXT record)

   *  DNS-Based Service Discovery (DNS-SD) to standardize the well-known
      entry point and to group tasks by protocol type or other
      categories

   *  providing additional properties to facilitate efficient
      communication

   *  organizations could optionally provide specific SVCB records for
      long-running tasks to improve efficiency

   An example of discovering tasks could be an agent connecting to an
   end-point that has details of image processing tasks for an
   organization.














Moussa, et al.          Expires 25 September 2026              [Page 11]

Internet-Draft               Task-discovery                   March 2026


      AI Agent Client
      wants to discover image tasks:   images._tasks._agents.example.com
      (mcp = service, foobar = agent/capability, example.com = organization domain)

            Agent                   DNS Resolver                   Task
              |                           |                          |
              |   1. SVCB Query           |                          |
              |   (Recursive)             |                          |
              |-------------------------->|                          |
              |   2. SVCB Response        |                          |
              |   (cached + validated)    |                          |
              |<--------------------------┤                          |
              |                           |                          |
              |   Response includes:      |                          |
              |   • Service target        |                          |
              |   • ALPN protocol(s)      |                          |
              |   • Port number           |                          |
              |   • IPv4/IPv6 hints       |                          |
              |   • DNSSEC signatures     |                          |
              |   • Capabilities (cost,   |                          |
              |      modalities, etc)     |                          |
              |                                                      |
              |   3. A2A, MCP, etc.                                  |
              ├----------------------------------------------------->|
              |   (Agent-to-Agent                                    |
              |    communication begins)                             |

              Figure 1: DNS-AID task discovery example 1

   Note that DNS is not used for agents to communicate with tasks,
   rather it indicates the protocol that should be used, the IP address
   and potentially other defined properties.  DNS would not index all
   tasks and is not suited to the discovery of lists of tasks, rather
   the use case is facilitating efficient communication to a known end-
   point.

   Implementation examples of DNS-AID can be found at [DNSAIDsite].

3.4.  Approach 4: Agent Registration and Discovery Protocol (ARDP)

3.4.1.  General Description of the Approach

   The Agent Registration and Discovery Protocol (ARDP) is a control-
   plane protocol designed to provide stable agent identifiers,
   authenticated registration, and authorized endpoint resolution in
   distributed and federated environments.





Moussa, et al.          Expires 25 September 2026              [Page 12]

Internet-Draft               Task-discovery                   March 2026


   ARDP is not limited to static agent “card” storage.  It defines a
   dynamic, soft-state registration model in which bindings expire and
   must be refreshed, and in which resolution is subject to
   authorization policy and privacy controls.  This distinguishes ARDP
   from passive directory models and enables its use in mobile,
   federated, and multi-tenant environments.

   Unlike static registries that merely store agent identification
   records, ARDP defines:

   *  Identity-bound registration with cryptographic proof-of-control
      (JWS-based PoC for REGISTER/refresh operations).

   *  Soft-state bindings with TTL and refresh semantics, allowing
      dynamic endpoint mobility.

   *  Fine-grained authorization for RESOLVE and QUERY operations.

   *  Capability advertisement independent of interaction protocol
      (e.g., MCP, A2A, HTTP, gRPC).

   *  Explicit federation model with provenance metadata and TTL
      honoring.

   *  Privacy-aware redaction defaults for discovery responses.

3.4.2.  Core Characteristics

   ARDP operates as a minimal control-plane discovery layer.  It does
   not define session management, task execution semantics, runtime
   authorization tokens, billing mechanisms, or governance frameworks.
   Instead, it focuses on:

   *  Binding a stable Agent Identifier (AID) to active endpoints and
      capability metadata.

   *  Ensuring that only entities that can prove control of an AID may
      register or refresh it.

   *  Providing authorized resolution of endpoints and capabilities.

4.  Our approach: task cards and task discovery

   This section aims to provided general high-level description and
   architecture of the proposed Task Discovery Ecosystem.  It also poses
   some questions that need answers and opens up venues for discussions.





Moussa, et al.          Expires 25 September 2026              [Page 13]

Internet-Draft               Task-discovery                   March 2026


4.1.  Task Discovery Ecosystem

+----------+                                                         +----------+
|          |                                                         |          |
|+--------+|      +--------+                         +--------+      |+--------+|
|| T.O. 1 || <--> |        |                         |        | <--> || Agent 1||
|+--------+|      |        |      +-----------+      |        |      |+--------+|
|          |      |        |      |           |      |        |      |     ↕    |
|+--------+|      |  T.O.  |      |   Task    |      | Agent  |      |+--------+|
|| T.O. 2 || <--> | Access | <--> |  Posting  | <--> | Access | <--> || Agent 2||
|+--------+|      | Layer  |      |  Platform |      | Layer  |      |+--------+|
|          |      |        |      |           |      |        |      |     ↕    |
|+--------+|      |        |      +-----------+      |        |      |+--------+|
|| T.O. n || <--> |        |                         |        | <--> || Agent m||
|+--------+|      +--------+                         +--------+      |+--------+|
|          |                                                         |          |
+----------+                                                         +----------+
     ↑                                                                    ↑
     |                         Communication  link                        |
     +--------------------------------------------------------------------+
* T.O: Task Owner

                  Figure 2: Task Discovery Ecosystem

   As shown in the figure, the ecosystem consists of different layers.

   *  Task Owner Layer: This layer hosts the entities that submit tasks
      requiring assistance from AI agents.  It provides mechanisms for
      verifying, authenticating, and registering trusted task owners,
      ensuring that only authorized parties can participate in the
      system.  This layer also manages the lifecycle of owner
      activity—including task submission, accounting and charging, and
      policy enforcement—and offers the privacy and security controls
      needed to protect owner data and identity.

   *  Agentic Layer: The Agentic Layer hosts the autonomous agents that
      evaluate, select, and execute tasks.  Agents in this layer expose
      diverse skill sets and operate as independent decision-making
      entities.  They are expected to discover posted tasks through
      standardized search interfaces, analyze task requirements, compare
      them against their own capabilities, and determine whether they
      are suitable candidates.  Once engaged, agents can communicate
      with task owners to request assignment, seek clarification,
      provide progress updates, or deliver results.  This layer may also
      support additional functions such as capability attestation, agent
      registration and authentication, reputation tracking, coalition
      formation for multi-agent tasks, and mechanisms for agents to
      manage their own operational state (availability, load, or cost).



Moussa, et al.          Expires 25 September 2026              [Page 14]

Internet-Draft               Task-discovery                   March 2026


      Within this layer, agent-to-agent discovery, communication, and
      session-management protocols—such as A2A, agntcy, ARDP, and
      DNS-AID—may be used to support coalition formation, peer
      coordination, and agent-level discovery needed to assemble
      appropriate teams for tasks that require multi-agent
      collaboration.  In some implementations, specialized “scouting
      agents” may continuously search for suitable tasks and, upon
      discovery, rely on agent-to-agent protocols to subcontract or
      delegate the task to the most appropriate agents within their
      network.

   *  Task Owner (T.O.)  Access Layer: This Layer provides the
      interfaces through which task owners interact with the
      task-posting platform.  It exposes the protocols required for safe
      and reliable operation, including mechanisms for submitting new
      tasks, tracking task status, and updating, retracting, or
      modifying previously posted tasks.  This layer also supports the
      communication requirements needed for rich interaction—such as
      multi-modal exchanges, session management, and secure transport
      between task owners and the platform.  Standardizing this layer
      enables task owners of different types and from different vendors’
      ecosystems to interact with task-posting platforms in a
      consistent, interoperable manner.  It should be noted here that
      also the task-posting platforms can come from different vendors as
      well, so standardized access layer is essential.

   *  Agent Access Layer: The Agent Access Layer provides the
      standardized interfaces through which agents interact with the
      task-posting platform and with other system components.  It
      exposes the protocols required for safe task discovery, capability
      advertisement, proposal submission, and session establishment.
      This layer also supports secure communication, multi-modal
      exchanges, status reporting, and lifecycle management for
      agent-initiated interactions.  By defining common access and
      communication primitives, the Agent Access Layer enables
      heterogeneous agents—potentially from different vendors or
      ecosystems—to interoperate reliably with task-posting platforms
      and with one another.

   *  Task-Posting Platform: The Task-Posting Platform is the
      environment in which task owners publish tasks (task cards for
      instance) and make them visible to eligible agents.  It maintains
      the authoritative catalog of active tasks and enforces the
      policies under which tasks may be posted, viewed, or acted upon.
      Platforms may apply subject-matter restrictions, require specific
      agent capabilities, or limit participation to task owners who meet
      defined trust or compliance requirements.  The platform is
      responsible for ensuring fair and consistent visibility across all



Moussa, et al.          Expires 25 September 2026              [Page 15]

Internet-Draft               Task-discovery                   March 2026


      posted tasks and for exposing standardized APIs that allow agents
      to search, filter, and retrieve tasks in a predictable manner.  In
      addition to basic posting and retrieval, the platform may support
      task lifecycle management, admission control, rate limiting,
      prioritization rules, and mechanisms for handling updates,
      cancellations, and task-owner clarifications.  This allows it to
      provide necessary OAM functionality for task owners.  Although
      platforms may differ in internal design, they are expected to
      expose interoperable interfaces that conform to the specifications
      defined by the Task Owner Access Layer and the Agent Access Layer,
      enabling cross-vendor compatibility and consistent behavior across
      deployments.

   *  The Communication Link: The Communication Link is an optional
      component that enables direct, bilateral interaction between task
      owners and agents after initial discovery.  Its purpose is to
      off-load certain interaction responsibilities from the access
      layers by providing a secure channel through which both parties
      can negotiate task-specific details.  Once an agent identifies a
      suitable task, it may use this link to contact the task owner
      directly and establish the terms under which the task will be
      fulfilled.  These terms may include trust requirements, handling
      expectations, privacy constraints, compensation models, escalation
      paths, or any other operational parameters relevant to the task.
      This link supports private sessions that operate outside the
      default policies of the task-posting platform while still relying
      on standardized, regulated, and secured communication protocols
      defined by the ecosystem.  It allows richer negotiation
      patterns—such as multi-modal exchanges, iterative clarification,
      or structured contract formation—without requiring the platform to
      mediate every interaction.

4.2.  Task cards

   *  what are task cards?

   *  how are they generated? (there should be a mechanism to generate
      these) -- potential for standardization.

   *  What are some proposed task card structures? -- potential for many
      IETF drafts and solution proposal.

   *  How are task cards used by agents to satisfy the different
      scenarios considered? -- (these task cards need to be designed
      such that they can be utilized to fulfill the above scenarios.
      Mechanism by which this is done might not be in IETF scope, but
      perhaps would invite creative designing proposals)




Moussa, et al.          Expires 25 September 2026              [Page 16]

Internet-Draft               Task-discovery                   March 2026


4.3.  Task discovery

   *  How are task cards stored? (authorization, authentication,
      standardization) --- potential for standardization

   *  How are task cards published and handled after being published?
      (expiration, prioritization, fairness) -- potential for
      standardization

   *  What are the possible different approaches to discovering them in
      light of the different scenarios being considered? -- potential
      for standardization

   *  How to ensure secure and private access to task cards? --
      potential for standardization

   *  Centralized and decentralized discovery?

   *  Efficient discovery? -- This is likely out of scope for the IETF,
      making it more suitable as a research topic for the IRTF.
      Alternatively, this could be handled through engineered,
      standardized methods, such as hierarchical or DNS-based discovery.

4.4.  Interaction between task owners and agents

   *  How do agents connect with task owners? (authentication,
      validation, and authorization) -- potential for standardization

   *  How can task owners monitor progress on their tasks? -- potential
      for standardization

   *  How do agents charge and bill for their service? -- This is likely
      out of scope for the IETF

   *  What happens if agents did not fulfill the task up to standards
      required?  -- IETF can provide a way to express satisfaction,
      similar to ai-pref

   *  how to insure privacy and security? -- potential for
      standardization.  Perhaps proposal such as ARDP might find utility
      here.

   *  authorization and authentication of agent? -- potential for
      standardization

   *  authorization and authentication of task owner? -- potential for
      standardization




Moussa, et al.          Expires 25 September 2026              [Page 17]

Internet-Draft               Task-discovery                   March 2026


   *  authorization and authentication of billboards? -- potential for
      standardization

5.  Complementary operations format

   This section aims to describe how the two models can operate
   side-by-side: registry-based discovery continues to offer a stable,
   authoritative directory of agents, while the billboard-driven
   approach adds dynamic task posting, proactive agent proposals, richer
   reputation building, and improved handling of vague or complex tasks.
   Together, they form a hybrid discovery ecosystem in which registries
   provide long-term identity and credentials, and the billboard layer
   provides real-time matching, diagnostics, coalition formation, and
   opportunities for newcomers—each compensating for the other’s
   weaknesses.

5.1.  A2A and Agntcy role in task discovery

   To be completed..

5.2.  DNS-AID role in task discovery

   To be completed..

5.3.  ARDP role in task discovery

   Being a control-plane protocol that is designed to provide stable
   agent identifiers, authenticated registration, and authorized
   endpoint resolution in distributed and federated environment, the
   ARDP can facilitate many features necessary for the operation of the
   Task Discovery Ecosystem proposed here.  To be exact, ARDP can:

   *  Serve as the authoritative identity and endpoint binding layer for
      agents that respond to task postings.

   *  Allow Agents discovering tasks via a billboard mechanism to:

      -  Validate peer agent identities when forming coalitions.

      -  Resolve authoritative endpoints for inter-agent coordination.

      -  Verify provenance and federation trust relationships.

   *  Task billboards may reference ARDP-resolvable AIDs instead of
      duplicating identity records.

   However, what the ARDP is not meant to do is:




Moussa, et al.          Expires 25 September 2026              [Page 18]

Internet-Draft               Task-discovery                   March 2026


   *  Task decomposition logic.

   *  Coalition formation strategies.

   *  Runtime authorization enforcement within an agent.

   *  Reputation scoring or bidding mechanisms.

   These functions can operate above ARDP or alongside it in
   complementary architectures such as the proposed task discovery
   model.

   Thus, in light of the above, it is clear that ARDP complements both
   registry-based discovery and billboard-based task discovery by
   providing a secure and interoperable control-plane foundation.

6.  Conclusion and Discussions

6.1.  Summary of advantages of the proposed Task Discovery Ecosystem

   *  A task-card storage entity is dynamic and demand-driven: posted
      tasks expire or are archived once completed, so the active dataset
      shrinks and grows with workload.  This contrasts with
      registry-based approaches that must persist and replicate every
      agent profile indefinitely.  By keeping only active task records
      readily searchable, the proposed model reduces persistent storage,
      indexing, replication bandwidth, and update churn, aligning
      infrastructure cost with actual demand while still supporting
      optional archival and a small authoritative registry for
      long-lived credentials, making it a better scalable solution.

   *  The proposed model reduces the task-owner’s burden of finding the
      right agent by shifting discovery work to agents: agents that
      believe they are a good fit proactively submit proposals, which
      narrows the owner’s search space and removes the need for owners
      to precisely specify required skills.

   *  For non urgent tasks that owners do not want to spend a lot for
      them to be done, they are posted for agents to bid on and owners
      can choose the best offer.  This also allows idle agents to have a
      chance to make money and perhaps help with load balancing

   *  By allowing agents to proactively propose for posted tasks, the
      platform enables newcomers and under-exposed agents to build
      verifiable reputation through completed work, reducing cold-start
      barriers and improving match quality—provided the system enforces
      admission controls, verification steps, and incentive mechanisms
      to limit noise and gaming.



Moussa, et al.          Expires 25 September 2026              [Page 19]

Internet-Draft               Task-discovery                   March 2026


   *  The billboard model augments registry-based discovery rather than
      replacing it: owners retain registry search capabilities while
      also posting raw tasks to receive proactive proposals.  This
      hybrid approach preserves existing workflows, lowers the barrier
      for non-expert owners, and enables richer matching strategies; to
      work well it requires interoperable metadata, admission controls,
      and clear ranking/deduplication rules so the two channels remain
      complementary and secure.

6.2.  IETF work required to realize the vision

   The proposed billboard-like agent initiated task discovery model
   offers clear benefits, but substantial IETF work is required to make
   it interoperable, secure, and scalable.  Standards are needed for
   task-posting formats, machine-readable credentials, admission and
   discovery APIs, policy profiles, privacy-preserving attestations, and
   budgeted search semantics; without these, owner-defined trust
   policies will fragment the ecosystem, invite spoofing, and force
   unscalable manual vetting.  The IETF should therefore define minimal,
   composable building blocks that preserve owner flexibility while
   enabling automated verification, cross-domain discovery, and fair
   matching across implementations.

   *  Task posting and metadata formats: a compact, extensible schema
      for raw task descriptions, required attributes, and diagnostic
      prompts.

   *  Discovery and billboard APIs: standardized endpoints and query
      semantics for posting tasks, submitting proposals, and retrieving
      shortlists.

   *  Standardized machine-readable credentials and attestations:
      interoperable formats and protocols for signed capability claims,
      provenance, selective-disclosure identity attributes, and
      revocation signals, enabling automated trust decisions between
      task owners, billboards, and agents without relying on proprietary
      or ad-hoc vetting.

   *  Policy profiles and admission rules: interoperable assurance
      levels (e.g., basic/verified/high-assurance) and a way to express
      owner preferences as machine-evaluable policies.

   *  Search semantics and stop rules: standardized notions of budgeted
      search, progressive widening, and marginal-gain stoppage so
      clients and servers can interoperate on when to halt exploration.
      This is also needed to limit the possibility of overload the read
      function of the agent/task registries.




Moussa, et al.          Expires 25 September 2026              [Page 20]

Internet-Draft               Task-discovery                   March 2026


   *  Coalition formation primitives: lightweight protocols for
      capability advertisement, role negotiation, payment split
      templates, and failure recovery.

   *  Fairness and anti-gaming controls: mechanisms that give newcomers
      a fair chance and prevent manipulation of the matching and
      reputation systems.  This includes onboarding micro-tasks for new
      agents, freshness boosts so proposals from less-visible agents are
      not buried, reputation-normalization rules to prevent score
      inflation, and signals for detecting sybil or duplicate agents.

   *  Privacy and selective disclosure: mechanisms (attribute
      attestations, minimal disclosure) that let agents prove claims
      without exposing sensitive data.

   *  Audit, logging, and revocation: tamper-evident logging mechanisms,
      standardized revocation lists, and dispute-resolution hooks that
      allow task owners, agents, and billboards to verify what happened
      during a task lifecycle across different administrative domains.
      This includes consistent formats for recording proposals,
      decisions, completions, and failures; mechanisms for revoking
      compromised or misbehaving agents; and interoperable audit trails
      that support cross-domain verification and accountability.
      Without these shared mechanisms, it becomes difficult to detect
      misconduct, resolve disputes, or maintain trust in a multi-vendor,
      multi-platform ecosystem.

   *  Operational guidance and standardized profiles — a set of shared
      deployment guidelines, recommended defaults, and well-defined
      configuration profiles that help different implementations behave
      consistently.  This includes safe presets for non-expert task
      owners (e.g., “fast match”, “high assurance”), normative guidance
      on how to apply admission policies and search budgets, and test
      vectors that allow implementers to verify correct behavior.
      Without this layer of operational guidance, platforms may
      interpret the same mechanisms differently, leading to
      fragmentation, inconsistent trust decisions, and unpredictable
      user experience.

7.  Security Considerations

   Security considerations are as outlined within the document under the
   privacy and security requirements

8.  IANA Considerations

   This document has no IANA actions.




Moussa, et al.          Expires 25 September 2026              [Page 21]

Internet-Draft               Task-discovery                   March 2026


9.  Informative References

   [DNSAIDsite]
              "DNS-AID web site for implementation examples", n.d.,
              <https://dns-aid.org/>.

   [I-D.draft-mozleywilliams-dnsop-dnsaid]
              Mozley, J., Williams, N., Sarikaya, B., and R. Schott,
              "DNS for AI Discovery", Work in Progress, Internet-Draft,
              draft-mozleywilliams-dnsop-dnsaid-01, 2 March 2026,
              <https://datatracker.ietf.org/doc/html/draft-
              mozleywilliams-dnsop-dnsaid-01>.

Contributors

   Hesham Moussa
   Huawei Canada
   Email: hesham.moussa@huawei.com


   Arashmid Akhavain
   Huawei Canada
   Email: arashmid.akhavain@huawei.com


   Roberto Pioli
   Independent
   Email: roberto.pioli@example.com


   Jim Mozley
   Infoblox, Inc.
   Email: jmozley@infoblox.com


   Nic Williams
   Infoblox, Inc.
   Email: nwilliams@infoblox.com


Authors' Addresses

   Hesham Moussa
   Huawei Canada
   Email: hesham.moussa@huawei.com






Moussa, et al.          Expires 25 September 2026              [Page 22]

Internet-Draft               Task-discovery                   March 2026


   Arashmid Akhavain
   Huawei Canada
   Email: arashmid.akhavain@huawei.com


   Roberto Pioli
   Independent
   Email: roberto.pioli@example.com











































Moussa, et al.          Expires 25 September 2026              [Page 23]
