Trace Aggregation Summary

Background

A multi-agent run emits a TraceEvent per LLM call, tool call, or critic invocation. Aggregating them per agent reveals which sub-agent is the bottleneck — the famous "exec_1_2 used 6 LLM calls vs 2 for the others" diagnostic from the observability lesson. This is the bare-minimum analytics primitive every agent observability stack ships with.

Problem statement

Implement summarise_trace(events). Group events by agent_id; within each group, count occurrences of each type. Return a regular dict (not a defaultdict) suitable for JSON serialisation.

Input

• events — list[dict]. Each event must have agent_id (str) and type (str). Other keys are ignored.

Output

Returns dict[agent_id -> dict[type -> count]]. Empty input returns {}.

Examples

Example 1 — basic aggregation

Input:
  [{agent_id: "a", type: "llm"},
   {agent_id: "a", type: "search"},
   {agent_id: "a", type: "llm"},
   {agent_id: "b", type: "llm"}]
Output:
  {"a": {"llm": 2, "search": 1}, "b": {"llm": 1}}

Example 2 — empty input

Input:  []
Output: {}

Constraints

• Output must be a plain dict (not defaultdict) so it round-trips through JSON cleanly.
• Order of keys in the output is not specified (rely on insertion order if you need stability).

Notes

• Why per-agent. A single bottleneck agent is the most common cause of slow runs. Grouping makes the offender obvious in one glance.
• Extension. Real telemetry adds latency and token-cost sums per type; this problem is the canonical aggregation kernel.