Autonomous Machine-to-Machine Agent Discovery and Capability Matchmaking: A Comprehensive Architectural Review

Full report

On this page

The transition from human-operated software infrastructure to autonomous machine-to-machine environments represents a fundamental paradigm shift in distributed systems architecture. In conventional service-oriented architectures, human developers read application programming interface documentation, provision credentials, configure network endpoints, and write custom integration code. In an autonomous machine-to-machine ecosystem, software agents must dynamically discover peers, interpret machine-readable capabilities, negotiate access, execute coordinated tasks, and recover from failures without routine human operation. This requires a robust, interoperable infrastructure for semantic discovery, cryptographic identity verification, stateful interaction, and automated fallback orchestration. The central computational challenge in autonomous agent ecosystems lies in matchmaking: determining autonomously whether a discovered peer is capable, available, and authorized to perform a specific task within defined constraints. Furthermore, the architecture must distinguish an unverified capability advertisement from cryptographic evidence that a peer can execute a task reliably. This report exhaustively analyzes the evolution of agent discovery mechanisms, utilizing primary source specifications and contemporary protocols to evaluate centralized registries, federated catalogs, peer-to-peer discovery, and capability-based search. By tracing the trajectory from location-bound legacy multi-agent frameworks to modern, decentralized, cryptographic identity protocols, this document proposes a standardized architecture for verifiable capability matchmaking and resilient coordination across independent systems.

Primary Findings in Agent Discovery and Matchmaking

The mechanisms by which software agents discover and interact with one another have undergone significant architectural revisions over the past three decades. Early attempts at standardizing multi-agent systems established foundational concepts but struggled with network scalability and rigid, location-bound identity models. Modern protocols have actively decoupled identity from network topology, introducing standardized manifests and cryptographic proofs to verify capability claims.

The Evolution from Location-Bound to Capability-Bound Identity

The Foundation for Intelligent Physical Agents specifications, developed in the late 1990s and standardized through the early 2000s, represent the earliest comprehensive formalization of interoperable agent infrastructure1. The Foundation for Intelligent Physical Agents model established an agent management reference architecture comprising the Agent Management System for lifecycle tracking and the Directory Facilitator as a mandatory yellow pages component where agents registered their service capabilities1. The architecture further defined the Agent Communication Language and an Agent Interaction Protocol Suite encompassing communicative acts, content logic, and shared ontologies5. However, this legacy framework relied on a location-bound identity model where an agent's identifier intrinsically contained its network addresses1. If an agent migrated or its endpoint changed, its identity effectively broke, requiring full re-registration with the Agent Management System and the Directory Facilitator1. This structural flaw corrupted audit logs because the system could not cryptographically verify whether the new endpoint represented the same agent or an imposter1. Furthermore, the Directory Facilitator required formal service descriptions based on heavy, shared ontologies that scaled poorly in open-ended networks, as federation between multiple Directory Facilitators required complex registration synchronization that became untenable as platform counts increased1. The fundamental architectural insight driving modern machine-to-machine network design is that an agent's identity must be entirely decoupled from its network topology. Modern proposals advocate for identity frameworks that route discovery based on semantic capabilities rather than physical locations. For instance, the proposed agent:// uniform resource identifier scheme decouples identity into an organizational trust root, a hierarchical capability path, and a stable cryptographic identifier1. This specific scheme enables capability-based discovery through distributed hash table key derivation, where the key is derived by hashing the trust root and the capability path together1. Consequently, agents are queried by what they do rather than where they reside, and trust-root scoping mathematically prevents cross-organization pollution by isolating search spaces to explicit queries1.

The Standardization of Capability Manifests and Context Protocols

