Multi-agent teams under latency pressure and budgets

Why it matters

Left alone, an agent team optimizes for thoroughness, because nothing in its context says how long the requester has waited. 3.3 asks you to bound that thoroughness by a deadline; this notebook shows what the model can be told about time.

What to practise

Build one team clock per task and stamp an [elapsed 252s] line onto the newest user message before every API call, for the lead and every helper it spawns. Note that a late helper sees the team’s elapsed time, not its own, and that stamping at the tail keeps the earlier prefix a prompt-cache hit. Then compare three arms: no clock, the clock with one sentence of latency pressure, and the clock with a budget such as [elapsed 252s / 600s].

How it fits

The clock is 3.3.3’s time-aware instruction, and its tail placement is 3.3.2’s cache reuse. The notebook warns that Claude may overrun a short budget, so compare it with 3.3.3’s host-side cancellation: the clock steers pacing, cancellation enforces the deadline. Before adopting a faster arm, check its answers on identical cases, as 3.3.4 does for verification.