Books for builders.

The single biggest mistake in agent design isn’t bad prompts. It’s the assumption that your agent will succeed on the first try. Every production agent is, at its core, a retry machine. The moment you internalize this, your architecture changes completely. You stop building happy-path pipelines and start building recovery systems.

We use a pattern we call “escalating introspection.” On the first failure, the agent retries with its original context. On the second, it appends a self-critique step before re-executing. On the third, it rewrites its own plan from scratch using the failure trace as a constraint. By the fourth attempt — and there should not be a fourth attempt — it flags for human review with a structured handoff packet. The packet isn’t an error log. It’s a diagnosis.

Most teams skip straight to human escalation because they don’t trust their agents to self-correct. That’s backwards. If you don’t trust your agent to self-correct, you haven’t built an agent. You’ve built a form with extra steps.

There’s a seductive lie in autonomous scheduling: that you can “set it and forget it.” You can’t. An unmonitored cron agent is a slow-motion disaster with a predictable schedule. We’ve seen agents dutifully execute the same broken workflow every six hours for three weeks because nobody wired up the dead man’s switch.

The rule is simple: every scheduled agent gets a heartbeat, a budget ceiling, and a kill condition. The heartbeat proves the agent is alive and progressing, not just alive and burning tokens. The budget ceiling prevents the 3 AM run that decides to “research thoroughly” and racks up forty dollars of inference before anyone wakes up. And the kill condition — this is the one people forget — defines what “success looks like,” so the agent knows when to stop instead of finding more work to do.

Your cron agent doesn’t need ambition. It needs a punch clock and a exit door.

Engineers treat the context window like an attic. They keep shoving things in — system prompts, chat history, retrieved documents, tool schemas, few-shot examples — and then wonder why the model “forgets” instructions from the top. It didn’t forget. You drowned it.

Here’s the math that should haunt you: at 200K tokens of context, the model is processing the equivalent of a 400-page novel on every single call. You’re paying for 400 pages of attention to get one paragraph of output. If you can’t articulate exactly why each token is in the window, it shouldn’t be there. We call this the “earned seat” principle — every piece of context must justify its presence or get evicted.

The teams shipping the best agent systems aren’t the ones with the biggest context windows. They’re the ones who use 12K tokens and make every one of them count. Retrieval is not a crutch for poor information architecture. It’s a scalpel.

The biggest misconception about distillation is that you’re making a smaller copy of a big model. You’re not. You’re teaching a small model to fake the big model’s homework. And that distinction matters enormously for how you structure the training data, what you evaluate, and when you declare victory.

A distilled model doesn’t know what the teacher knows. It knows what the teacher says. Those are very different things. The teacher model might hedge an answer because it’s genuinely uncertain — the student learns to hedge as a stylistic tic. The teacher might chain-of-thought through a complex problem — the student memorizes the chain without understanding the links. This is why evaluation on the distillation set is almost meaningless. Your student will ace that test. It’s a cheat sheet.

The real test is adversarial: novel problems, distribution shifts, edge cases the teacher never saw. If your distilled model handles those, you’ve built something useful. If it doesn’t, you’ve built a very expensive autocomplete that happens to sound smart.