An interoperability test for federated agent registries

AWS separates discovery within an AWS environment from discovery across environments. Its announcement describes Agent Registry as AWS-environment discovery infrastructure and Agentic Resource Discovery, or ARD, as a shared specification spanning clouds, on-premises systems, SaaS platforms, and enterprise applications. AWS says ARD gives registries a common resource format and discovery protocol (AWS announcement).

That description does not establish that AWS Agent Registry implements ARD federation. It identifies two concepts and their intended scopes. Evidence that deployed registries interoperate must come from the implementations and topology under test.

The canonical ARD specification defines a JSON Schema entry, publication and ingestion semantics, registry search, and federation. It also identifies OpenAPI 3.1 interfaces for POST /search, POST /explore, and GET /agents; discovery through the predecessor well-known catalog path is optional (ARD specification).

The practical test is to follow one entry that exists only in a remote registry. Its path makes four different questions visible without turning them into one compatibility score.

Put one remote-only entry into motion

Begin with a valid ARD entry and a deliberately invalid variant. Submit each through the publication interface exposed by the source registry. Capture the submitted payload, response, and resulting stored state.

Schema validation alone shows only whether the entry satisfies the tested schema. Publication evidence requires an observed transaction and outcome. Acceptance and storage are separate observations and should not be inferred from schema validity.

Next, make the valid entry available to a second registry through the configured ingestion or federation path. Inspect what that registry receives, whether it validates or normalizes the entry, and whether an update to the same identity changes the available representation. A rejection can be assessed against a specification requirement only after the behavior is mapped to the applicable clause and revision.

Now query the source registry directly. Exercise POST /search, POST /explore, and GET /agents separately where the implementation exposes them. Use queries that cover an exact match, an omission, a filter, and two entries with similar discovery attributes. The predecessor well-known catalog path is optional, so its absence alone does not demonstrate failure of mandatory ARD behavior (ARD specification).

Finally, issue the same queries through the second registry. The remote-only entry forces the implementation to do more than return local data. Capture the path taken, each response, the final result, and any failure surfaced to the client.

A pass at one step does not answer the next question. A schema-conforming entry may never be accepted. An accepted entry may never reach another registry. A successful local query does not show remote traversal. A remote result demonstrates the tested exchange, not universal interoperability.

Read contrasting outcomes before assigning meaning

Run the remote query under several conditions: with both registries available, with the remote registry unavailable, with overlapping local and remote entries, and after updating the source entry. These changes expose how the implementation behaves when federation is no longer a clean success path.

The resulting observations may include rejection, duplication, merging, delay, or omission. None is automatically a conformance finding. For example, if the initiating registry omits an entry that remains present at the source, the test establishes an omission under that configuration. Whether the omission violates ARD depends on the applicable federation semantics.

Freshness requires the same restraint. If an update appears through one path before another, the run shows propagation behavior at that time. It does not establish a general synchronization guarantee unless the selected specification revision defines one and the test measures against it.

Keep the product version, enabled interfaces, authentication setup, schema revision, and topology attached to every outcome. Those details determine what was actually exercised. They also make disagreements diagnosable: the evaluator can compare the expected behavior for the selected contract with the request, response, and state that were observed.

Stop at the claim the run earned

The strongest defensible conclusion may be narrow: two named registry versions exchanged one remote-only entry through one configured topology. That statement does not cover malformed entries, updates, exploration, overlapping results, or partial failure unless those cases also ran.

The same limit applies to AWS. Agent Registry can be included as an implementation in this test, but AWS’s description of Agent Registry and ARD does not itself support the statement that Agent Registry implements ARD federation (AWS announcement).

For teams moving from architecture diagrams to working infrastructure, the next useful step is not to award a broad compatibility label. It is to choose a remote-only fixture, run it through the actual registry topology, and state only what that path demonstrated. That discipline belongs in any larger agent-system build.