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