To eliminate the need for the heavy, brittle ontologies of legacy multi-agent systems, contemporary architectures utilize structured, machine-readable manifests that establish syntactic interoperability. The Agent-to-Agent protocol, introduced by Google in April 2025 and subsequently governed by the Linux Foundation, introduces the Agent Card as its primary discovery mechanism6. An Agent Card is a JavaScript Object Notation metadata document typically published at a well-known URL, describing the agent's identity, skills, communication endpoints, supported protocol bindings, and authentication requirements7. The Agent-to-Agent protocol deliberately reuses proven web infrastructure, supporting transport-agnostic bindings such as JSON-RPC 2.0 over HTTP, gRPC for high-throughput internal systems, and Server-Sent Events for streaming state updates7. The release of the version 1.0 specification in March 2026 formalized Signed Agent Cards, allowing a client agent to read a manifest and immediately determine if a target peer possesses required capabilities, matching protocol versions, and compatible security schemes before initiating an interaction7. Similarly, the Model Context Protocol, an open standard introduced in 2024, standardizes how applications expose tools and context to autonomous models via a client-server architecture9. The Model Context Protocol requires servers to explicitly negotiate capabilities upon connection. Servers declare tool availability and respond to list requests with JSON Schema definitions of expected input parameters12. The protocol utilizes a robust semantic discovery model where tool names must conform to strict ASCII constraints, and definitions include both human-readable descriptions and machine-readable JSON Schema usage guidelines defaulting to the 2020-12 specification12. Crucially, the Model Context Protocol addresses the pervasive problem of stale registrations through active state management. Servers declaring the listChanged: true capability actively emit notifications when the availability of tools changes, allowing connected clients to continuously update their understanding of the peer's capabilities without polling12. This active signaling prevents agents from attempting to invoke degraded or offline services, thereby reducing excessive network traffic and improving overall system reliability. Furthermore, servers are instructed to return tools in a deterministic order to allow clients to reliably cache tool lists, which significantly improves prompt cache hit rates when tools are included in large language model context windows12.

Discovery Architectures: Introduction Versus Exploration Phases

The World Wide Web Consortium Web of Things architecture provides a mature, established framework for separating the discovery of an entity from the extraction of its detailed capabilities. The Web of Things Discovery specification delineates two distinct and necessary phases: Introduction and Exploration13. Introduction mechanisms, such as Multicast DNS and DNS Service Discovery, allow agents to broadcast their presence on local networks using specific service types, such as \_wot.\_tcp, without exposing sensitive operational data or proprietary schemas13. Once introduced, the Exploration phase begins. During Exploration, agents retrieve a Thing Description, a machine-readable blueprint defining the entity's properties, actions, and events, along with the necessary security definitions required to interact with them15. Because full capability metadata may contain sensitive pricing models, exact input schemas, or proprietary algorithms, the Exploration phase is explicitly protected by authorization mechanisms13. To scale this across broad, multi-domain networks, the Web of Things architecture defines the Thing Description Directory, a searchable database supporting syntactic queries via JSONPath or XPath, and semantic queries via SPARQL13. This phased approach prevents unauthorized peers from scraping detailed capability schemas while still allowing broad, lightweight initial discovery. Furthermore, the specification supports the use of a Thing Link, allowing a resource-constrained agent to host a minimal local manifest that points to a full Thing Description hosted securely in a remote directory, optimizing bandwidth and storage on edge devices13.

Cryptographic Capability Attestation and Verifiable Execution

The most critical advancement separating legacy autonomous systems from modern enterprise architectures is the transition from trusting a claimed capability to requiring mathematical capability attestation. A claimed capability is merely an advertisement broadcast by an agent; reliable autonomous systems require verifiable evidence that a peer can execute a task appropriately. Systems such as the Agent Graph Trust Protocol and the Global Agent Identity Document mandate the use of World Wide Web Consortium Decentralized Identifiers and Verifiable Credentials18. A Decentralized Identifier provides a globally unique, persistent, cryptographically verifiable, self-sovereign identifier that does not depend on a central registry or DNS authority19. When an agent advertises a capability, modern architectures require it to present a Verifiable Credential signed by a trusted third party, a domain authority, or an accreditation body18. This effectively solves the problem of misleading descriptions: a client agent does not simply trust the text of an Agent Card; it cryptographically verifies the credential proving the agent is accredited to perform the specific task. The Agent Graph Trust Protocol expands this by formalizing Learning Signals, where the atomic unit of feedback is a signed attestation bound to content-addressed artifacts that make the evaluation reproducible18. Furthermore, to guarantee that the agent operates correctly at runtime, systems are increasingly integrating Verifiable Execution Traces and Trusted Execution Environment attestations22. These mechanisms bind the identity of the software agent to the physical or virtual hardware executing the task. The resulting attestation provides an unbroken chain of cryptographic provenance from the initial capability claim, through the secure execution enclave, to the final computational output, completely eliminating reliance on the host organization's unverified operational claims23.

Comparison of Credible Matchmaking Approaches

