You're about to become
the bottleneck again.

Here's the setup — and the payoff

Two words we'll use precisely, because it matters: a turn is one full ask-to-response interaction with you. A step is a single LLM request/response inside that turn — a turn with 10 tool-call round-trips contains 10 steps.

The constraint just flipped. Welcome back to the critical path.

A session that felt slow, step by step

A long-running Amplifier session had big, unexplained gaps of wall-clock time between LLM calls — each gap sitting inside a single step, not the turn as a whole. And during those gaps, zero events were logged. Not even streaming telemetry. We pointed context-intelligence (graph-based session analysis) at it and dumped every event in a clean gap.

This particular gap — nearly six minutes — was pulled from deep in an unusually long-running session, hundreds of steps in. Early on, the same stall was only tens of seconds; more on how it grew, next slide.

Worth sitting with: at that ~6-minute-per-step rate, a single turn needing ~10 tool-call steps would burn roughly an hour of pure stall (10 × ~6 min) — on top of the actual work. Illustrative math, not a directly observed single-turn total: the per-step figure is measured; the 10-step multiplication just shows how it compounds within one turn.

Not flat. Growing.

First guess: a flat ~6-minute stall on every step — maybe rate-limiting or provider throttling. So we mapped the whole session: 165 turns, 1,095 steps (~6.6 steps per turn on average, no chattier-over-time trend). That confirms the bug hit every single step — every raw LLM request — not once per turn. A turn with 10 tool-call round-trips paid this cost 10 separate times.

Honest caveat: this session had already been resumed 18 times over ~3 weeks and carried 2,285+ messages of accumulated history even at turn 1 — that's why turn 1–2 already shows a real 71–73s stall, not a negligible one. The proven pattern is that impact scales with accumulated context size (message/token volume), not simply turn count starting from zero. A session that stays short in a single sitting carries far less history and sits much further down this curve — the multi-minute stalls above are what a long-lived, frequently-resumed, heavily-used session produces. That's a real and common pattern for serious work, but not every session. Place your own sessions on this curve by message/token count, not turn count.

71s → 368s+. Growth tracks conversation history the entire way — not the clock.

Who actually solved this

The broader Amplifier ecosystem — evals, the Digital Twin Universe, and tester agents (browser/terminal/reality-check) — exists precisely to prove fixes are real in realistic environments rather than asserted. This particular fix leaned on pytest, a synthetic benchmark, and live production re-measurement instead, in that same "prove it, don't assert it" spirit.

The human's actual role: 10 short steering prompts drove 213 autonomous tool/agent actions — roughly 21 autonomous actions per prompt. The human noticed something felt slow and made a handful of go/verify/ship/share calls — didn't write code, run a test, or craft a single query directly. One nuance worth keeping: the root-cause tracing and fix-design scoping were done by the root agent itself, using systematic-debugging and council skills as its own reasoning scaffold — implementation and shipping were what got delegated to specialist agents (bug-hunter, git-ops).