Proposal: Cost and budget propagation extension for multi-agent delegation

## Abstract

An extension for propagating budget constraints from caller to callee and reporting incurred cost back up the chain. Aligns with OTel GenAI semantic conventions so A2A metadata maps directly to span attributes without translation.

## Problem

I've been working on cost observability in OTel GenAI and kept running into the same wall. You can observe what a single operation costs, but the moment you cross a delegation boundary in A2A, that information vanishes. The caller sends work downstream and has no idea what it cost until (maybe) someone checks a billing dashboard days later.

The practical gaps I kept hitting:

There's no way to tell a downstream agent "you have $0.50 remaining." Each agent in the chain runs completely unaware of the budget it's operating within. When a task comes back completed, you get the answer but not the bill. And if something in the chain goes sideways and starts burning tokens, the root caller finds out from an invoice, not from the protocol.

Issue #1155 raised the token visibility question last year. Maintainers were unambiguous: this belongs as an opt-in extension, not core spec. OTel handles per-operation metrics. What nobody has proposed yet is the wire format for actually passing constraints and cost roll-ups between agents.

## Proposed solution

Extension URI: `https://a2a-protocol.org/extensions/budget/v1`

**Budget constraint (outbound, in SendMessageRequest metadata)**

Caller includes remaining budget. Downstream agents SHOULD respect it or reject with a descriptive error if the budget is clearly insufficient.

```json
{
"metadata": {
"https://a2a-protocol.org/extensions/budget/v1": {
"budget": {
"cost": {"amount": 0.50, "currency": "USD"},
"tokens": {"limit": 5000},
"deadline": "2026-08-09T12:00:00Z"
}
}
}
}
```

All three are optional. You might only care about tokens. Or only dollars. I included deadline because every enterprise workflow I've seen has some SLA attached, and making people invent a separate extension just for "finish by X" felt like overkill.

**Cost report (return, in Task metadata on completion)**

```json
{
"metadata": {
"https://a2a-protocol.org/extensions/budget/v1": {
"incurred": {
"cost": {"amount": 0.12, "currency": "USD", "source": "provider"},
"tokens": {"input": 1200, "output": 340},
"delegations": 2
}
}
}
}
```

`source` uses the same enum as OTel GenAI (`provider`, `pricing_table`, `estimate`). Important because you really don't want to aggregate a billed actual with someone's rough estimate and treat the sum as authoritative.

`delegations` is there because knowing the chain went 4 levels deep is useful context when you're staring at a $3.20 charge on what should have been a simple lookup.

**Roll-up semantics**

When B delegates to C, B subtracts its own consumption before passing the remainder. On return, B sums its cost with C's reported cost. Root caller sees total. Straightforward arithmetic, no coordinator needed.

**OTel alignment**

I have a PR open in OTel GenAI (open-telemetry/semantic-conventions-genai#443) adding `gen_ai.usage.cost.amount`, `.currency`, and `.source`. The field names here match intentionally. An instrumentation library that emits both A2A metadata and OTel spans populates both from the same values without any mapping layer.

## Why this fits A2A extensions

It's metadata enrichment only. Nothing touches the core schema, message flow, or task lifecycle. An agent that doesn't care about budgets ignores the metadata and works exactly as before. Composes with #2026 (trace propagation gives you the call graph) and my #2103 (span conventions give you the structure). This fills in the financial dimension that both of those deliberately left out.

## Deliverables

| Artifact | Status |
|----------|--------|
| Extension spec document | Draft (this issue) |
| Python reference implementation | Planned |
| Integration example (2-agent delegation with budget) | Planned |

## Prior art

Issue #1155 is where maintainers said this belongs as an extension. The traceability sample has cost/token fields but they're scoped to a single task's internal steps, not cross-agent propagation. On the OTel side, PR #443 adds per-operation cost attributes and PR #439 adds budget governance. I scoped #2103 (span conventions) to explicitly exclude cost so this could stand on its own.

## Request

I'd like to write the full spec and reference implementation for this if there's interest. The OTel work gives me the attribute schema already. And keeping this separate from #2103 means neither proposal has to wait on the other.