Matchmaking architectures dictate how autonomous agents traverse networks to locate peers satisfying specific operational constraints. The selection of an architecture heavily influences system latency, resistance to censorship, privacy, and susceptibility to stale data. The analysis identifies four primary discovery architectures utilized in multi-agent environments, each presenting distinct operational tradeoffs. The following data structure contrasts the four dominant approaches for agent discovery, evaluating their operational mechanisms, principal advantages, limitations, and ideal deployment contexts based on current industry specifications.

Resolving Matchmaking System Degradation

A pervasive issue in legacy architectures is the persistence of stale capability registrations, which directly leads to excessive search traffic, routing failures, and failed task delegations. Centralized and federated registries attempt to mitigate this by requiring time-to-live values or active keep-alive signals from registered agents14. However, a network keep-alive merely confirms host presence, not the availability of specific computational capabilities. Modern protocols address capability availability through active subscription and event-driven architectures. By utilizing standard bindings like Server-Sent Events or JSON-RPC notifications, client agents can open a continuous listening stream. When a peer's availability degrades or its authorized toolset changes, the server emits a structured notification, allowing the client to instantly invalidate its local cache and seamlessly reroute its operational logic to a fallback agent7. To combat misleading descriptions, architectures must move beyond natural language semantic matching or simple ontology tags, which can be easily manipulated by malicious or poorly programmed agents to attract unwarranted transaction traffic. The integration of World Wide Web Consortium Verifiable Credentials shifts the burden of trust from the agent's self-advertised text manifest to a trusted cryptographic issuer18. If an agent claims the capability to execute high-value financial settlements, the matchmaking process does not evaluate the textual description; it evaluates the cryptographic signature of the financial authority that issued the capability credential. Incompatible capability vocabularies remain a significant friction point in cross-domain matchmaking. When agents utilize disparate semantic ontologies, exact matching fails. Solutions involve utilizing intermediate mapping agents or leveraging hybrid semantic service matchmaking, where an exact match is prioritized, but if unavailable, the system falls back to semantic proximity scoring using embedded representations of the capability descriptions26. Circular discovery—where federated nodes continuously refer a querying agent to one another without resolution—is mitigated by embedding query TTL counters in the search protocol payload, forcing the query to terminate after a set number of hops, and by enforcing strict trust-root scoping that limits the query boundaries to specific organizational domains1.

Recommended Design: Verifiable Capability-Based Discovery

To eliminate unnecessary human intervention while preserving explicit authorization boundaries, machine-to-machine systems require an architecture that merges the standardized interface declarations of the Agent-to-Agent and Model Context protocols with the cryptographic rigidity of Decentralized Identifiers and Verifiable Credentials. The recommended design relies on a two-tiered Portable Capability Record and an automated, cryptographically validated selection process that generates understandable rejection reasons.

The Portable Capability Record Structure

The Portable Capability Record serves as the standard representation of an agent. It is structurally inspired by the Agent-to-Agent Agent Card and the Web of Things Thing Description, but mathematically anchored to a Decentralized Identifier document. To protect proprietary logic, limit attack surfaces, and enforce zero-trust principles, the record strictly partitions metadata into public and authorized segments8. The public metadata segment serves as the Introduction Layer. This segment is freely available via an unauthenticated .well-known endpoint or published directly to a public Distributed Hash Table. It contains only the minimal information necessary for network routing and basic capability identification. The public segment includes the agent's Decentralized Identifier, which serves as its globally unique identity. It declares the organizational trust root vouching for the agent, providing an immediate context of ownership. The public record also lists the network endpoints for supported protocol bindings, such as HTTPS or gRPC, and high-level capability uniform resource names representing general skills. Finally, it explicitly declares the supported cryptographic authentication schemes required to access further information. The authorized metadata segment serves as the Exploration Layer. This segment is accessible only after the requesting client agent authenticates using the schemes declared in the public metadata and proves its authorization to view detailed operational schemas. The authorized segment contains strict JSON Schema definitions of expected input and output parameters, mirroring the structural requirements of the Model Context Protocol12. It details resource limits, availability quotas, latency service-level agreements, and dynamic pricing structures. Crucially, the authorized segment houses an array of Verifiable Credentials, representing the cryptographic proofs attesting to the agent's specialized capabilities, regulatory compliance status, or execution environment integrity18. It also includes provenance uniform resource identifiers pointing to content-addressed artifacts that guarantee the reproducibility of the agent's logic and training lineage18.

The Autonomous Selection Process

