[Extension Proposal] Edge-cloud capability contract

[catyans]

Abstract

Propose an optional A2A profile/data extension that makes edge-cloud task placement constraints machine-readable. It lets an agent declare where it can execute, what data classifications and regions it accepts, expected latency/offline behavior, side-effect and idempotency semantics, and supported attestation/result-verification mechanisms. A caller activates the extension and attaches request-specific constraints; the callee either returns an execution receipt satisfying them or rejects the task before execution.

Motivation

The core protocol intentionally provides generic Agent Cards, security schemes, task lifecycle, and extension metadata. It does not define semantics for deciding whether a task may move from an edge site to a cloud region, whether a weak-network/offline execution mode is supported, or whether retrying a side-effecting task is safe.

Natural-language skill descriptions are not sufficient for a deterministic gateway or policy engine. The same task may be technically supported but prohibited because its input is restricted to a region, requires a device-local control loop, exceeds a latency bound, or lacks an acceptable verifier. These constraints are domain-specific and should not enlarge the core A2A types, so an extension is the appropriate mechanism.

The proposal complements MCP tool annotations: MCP describes tools available inside an agent boundary, while this A2A extension governs a cross-agent task placement and receipt. It does not replace TLS, A2A authentication/authorization, Agent Card signatures, or platform policy.

Initial technical approach

Extension URI (sample/incubation):

https://github.com/a2aproject/a2a-samples/extensions/edge-cloud-capability-contract/v1

The extension defines three JSON objects carried through existing A2A extension points:

1. CapabilityContract in AgentExtension.params
   • execution sites and regions
   • accepted data classifications
   • latency/offline ranges
   • side-effect class and idempotency support
   • supported attestation and deterministic verification methods
2. ExecutionRequirements in request Message.metadata[URI]
   • allowed sites/regions and data classification
   • max latency/network mode
   • idempotency key and required verification/attestation methods
3. ExecutionReceipt in response Message or Artifact metadata
   • selected site/region
   • contract version/digest
   • result digest, verifier status, and optional attestation reference

Normative rules:

• the server MUST validate requirements before causing declared side effects;
• absent activation, behavior remains core A2A;
• declarations are claims, not trust anchors; clients MUST apply local policy and SHOULD verify signed Agent Cards/attestations;
• raw credentials, private topology, and sensitive input data MUST NOT be placed in extension metadata;
• a repeated side-effecting request is only replay-safe when an idempotency key is supplied and the contract declares support;
• rejection uses existing A2A error behavior rather than inventing a parallel task state machine.

Reference sample

I plan to submit a small specification, JSON Schemas, and dependency-free validator to a2aproject/a2a-samples so the shape and fail-closed validation rules can be evaluated without changing the core protocol.

This proposal follows the extension lifecycle in docs/topics/extension-and-binding-governance.md; it requests discussion and, if the direction is useful, maintainer sponsorship for an experimental extension repository.