Discovery flow

During discovery, the assistant decides which business the customer means, where to look for its support agents, and whether a candidate fits the request. See How OSD works for the publishing-to-connection flow and Discover support for HTTP examples.

flowchart TD
    I["Identify the brand and support need"] -->|Known domain| B["Retrieve and validate brand manifest"]
    I -->|Registry search| R["Receive candidate entries"]
    R --> V["Compare candidate with brand manifest"]
    V -->|Match| S["Assess suitability and select"]
    B -->|Valid manifest| S
    B -->|Unavailable or invalid| N["Retry or use another support route"]
    V -->|Mismatch or inconclusive| N
    S --> C["Read the card and connect to the agent"]

Identify the intended brand

The assistant starts with the customer’s request and context. An itinerary might identify Example Air for a cancelled flight. A request naming only a product or an ambiguous business may need clarification.

Mapping a brand name to its canonical domain is the assistant’s job. A candidate’s osd:brandDomain is a claim to check, not proof of the right business. Keep the discovery query to the brand and task. Customer records belong in the later, authorized interaction.

Obtain candidate entries

If the brand’s canonical domain is known, the assistant can retrieve and validate https://{osd:brandDomain}/.well-known/ard.json directly. Entries read from the intended brand’s validated manifest are endorsed by that publication.

Otherwise, search a configured registry by brand or support need. Request an exact OSD contract version, check the response’s declared version, and validate the body. Each result includes a complete entry, a relevance score, and the registry source. These are candidates to check, not proof of endorsement.

Consider entries that fit the task and use an artifact type the client supports. If none fits, refine the query or offer another support route.

Check endorsement and suitability

Compare each registry candidate with the intended brand’s manifest. Only a complete match counts. See the trust model for the comparison rule.

• Match: The complete entry matches a published entry. Assess whether the agent fits the task.
• Mismatch: The manifest is valid, but no entry matches. Do not treat the candidate as endorsed. Check another candidate or the brand’s published alternatives.
• Inconclusive: The manifest could not be retrieved or validated. Do not treat the candidate as endorsed. Retry the check or offer another support route.

Several endorsed agents can serve different needs. Choose one that fits the request under the host’s trust policy. If the brand or agent is still ambiguous, ask the customer before connecting.

Connect after discovery

Read the selected entry’s artifact through url or inline data and follow its protocol-specific connection details, such as an MCP Server Card or an A2A Agent Card. The agent handles authentication, operations, and customer permissions. The assistant obtains any confirmation the action requires. Changing a booking or opening a ticket happens over this connection. Discovery itself does not authenticate the customer or authorize those actions.