[Spec] Define normative AgentCard capability declaration contract for safe agent discovery
- 主要言語
- 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 はまだ評価されていません。