Motivation & Context

Several components re-invoke an inner agent or chat client multiple times within what the caller sees as a single run. Each inner call reports its own usage, but the looping component returned only the final call's response, so every earlier call's tokens were dropped. Callers reading response.Usage therefore under-reported the true cost of a run, and the error grew with the number of iterations.

Three non-streaming loops were affected:

• LoopAgent — set Usage from the last iteration only.
• ToolApprovalAgent — re-invokes the inner agent for each round of auto-approved tool calls.
• MessageInjectingChatClient — re-invokes the inner client for each round of injected messages.

Accurate token accounting matters for cost attribution, billing and budget enforcement, and the components most affected are precisely those that can iterate many times.

Streaming paths were audited and were already correct: UsageContent updates are forwarded to the caller and summed by the terminal ToAgentResponse() / ToChatResponse() conversion. That is the same contract FunctionInvokingChatClient relies on, which is why no aggregation is added there — doing so would double count.

Description & Review Guide

• What are the major changes?

  Adds an internal shared helper, UsageAggregationExtensions, compiled into Microsoft.Agents.AI and Microsoft.Agents.AI.Workflows via a new InjectSharedUsage property:

  • MergeUsage / AccumulateUsage sum two UsageDetails, covering all nine strongly-typed counters plus per-key AdditionalCounts, with null-aware addition (null means "not reported", not zero). This deliberately mirrors UsageDetails.Add — what FunctionInvokingChatClient itself uses — while returning a new instance rather than mutating in place, so a caller-owned UsageDetails is never aliased or modified.
  • WithAggregatedUsage returns a copy of a ChatResponse / AgentResponse carrying the aggregated usage, with an optional message-substitution parameter for transcript-style results.

  The three loops now accumulate usage across every iteration and return a copy carrying the total. ToolApprovalAgent's MaxAutoApprovalIterations cap branch is included: it takes an extra final turn outside the accumulating loop and previously returned early, discarding the aggregate entirely. That is the highest-spend path by definition, since the cap exists to bound a runaway loop.

  Microsoft.Agents.AI.Workflows' MessageMerger is refactored onto the shared helper. This also fixes a latent bug in its local merge, which used raw long? addition — so null + 5 evaluated to null and silently zeroed a count whenever one side omitted a field — and which returned caller-owned instances by reference.

• What is the impact of these changes?

  response.Usage now reflects the whole run for these components rather than just the final inner call. Reported token counts will increase for multi-iteration runs; this is the correction, not a regression. There are no public API changes — the helper is internal — and no behavioural change to message content, ordering, or streaming. Usage continues to be reported only on .Usage and is never duplicated as UsageContent in messages.

• What do you want reviewers to focus on?

  Whether the aggregation boundaries are right: each loop should count every inner call exactly once, with no double counting where components nest, since FunctionInvokingChatClient sits directly above MessageInjectingChatClient in the ChatClientAgent pipeline.

Related Issue

Closes #7537

Contribution Checklist

• The code builds clean without any errors or warnings
• All unit tests pass, and I have added new tests where possible
• The PR follows the Contribution Guidelines
• This PR is linked to an issue and there is no other open PR for this issue (see Related Issue above).
• This is not a breaking change. If it is a breaking change, add the breaking change label (or add "[BREAKING]" to the title prefix, before or after any language prefix) — a workflow keeps the label and title prefix in sync automatically.