The Agent Survival Guide — Production Agents, Not Demo-ware

Overview

Your agent does not need a better model. It needs a better harness.

That’s the thesis, and it came from auditing a real agent codebase where the permission gates were written but never called and the spend meters skipped the main loop entirely. The safety code existed. Nobody wired it in. Most agent projects fail exactly like that, for boring plumbing reasons. The loop never observes tool results. Context gets stuffed until the model gets dumber. Verification happens after the task instead of inside it. RAG gets over-built before anyone even tries search tools. Prompt injection gets “handled” with a system prompt.

So I wrote the reference I wished existed. 17 guidebook chapters, 8 implementation guides with working Python, 100+ cited sources across Anthropic, OpenAI, METR, tau-bench, and real production post-mortems. Free, MIT, and deliberately not demo-ware.

The ten golden rules

The whole guide compresses into ten rules, each expanded by a chapter with the evidence behind it:

1. Don’t build an agent when a workflow will do.
2. One main loop, flat history, bounded everything.
3. The LLM proposes, deterministic code disposes.
4. Tools are prompts.
5. Context is a depleting attention budget.
6. Verification is a loop phase, not QA.
7. Ground or abstain, enforced mechanically.
8. Memory is an attack surface.
9. Evals are the steering wheel.
10. Autonomy is asymmetric.

If you’ve built agents in production, each of these maps to a scar. If you haven’t yet, they’re the scars you get to skip.

STAGE MAP — two halves, one system

flowchart LR
    subgraph GUIDE["Guidebook — WHAT and WHY"]
        CH["17 chapters<br/>foundations → checklists"]
        RULES["Numbered imperative Rules<br/>machine-consumable per chapter"]
        SRC["100+ cited sources<br/>Anthropic · OpenAI · METR · tau-bench"]
    end
    subgraph IMPL["Implementation — HOW"]
        IM["8 reference builds<br/>agent loop · gates · evals · memory"]
        PY["copy-adapt Python"]
    end
    subgraph USERS["Who loads it"]
        HUMAN["Engineers<br/>architecting + reviewing"]
        MODEL["LLMs<br/>chapters loaded as constraints"]
    end
    CH -->|"maps chapter → build"| IM
    GUIDE --> USERS
    IMPL --> USERS

The split is on purpose. You read the guidebook for judgment and you use the implementation for code, and they map to each other chapter by chapter, so impl-01 is the working form of the loop-anatomy and tool-design chapters, and so on down the build order.

The loop the whole book orbits

Chapter 02 defines the anatomy everything else hangs off: the LLM proposes an action, a deterministic gate decides if it’s allowed, execution happens, the result is actually observed, and verification runs inside the loop before the next step. Every failure mode in the book is some link of this chain skipped.

flowchart LR
    PROPOSE["LLM proposes<br/>next action"]
    GATE["Deterministic gate<br/>permissions · spend · policy"]
    EXEC["Execute tool"]
    OBSERVE["Observe result<br/>actually read it"]
    VERIFY["Verify inside the loop<br/>not after the task"]
    PROPOSE --> GATE --> EXEC --> OBSERVE --> VERIFY --> PROPOSE
    GATE -.->|"denied"| PROPOSE
    VERIFY -.->|"failed → replan"| PROPOSE

What the chapters actually cover

Foundations and the loop (01, 02), tool design where tools are treated as prompts and errors as retry instructions (03), context engineering against context rot (04), Agent Skills and MCP (05), model portability and cost control (06), grounding with the agentic-search-before-indexes argument (07), memory systems and memory poisoning (08), the verifier ladder and cite-or-abstain architecture (09), evals with pass^k and judge calibration (10), prompting at the right altitude (11), multi-agent orchestration with the honest numbers on when parallel agents pay versus when they burn 15x the cost (12), security with the lethal trifecta and policy-as-code (13), data-access agents and the text2SQL cliff (14), domain playbooks for BFSI, healthcare, and education (15), the 2026 market landscape (16), and the build/review/ship checklists (17).

Written for two readers at once

Every chapter opens with numbered imperative Rules, written to be machine-consumable. That’s the structural bet of the whole project: engineers read it like a book, and models load the chapters and checklists straight into context as constraints while generating harness code. Same files, two consumers, and that requirement changed how every page is structured. Rules first, evidence after, checklists at the end.

There’s a defined floor, too. The minimum viable harness is the agent-loop build plus the gates build plus a 20-case smoke set from the evals guide. Everything past that is an upgrade you justify, not a default you cargo-cult.

Engineering decisions

• Judgment and code are different artifacts. Mixing principles into code comments buries them, and mixing code into essays makes it unrunnable. Two directories, one system, explicit cross-references both ways, with a declared build order where dependencies flow downward.
• Citations or it didn’t happen. Every failure-mode claim traces to a source, a benchmark, or a named post-mortem. The guide argues from evidence because that’s the only way it stays useful when the model landscape shifts.
• Reading orders by goal. Nobody reads a reference cover to cover. The guidebook ships paths: architecting, reviewing an existing agent, calibrating an LLM’s output, shipping this week.

Highlights

• 17 chapters + 8 implementation guides, chapter-to-build mapping throughout
• Ten golden rules that compress the whole discipline, each backed by a chapter of evidence
• 100+ cited sources, from lab research to production post-mortems
• Born from a real audit where the safety code existed but was never wired in
• Loadable by LLMs as constraints, not just readable by humans