epoch.training← the field guide

Field Guide · Part III — The modern stack · 19

// agents in production

Agents that don't fall over in production

An agent is a model in a loop with tools — deceptively simple to demo, genuinely hard to keep standing. The demo works on the third try. Production has to work on the ten-thousandth. The difference is engineering, not a bigger model.

Strip away the marketing and an "agent" is a short loop: give a language model a set of tools (functions it can call — search, a database query, a shell command), let it decide which to call and with what arguments, run the tool, feed the result back, and repeat until the task is done. That's it. The founding pattern in the literature is ReAct — Yao et al. showed that interleaving explicit reasoning traces with actions lets a model plan, act, observe the result, and adjust, which beats reasoning or acting alone. Schick et al.'s Toolformer showed a model could even teach itself when to call an API from a handful of examples. Those papers make the loop work. Keeping it working under real traffic is a different discipline.

A note on sources: the reliability of production agents is still mostly documented in engineering practice, not peer-reviewed papers — the academic literature is thin and moves slower than the field. Below I cite the primary research that does exist plus one reputable engineering guide, and flag the rest as craft.

How agents fall over

The failure modes are specific and recurring:

Reliability is engineering, not a smarter model

None of these are fixed by a better model — a smarter model just fails less often, which hides the problem until scale exposes it. They're fixed by building around the model:

for step in range(MAX_STEPS):              # 1. hard loop limit
    call = model.next_action(history)
    if not schema_valid(call):             # 2. reject hallucinated calls
        history.append(error("bad tool call")); continue
    if call.tool in IRREVERSIBLE:          # 3. gate the dangerous ones
        if not human_approves(call): break
    try:
        result = run_with_retry(call)      # 4. retry transient failures
    except ToolError as e:
        result = error(str(e))             # 5. recover, don't crash
    history.append(result)
    if call.tool == "finish": break
The reliable-agent loop. The model picks the action; the five numbered guards — not the model — are what keep it standing in production.

Why it matters: the same instinct that keeps a supercomputing job from corrupting a shared filesystem — validate inputs, bound the blast radius, gate the irreversible, measure everything — is exactly what keeps an agent from taking a bad action ten thousand times an hour. The model is the easy part. The reliability is infrastructure, and it's the part that decides whether your agent ships or gets pulled after the first incident.

Sources & where to go deeper

S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan & Y. Cao, "ReAct: Synergizing Reasoning and Acting in Language Models", ICLR 2023 / arXiv:2210.03629 — the reason-act-observe loop that founds modern agents.
T. Schick, J. Dwivedi-Yu, R. Dessì, R. Raileanu, M. Lomeli, L. Zettlemoyer, N. Cancedda & T. Scialom, "Toolformer: Language Models Can Teach Themselves to Use Tools", NeurIPS 2023 / arXiv:2302.04761 — self-supervised tool use.
engineering guide: Anthropic, "Building Effective Agents", Anthropic, Dec 2024 — guardrails, human checkpoints, and keeping designs simple. Reliability practice is largely craft; peer-reviewed coverage remains thin.

This is one page of twenty.

The workshops go deep on the real thing — scheduling, storage, interconnect, GPUs — hands-on, on real infrastructure, from someone who's run these machines at national scale.

See the trainings →