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 and is not yet implemented. Structure and details may 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 catalogue. 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). 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.