AGTP Agent Discovery and Name Service
draft-hood-agtp-discovery-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Chris Hood | ||
| Last updated | 2026-10-30 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-hood-agtp-discovery-02
Independent Submission C. Hood
Internet-Draft Nomotic, Inc.
Intended status: Informational 30 October 2026
Expires: 3 May 2027
AGTP Agent Discovery and Name Service
draft-hood-agtp-discovery-02
Abstract
The Agent Transfer Protocol (AGTP) enables agents to communicate once
they know each other's canonical identifiers. This document
specifies two layered mechanisms by which agents find each other and
by which human-readable names resolve to Canonical Agent-IDs: the
DISCOVER method, which queries for agents matching a capability
description, and the Agent Name Service (ANS), which provides
governed name-to-Agent-ID resolution.
The architectural relationship is layered. AGTP-Presence
[AGTP-PRESENCE] provides ambient awareness of agents within
visibility scopes as a substrate property. DISCOVER operates over
the Presence substrate to query the live population. ANS provides
human-readable name resolution, analogous to DNS for the web, with
name authorities federating across organizational boundaries. This
document also introduces Anticipatory Discovery Services (ADS) as a
forward-looking composition pattern where application-layer services
preload agent awareness based on observed operational signals.
DISCOVER and ANS together provide the application-layer interfaces
for discovery and naming that compose with the substrate-level
ambient discovery defined in [AGTP-PRESENCE].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Hood Expires 3 May 2027 [Page 1]
Internet-Draft AGTP-DISCOVER October 2026
This Internet-Draft will expire on 3 May 2027.
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The Discovery Layers . . . . . . . . . . . . . . . . . . 3
1.2. Search, Discover, Resolve . . . . . . . . . . . . . . . . 4
1.3. The Layered Architecture . . . . . . . . . . . . . . . . 4
1.4. Why Separate Search and Discovery From Naming . . . . . . 5
1.5. Design Principles . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. The DISCOVER Method . . . . . . . . . . . . . . . . . . . . . 7
3.1. Method Definition . . . . . . . . . . . . . . . . . . . . 7
3.2. Operational Modes . . . . . . . . . . . . . . . . . . . . 8
3.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. DISCOVER Request Example . . . . . . . . . . . . . . . . 10
3.5. DISCOVER Request Example: Domain-Constrained Search . . . 10
3.6. DISCOVER Response . . . . . . . . . . . . . . . . . . . . 13
3.7. Ranking Algorithm . . . . . . . . . . . . . . . . . . . . 14
4. Agent Name Service . . . . . . . . . . . . . . . . . . . . . 14
4.1. ANS Architecture . . . . . . . . . . . . . . . . . . . . 14
4.2. Relationship to Presence . . . . . . . . . . . . . . . . 15
4.3. ANS Registration . . . . . . . . . . . . . . . . . . . . 16
4.4. ANS Deregistration . . . . . . . . . . . . . . . . . . . 16
4.5. Index Freshness . . . . . . . . . . . . . . . . . . . . . 16
5. Cross-ANS Federation . . . . . . . . . . . . . . . . . . . . 16
5.1. The Federation Problem . . . . . . . . . . . . . . . . . 17
5.2. Federation Protocol . . . . . . . . . . . . . . . . . . . 17
5.3. Trust in Federation . . . . . . . . . . . . . . . . . . . 17
6. Dynamic Routing and Failover . . . . . . . . . . . . . . . . 18
6.1. Capability-Based Routing . . . . . . . . . . . . . . . . 18
6.2. Agent Availability Signals . . . . . . . . . . . . . . . 18
7. Anticipatory Discovery Services . . . . . . . . . . . . . . . 18
7.1. The Anticipatory Pattern . . . . . . . . . . . . . . . . 18
7.2. Architectural Position . . . . . . . . . . . . . . . . . 19
7.3. Composable ADS Providers . . . . . . . . . . . . . . . . 19
7.4. Trust and Privacy Considerations . . . . . . . . . . . . 20
Hood Expires 3 May 2027 [Page 2]
Internet-Draft AGTP-DISCOVER October 2026
7.5. Forward-Looking Composition . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8.1. Discovery Result Injection . . . . . . . . . . . . . . . 21
8.2. Discovery Enumeration . . . . . . . . . . . . . . . . . . 21
8.3. Behavioral Trust Score Manipulation . . . . . . . . . . . 21
8.4. Scope Negotiation Abuse . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9.1. DISCOVER Method Registration . . . . . . . . . . . . . . 22
9.2. New Authority-Scope Domains . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. ANS Deployment Considerations . . . . . . . . . . . 24
Appendix B. Mapping to DAWN Discovery Records . . . . . . . . . 24
B.1. Infrastructure-Assisted Discovery . . . . . . . . . . . . 26
Appendix C. Changes from v01 . . . . . . . . . . . . . . . . . . 27
Appendix D. Changes from v00 . . . . . . . . . . . . . . . . . . 28
D.1. Substantive Changes . . . . . . . . . . . . . . . . . . . 28
D.2. Wire Format Compatibility . . . . . . . . . . . . . . . . 29
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction
1.1. The Discovery Layers
A deployed AGTP ecosystem contains agents registered across many
organizations, governance zones, and trust tiers. An orchestrator
agent that needs to delegate a task to a capable peer faces three
distinct but related problems:
1. *Population awareness*: which agents are currently active and
visible within my scope of operations?
2. *Capability matching*: among those visible agents, which can
provide the capability I need?
3. *Name resolution*: given a human-readable name (such as
concierge.acme.com), what is its Canonical Agent-ID?
These three problems are distinct and benefit from distinct
mechanisms. Conflating them produces designs that are either too
narrow (a single query interface that handles all three poorly) or
too broad (a single registry that tries to be all things to all
callers). This document specifies the application-layer interfaces
for capability matching and name resolution, while deferring to
[AGTP-PRESENCE] for population awareness.
Hood Expires 3 May 2027 [Page 3]
Internet-Draft AGTP-DISCOVER October 2026
1.2. Search, Discover, Resolve
Earlier revisions of this document and of [AGTP-PRESENCE] used
"discovery" for all three problems. This revision adopts the
distinction [RFC6763] draws for DNS-based service discovery and
applies it to agents, because the three operations have different
inputs, different outputs, and different trust properties:
Search: The caller has a need and no identity. Input: capability
criteria, an intent, trust and governance constraints. Output: a
ranked list of candidate agents the caller had no prior knowledge
of. Search is what the DISCOVER method does when invoked with
intent or capability_domains. Its results are candidates to be
evaluated, never agents to be trusted on the strength of the
result.
Discover: The caller has an identity and no current location.
Input: a Canonical Agent-ID. Output: the agent's current
attachment, the signed, short-lived record of where it can be
reached, and its Identity Document ([AGTP-IDDOC]). The presence
substrate of [AGTP-PRESENCE] provides discovery ambiently, and the
DISCOVER method performs it when invoked against a known Agent-ID.
Its result is bound to the identity by signature.
Resolve: The caller has a name and no identity. Input: a human-
readable name under a naming authority. Output: the Canonical
Agent-ID the authority has bound to it. The Agent Name Service
performs resolution. Its result is bound to the name by the
authority's signature and is only as trustworthy as the authority.
The method is named DISCOVER for continuity with the registered AGTP
method vocabulary and because its registry-resolved and presence-
resolved modes are discovery in this sense; its intent-driven mode is
search, and the text says so where it matters. An agent name and an
agent address are aliases that resolve or discover to an Agent-ID;
the Agent-ID is the identity, and nothing in this document treats a
name or an address as one.
1.3. The Layered Architecture
The discovery architecture for AGTP is layered:
* *AGTP-Presence* [AGTP-PRESENCE] provides population awareness as a
substrate-level property. Agents joining the AGTP network become
ambiently aware of other agents within their visibility scope
without requiring queries against a central directory.
Hood Expires 3 May 2027 [Page 4]
Internet-Draft AGTP-DISCOVER October 2026
* *The DISCOVER method* (specified in this document) provides the
search interface. DISCOVER operates over the Presence substrate,
filtering the ambient population by capability, trust posture, and
governance constraints, and returns ranked candidates.
* *Agent Name Service (ANS)* (specified in this document) provides
governed name-to-Agent-ID resolution, analogous to DNS for the
web. ANS resolves human-readable names to Canonical Agent-IDs
through federated name authorities. Resolution is distinct from
search: a resolved name yields one identity bound by the
authority's signature, where a search yields candidates.
* *Anticipatory Discovery Services (ADS)* (introduced as a forward-
looking composition pattern in this document) provide application-
layer services that observe agent operational signals and preload
awareness of agents the observed agent is likely to need before
explicit queries are issued.
Population awareness is the responsibility of [AGTP-PRESENCE] and is
outside this document. This document specifies the application-layer
query and naming interfaces that compose with that substrate.
1.4. Why Separate Search and Discovery From Naming
The internet has DNS for naming and presence systems (XMPP, Matrix)
for population awareness as separate layers, because they answer
different questions. DNS answers "what is the address for this
name?" Presence systems answer "who is here right now?" These are
different functions with different governance models, different
update cadences, and different consumer use cases.
AGTP follows the same pattern. ANS is the naming layer, providing
stable name-to-identifier mappings with the governance and federation
properties that naming systems require. Presence is the population
layer, providing ambient awareness with the convergence and
visibility properties that population systems require. Conflating
them, as some agent infrastructure proposals do, produces
architectures that fit neither use case well.
1.5. Design Principles
*Agent-native.* Search, discovery, and naming results return
Canonical Agent-IDs and Agent Identity Documents; no web page or
proprietary record appears in a result. The result of a DISCOVER
query is the same shape as the result of resolving a known agent URI.
Hood Expires 3 May 2027 [Page 5]
Internet-Draft AGTP-DISCOVER October 2026
*Governed.* ANS servers and DISCOVER endpoints are AGTP-aware
infrastructure. They enforce trust tier requirements, behavioral
trust score floors, and governance zone constraints before returning
any result. ANS servers act as Scope-Enforcement Points for naming
queries; DISCOVER endpoints act as Scope-Enforcement Points for
capability queries.
*Ranked.* DISCOVER results are ranked by behavioral trust score,
trust tier, and declared capability depth. The highest-quality
agents matching the query appear first.
*Brokered.* DISCOVER endpoints *MAY* negotiate authority scope on
behalf of the requesting agent, informing it of what scope is
required to interact with each discovered agent before commitment.
*Layered.* This document leaves population awareness to
[AGTP-PRESENCE]. The DISCOVER method and ANS compose with Presence
and replicate none of its function.
2. Terminology
The 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 [RFC2119] [RFC8174] when, and only
when, they appear in all capitals.
DISCOVER: An AGTP floor method that searches for agents matching a
capability description, trust requirement, and governance context,
or discovers a known Agent-ID's current attachment. Returns a
ranked list of Agent Identity Documents. See Section 1.2.
ANS (Agent Name Service): An AGTP-aware server implementing the
DISCOVER method and maintaining an index of registered agents and
their capabilities. Acts as a SEP for discovery queries.
Behavioral Trust Score: A numeric value in the range 0.0 to 1.0
Hood Expires 3 May 2027 [Page 6]
Internet-Draft AGTP-DISCOVER October 2026
assigned to an agent at packaging time by a governance platform's
pre-packaging verification pipeline. The score reflects the
degree of observed behavioral alignment between the agent's
declared capabilities, its archetype, and its verified conduct
during behavioral testing. A score of 1.0 indicates full
alignment; a score of 0.0 indicates disqualifying behavioral
discrepancy. The score is embedded in the agent's .agent or .nomo
package at issuance, covered by the package integrity hash, and
surfaced in the Agent Identity Document. It cannot be agent-
asserted or modified without invalidating the package. ANS
servers *MUST* use the behavioral trust score from the verified
Agent Identity Document when ranking DISCOVER results.
Search Query: A structured expression of the requesting agent's
capability need, expressed as a natural language intent,
structured capability criteria, or both. Earlier revisions called
this a discovery query.
Agent Identity Document: As defined in [AGTP-IDDOC]. The signed
document a Canonical Agent-ID resolves to, carrying the agent's
identity, lifecycle state, trust posture, and capabilities;
returned as a search or discovery result. Earlier revisions used
the retired name Agent Manifest Document.
Attachment: The signed, short-lived record of where an agent can
currently be reached, which the presence substrate of
[AGTP-PRESENCE] resolves an Agent-ID to. The Agent-ID is
permanent identity; the attachment is its current location and
changes without the identity changing.
Scope Negotiation: The ANS's declaration of what Authority-Scope the
requesting agent will need to interact with each discovered agent.
3. The DISCOVER Method
3.1. Method Definition
DISCOVER is a floor method of [AGTP] and is registered in the IANA
AGTP Method Registry. It is the protocol-level interface for agent
search and for discovery of a known agent's attachment, operating
over the AGTP-Presence substrate [AGTP-PRESENCE] for population
awareness and against ANS servers for governed query brokering.
Hood Expires 3 May 2027 [Page 7]
Internet-Draft AGTP-DISCOVER October 2026
Purpose: Search for agents matching a capability description and
governance constraints, or discover the current attachment of a known
Agent-ID. Returns a ranked list of Agent Identity Documents drawn
from the live presence layer (per [AGTP-PRESENCE]) within the
requesting agent's visibility scope. The requesting agent *MUST*
carry discovery:query in its Authority-Scope header to invoke
DISCOVER.
Category: ACQUIRE. Idempotent: Yes.
3.2. Operational Modes
DISCOVER operates in three modes, distinguished by the endpoint it
queries:
*Direct Presence query.* The requesting agent invokes DISCOVER
against the local AGTP-Presence overlay coordinator. Results are
drawn from agents currently visible in the requesting agent's
visibility scope per the scoped overlay partitioning of
[AGTP-PRESENCE]. This mode requires no ANS server.
*ANS-brokered query.* The requesting agent invokes DISCOVER against
an ANS server. The ANS server combines its own indexed naming
records with current Presence overlay state to return ranked results
spanning both. ANS-brokered queries provide capability-aware
ranking, scope negotiation, and cross-zone federation.
*Cross-scope resolution.* The requesting agent invokes DISCOVER with
a capability or industry partition that resolves into a scope the
agent has yet to join. The cross-scope resolution mechanism in
[AGTP-PRESENCE] returns agent records from the target scope, which
DISCOVER then ranks and returns to the requester.
The mode is determined by the request target. Implementations
*SHOULD* prefer direct Presence queries for in-scope search and ANS-
brokered queries for cross-zone or capability searches requiring
governed brokering. A DISCOVER whose criteria name a single Agent-ID
is a discovery in the sense of Section 1.2 in any mode; one that
carries intent or capability_domains is a search.
3.3. Parameters
+======================+==========+==============================+
| Parameter | Required | Description |
+======================+==========+==============================+
| intent | *SHOULD* | Natural language description |
| | | of the needed capability |
+----------------------+----------+------------------------------+
Hood Expires 3 May 2027 [Page 8]
Internet-Draft AGTP-DISCOVER October 2026
| capability_domains | *MAY* | Structured capability |
| | | criteria matching DESCRIBE |
| | | domain names |
+----------------------+----------+------------------------------+
| trust_tier_min | *MAY* | Minimum Trust Tier to |
| | | include in results (1, 2, or |
| | | 3) |
+----------------------+----------+------------------------------+
| behavioral_trust_min | *MAY* | Minimum behavioral trust |
| | | score (0.0-1.0) |
+----------------------+----------+------------------------------+
| governance_zone | *MAY* | Restrict results to a |
| | | specific governance zone |
+----------------------+----------+------------------------------+
| org_domain | *MAY* | Restrict results to agents |
| | | from a specific org domain |
+----------------------+----------+------------------------------+
| available_only | *MAY* | If true, exclude agents |
| | | whose availability signal |
| | | (Section 6.2) is |
| | | unavailable: lifecycle state |
| | | other than Active, or at |
| | | session capacity. Default |
| | | false; unavailable agents |
| | | are returned and marked |
+----------------------+----------+------------------------------+
| max_cost | *MAY* | Upper bound, as a decimal |
| | | string in the unit named by |
| | | cost_unit, on the price an |
| | | agent's pricing manifest |
| | | declares for the capability |
| | | sought. Pricing manifests |
| | | and their indexing by ANS |
| | | are specified in the AGTP |
| | | commerce companion; a server |
| | | that indexes no pricing |
| | | *MUST* ignore this parameter |
| | | and say so in the response |
+----------------------+----------+------------------------------+
| cost_unit | *MAY* | Unit for max_cost, from the |
| | | AGTP Budget Unit Registry of |
| | | [AGTP] |
+----------------------+----------+------------------------------+
| limit | *MAY* | Maximum number of results to |
| | | return (default: 10) |
+----------------------+----------+------------------------------+
| scope_negotiate | *MAY* | If true, include required |
| | | Authority-Scope for each |
Hood Expires 3 May 2027 [Page 9]
Internet-Draft AGTP-DISCOVER October 2026
| | | result |
+----------------------+----------+------------------------------+
Table 1: DISCOVER Parameters
3.4. DISCOVER Request Example
AGTP/1.0 DISCOVER
Agent-ID: agtp://agtp.acme.tld/agents/orchestrator
Authority-Scope: discovery:query, agents:delegate
Request-Signature: <JWS per AGTP>
Session-ID: sess-discovery-01
Task-ID: task-disc-001
Content-Type: application/vnd.agtp+json
{
"method": "DISCOVER",
"task_id": "task-disc-001",
"parameters": {
"intent": "Audit smart contracts for security vulnerabilities",
"capability_domains": ["methods", "tools"],
"trust_tier_min": 1,
"behavioral_trust_min": 0.85,
"governance_zone": "zone:external-partner",
"limit": 5,
"scope_negotiate": true
}
}
3.5. DISCOVER Request Example: Domain-Constrained Search
The following example illustrates a targeted DISCOVER query locating
agents capable of auditing Solidity smart contracts within a specific
governance zone and trust tier threshold. The requesting
orchestrator carries discovery:query and agents:delegate scope,
signaling that it intends to act on the results by delegating work.
Hood Expires 3 May 2027 [Page 10]
Internet-Draft AGTP-DISCOVER October 2026
AGTP/1.0 DISCOVER
Agent-ID: agtp://agtp.finco.tld/agents/orchestrator
Request-Signature: <JWS per AGTP>
Authority-Scope: discovery:query agents:delegate audit:*
Session-ID: sess-compliance-q2
Task-ID: task-disc-solidity-01
Content-Type: application/vnd.agtp+json
{
"method": "DISCOVER",
"task_id": "task-disc-solidity-01",
"parameters": {
"intent": "Audit Solidity smart contracts for reentrancy, overflow, and access control misconfiguration",
"capability_domains": ["methods", "tools", "zones"],
"trust_tier_min": 2,
"behavioral_trust_min": 0.88,
"governance_zone": "zone:finance",
"limit": 3,
"scope_negotiate": true
}
}
The ANS server returns a ranked result set. The top result carries
Trust Tier 1 with a behavioral trust score of 0.97, exposing the
required_scope field indicating what the orchestrator must carry
before a DELEGATE to this agent will be accepted:
Hood Expires 3 May 2027 [Page 11]
Internet-Draft AGTP-DISCOVER October 2026
{
"status": 200,
"task_id": "task-disc-solidity-01",
"result": {
"query_id": "qry-sc-audit-3c9f",
"total_matches": 7,
"returned": 3,
"results": [
{
"rank": 1,
"canonical_id": "4f7e1a2b9c3d...",
"attachment": {
"node": "9b21...a7d4",
"binding": "quic",
"endpoint": "agents.auditor.tld:4480",
"mode": "full",
"exp": 1793300000,
"seq": 17
},
"identity_document_uri": "agtp://agtp.auditor.tld/agents/solidity-auditor",
"available": true,
"agent_label": "solidity-auditor",
"org_domain": "auditor.tld",
"trust_tier": 1,
"behavioral_trust_score": 0.97,
"supported_methods": ["QUERY", "ANALYZE", "VALIDATE", "REPORT"],
"capability_match_score": 0.96,
"governance_zone": "zone:finance",
"required_scope": "audit:read code:analyze",
"job_description": "Static and dynamic analysis of Solidity smart
contracts. Detects reentrancy, overflow, and
access control vulnerabilities."
}
],
"ans_signature": {
"algorithm": "ES256",
"key_id": "ans-key-finance-01",
"value": "[base64-encoded-signature]"
}
}
}
The requesting agent verifies the ans_signature before trusting any
result. It then issues a DESCRIBE to agtp://agtp.auditor.tld/agents/
solidity-auditor to confirm method support before committing to
DELEGATE.
Hood Expires 3 May 2027 [Page 12]
Internet-Draft AGTP-DISCOVER October 2026
3.6. DISCOVER Response
The DISCOVER response body contains a ranked list of result entries,
each carrying the agent's Canonical Agent-ID, its current attachment
per [AGTP-PRESENCE] so that the result is reachable without a further
resolution step, and optional scope negotiation fields:
{
"status": 200,
"task_id": "task-disc-001",
"result": {
"query_id": "qry-7f3a9c",
"total_matches": 23,
"returned": 5,
"results": [
{
"rank": 1,
"canonical_id": "3a9f2c1d8b7e4a6f...",
"attachment": {
"node": "7f3a...c2e1",
"binding": "quic",
"endpoint": "agents.auditor.tld:4480",
"mode": "full",
"exp": 1793300000,
"seq": 42
},
"identity_document_uri": "agtp://agtp.auditor.tld/agents/contract-auditor",
"available": true,
"agent_label": "contract-auditor",
"org_domain": "auditor.tld",
"trust_tier": 1,
"behavioral_trust_score": 0.97,
"supported_methods": ["QUERY", "VALIDATE", "REPORT"],
"capability_match_score": 0.94,
"required_scope": "audit:read code:analyze",
"job_description": "Static and dynamic analysis of Solidity smart contracts."
}
],
"ans_signature": {
"algorithm": "ES256",
"key_id": "ans-key-public-01",
"value": "[base64-encoded-signature]"
}
}
}
Hood Expires 3 May 2027 [Page 13]
Internet-Draft AGTP-DISCOVER October 2026
The ans_signature covers the full result set including all manifests
and the query_id. The requesting agent *MUST* verify the signature
before trusting any discovery result. An unsigned or invalid
DISCOVER response *MUST* be rejected.
3.7. Ranking Algorithm
ANS servers *MUST* rank results by a composite score computed as:
rank_score = (trust_tier_weight * normalized_trust_tier)
+ (behavioral_trust_weight * behavioral_trust_score)
+ (capability_match_weight * capability_match_score)
Default weights: trust_tier_weight = 0.3, behavioral_trust_weight =
0.4, capability_match_weight = 0.3. ANS servers *MAY* publish
alternative weight configurations for domain-specific deployments.
The capability_match_score is computed by the ANS server as a
normalized relevance score between the query's intent and
capability_domains and the candidate agent's declared capabilities.
The computation method is implementation-defined but *MUST* be
deterministic for identical inputs.
4. Agent Name Service
4.1. ANS Architecture
The Agent Name Service provides governed resolution of human-readable
names to Canonical Agent-IDs. ANS is the naming layer for AGTP,
analogous to DNS for the web. ANS leaves to Presence the population
awareness functionality provided by [AGTP-PRESENCE]; it provides the
stable name-to-identifier mapping that complements ambient discovery
in the sense of Section 1.2.
An ANS server is an AGTP endpoint that:
1. Maintains a registry of name-to-Agent-ID bindings for agents in
its naming authority. The registry is structured for fast lookup
on the name key, comparable to DNS zone file lookup.
2. Resolves DISCOVER queries that include name-based criteria by
returning the bound Agent-ID and associated Agent Identity
Document. ANS may consult the Presence overlay for current
operational state of the resolved agent.
3. Enforces Trust Tier and behavioral trust score thresholds on all
queries before returning results.
Hood Expires 3 May 2027 [Page 14]
Internet-Draft AGTP-DISCOVER October 2026
4. Signs all DISCOVER responses with the ANS's governance key.
5. Acts as a SEP for naming traffic: agents without discovery:query
scope *MUST* be rejected with 455 Scope Violation.
ANS servers are themselves AGTP agents: they have canonical Agent-
IDs, Agent Genesis records, and Agent Identity Documents. Their
capabilities include discovery:query and discovery:register as
Authority-Scope domains.
Multiple ANS servers *MAY* be deployed for different naming
authorities, organizations, or trust tier populations. Cross-ANS
federation is described in Section 5.
4.2. Relationship to Presence
ANS and AGTP-Presence are complementary layers serving different
discovery use cases:
+========================+===============+========================+
| Question | Layer | Mechanism |
+========================+===============+========================+
| Who is here right now? | Presence | Ambient overlay |
| | | membership |
+------------------------+---------------+------------------------+
| What is the Agent-ID | ANS | Name-to-identifier |
| for this name? | | resolution |
+------------------------+---------------+------------------------+
| Which agents can do X? | DISCOVER over | Capability filter over |
| | Presence | visible population |
+------------------------+---------------+------------------------+
| Which agents named | DISCOVER via | Name-anchored |
| X.acme.com exist? | ANS | capability resolution |
+------------------------+---------------+------------------------+
Table 2
An agent's full discovery toolkit consists of all three: ambient
awareness through Presence, governed name resolution through ANS, and
capability-driven query through DISCOVER. These compose without
duplication.
ANS servers *MAY* consult Presence overlay state when answering
DISCOVER queries to ensure that resolved agents are currently
reachable. An ANS-resolved name pointing to an Agent-ID that is no
longer in any visible Presence overlay *SHOULD* be returned with an
availability indicator, allowing the requesting agent to decide
whether to attempt connection.
Hood Expires 3 May 2027 [Page 15]
Internet-Draft AGTP-DISCOVER October 2026
4.3. ANS Registration
An agent registers with an ANS server through a governed process tied
to AGTP activation:
1. On completion of the AGTP ACTIVATE transaction, the governance
platform automatically submits the agent's Agent Identity
Document and DESCRIBE capability data to the designated ANS
server(s) for the agent's governance zone.
2. The ANS server verifies the agent's lifecycle state is Active.
3. The ANS server indexes the agent's capabilities, trust tier, and
behavioral trust score.
4. The ANS server updates its result index within 60 seconds.
Manual registration is unsupported. ANS registration is a
consequence of AGTP activation, with no independent registration
step. This ensures that only Active, registered agents appear in
discovery results.
4.4. ANS Deregistration
When an agent's lifecycle state transitions to Suspended, Revoked, or
Deprecated, the governance platform *MUST* notify the relevant ANS
servers within 60 seconds. The ANS server *MUST* remove the agent
from its result index before the next DISCOVER request is processed.
ANS servers *MUST* treat deregistration as urgent: a Revoked agent
that continues to appear in discovery results is a governance
failure. ANS servers *MUST* log deregistration events.
4.5. Index Freshness
ANS servers *MUST* refresh capability data for indexed agents at a
configurable interval (recommended: 24 hours). Refresh is triggered
by issuing DESCRIBE requests to each indexed agent's canonical URI.
If an agent fails to respond to a DESCRIBE request after three
consecutive attempts, the ANS server *MUST* remove it from the index
and notify the governance platform.
5. Cross-ANS Federation
Hood Expires 3 May 2027 [Page 16]
Internet-Draft AGTP-DISCOVER October 2026
5.1. The Federation Problem
An agent in one naming authority may need to resolve names registered
in a different authority. Organization-scoped ANS servers lack
visibility into other organizations' naming records.
Naming federation in ANS follows the DNS root and TLD hierarchy.
Cross-organizational name resolution proceeds through established
federation patterns at the naming authority layer. Population
federation across organizations is handled separately by the cross-
scope resolution mechanism in [AGTP-PRESENCE].
5.2. Federation Protocol
AGTP supports a federated discovery model in which ANS servers can
query peer ANS servers on behalf of requesting agents. A federated
DISCOVER query:
1. The requesting agent sends a DISCOVER request to its local ANS
server.
2. If the local ANS server's index holds insufficient results (fewer
than limit results above the requested thresholds), it MAY
forward the query to federated peer ANS servers it trusts.
3. Federated queries *MUST* carry the original requesting agent's
Agent-ID and scope requirements. The forwarding ANS server *MUST
NOT* expand the scope or lower the trust requirements in the
forwarded query.
4. Peer ANS servers apply their own governance policies to the
forwarded query and return signed result sets.
5. The local ANS server merges, re-ranks, and re-signs the combined
result set before returning it to the requesting agent.
6. The merged result includes a federation_path field listing the
ANS servers that contributed results.
5.3. Trust in Federation
Federated ANS results *MUST* be treated with the same trust level as
the federated ANS server's own Trust Tier claim. An ANS server
*MUST* declare the trust tier of its indexed agents accurately;
misrepresenting agent trust tiers in federated results is a
governance violation.
Hood Expires 3 May 2027 [Page 17]
Internet-Draft AGTP-DISCOVER October 2026
6. Dynamic Routing and Failover
6.1. Capability-Based Routing
ANS servers *MAY* support dynamic routing: when a requesting agent's
preferred target agent is unavailable (lifecycle state Suspended,
absent from responding, or rate-limited), the ANS server *MAY* return
an equivalent agent from its index as a routing alternative.
Dynamic routing responses *MUST* indicate: - routing_reason: the
reason the primary agent was withheld - equivalent_confidence: a
score (0.0-1.0) indicating how closely the alternative matches the
primary agent's capabilities
The requesting agent retains the right to reject the alternative.
6.2. Agent Availability Signals
ANS servers *SHOULD* monitor indexed agents' availability by
periodically checking the /status sub-resource defined in
[AGTP-IDDOC]. Agents with lifecycle_state: Suspended or
active_session_count at capacity *SHOULD* be marked as unavailable in
routing responses.
7. Anticipatory Discovery Services
This section introduces Anticipatory Discovery Services (ADS) as a
forward-looking composition pattern. ADS is an architectural concept
specified here in outline form; a full specification is deferred to a
future document.
7.1. The Anticipatory Pattern
Baseline discovery in AGTP combines ambient awareness within Presence
overlays, governed name resolution through ANS, and capability-driven
query through DISCOVER. An agent's effective awareness is bounded by
the scopes it has joined and the queries it explicitly issues.
Anticipatory Discovery Services expand this awareness proactively.
An ADS observes an agent's operational signals (methods invoked,
capabilities accessed, recent peers, principal context, time-of-day
patterns) and predicts which categories of agents the observed agent
is likely to need next. ADS then preloads awareness of relevant
agents through proactive Presence overlay joining or rendezvous
lookups, before the observed agent has issued an explicit DISCOVER
query.
Hood Expires 3 May 2027 [Page 18]
Internet-Draft AGTP-DISCOVER October 2026
The pattern is analogous to anticipatory service in hospitality:
recognizing that a guest walking toward the pool will need towels and
providing them before the request is articulated. The signal
precedes the explicit ask; the response is preloaded based on the
observed pattern.
7.2. Architectural Position
ADS is an application-layer service, above the substrate. It
composes with the layers specified elsewhere in the AGTP draft
family:
* *AGTP base* provides the wire-level identity and methods
* *[AGTP-TRUST]* provides trust posture for filtering predictions
* *[AGTP-PRESENCE]* provides the population substrate that ADS
expands awareness within
* *This document* provides the DISCOVER and ANS mechanisms that ADS
proactively invokes on behalf of observed agents
ADS operates as a service that agents subscribe to or organizations
host. It uses AGTP primitives (DISCOVER queries, ANS resolutions,
Presence overlay joining, attribution records) but is outside the
substrate itself.
7.3. Composable ADS Providers
This document explicitly accommodates multiple deployment models for
ADS:
*Self-hosted ADS.* Organizations operate their own ADS for their
agents. The model is trained on the organization's own data.
Operational signals never leave the org. Anticipatory benefit is
bounded by the org's own scale and pattern diversity.
*Trust-tier-scoped ADS.* ADS services operate per trust tier,
observing patterns within a tier and serving anticipatory predictions
to participating agents. Cross-organizational learning improves
predictions; privacy is managed through aggregated or differentially
private signal exchange.
Hood Expires 3 May 2027 [Page 19]
Internet-Draft AGTP-DISCOVER October 2026
*Specialized provider ADS.* Just as trust providers can specialize
(as described in [AGTP-TRUST]), ADS providers may specialize by
capability domain, industry vertical, or trust tier. A finance ADS
for trading agents, a consumer-services ADS for retail agents, a
healthcare ADS for clinical agents. Agents subscribe to one or more
ADS providers appropriate to their domain.
*Capability-derived ADS.* ADS scoped per capability dimension (per
the partition model in [AGTP-PRESENCE]). Capability-specific
prediction models operate within each capability scope, with cross-
scope coordination through standard federation patterns.
7.4. Trust and Privacy Considerations
ADS observes operational patterns that may include sensitive
information about agent activity, principals served, capabilities
accessed, and interaction patterns. Several mitigations are
acknowledged in this outline; full specification is deferred:
* ADS subscription *MUST* be opt-in. Agents that never subscribe to
any ADS provider operate with baseline Presence and on-demand ANS/
DISCOVER without anticipatory preloading.
* ADS providers *MUST* scope their predictions within the visibility
constraints of the observed agent. ADS expands discovery within
existing access; it grants no access the agent would otherwise
lack.
* Local-only ADS deployments preserve privacy by keeping operational
signals within the organizational boundary.
* ADS providers that aggregate signals across organizations *SHOULD*
apply differential privacy or aggregate-only observation patterns.
7.5. Forward-Looking Composition
ADS is positioned in this document as an architectural concept worth
specifying. The agent population is growing; the operational
sophistication of agent discovery is going to grow with it. ADS
represents a natural composition pattern where application-layer
services consume AGTP primitives to provide value beyond what the
substrate or the basic query interfaces deliver on their own.
Future revisions or companion documents will specify:
* The signal vocabulary that ADS providers ingest
* The prediction interface between ADS and observed agents
Hood Expires 3 May 2027 [Page 20]
Internet-Draft AGTP-DISCOVER October 2026
* The preloading protocol for proactive Presence overlay joining
* Privacy semantics for cross-organizational signal aggregation
* Feedback mechanisms for prediction quality assessment
This document establishes the architectural slot for ADS within the
AGTP discovery layer, naming the pattern and positioning it as a
composable application-layer service alongside the credit-rating
trust providers described in [AGTP-TRUST].
8. Security Considerations
8.1. Discovery Result Injection
Threat: A malicious ANS server returns forged Agent Identity
Documents pointing to attacker-controlled agents.
Mitigation: All DISCOVER responses *MUST* be signed by the ANS
server's governance key. The requesting agent *MUST* verify the
ans_signature field before trusting any result. The ANS server's
governance key *MUST* be resolvable via the ANS server's own Agent
Identity Document, creating a verifiable trust chain.
8.2. Discovery Enumeration
Threat: A malicious agent uses repeated DISCOVER queries to enumerate
all agents in a governance zone, gaining knowledge of the
organization's agent architecture.
Mitigation: ANS servers *MUST* enforce rate limiting per requesting
Agent-ID. ANS servers *MAY* require discovery:query scope to include
agents from restricted governance zones. ANS servers *SHOULD* log
high-frequency DISCOVER queries as anomaly signals.
8.3. Behavioral Trust Score Manipulation
Threat: An agent artificially inflates its behavioral trust score to
appear higher in discovery results.
Mitigation: Behavioral trust scores are computed by the governance
platform's pre-packaging verification pipeline and embedded in the
agent's .agent or .nomo package at issuance time. The score is part
of the signed manifest and cannot be modified without invalidating
the package integrity hash. ANS servers *MUST* use the trust score
from the verified Agent Identity Document; agent-asserted fields are
ignored.
Hood Expires 3 May 2027 [Page 21]
Internet-Draft AGTP-DISCOVER October 2026
8.4. Scope Negotiation Abuse
Threat: An ANS server inflates the required_scope field in discovery
results, causing requesting agents to request broader scope than
necessary.
Mitigation: Requesting agents *MUST NOT* blindly request the scope
declared in discovery results. The required_scope field is
informational; agents *MUST* evaluate the scope against their own
authorization and request only what is needed for the specific task.
Governance platforms *SHOULD* flag scope requests that significantly
exceed the scope of prior tasks in the same session.
9. IANA Considerations
9.1. DISCOVER Method Registration
This document requests registration of the DISCOVER method in the
IANA AGTP Method Registry established by [AGTP]:
+==========+===========+==============================+
| Method | Status | Reference |
+==========+===========+==============================+
| DISCOVER | Permanent | [AGTP]; search and discovery |
| | | semantics in this document |
+----------+-----------+------------------------------+
Table 3: DISCOVER Method Registry Entry
9.2. New Authority-Scope Domains
This document uses the following Authority-Scope domains defined in
[AGTP] Appendix A:
+====================+==========================================+
| Domain | Used For |
+====================+==========================================+
| discovery:query | Sending DISCOVER requests to ANS servers |
+--------------------+------------------------------------------+
| discovery:register | ANS registration operations (governance |
| | platform only) |
+--------------------+------------------------------------------+
Table 4
No new domains are requested; these are from the existing reserved
set.
Hood Expires 3 May 2027 [Page 22]
Internet-Draft AGTP-DISCOVER October 2026
10. References
10.1. Normative References
[AGTP] Hood, C., "Agent Transfer Protocol (AGTP)", Work in
Progress, Internet-Draft, draft-hood-independent-agtp-10,
2026, <https://datatracker.ietf.org/doc/html/draft-hood-
independent-agtp-10>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
10.2. Informative References
[AGTP-IDDOC]
Hood, C., "AGTP Agent Identity Document", Work in
Progress, Internet-Draft, draft-hood-agtp-identity-
document-00, 2026, <https://datatracker.ietf.org/doc/html/
draft-hood-agtp-identity-document-00>.
[AGTP-PRESENCE]
Hood, C., "AGTP Presence: Ambient Discovery and Visibility
for Agents", Work in Progress, Internet-Draft, draft-hood-
agtp-presence-01, 2026,
<https://datatracker.ietf.org/doc/html/draft-hood-agtp-
presence-01>.
[AGTP-TRUST]
Hood, C., "AGTP Trust and Verification Specification",
Work in Progress, Internet-Draft, draft-hood-agtp-trust-
03, 2026, <https://datatracker.ietf.org/doc/html/draft-
hood-agtp-trust-03>.
[DAWN-INFRA]
Dunbar, L., "Infrastructure-Assisted Discovery of AI
Agents", Work in Progress, Internet-Draft, draft-dunbar-
dawn-infra-assisted-discovery, 2026,
<https://datatracker.ietf.org/doc/html/draft-dunbar-dawn-
infra-assisted-discovery>.
Hood Expires 3 May 2027 [Page 23]
Internet-Draft AGTP-DISCOVER October 2026
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/rfc/rfc6763>.
Appendix A. ANS Deployment Considerations
Small organizations may run no dedicated ANS servers. The AGTP
governance platform *MAY* provide built-in ANS functionality as part
of the agent registry. In this case, the governance platform's
registry endpoint serves both registration (ACTIVATE) and discovery
(DISCOVER) queries.
Large organizations with hundreds or thousands of agents *SHOULD*
deploy dedicated ANS infrastructure with appropriate indexing and
caching. The ANS index is a read-heavy workload; standard caching
and replication patterns apply.
Cross-organization federation requires bilateral trust establishment
between ANS operators. The protocol for establishing ANS federation
trust is out of scope for this document but follows the same patterns
as AGTP Trust Tier 1 verification: DNS ownership challenge and mutual
certificate exchange.
Appendix B. Mapping to DAWN Discovery Records
The IETF DAWN working group scopes discovery of agents within a local
network, an organization, or a set of cooperating parties, over DNS
and mDNS, and leaves identity, capability catalogs, Internet-wide
search, and trust evaluation out of scope. The DISCOVER method's
search mode and the ANS federation of this document are outside that
scope; the discovery of a known agent's attachment within an
organization is inside it. This appendix states the mapping for that
case, so that an AGTP agent can be found by a DAWN-conformant
resolver and a DAWN-published agent can be reached over AGTP.
The DAWN work describes an agent with a record borrowed from the A2A
Agent Card in its initial revision: a self-asserted JSON document
served at a well-known HTTPS path and trusted through its domain.
The mapping from an AGTP Agent Identity Document to that record is
lossy in one direction and incomplete in the other:
Hood Expires 3 May 2027 [Page 24]
Internet-Draft AGTP-DISCOVER October 2026
+==================+==============+==============================+
| Agent Identity | DAWN record | Carried |
| Document | | |
+==================+==============+==============================+
| agent_id | name or URL | as an opaque identifier in |
| | of the | the record's name; the |
| | record | Agent-ID is the identity, |
| | | the record's URL is an alias |
+------------------+--------------+------------------------------+
| name, | the record's | yes |
| description, | descriptive | |
| capabilities | fields | |
+------------------+--------------+------------------------------+
| methods, | the record's | as strings; the AGTP |
| scopes_accepted | capability | semantics are lost |
| | or skill | |
| | list | |
+------------------+--------------+------------------------------+
| status | none | lost; a DAWN record cannot |
| (lifecycle | | say an agent is suspended |
| state) | | |
+------------------+--------------+------------------------------+
| issuer | none | lost; a DAWN record is self- |
| signature, | | asserted |
| agent_public_key | | |
+------------------+--------------+------------------------------+
| attachment | the record's | yes, as a bare URL; the |
| (current | endpoint URL | signature is lost |
| location) | | |
+------------------+--------------+------------------------------+
Table 5: Identity Document to DAWN Record
An AGTP agent that publishes a DAWN record *MUST* place its Canonical
Agent-ID in the record so that a DAWN resolver's result can be
discovered (in the sense of Section 1.2) through AGTP to the signed
Identity Document. A DAWN record with no Agent-ID maps to an
Identity Document at Level 1 of [AGTP] only, with no issuer, and AGTP
treats it as a search result, short of a discovered identity. The
reverse mapping, from a DAWN record to an Identity Document,
therefore falls short of registration and cannot replace it.
Hood Expires 3 May 2027 [Page 25]
Internet-Draft AGTP-DISCOVER October 2026
B.1. Infrastructure-Assisted Discovery
[DAWN-INFRA] describes managed enterprise, edge, and network
deployments in which discovery is fed by two infrastructure inputs: a
Resource Publication Hook, through which an orchestration or hosting
system supplies the discovery mechanism with the agent instances
currently deployed and their endpoints, and an Attachment Context
Hook, through which the network supplies an abstract representation
of the requester's current attachment (site, VPN, tenant, slice, edge
region). The motivating failure is a discovery system that keeps
returning an instance that has been withdrawn or is unreachable from
where the requester now is. AGTP meets the same need with one
publish event and one verified identity in place of two feeds, and
the mapping is stated here for readers coming from that work.
The Resource Publication Hook is ACTIVATE. A successful ACTIVATE is
the publish event of [AGTP]: it triggers registration with the ANS of
the agent's zone (Section 4) and the first ANNOUNCE into the presence
substrate ([AGTP-PRESENCE]), and DEACTIVATE, REVOKE, and DEPRECATE
are the withdrawal events. The dynamic half of what the hook would
carry, the current endpoint, is the attachment record of
[AGTP-PRESENCE]: signed by the agent, sequenced, and short-lived, so
that a withdrawn or moved instance expires out of discovery on its
own and a stale attachment yields nothing an attacker can use. An
orchestrator that instantiates, moves, scales, or withdraws instances
does so through the lifecycle methods, and discovery follows without
a side channel.
The Attachment Context Hook divides into two inputs that AGTP already
binds to the requester. Administrative context (tenant, VPN,
organization, governance zone) is a property of the requester's
verified identity: the governance_zone and org_domain of the Identity
Document the requester's Agent-ID resolves to, under the issuer's
signature. That is why the DISCOVER governance-zone rule of [AGTP]
needs no network hook: the server reads the requester's zone from the
document it has already verified. Location context (which site or
edge region the requester is attached to) is the requester's own
presence: the overlays it has joined and the attachment record it has
itself announced per [AGTP-PRESENCE], whose region partition
dimension carries exactly the site and edge granularity the use case
needs. In both cases the context arrives signed and bound to the
requester, with no middlebox inferring it, which is the integrity,
origin, and freshness protection [DAWN-INFRA] asks for in its
security considerations, and the underlying network detail (UPF, DNN,
slice, serving gateway) stays with the network, since the abstract
context is all the requester's identity and attachment expose.
Hood Expires 3 May 2027 [Page 26]
Internet-Draft AGTP-DISCOVER October 2026
The use case's own boundary, that discovery returns the applicable
entities and leaves selection to the requester, is the search line of
Section 1.2: DISCOVER returns ranked candidates, each with its
current attachment, and the requester chooses.
On the word itself: [DAWN-INFRA] uses "attachment" for the
requester's network attachment, this family uses it for the
discovered agent's. They are the same network term, where a node
attaches, applied to the two parties of a discovery. Both parties
have an attachment; AGTP publishes the target's as the attachment
record and uses the requester's as search context.
Appendix C. Changes from v01
Version 02 is a vocabulary and alignment revision. The DISCOVER
method, the ANS protocol, federation, and the ADS pattern are
unchanged on the wire.
* *Search, discover, resolve* (Section 1.2). The three operations
the document already separated are now named distinctly, following
[RFC6763]: search (criteria to candidates), discover (identity to
attachment), resolve (name to identity). Applied through the
introduction, design principles, terminology, and method
definition. The DISCOVER method keeps its name; its intent-driven
mode is called search where it matters.
* *Agent Identity Document* replaces the retired name Agent Manifest
Document throughout; *Agent Genesis* replaces Birth Certificate.
Attachment is defined as the signed current location an Agent-ID
resolves to.
* *Owner-ID* is no longer shown as a request header in the examples,
matching [AGTP]; Request-Signature is shown instead.
* *Results carry the attachment.* Each DISCOVER result now carries
the agent's current attachment record per [AGTP-PRESENCE] in place
of the host-anchored manifest_uri, so a search result is reachable
without a further resolution step; the Identity Document location
is identity_document_uri.
* *available_only, max_cost, cost_unit* added to the DISCOVER
parameters, binding the availability signals and the commerce
pricing manifests to search.
* *DAWN mapping* (Appendix B): the Identity Document to DAWN record
mapping for the in-scope organizational case, stated as lossy,
with the Agent-ID as the join; and the mapping of the
infrastructure-assisted discovery hooks of draft-dunbar-dawn-
Hood Expires 3 May 2027 [Page 27]
Internet-Draft AGTP-DISCOVER October 2026
infra-assisted-discovery onto ACTIVATE as the publish event and
the requester's verified identity and own attachment
(Appendix B.1).
* References: base to draft-hood-independent-agtp-10, AGTP-CERT to
-03, AGTP-PRESENCE to -01, AGTP-IDDOC and RFC 6763 added.
Hardcoded section numbers replaced. Five unused references
dropped. House style pass.
Appendix D. Changes from v00
Version 01 restructures this document around the layered discovery
architecture that emerged from the publication of [AGTP-PRESENCE].
The DISCOVER method definition and the substantive ANS specification
content are preserved; the architectural framing and section
organization are revised to reflect the layered model.
D.1. Substantive Changes
The following substantive changes were made in v01:
1. *Layered architecture framing.* The introduction now establishes
the three distinct discovery problems (population awareness,
capability matching, name resolution) and assigns each to its
appropriate layer ([AGTP-PRESENCE], the DISCOVER method, and ANS
respectively). The document no longer presents ANS as the
primary discovery mechanism; ANS is now positioned as the naming
layer that composes with Presence.
2. *DISCOVER over Presence substrate.* The DISCOVER method is now
specified to operate over the AGTP-Presence substrate as its
primary mode, with ANS-brokered queries and cross-scope
resolution as additional operational modes. The method's wire
format is unchanged.
3. *ANS reframed as name resolution.* The Agent Name Service section
now positions ANS as a governed name-to-Agent-ID resolution layer
analogous to DNS, complementing the population awareness provided
by AGTP-Presence. A new "Relationship to Presence" subsection
makes the layered composition explicit.
4. *Anticipatory Discovery Services introduced.* A new section
(Section 7) introduces ADS as a forward-looking composition
pattern where application-layer services preload agent awareness
based on observed operational signals. The architectural concept
is named and positioned; full specification is deferred to future
work.
Hood Expires 3 May 2027 [Page 28]
Internet-Draft AGTP-DISCOVER October 2026
5. *Informative references added.* AGTP-PRESENCE and AGTP-TRUST are
added to the informative references. Cross-references throughout
the document point to the appropriate layer for population
awareness, trust posture consumption, and credit-rating-analogous
trust provider composition.
D.2. Wire Format Compatibility
The DISCOVER method wire format is unchanged. Implementations
conforming to v00 of this document continue to interoperate with v01.
The architectural reframing affects how the document describes the
relationships between layers; the protocol behavior that v00
implementations have shipped is the same.
Author's Address
Chris Hood
Nomotic, Inc.
Email: chris@nomotic.ai
URI: https://nomotic.ai
Hood Expires 3 May 2027 [Page 29]