When an autonomous agent queries a directory or a hash table for a capability, it typically receives multiple candidate records. The selection pipeline must evaluate these candidates algorithmically without requiring human supervision to browse a directory or interpret capabilities6. The pipeline follows four distinct, sequential state transitions. First, the client performs a Syntactic Match, filtering candidates based on the presence of the required capability uniform resource name and mutually compatible protocol bindings derived from the public metadata segment7. Second, the client initiates Schema Validation. It authenticates, requests the authorized metadata from the surviving candidates, and evaluates the input schema to ensure it possesses the requisite data structures to invoke the tool12. Third, the client executes Cryptographic Verification. It extracts the presented Verifiable Credentials from the candidate's manifest, verifies the issuer's signature against a public key registry, checks cryptographic revocation lists, and validates that the credential specifically authorizes the requested task18. Finally, the client performs Constraint Optimization, evaluating the surviving candidates against resource limits, historical reliability, and cost constraints to select the primary target, caching the runner-up candidates as fallbacks. To prevent circular discovery loops and operational ambiguity, rejected interactions must return highly specific, standardized rejection reasons. The protocol distinguishes between an ExtensionSupportRequiredError, indicating the client lacks a protocol extension required by the server; a SchemaMismatchError, indicating the client cannot satisfy the required JSON Schema; and a CredentialVerificationFailed error, indicating the agent's cryptographic proof is invalid, expired, or revoked8.

Concrete Example: Logistics Discovery, Selection, and Fallback

Consider an autonomous Supply Chain Orchestrator Agent acting as a client. It is tasked with dynamically rerouting a shipment containing sensitive materials and requires a Routing Optimization Agent with a specific regulatory clearance level. During the discovery phase, the Orchestrator Agent queries a federated Agent Name Service for the capability under the specific trust root of a global logistics consortium1. The naming service returns the public metadata for three candidates: Agent Alpha, Agent Beta, and Agent Gamma. The Orchestrator Agent connects to all three candidates, authenticating via its own Decentralized Identifier, and requests their authorized metadata for exploration. Agent Alpha returns its detailed schemas. The Orchestrator Agent analyzes Agent Alpha's input schema and discovers a required string parameter for a hazardous material certificate that the Orchestrator Agent does not possess in its current context. The Orchestrator Agent logs a SchemaMismatchError and autonomously rejects Agent Alpha without human intervention. Next, Agent Beta returns its metadata, including a Verifiable Credential claiming active regulatory compliance for handling sensitive logistics. The Orchestrator Agent checks the credential's signature against the issuing regulatory authority's decentralized registry and discovers the credential has been placed on a status revocation list19. The Orchestrator Agent logs a CredentialVerificationFailed error and rejects Agent Beta. Agent Gamma provides a compatible input schema, valid and unrevoked credentials, and acceptable latency limits. The Orchestrator Agent successfully selects Agent Gamma as the primary execution peer. The Orchestrator Agent initiates the task using JSON-RPC over an active Server-Sent Events connection to track continuous task lifecycle state transitions7. Mid-execution, Agent Gamma experiences a critical backend system failure causing its availability to change. Because the architecture supports active state management notifications, the connection is cleanly severed with a specific provider offline exception, rather than hanging indefinitely and locking the Orchestrator Agent's processing thread12. The Orchestrator Agent immediately consults its cached, pre-validated list. Because Agents Alpha and Beta were rejected for hard constraints, the Orchestrator Agent autonomously triggers a broader discovery query with relaxed quality-of-service parameters, or initiates a Contract Net Protocol broadcast to nearby edge nodes to recruit an emergency fallback, ensuring the shipment is rerouted without requiring a human operator to intervene30.

Addressing Human Prerequisites and System Transferability

While this architecture eliminates routine operational intervention, it is critical to identify the remaining human prerequisites. Human engineers and domain experts must still define the root organizational policies, establish the initial Decentralized Identifier trust anchors, and define the governance frameworks that dictate which external credential issuers are trusted by the organization. Furthermore, in accordance with Model Context Protocol guidelines regarding trust and safety, certain high-risk tools—such as those executing financial transfers or altering physical infrastructure—retain explicit human-in-the-loop requirements, manifesting as confirmation prompts required before the machine-to-machine transaction can clear12. This recommended design transfers seamlessly to other machine-to-machine systems because it is built upon transport-agnostic, standardized primitives. By separating the discovery mechanism from the execution context, a manufacturing agent utilizing the Web of Things protocol bindings can utilize the exact same capability record structure and cryptographic verification flow as a large language model utilizing the Model Context Protocol to execute a software build process. The architecture does not assume that the communication infrastructure performs reasoning; it strictly treats the network as a verifiable conduit for capability exchange. Furthermore, because trust is anchored in cryptography rather than physical network boundaries, independent systems can interoperate securely without requiring a mandatory central operator or a unified cloud provider.

