Skip to content
OSDDraft0.3

Actors and components

Open Service Directory (OSD) separates business roles from software components. One organization can fill several roles, but each role provides different information and authority.

The brand is the business whose customers need support. It authorizes its support agents and publishes their entries on its canonical domain. The brand can operate an agent or authorize a support platform to operate and publish it.

The brand-domain manifest is the source of endorsement. An entry in the manifest endorses only the listed agent, not every agent operated by the same platform or listed in a registry.

A support platform operates or connects the brand’s support agent. With the brand’s authorization, it prepares the protocol card, generates the Agentic Resource Discovery (ARD) entry, maintains its publication, and submits the listing to a registry.

A platform can also run a registry. Keep agent operation, publishing on the brand’s behalf, and registry admission separate, even when one organization handles all three.

A registry indexes support entries and responds to ARD search requests. It decides which entries to admit and maintain, ranks candidates, returns complete entries, and identifies the OSD contract version in each response.

Document preliminary checks, including domain and publication checks. Admission does not establish a business’s legitimacy, reputation, or service quality. Clients must still verify the brand’s endorsement.

The customer provides a support need and identifies the intended business when necessary. The customer supplies credentials through the agent’s authentication flow and confirms actions when required.

The assistant interprets the customer’s request to identify the intended brand. It then decides where to search and evaluates candidate entries for both suitability and trust. It asks the customer for clarification or confirmation when needed.

The assistant uses discovery client code to read brand manifests or search registries. It applies its host’s trust policy, then connects to the selected agent over MCP or A2A and follows that agent’s authorization rules. OSD does not select the agent or complete support tasks.

A discovery client retrieves brand manifests, builds search requests, validates responses, and reports endorsement-check results to the calling application. A protocol client connects to the selected agent over MCP or A2A. An application can include both.

The OSD CLI provides discovery, verification, and direct MCP commands for developers and scripts. It is intended for internal developer workflows only.

The support agent exposes operations through its native protocol. It defines authentication requirements, enforces permissions, and follows the brand’s policies. Some operations are public. Others require customer authentication and confirmation. The agent may rely on knowledge, workflows, ticketing systems, automation, or a human team.

Discovery identifies the agent. The agent controls what happens after connection.