a2aproject / a2aproject/A2A

[Spec] Define normative AgentCard capability declaration contract for safe agent discovery

オープン
#1,377 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る
主要言語
Shell
スター
25.7k
フォーク
2.6k
平均マージ
3日 6時間
マージ済み PR(30日)
16

説明

## Problem

Agent Cards declare capabilities (e.g., `pause_resume`, `streaming_message`, `push_notifications`), but the specification does not define:

1. **Which capabilities MUST be declared** vs implicitly assumed
2. **Backward-compatibility rules** when new capabilities are introduced
3. **How multi-agent orchestration** validates capability compatibility before delegating tasks
4. **Safe discovery boundaries** — what can agents safely assume about peers without checking?

This ambiguity creates **critical interoperability risks**:

- **Silent capability drift**: Agents add new capabilities without declaring them; orchestration chains break
- **Unsafe discovery**: Orchestrator discovers Agent B without validating it supports capabilities needed for the task; task fails mid-execution
- **Backwards incompatibility**: New agents with new features can silently break clients expecting old behavior

## Evidence

From recent issues and design discussions:
- a2aproject/A2A#1285: "Is supportedInterfaces information that must be declared?" → **unanswered confusion**
- a2aproject/A2A#1286: Request to add `source` field in Messages for multi-agent scenarios (requires capability declaration)
- a2aproject/A2A#1276: Pause/Resume added as capability flag; **how do agents discover this?**
- a2aproject/A2A#1313 (Phase B): Message/Artifact unification deferred; needs **capability versioning** strategy
- No reference implementation or test demonstrating capability negotiation

## Proposed Solution

### 1. Define Capability Tiers

**Tier 1: Implicit** (all compliant agents MUST support without declaration):
- `SendMessage` (single message only, no history)
- `GetTask`
- `ListTasks`
- Basic error handling