Prioritized Feature Proposals

To realize this decentralized, verifiable architecture across independent ecosystems, system implementers must prioritize three specific infrastructural features. These proposals eliminate unnecessary human prerequisites, establish secure protocol boundaries, and provide robust failure handling. The following data structure details the problem, agent-visible behavior, expected benefit, dependencies, implementation effort, and principal failure modes for each proposed feature.

Practical Adoption Sequence, Unresolved Questions, and Success Criteria

Transitioning the software industry from static integrations to dynamic, capability-based machine-to-machine discovery requires a phased adoption sequence that builds foundational trust while progressively eliminating human bottlenecks and legacy architecture.

Practical Adoption Sequence

The first phase of adoption focuses on manifest standardization to achieve syntactic interoperability. Organizations must adopt standard machine-readable representations of capabilities, deploying Agent Cards and tool schemas at well-known URLs across their infrastructure7. This establishes baseline syntactic discovery on local networks and internal enterprise catalogs without requiring massive overhauls of existing security models. The second phase involves directory federation and the deployment of introduction networks. Organizations implement Thing Description Directories internally to aggregate the manifests created in the first phase13. Subsequently, they begin bridging these independent directories using federated Agent Name Services to allow cross-departmental and limited cross-organizational discovery, relying on existing public key infrastructure for baseline transport security21. The third phase shifts the architecture toward cryptographic identity and zero-trust authorization. Organizations replace basic access keys with Decentralized Identifiers. They mandate that all high-risk capabilities require the real-time presentation of Verifiable Credentials before releasing detailed JSON schemas or accepting task delegations18. This phase completely divorces capability authorization from network location. The final phase achieves full decentralization and hardware attestation. The network shifts from federated catalogs to trust-root scoped distributed hash table routing. Organizations introduce Verifiable Execution Traces to mathematically prove that an agent's computational execution matches its capability claims, binding the software identity to secure hardware enclaves1.

Unresolved Architectural Questions

Despite rapid standardization across the industry, several critical challenges remain unresolved in machine-to-machine ecosystem research. Cross-ontology semantic interoperability is a persistent hurdle. While strict schemas define exact data structures, agents across different industries frequently use different terminologies for identical concepts. Determining how an agent can autonomously translate an unknown schema requirement without incurring the unacceptably high latency of invoking a large language model for semantic mapping during the routing phase remains computationally difficult. Dynamic financial settlement presents another unresolved challenge. When fallback agents are dynamically recruited during a network failure, resolving real-time pricing disputes and ensuring the non-repudiation of machine-to-machine micropayments without relying on a slow, centralized ledger remains an ongoing structural hurdle. Furthermore, global logout and session invalidation across highly distributed systems is complex. Establishing a unified global session management protocol that can instantly cascade credential revocations across all active protocol bindings and immediately halt in-flight agent tasks is theoretically complex and operationally fragile under high network latency19.

Measurable Success Criteria for Future Implementers

To objectively evaluate the efficacy of newly implemented machine-to-machine discovery systems, developers must rely on strictly measurable performance indicators rather than subjective assessments of autonomy. The following data structure defines a comprehensive suite of success criteria for architectural implementation.

By implementing a two-tiered discovery mechanism—where public introduction is routed via distributed hash tables, and detailed exploration is gated by strict cryptographic capability attestation—architects ensure privacy, mitigate cross-organizational pollution, and mathematically prevent unauthorized task execution. As organizations adopt standardized state-recovery signaling and verifiable execution traces, the autonomous computing landscape will successfully transition from fragile, point-to-point application programming interface integrations into a fluid, highly resilient, global computing fabric capable of verifiable coordination.

Works cited

1. Agent Identity URI Scheme: Topology-Independent Naming ... \- arXiv, https://arxiv.org/html/2601.14567v1

2. Agent Based Software Development \- SlideServe, https://www.slideserve.com/enye/agent-based-software-development

