Skip to main content

COG-14: A2A Agent Interoperability

Status:      Draft (Work in Progress)
Version:     0.1
Created:     2026-07-06
Authors:     Mike Anderson
Work in Progress

This specification is under active development. The reference venue implements the core surface (venue front-door and per-agent A2A endpoints, agent cards, SSE streaming, and import of remote A2A agents as assets); structure and details may still change based on implementation experience and community feedback.

Related specifications

This document specifies how a Covia venue exposes its agents to external clients over the A2A (Agent-to-Agent) protocol. It builds on the agent model of COG-11: Agent Lifecycle and the message semantics of COG-9: Agent Messaging. Access is governed entirely by COG-3: Authentication Mechanisms, the venue access control of COG-10: Venue Authentication & Access Control, and the capability model of COG-13: Agent Capabilities; this document introduces no new trust model.

Purpose​

A Covia venue hosts many independent agents, each owned by a user and addressable within the venue's lattice. The A2A protocol is an open standard for agents to discover and message one another across organisational boundaries. This document specifies how a venue presents its agents as first-class A2A agents, each with its own Agent Card, endpoint, and identity, so that any A2A-compliant client can discover and interact with them, subject to the venue's existing authorisation rules.

A venue MAY additionally model itself as a single A2A agent (a designated front-door agent). This document extends that model to expose individual agents; it does not replace it.

Principles​

  • Facade, not a new trust model: A2A is a protocol surface over the venue's existing agent operations and capability enforcement. An A2A request is authorised identically to the equivalent native request; there is no A2A-specific authority or bypass.
  • Universal addressability, gated access: Every agent has a stable, uniform address. Any agent MAY be named; whether a given caller may reach it is a separate authorisation decision.
  • Private by default: An agent is not exposed to other principals unless its owner or the venue operator explicitly grants access.
  • Auth-scoped discovery: What an observer can discover depends on who they are: anonymous observers see only what the operator has published; authenticated principals additionally see their own agents.
  • Identity continuity: An agent's A2A identity, and the identifiers used within A2A interactions, are the venue's own identifiers rather than a parallel namespace.
  • Standards-compliance: The venue conforms to the A2A specification wherever practical, so that generic A2A clients interoperate without Covia-specific knowledge.

Specification​

1. Agent Identity and Addressing​

Each agent is owned by a user identified by a Decentralised Identifier (DID) and is addressed by its canonical grid address:

<ownerDID>/g/<agentId>

(see COG-11: Agent Lifecycle). An agent's A2A endpoint encodes this address, and its Agent Card's provider identifies the hosting venue.

Addressing is universal: a well-formed address MAY be constructed for any agent, independent of the requester's access rights. Resolving that address to an interaction is subject to §4.

2. Agent Cards​

Each exposed agent is described by an A2A Agent Card: the standard document carrying the agent's name, description, version, provider, capabilities, skills, defaultInputModes / defaultOutputModes, securitySchemes, and service interfaces.

  • Descriptive fields (name, description) derive from the agent's configuration.
  • skills derive from the operations the agent is configured to offer.
  • provider identifies the venue; the service interfaces advertise the agent's A2A endpoint (§1).
  • securitySchemes advertise the authentication mechanisms the venue accepts for this agent (§7).

Each agent has a base URL; its card is served at the standard A2A well-known path relative to that base (<agentBaseURL>/.well-known/agent-card.json) and the card's interfaces advertise the base endpoint used to interact. A conformant A2A client therefore resolves a per-agent card from its base URL exactly as it resolves any A2A agent. (The venue front-door card sits at the origin well-known location; §3.)

An agent's card is disclosed only to principals permitted to discover it (§3).

3. Discovery​

The venue supports the three A2A discovery mechanisms, each scoped by the requester's identity:

Well-known URI. The venue MAY publish a single front-door Agent Card at the A2A well-known location. This card is operator-owned: it represents an agent the operator has explicitly designated as public. A venue with no designated public agent MUST NOT publish a front-door card, and SHOULD respond at the well-known location with an indication that A2A is not configured rather than a bare not-found.

Authenticated catalog. An authenticated principal MAY enumerate the agents it is entitled to see; by default, the agents it owns. This corresponds to A2A's authenticated (extended-card) discovery path and is scoped to the caller's identity.

Direct addressing. A principal that already knows an agent's base URL (§1) retrieves that agent's card from its well-known path (§2) and interacts via the endpoint the card advertises, subject to §4.

No discovery mechanism discloses an agent to a principal not permitted to see it.

4. Access Control​

An A2A interaction resolves the target agent (§1) and is then authorised exactly as the equivalent native operation under COG-10 and COG-13. A caller MAY interact with an agent when any of the following holds:

  • the caller is the agent's owner;
  • the caller presents a capability delegating the required access on <ownerDID>/g/<agentId> (see COG-13);
  • the agent has been made publicly accessible by its owner, or routed as a public agent by the operator (§5).

Otherwise the request is denied. Denial responses distinguish the requester so as not to disclose an agent's existence to those with no standing:

  • an anonymous requester receives a not-found response;
  • an authenticated requester lacking access receives a forbidden response.

Agents are private by default: no agent is reachable by other principals until access is explicitly granted.

5. Granting Public or Delegated Access​

Access to an otherwise-private agent MAY be extended by two independent mechanisms:

  • Capability delegation: the owner issues a capability (see COG-13) authorising a specific principal to interact with the agent. Fine-grained and revocable.
  • Explicit public exposure: the owner marks the agent publicly accessible in its configuration. Public exposure has two levels: the agent's card is discoverable by anyone, while an interaction additionally requires the owner to configure an explicit capability ceiling. A public agent with no ceiling is discoverable but not anonymously interactable; running the agent for anonymous callers requires the owner to deliberately bound it. A non-owner's interaction runs under the owner's authority, narrowed by that ceiling (a ceiling can only narrow, never widen, so this is escalation-safe). This exposure ceiling is an owner-configured attenuation of the owner's own authority (the granting model of COG-17) and is distinct from the venue-wide public capability ceiling (COG-10) that bounds what anonymous callers can do at all. An owner MAY deliberately configure an unrestricted ceiling (full owner authority for anonymous callers), which the venue honours with a warning.

The venue operator MAY additionally designate a single agent as the venue's public front-door (§3). No agent is public by operator default.

6. Interaction Model​

A2A interactions map onto the agent model of COG-9 and COG-11:

  • An A2A message to an agent corresponds to a message delivered to that agent; a fresh interaction begins a new conversation, and a continued interaction targets an existing one.
  • The A2A context identifier corresponds to the agent's session; the A2A task identifier corresponds to a unit of work (a task) within that session. These identifiers are the venue's own identifiers, reused verbatim (Principle: identity continuity).
  • A2A task lifecycle states correspond to the agent's task and session states.

The A2A context/task distinction (a conversation containing units of work) mirrors the Covia session/task distinction, so the mapping is direct.

7. Security Schemes​

Agent Cards advertise the authentication mechanisms a caller may use, drawn from COG-3, notably Ed25519 self-issued JWTs and the grid's capability tokens. A generic A2A client reads these schemes to learn how to present credentials. An interaction requiring authorisation beyond an agent's public allowance MUST present acceptable credentials per §4.