**Tier 2: Declared** (optional; MUST be in Agent Card if supported):
- `pause_resume`: bool — agent supports pause/resume operations (task can transition to PAUSED state)
- `streaming_message`: bool — agent can stream Message objects with `partial: true` flag (#1261)
- `push_notifications`: bool — agent supports push notification registration (#1372)
- `context_reuse`: bool — can agents share context ID across separate calls?
- `multi_tenant`: bool — agent runs in multi-tenant mode; check `AgentInterface.tenant`
- `message_history_injection`: bool — agent accepts injected message history in SendMessage (#1373)
- Custom capabilities via Extensions: Extensible schema for vendor-specific capabilities

**Tier 3: Deprecated** (supported but discouraged):
- Direct artifact streaming (superseded by Message streaming in a2aproject/A2A#1313 Phase A)

### 2. Version Negotiation Fields (New in AgentCard)

Add optional version range fields to `AgentCard`:

```protobuf
message AgentCard {
...
// Minimum A2A protocol version this agent supports
string min_protocol_version = 7; // e.g., "0.3.0"
// Maximum A2A protocol version this agent supports
string max_protocol_version = 8; // e.g., "1.2"
}
```

Also add to `AgentInterface` for protocol-binding-specific version negotiation:

```protobuf
message AgentInterface {
...
// Protocol version(s) supported by this interface
repeated string protocol_versions = 4; // e.g., ["1.0", "1.1"]
}
```

### 3. Discovery Safeguards (Normative Pattern)

When discovering an agent (client-side validation):

```python
def safe_discover(agent_card: AgentCard, my_protocol_version: str) -> bool:
# Check version range compatibility
if not version_in_range(my_protocol_version,
agent_card.min_protocol_version,
agent_card.max_protocol_version):
log.warning(f"Agent protocol version {agent_card.min_protocol_version}-{agent_card.max_protocol_version} incompatible with mine {my_protocol_version}")
return False

# Check required capabilities for intended use case
if my_task_requires_streaming and not agent_card.capabilities.get("streaming_message"):
log.warning("Agent does not declare streaming_message capability; streaming will fail")
return False

return True
```

### 4. Multi-Agent Orchestration (Transitive Capability Validation)

When Agent A delegates to Agent B (which may delegate to Agent C):

```
A → B → C

Step 1: A discovers B, validates B.capabilities against task requirements
Step 2: If B delegates to C, B must validate C.capabilities
Step 3: If B's capability = "context_reuse: false", A cannot rely on shared context
```

**Failure mode without validation:**
```
A requires streaming_message
A discovers B (no capability check)
A sends streaming message to B
B fails because it doesn't support streaming
→ Silent failure mid-orchestration
```

**With validation:**
```
A requires streaming_message
A discovers B
A checks: B.capabilities.streaming_message == false
A refuses to delegate to B, tries next agent
→ Deterministic, predictable behavior
```

### 5. Capability Stability Guarantee

Once a capability is declared in the specification, it has stability guarantees:

- **Cannot be removed** (only deprecated)
- **Can only be extended** (new fields added, not removed)
- **Deprecation period**: 2 major versions before removal (if ever)
- **Example**: `pause_resume` introduced in v1.0 → cannot be removed in v1.x, marked deprecated in v2.0, removed in v3.0

This ensures orchestration chains don't break on minor version updates.

## Acceptance Criteria

- [ ] Add new "Capability Declaration & Discovery" section to `docs/specification.md` with subsections:
- Capability tiers (Tier 1/2/3)
- Declaration requirements
- Version negotiation
- Safe discovery pattern (pseudocode)
- Multi-agent orchestration rules
- [ ] Update `a2a.proto` AgentCard and AgentInterface with:
- `min_protocol_version`, `max_protocol_version` fields (strings, optional)
- `protocol_versions` array in AgentInterface (new field, optional)
- Comment blocks explaining each new field
- [ ] Create conformance test case `tests/conformance/capability-discovery.json`:
- Golden trace: Agent A discovers B, validates capabilities, delegates task
- Invariant: If B doesn't declare `streaming_message`, no streamed messages sent
- Invariant: Version mismatch detected before delegation
- [ ] Document in `CONTRIBUTING.md` / SDK development guide:
- "How to declare capabilities in your agent"
- "How to validate discovered agent capabilities"
- Checklist for new capability additions
- [ ] Update existing issues:
- a2aproject/A2A#1276 (pause_resume): Add acceptance criterion "Agent declares `pause_resume: true` in capabilities"
- a2aproject/A2A#1286 (source field): Add acceptance criterion "Agent declares support for multi-agent attribution"
- a2aproject/A2A#1313 (Phase A/B): Cross-reference this for version/capability negotiation strategy

## Why This Matters

| Without This | With This |
|-----------|-----------|
| ❌ Silent capability drift | ✅ Explicit declarations; versioning prevents drift |
| ❌ Multi-agent chains break mid-task | ✅ Capability validation before delegation |
| ❌ New features break old clients | ✅ Version negotiation + deprecation path |
| ❌ SDKs implement discovery differently | ✅ Normative pattern ensures consistency |
| ❌ "Free discovery is dangerous" (per lens) | ✅ Bounded discovery: validated compatibility |

## Related Issues & Linked Work

- **Streaming**: a2aproject/A2A#1261 (Message streaming) — new capability `streaming_message`
- **Unification**: a2aproject/A2A#1313 (Message/Artifact) — Phase A/B roadmap references versioning
- **Agent Features**: a2aproject/A2A#1276 (pause_resume), a2aproject/A2A#1286 (source field) — examples of declared capabilities
- **Multi-tenant**: a2aproject/A2A#1271 (tenant field), a2aproject/A2A#1273 (multi-tenancy) — capability declaration for tenancy
- **Orchestration**: a2aproject/A2A#1317 (context reuse) — needs capability negotiation

## Additional Context

This proposal addresses the "free discovery is dangerous" lens from the A2A architecture review:

> *Discovery of new agents/capabilities can silently break existing agents (capability drift / compatibility breakage). Identify where A2A discovery/selection could produce unstable or incompatible interactions. Propose compatibility constraints and safety gates.*

**This issue proposes those safety gates**: explicit capability declaration, version negotiation, and safe discovery patterns.

コントリビューションガイド

コントリビューションガイドを開く

評価

この issue はまだ評価されていません。

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。