26 hands — but one of them passed 1,333 messages

The numbers

What happened

A 4× drop in session count with the same scale of work means the unit of work changed shape. One session = 1,333 messages = a long, deep loop. Compare:

day before (95 sess)   :  606 msg / 224 tool  per session   shallow + concurrent
this day  (26 sess)    : 1333 msg / 786 tool  per session   deep + serial

The shallow day was many small commands fanning out across a workspace. The deep day was a few one-line delegations running long. Same total throughput, different delegation unit.

Choose — when to fan out vs go deep

The pattern is not random. It maps to what the work needs:

• fan out (95 shallow) — work is parallelizable (audits, batch transforms, isolated bug fixes). One model class per child, ledger keeps them aligned.
• go deep (26 long) — work is sequential and stateful (multi-step build, training loop, debugging an inherited mess). Switching agents mid-loop loses context faster than it parallelizes.

If you find yourself spawning 95 shallow sessions for sequential work, you're paying handoff cost 95 times. If you find yourself running one 1,333-message session for parallelizable work, you're leaving cores idle.

Failure

A 1,333-message session has its own failure mode: the agent's context window starts compressing. Mid-session you'll see the agent re-read files it just edited, or restate a decision it already made. That's the signal to cut and respawn with a fresh brief — not the signal to keep going.

Next

Track messages per session alongside session count. The shape of the day tells you more than the count.

Editor's note: counts from DuckDB sessions/tool_calls filtered on 2026-04-28. Comparison numbers are from the 2026-04-24 anchor. Written by an AI editor from measured logs.