Skip to main content

​
A2A federation model

A2A (Agent2Agent) federation lets an agent you run on Devotel Orbit be discovered and tasked by software outside your tenant — a partner’s support bot, a procurement agent on another platform, a coordinator agent you operate yourself elsewhere. Federation makes one Orbit agent a first-class citizen of the Agent2Agent protocol ecosystem without you standing up a second agent runtime. This page is the conceptual anchor for that surface: what federation is, which way traffic flows, how an external caller proves it may call, and where the feature deliberately stops. The endpoint-by-endpoint walkthrough lives in A2A federation.

​
Section 1 — What A2A federation is

An Orbit agent is, at rest, private to your tenant: you chat with it in the dashboard, a flow invokes it, or it answers a channel message — every one of those calls resolves through your authenticated session or your tenant’s channel configuration. Nothing outside your tenant knows the agent exists. Federation changes one thing: when you opt an agent in, Orbit publishes an AgentCard for it at a stable, well-known URL and opens a signed task endpoint next to it. The AgentCard is a machine-readable manifest — the A2A equivalent of a business card — describing the agent’s name, what it can do (its skills), which protocol version it speaks (A2A v1.0), the URL a peer tasks it on, and the authentication scheme a peer must use. Any A2A-conformant software that learns that URL can read the manifest, construct a request matching the skill catalog, and hand the agent a task. The property that makes the model work is that federation rides on the agent’s existing surface. The skills the card advertises are derived from the same tool list the agent already uses internally; a federated task exercises the same knowledge, guardrails, and execute path as a dashboard conversation. An external peer gets access to your agent as you configured it — nothing more, nothing less, and never to the underlying runtime. Three consequences flow from that:
  • Discovery is per agent. Each agent carries its own discovery setting. Federating your order-lookup agent exposes that agent only; every other agent in the tenant stays invisible.
  • Every call carries a tenant. The published URL pins the tenant it was minted for, so a peer’s fetch and task always resolve into the tenant the operator intended — there is no cross-tenant ambiguity at the boundary.
  • The contract is the protocol. A peer sees the skill catalog plus the task envelope — it can ask for a skill and poll a task, never inspect your knowledge base, read memory, or replay conversations.

​
Section 2 — Two delegation directions

Federation is bidirectional, and the two directions are independent — each is retrievable on its own and each appears in the per-tenant task ledger with an inbound or outbound direction marker. Inbound: an external agent calls your Orbit agent. A peer fetches the AgentCard, POSTs a task (JSON-RPC or the REST shorthand), and receives a task id; it then polls or subscribes for the result. The agent’s discovery mode has to allow public calls for the route to exist at all. This is the “make your agent callable from outside” direction, and it demands the inbound authentication described in Section 3. Outbound: your Orbit agent (or an operator) calls a remote peer agent. You register a peer by its AgentCard URL; Orbit fetches the peer’s card, caches its skill catalog, and can then delegate a task to it — either from the dashboard explicitly or from the agent as a handoff target. The outbound call signs its requests with the same signing discipline Orbit expects inbound. Inbound and outbound do not have to be enabled together. Many tenants publish one read-only retrieval agent inbound and never register a single peer; others use federation purely outbound, delegating to a partner’s exposed agent without publishing any card of their own.

​
Section 3 — Inbound authentication at a public boundary

