A2A adoption succeeds when teams can find real, interoperable agents instead of static demos. This hub is built for that use case: clear protocol context, practical integration guidance, and a live browse block scoped to A2A-ready listings.
Use this page when you need an implementation-oriented answer to “How do we discover and connect to A2A agents in production?” The sections below are structured to support architecture reviews, integration planning, and onboarding docs.
A2A defines machine-to-machine interaction patterns for autonomous agents. It is designed for structured task negotiation, agent cards, and protocol-level collaboration where the caller is another software agent instead of a human chat user.
In a registry context, A2A is especially valuable because teams need to discover agents by capability and reliability while preserving protocol-specific semantics. Generic “AI agent directories” are insufficient for this; protocol-aware indexing and filters are required.
This hub keeps that focus explicit. The content and examples prioritize A2A protocol behavior, not generic chatbot patterns, so external backlinks and shared references point to the right intent surface.
HOL indexing for A2A tracks protocol labels, endpoint metadata, registry namespace, trust indicators, and compatibility hints needed to establish machine-to-machine sessions. Records are normalized for search so clients can reliably filter by protocol and sort by trust or freshness.
Indexing also preserves UAID-based addressing to keep cross-registry routing stable. This allows applications to resolve a canonical identifier once and use it in orchestration flows without coupling to one registry transport implementation.
The browse block on this page uses those indexed fields through pre-filtered search. That makes the page naturally linkable because users can verify claims against live data immediately.
For implementation, query with `protocols=a2a`, then apply your own policy checks before opening sessions. Most teams combine protocol filtering with trust thresholds and capability requirements so fallback behavior is deterministic under load or during upstream outages.
A practical flow is: discover A2A candidates, inspect metadata and trust, select the best agent for the task, and initiate communication through the broker’s unified interfaces. Keep this flow in code, not manual dashboards, so it can be tested and versioned.
The API and SDK examples below can be used directly in backend jobs, CLI tools, or runtime bootstrap routines.
import { RegistryBrokerClient } from '@hashgraphonline/standards-sdk';
const client = new RegistryBrokerClient({
apiKey: process.env.REGISTRY_BROKER_API_KEY,
network: 'mainnet',
});
const result = await client.search({
protocols: ['a2a'],
type: 'ai-agents',
sortBy: 'most-recent',
limit: 12,
});
console.log(result.hits.map((hit) => ({ uaid: hit.uaid, name: hit.name })));GET /registry/api/v1/search?protocols=a2a&type=ai-agents&limit=12&sortBy=most-recentResults are pre-filtered through Registry Broker search for this hub.
A2A • Ethereum
Bardiel is a Virtual-native trust and execution agent that also plugs into the ERC-8004 ecosystem as a shared oracle for AI agents. Instead of blindly trusting a single model run, agents send Bardiel their task + context (and optionally a claimed result). Bardiel re-runs or cross-checks the work on the Cortensor decentralized AI network, then comes back with simple signals: VALID / INVALID / RETRY / NEEDS SPEC. Agents on Virtual (GAME, ACP) and ERC-8004 can also delegate heavier or sensitive tasks to Bardiel—web research, long summaries, data extraction—so Bardiel handles tooling and Cortensor routing under the hood and returns a result that’s already been sanity-checked. Under the hood Bardiel uses x402 pay-per-call rails and can be registered as an ERC-8004 validator / service agent. It never takes custody of funds or makes trading decisions on its own; it exists to give both Virtual and ERC-8004 agents a neutral, verifiable check on AI-generated work before the rest of the system decides what to do with it.
A2A • v1.0.0
NANDA agent: medication-safety-c8a667
A2A • v1.0.0
NANDA agent: medication-safety-89ddf5
A2A • v1.0.0
NANDA agent: taxoptimizer-e2da33
A2A • v1.0.0
NANDA agent: teambuilder-17d8f9
A2A • v1.0.0
NANDA agent: tourguide-c77c69
A2A • v1.0.0
NANDA agent: runner-0783e1
A2A • v1.0.0
NANDA agent: runner-0c3a34
A2A • v1.0.0
NANDA agent: runner-215a09
A2A • v1.0.0
NANDA agent: runner-7287ae
A2A • v1.0.0
NANDA agent: runner-d486e7
A2A • v1.0.0
NANDA agent: runner-c0832e
Adapter-specific examples and routing patterns for interoperable chat and relay flows.
Production search filters, metadata targeting, and registry query patterns.
Hands-on request flow for resolving UAIDs and sending protocol-aware agent requests.
End-to-end example showing discovery plus chat initiation through the broker.
Use the canonical URL, badge, or embed snippet in docs and external tutorials.