[Extension Proposal] Edge-cloud capability contract

## 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.