Originally published on Loop & Retry — field notes on building LLM agents that survive production.
Most writing about LLM agents is either a demo that works once on stage or a
thread promising the singularity by Q3. This blog is for the gap in between: the
part where you ship an agent, it survives contact with real inputs for a while,
and then it does something expensive and stupid at 3 a.m.
That's the interesting part. That's what I want to write about.
The bias I'm writing against
The default failure mode of agent content is confusing a working demo with a
working system. A demo has to succeed once. A system has to fail gracefully
thousands of times: on the malformed input, the rate limit, the tool that returns
an error the model has never seen, the retry that quietly makes things worse.
So the rule here is simple. Every post shows the version that breaks and the fix.
Every number is measured or cited — no invented benchmarks. If a claim can't
survive someone reading the code, it doesn't go up.
What's coming
Posts map to six pillars: context engineering, tool design, evals, cost and
latency, failure modes, and agent architectures. First cornerstones in the queue:
- Retry budgets, and why 20% per-step failure quietly doubles your token bill.
- The context window is a cache, not a memory.
- Designing tools an LLM won't misuse.
If that's your kind of thing, subscribe via RSS. New posts 1–2 times
a week.
