long-horizon systems, orchestration, tool use
agents don't fail the way demos fail. they fail at hour six, in a state nobody wrote down, holding a lock on something real. most of what i build is not the agent — it's the part that survives the agent being wrong for four hours.
┌──────────┐ ─────► session ├─────► 37 mcp servers loaded └────┬─────┘ ttft: unacceptable │ │ kill ▼ ┌──────────┐ │ reconnect ├─────► hook enumerates available, └────┬─────┘ re-enables only what's needed │ ▼ continue ← state dies here. that's the trade.
the cheapest fix for time-to-first-token was not loading less. it was loading nothing and paying for a reconnect. what that costs is every bit of session state — survivable only because of what's in the next diagram.
t0 t+2h t+4h t+6h t+8h ├─────────┼──────────┼──────────┼──────────┤ ▪ ckpt ▪ ckpt ▪ ckpt ✕ ▪ resumed context rot, not a crash
the failure is never an exception. it's the agent still running, confidently, on a premise that stopped being true two hours ago. everything upstream of the checkpoint is cheap; the expensive question is what you're willing to call a checkpoint.
long-horizon agents in critical industries — where being wrong for four hours has a cost denominated in something other than tokens. more →
four engines behind one runtime, and a memory identity per agent that outlives any single session. more →
one call shape, five model dialects. the interesting part is what you cannot normalize. more →
“i blow the agent away — kill the session, instant-reconnect, and specify only the tools it actually needs.” read →
whether swarms are a real topology or a scheduling failure wearing a costume. i keep building them and keep not being sure.