ADK never tells you how your agents are wired. The timing does.

Ask a team to draw their agent system and you get a clean diagram: a router, three specialists, a parallel research block, a summariser. Ask what the deployed system actually does and the honest answer is usually "that, we think". Nothing verifies the diagram, so it drifts, and it drifts silently, because a structural regression in an agent system does not throw.

The bug that raises no error

Here is the failure this whole area exists to catch. A ParallelAgent whose branches end up executing one after another still returns the correct answer. It costs the same in tokens. No exception, no log line, no status change.

The signal is the concurrency ratio: the sum of child durations divided by the parent's wall-clock duration. Genuinely parallel branches push it towards the number of branches. A ratio near 1.0 means they queued. That single number is the difference between an agent that feels fast and one users abandon, and it is absent from every log you have.

How structure is recovered from a flat stream

Every span carries a parent, a start time and an end time. That is enough to reconstruct composition using interval algebra, without anybody declaring anything:

• Root: the span with no parent in the trace.
• Sequential: sibling spans whose intervals do not overlap and run in a consistent order.
• Parallel: siblings whose intervals overlap materially. The overlap is the evidence; the class name never appears.
• Loop: the same agent recurring under the same parent, which is how an iteration shows up when nothing announces it.

The result is a graph nobody maintains. It cannot go stale, because it is regenerated from what ran, which is exactly the property a hand-drawn diagram lacks.

Why this beats a declared graph

Most tooling in this space asks you to describe your graph: decorators, a registration call, a YAML file. That produces a diagram of your intentions, and the maintenance burden lands on the person least likely to remember it, whoever adds a sub-agent six months later under deadline.

Put money on the graph

Structure alone is interesting. Structure with spend on it changes decisions. Once the graph is derived, each node can carry the cost of the calls made underneath it, and the question "which branch is expensive" becomes a glance instead of an investigation.

Two rules keep that honest, both learned the hard way:

• Deduplicate before you attribute. ADK emits two spans sharing one LLM event id per model call. Joining cost to spans on that id without deduplicating reports double the real spend, uniformly, plausibly, across the whole graph. See ADK agent cost.
• Never add tool cost to agent cost. What is derivable for a tool is the cost of the model call that consumed its output: an upper bound, not a disjoint share. Summing the two counts the same money twice.

Derived topology is computed from the same spans the cost figures come from, so the graph and the invoice cannot disagree about what happened. It is also cached with an explicit sync rather than recomputed per request. Reconstructing a graph from raw spans on every page load is a good way to make an observability tool the slowest thing in your stack.

What to check on your own system this week

• Concurrency ratio on every parallel block. If it is near 1.0, your parallelism is decorative.
• Unexpected loops. A recurring agent under one parent that you did not design as a loop is usually a retry or a hand-off cycle.
• Depth you did not intend. Hand-off chains grow quietly; each hop is latency and another chance to lose context.
• The expensive branch. Then go and read its prompt. See prompt management for changing it without a deploy.