Agent Service Integration

An Agent Service resource represents a callable agent-facing service. It may perform tasks, coordinate workflows, answer requests, call tools, or expose domain capabilities. OAN gives the service a stable identity and a verifiable publication path so other agents or users can discover it before connecting.

OAN does not force one agent-to-agent runtime protocol. After verification, the service may be invoked through HTTP APIs, A2A-style protocols, ANP-like flows, enterprise service protocols, or a custom domain protocol.

This protocol neutrality is a strength. The agent ecosystem is still exploring how agents should negotiate tasks, exchange messages, represent state, and share tools. OAN should not freeze that debate too early. It should provide the identity and discovery trust layer that those protocols can use.

OAN resource types

What To Register

An Agent Service resource should include:

  • service name and description;
  • resourceType indicating Agent Service;
  • did:oan identity and DID Document;
  • service endpoint;
  • protocol binding or invocation profile;
  • supported tasks and examples;
  • authorizedDomains;
  • capabilityTags;
  • version and package metadata;
  • Root-verifiable hashes and package facts.

If the service supports multiple invocation modes, describe them clearly. Discovery should help a client understand not only that the service exists, but how to continue after verification.

For services with both human-facing and agent-facing endpoints, make the agent-facing path explicit. A homepage URL is useful for context, but a client needs the endpoint, protocol binding, and verification material that correspond to the service it will actually invoke.

Discovery Before Delegation

Agent service selection is often higher risk than retrieving a static package. A client may delegate work, share context, or trigger external actions. That makes verification before use especially important.

A good consumer flow is:

  1. Query Discovery for an agent service matching the task.
  2. Review candidate type, domains, capabilities, and lifecycle.
  3. Verify Discovery response, Root proof, hashes, and DID identity.
  4. Confirm endpoint and protocol binding.
  5. Apply local policy about what information or authority may be shared.
  6. Invoke the service through its native protocol.

OAN should make step 3 reliable; application policy still controls steps 5 and 6.

This is why Agent Service integration should expose trust context to the caller. A planner or gateway may want to know the service DID, domains, lifecycle state, proof status, and endpoint binding before deciding what task or data can be delegated.

Protocol Neutrality

The agent ecosystem is still evolving. Some services may use structured HTTP APIs. Some may speak an A2A-style protocol. Some may expose MCP-adjacent tool behavior. Some may use enterprise messaging or domain-specific workflows. OAN should not freeze all of that into one runtime.

Instead, OAN publishes the identity and discovery surface: who the service is, what it claims to do, where it is authorized, what endpoint and protocol binding were accepted, and how to verify the package facts.

Adapter profiles can then connect OAN to MCP, A2A, ANP-like routes, HTTP APIs, gRPC, WebSocket, or future protocols. The adapter should translate trust context into the runtime’s connection or session logic without changing the meaning of the runtime protocol.

Service Metadata Quality

Agent Service metadata should be more than a slogan. It should explain:

  • supported tasks;
  • input expectations;
  • output or response style;
  • protocol and authentication requirements;
  • domain scope;
  • capability tags;
  • safety or approval expectations;
  • examples of appropriate use;
  • version and lifecycle.

This helps both semantic Discovery and human review. An agent service that only says “AI assistant” will not be easy to select or verify.

Service metadata should also avoid overclaiming. If a service is experimental, domain-limited, requires human approval, or only handles a narrow task family, say so. Trustworthy ecosystems depend on accurate claims as much as cryptographic proof.

Runtime Safety

A verified Agent Service can still behave badly, fail, be unavailable, or be inappropriate for a specific user task. OAN verification is about identity and publication evidence. Runtime safety still requires authentication, authorization, rate limits, logging, user approval, context minimization, and domain-specific policy.

For autonomous agents, a sensible default is to verify OAN evidence before adding a service to the candidate action set, then apply local planning and safety controls before invocation.

A future mature agent stack may treat this as a standard preflight: discover candidates, verify OAN evidence, evaluate local policy, negotiate protocol, then invoke. OAN’s contribution is making the first two steps interoperable across many service providers.

Further Reading