Why this blog exists

This blog, Loop & Retry, serves a specific purpose in the world of building language model (LLM) agents for production. Many existing writings on the subject are either one-off demos that work in a single instance or posts predicting a technological singularity within a few months. This blog aims to fill the gap between these two extremes, focusing on the more realistic scenario where an agent is shipped and deployed, only to encounter unexpected issues later on.

The author's main concern is the tendency for agent content to be mistaken for a functioning system when in fact it's only a working demo. A demo only needs to succeed once, while a system must be able to handle thousands of potential failures, including malformed inputs, rate limits, tool errors, and retries that may exacerbate the problem.

The underlying principle guiding the blog is straightforward: every post should demonstrate the version that fails and the subsequent fix. All numerical data should be measured or cited, without relying on fabricated benchmarks. If a claim cannot be validated through reviewing the actual code, it should not be published.

The blog is structured around six key pillars: context engineering, tool design, evaluations, cost and latency, failure modes, and agent architectures. The first area to be explored in depth is retry budgets, specifically why a 20% per-step failure rate quietly leads to a doubling of token costs. Upcoming posts will aim to cover these topics approximately once or twice a week, with new content published via RSS for subscribers interested in this niche area of LLM agent development.