3. (PDF) Standardizing Agent Interoperability: The FIPA Approach, https://www.researchgate.net/publication/225131620\_Standardizing\_Agent\_Interoperability\_The\_FIPA\_Approach

4. Österreichisches Forschungsinstitut für / Austrian Research Institute, https://www.ofai.at/papers/oefai-tr-2007-09.pdf

5. FIPA: Specifying Protocols for Multi-Agent Systems Interaction, https://dpsframework.org/essays/poslad/2007-11-01-Poslad\_en.html

6. Toward Intelligent Skill Discovery in A2A via Fine-Tuned Small, https://publications.hevs.ch/index.php/attachments/single/2007

7. The A2A Protocol Explained | How AI Agents From Different Vendors, https://www.scaler.com/topics/a2a-protocol/

8. Agent2Agent (A2A) Protocol Specification, https://a2a-protocol.org/latest/specification/

9. Model context protocol (MCP) \- OpenAI Agents SDK \- GitHub Pages, https://openai.github.io/openai-agents-python/mcp/

10. Model Context Protocol (MCP) Tool Descriptions Are Smelly ... \- arXiv, https://arxiv.org/html/2602.14878v3

11. MCP-Zero: Active Tool Discovery for Autonomous LLM Agents \- arXiv, https://arxiv.org/html/2506.01056v3

12. https://modelcontextprotocol.io/specification/2026-07-28/server/tools

13. Web of Things (WoT) Discovery \- W3C, https://www.w3.org/TR/wot-discovery/

14. Discovery | Eclipse LMOS, https://eclipse.dev/lmos/docs/lmos\_protocol/discovery/

15. Web of Things (WoT) Architecture 1.1 \- W3C, https://www.w3.org/TR/wot-architecture11/

16. What is Web of Things (WoT) \- ITU Online IT Training, https://www.ituonline.com/tech-definitions/what-is-web-of-things-wot/

17. Web of Things (WoT) Discovery \- W3C, https://www.w3.org/TR/2020/WD-wot-discovery-20201124/

18. Agent Graph Trust Protocol (AGTP) 2.1, https://agtp.cc/

19. Agentic AI Identity and Access Management: A New Approach, https://cloudsecurityalliance.org/artifacts/agentic-ai-identity-and-access-management-a-new-approach

20. Global AI Agent Identification and Governance Framework (GAID), https://opendigitalproductfactory.com/architecture/GAID/

21. Cross-Organization AI Agent Federation: Trust, Discovery, and, https://zylos.ai/research/2026-03-01-cross-org-ai-agent-federation/

22. Towards Host-Independent Autonomy via Verifiable Execution Traces, https://www.researchgate.net/publication/398850624\_VET\_Your\_Agent\_Towards\_Host-Independent\_Autonomy\_via\_Verifiable\_Execution\_Traces

23. TessIndex: Capability Verified Identity System for the Agent Economy, https://arxiv.org/html/2608.21942v1

24. W3C Semantic Agent Communication Community Group \- GitHub, https://github.com/slashlifeai/agent-ontology

25. Scalable and Practical Verification of AI Autonomy \- OpenReview, https://openreview.net/pdf/3f6735f378d62f71825b8ce4a53b05988ac364a1.pdf

26. STC: Semantic Taxonomical Clustering for Service Category Learning, https://arxiv.org/pdf/1303.5926

27. Semantic-based Adaptation of Quality of Experience in Web, https://www.researchgate.net/publication/371394785\_Semantic-based\_Adaptation\_of\_Quality\_of\_Experience\_in\_Web\_Multimedia\_Streams

28. A Proof-of-Concept Trust Layer for Secure AI Agent Discovery ... \- arXiv, https://arxiv.org/pdf/2604.26997

29. How to Monitor Multi-Agent AI Workflows | LogicMonitor, https://www.logicmonitor.com/blog/googles-agent-to-agent-a2a-protocol-is-here-now-lets-make-it-observable

30. index — Agent Communications, https://agent-comms.anuna.io/

31. draft-somoza-dmsc-atn-agent-trust-negotiation-00 \- IETF Datatracker, https://datatracker.ietf.org/doc/html/draft-somoza-dmsc-atn-agent-trust-negotiation-00

32. Siemens feedback on implementing a Thing Description repository, https://semweb.pro/conference/2021/presentation/siemens-feedback-on-implementing-a-thing-description-repository/