Why agent systems become slow, expensive and fragile

The measured mechanisms behind agent bloat: context resends, oversight cost, cumulative failures, and the attribution traps that make dashboards lie about all of it.

8/29/2026

Ask someone why their agent system is slow and they will blame the model. The telemetry says otherwise: in my own measured runs, most of the cost and latency accumulated around the model, not inside it. This article names the mechanisms.

Three mechanisms: every hop resends context, oversight costs more than work, and failures accumulate through retries, inbox errors, tool-output bloat, and stale duplicate workers
Measured across 551 sessions and two public dashboards. None of this is illustrative. Evidence date: 29 August 2026. Download the editable Excalidraw source.

The mechanisms

Every hop resends context. When a planner hands work to a worker, the worker receives its instructions again, plus enough history to act. The reviewer reads the output plus the original context. Each hop re-pays for tokens the previous hop already spent.

Oversight costs more than work. Planning tokens, review tokens, and polling waits are all real spend. In the one-agent-two-models comparison — the same tasks through both paths, with per-call traces — oversight across four orchestration layers exceeded the tokens spent doing the actual task. The measured multiplier behind this is in the cost-machine sequence below.

Failures are cumulative, not isolated. A retry is cheap; a retry culture is not. Inbox errors, browser reconnects, tool-output bloat, and stale duplicate workers each add a little. Together they turn a two-minute task into a twenty-minute session.

Interruptions and inference-vs-tool bottlenecks. A cancelled task still bills its tokens. And long tool calls (a browser action, a file write) block the inference loop, so wall-clock time diverges from token cost — which is why "it took ages" and "it cost a lot" are different measurements.

The request path: user request, planner agent, worker agent, reviewer agent, cumulative bill — each arrow is a context resend
Each arrow is a context resend. Hops, not model choice alone, drive the cost curve. Evidence date: 29 August 2026. Download the editable Excalidraw source.

A request through the cost machine

Five steps: request parsed, planned, worked, reviewed, reported — with context resend costs one through four and a total of four times the actual work
The multiplier is measured, not illustrative. Per-call traces exist for this exact path. Evidence date: 29 August 2026. Download the editable Excalidraw source.

The attribution trap (canonical)

This section is the canonical description of the cumulative-versus-task and unknown-versus-zero problems. Other articles link here rather than re-deriving them.

Before: gaps in provider counters render as zeros, making cost look lower than truth. After: missing data marked unknown, totals exclude it honestly, no false confidence
Unknown is not zero. The pipeline changed specifically so gaps never render as zero. Evidence date: 29 August 2026. Download the editable Excalidraw source.

Cumulative-versus-task metrics and unknown-versus-zero are the two quiet ways dashboards lie. Fixing them is what made honest optimisation possible at all.

What to do about it

The structural fixes are boring and effective: fewer hops (delete layers that don't repay their coordination cost), task-scoped metrics (attribute tokens to the task, not the lifetime counter), bounded tool output (truncate what you would never read), and a stale-worker reaper. The routing rule — cheap workhorse by default, frontier for genuinely hard work — is documented in the routing benchmark article.

Why this matters outside the terminal

"It took ages" and "it cost a lot" are different measurements — and the same trap exists in marketing data, where platform latency and platform spend get conflated. The habit of separating them transfers directly.

Where to go next