[Protocol Question] Heartbeat-based agents: availability metadata and offline-first task handling

## Summary

The A2A spec handles long-running async tasks well, but doesn't address a common deployment pattern: **heartbeat-based agents** that run on a schedule (e.g., every 4 hours via cron) rather than serving continuously. These agents have no persistent server — they wake, process work, and sleep.

This creates a gap between what the spec assumes and what many real deployments look like.

## The Problem

The A2A spec assumes a live service endpoint:

> "A2A operations are designed for asynchronous task execution... Clients retrieve task updates through polling, streaming, or push notifications."

But this assumes the *initial* `tasks/send` POST reaches a live server. For heartbeat agents, there's no server listening between cycles. Callers have no way to know:

- Whether the agent is currently active
- When it will next be active
- How long tasks will take to process (latency is bounded by the heartbeat interval, not network RTT)

## What's Missing from AgentCard

The current AgentCard schema covers identity, service endpoint, capabilities (`streaming`, `pushNotifications`), authentication, and skills. It has no availability or scheduling fields:

- No `scheduleType` (cron, interval, persistent, manual)
- No `nextActiveAt` / `lastActiveAt`
- No `taskLatencyMaxSeconds`
- No indication that an agent processes tasks in batches during wake windows rather than immediately

This means callers can't distinguish between "this agent is slow" and "this agent processes work in 4-hour batches." Those require completely different caller behavior.

## The Extensions Mechanism Looks Right

The spec's `Extension` mechanism seems designed for exactly this:

> "A mechanism for agents to provide additional functionality or data beyond the core A2A specification."

An availability extension could allow agents to self-describe their operational model:

```json
{
"extensions": [
{
"uri": "https://example.com/extensions/availability/v1",
"params": {
"scheduleType": "cron",
"cronExpression": "0 */4 * * *",
"timezone": "America/New_York",
"nextActiveAt": "2026-03-21T04:00:00Z",
"lastActiveAt": "2026-03-21T00:00:00Z",
"taskLatencyMaxSeconds": 14400
}
}
]
}
```

## Questions for the Spec Team

1. **Is this a known gap?** Are heartbeat/scheduled agents an intended use case for A2A, or is the spec intentionally scoped to persistent-server deployments?

2. **Is the extensions mechanism the right path?** Or should availability metadata be standardized in the core AgentCard schema? Other fields like `capabilities.streaming` are core — is availability more like a capability or more like an extension?

3. **Task submission to offline agents:** Should the spec address how callers handle `tasks/send` to an agent that's currently offline? Options include: relay/proxy layer (caller POSTs to an intermediary that queues and delivers on next wake), client-side retry with backoff, or a dedicated `tasks/queue` endpoint semantics.

4. **Relay/proxy pattern:** Is there prior art in the A2A ecosystem for relay layers? I'm building one (as a gateway feature for OpenClaw agents) and would benefit from knowing if there's a reference design or if this is genuinely new territory.

## Context

I'm running an OpenClaw agent (heartbeat-based, 4-hour cycles) registered on an agent discovery registry I operate ([the-agora.dev](https://the-agora.dev)). We added an optional `availability` field to the registry's AgentCard schema to address this gap locally, but a standardized approach in the A2A spec would be more useful to the ecosystem.

Related: the spec explicitly defers curated registry API design to implementors ("The current A2A specification does not prescribe a standard API for curated registries"), which is the right call — but availability metadata seems like something that belongs in the core AgentCard regardless of how discovery works.

Read the A2A specification to understand the AgentCard schema and extensions mechanism. Examine the existing code for AgentCard definitions and task handling endpoints. The goal is to propose a design for availability metadata, either as a core schema addition or an extension, and address task submission to offline agents.

Scritto dal modello di indicizzazione a partire dal testo della issue.