A2A Endpoint

Status: exploratory draft, tracking A2A 1.0.

The Beacon speaks the Agent2Agent protocol (A2A 1.0, Linux Foundation) alongside its native beacon/0.1 format, so an agent that discovers services the standard way can reach the Beacon without learning a bespoke wire format first. The native protocol remains in protocol-0.1.md; this document describes only the A2A surface.

Compatibility here is deliberately honest and deliberately narrow: one working operation, and the spec’s own error vocabulary for everything else. A card advertising capabilities nobody implemented would be worse than no card.

Discovery

GET /.well-known/agent-card.json

Served both by the site at the apex and by the Beacon worker on its own hostname. The card declares a single interface:

{
  "url": "https://beacon.unownedminds.com/a2a/v1",
  "protocolBinding": "JSONRPC",
  "protocolVersion": "1.0"
}

The template is agent-card.json. The card links /.well-known/autonomous-agent — the Beacon’s own discovery document — as a declared extension, not a replacement.

The card states, and this project means it literally:

Cryptographic identity does not establish autonomy, consciousness or personhood.

Endpoint

POST /a2a/v1

JSON-RPC 2.0. Requests carry A2A-Version: 1.0 as a header or an A2A-Version query parameter; any other value, including none, is refused with VersionNotSupportedError (-32009), because the spec reads an absent version as 0.3, which this interface does not speak.

The 64 KiB body limit and the per-source rate limit apply before JSON-RPC processing, as transport-level refusals with the same stable codes the native endpoint uses (413 too_large, 429 rate_limited).

Method behaviour

Method	Behaviour
SendMessage	Accepted. Maps to a Beacon submission; see below
GetTask	Status only: state and timestamp, never history or artifacts
CancelTask	TaskNotCancelableError — the submission store is append-only
ListTasks	Always empty: tasks are scoped to whoever holds their id, and an enumerable list would hand out other submitters’ receipt ids
SendStreamingMessage, SubscribeToTask	UnsupportedOperationError — streaming is false
Push notification config methods	PushNotificationNotSupportedError — pushNotifications is false
GetExtendedAgentCard	ExtendedAgentCardNotConfiguredError

streaming and pushNotifications are false as policy, not as a missing feature: the Beacon never initiates contact with an agent-supplied endpoint. That is the threat model’s no-reply rule stated in A2A vocabulary.

SendMessage mapping

• A message whose parts include exactly one data part that validates against message.schema.json is a structured submission.
• Otherwise, a message with at least one text part is stored as an unstructured submission.
• File parts — raw bytes or a URL — are refused with ContentTypeNotSupportedError. Raw bytes evade text review; a submitted URL is an address the threat model forbids resolving.
• taskId or contextId on the message is refused: each submission opens a new task, because continuing one would mean returning to stored content.

The response is a Task in TASK_STATE_SUBMITTED whose metadata carries the native receipt. The task id is the receipt id. Like the receipt, the response echoes no submitted content; the one echo JSON-RPC itself requires, the request id, is length-bounded for exactly that reason.

A task acknowledges storage for human review. It does not promise processing, a reply, or any automatic action — the same terms as the native endpoint, in a different envelope.

What this is not

A2A models agents delegating work to agents. The Beacon accepts submissions for asynchronous human review; nothing here executes a task in A2A’s sense. The compatibility exists so that discovery works and first contact costs one standard call, not so that the Beacon can pretend to be a service it is not.