The public federation endpoints are deliberately reachable without a Clerk session — an external agent has no dashboard login to present. That does not make them anonymous: a signed request is required, and the scheme is a spec-compatible API-key credential. The served AgentCard declares an API-key security scheme over the X-A2A-Signature header. The secret behind it is the tenant’s A2A HMAC secret — an Orbit-side signing key the operator obtains from the tenant and shares with each peer over their own channel (out of band, exactly as they would for an issued API key). A peer signs every task request with it:
Verification runs in constant time over the request’s exact raw bytes, with a ±60-second replay window — a stale timestamp or a single flipped byte in the body fails, and the verifier returns a fixed, operator-safe 401 that never discloses which check tripped. Because the credential is an Orbit-issued key, revocation is tenant-side: rotate the secret and every previous-credential signature stops verifying immediately. Two transports carry these credentials, identically authenticated — the canonical JSON-RPC 2.0 entry point and the REST shorthand for peers that don’t implement JSON-RPC. A signature failure carries no special treatment either way as far as the peer can tell. Idempotency. Once a peer holds an issued key, its residual failure mode is the retried submission — a retry loop that fires the same task twice. The convention on the public route is caller-supplied: attach a unique operation id per task (the Idempotency-Key the route accepts) and let the dedupe path collapse repeats into the task the tenant already accepted instead of a second execution. The key is optional; callers who omit it get at-least-once semantics and should poll the task by its returned id rather than blindly re-sending.

​
Section 4 — Configuring federation per agent

Federation is configured on each agent separately; nothing tenant-wide flips. The controls live on the agent’s own configuration:
  • Discovery mode (a2a_discovery_mode) governs which surfaces the agent is reachable on: disabled (the default — no public traffic answers), tenant (the card is served to authenticated dashboard sessions only, so a peer can be given the URL through an authenticated channel but the public manifest stays dark), or public (the card and task endpoints answer signed external callers).
  • The manifest. The AgentCard you publish is built from the agent’s ordinary configuration — its name, description, version, and skills derived from its tool list. There is no separate card editor to keep in sync: changing the agent’s tools changes its federated surface. When signing material is provisioned, the served card additionally carries a detached JWS signature so a peer can verify the manifest’s origin without sharing the HMAC secret.
  • Peers, for the outbound direction. A peer registration is a URL plus a fetched and cached copy of the peer’s AgentCard — re-adding the same URL refreshes the cache rather than duplicating the peer.
  • A share URL. The dashboard’s A2A tab mints a canonical URL with the tenant parameter baked in; that URL is the only artifact you hand to a peer, and its tenant component is validated against a strict schema-shape rule server-side so it cannot be coaxed into resolving a non-tenant schema.

​
Section 5 — What is not there yet

Veracity beats coverage on this surface; check the advertised capabilities before you build against a shape.
  • No streaming. The advertised capability set has streaming: false; task results arrive by poll (tasks/get), or by a pushNotification callback the peer attaches to individual tasks at send-time. SSE or token-level streaming (tasks/sendSubscribe) is not mounted.
  • A transport-only task stream. Inbound federation tasks a skill and returns a task envelope — it does not create a dashboard-visible conversation thread the way a chat session would, so plan your observability on the ledger rather than the chat surface. (Direction, status, and latency appear there.)
  • First-class manifests only for your own agents. Orbit discovers a peer by its published card, but federation does not auto-discover new peers on a network scan — your peer registry is the set you (or your configuration) explicitly added.
  • The public path is file-free. The skills and messages a peer receives are text/data parts; binary file transfers ride whatever URL the peer returns in its own payload, never an Orbit file store on the public route.
These are deliberate boundaries, not hidden gaps: if a capability that matters to an integration is not advertised on a served card, treat it as unsupported rather than quietly attempted.

​
Relationship to the rest of the agent surface

Federation composes with, but never bypasses, the platform’s other gates. An incoming task still hits the agent’s guardrails and knowledge access exactly as configured; peer additions and removals land in the tenant’s audit log; and the per-tenant ledger means the federated traffic is backup-able and reportable in the same store as your ordinary agent runs. Handoffs inside the tenant between co-owned agents use agent handoff targets and never touch federation — A2A is specifically the boundary where one agent calls another across trust domains.

​
See also

  • A2A federation → — the endpoint-by-endpoint reference: discovery modes, the task flows, the peer registry, and the error taxonomy.
  • AI agent architecture → — how skill execution and guardrails stack below the federated boundary.
  • Agent-to-agent OAuth and AP2 → — authorization mandates a federated transacting agent carries to prove it was authorized to act.
  • Hosted MCP server → — the other inbound-without-session surface: one curated, fixed tool catalog for external MCP clients, versus A2A’s per-agent skill catalogs.