Agents Are Not Magic: Design Them Like Distributed Systems
An agent is just an LLM plus tools plus a loop. Borrowing decades of distributed-systems practice beats stacking prompts.
阅读中文版Agents are the hottest, most mythologized concept around. Strip the hype: an agent is an LLM that decides, tools that act, and a loop that iterates. That’s a distributed system. Borrow decades of distributed-systems practice and most “mystical” agent problems become ordinary engineering problems.
State: an agent session is a stateful service
An agent’s context is its state. Externalize state (persist it), version it after every tool call, and the system can recover from crashes — table stakes in distributed systems, and equally needed for agents.
Tool calls must be idempotent
Tools are an agent’s side-effect interface. A retried network call that double-charges or double-orders is the most common production incident in agent apps. Fix: idempotency keys on every tool call with server-side dedup; for non-idempotent operations (payments, sends), always add a human confirmation point.
Timeouts and circuit breakers, by level
Set separate timeouts for tool calls (2s), LLM calls (30s) and the whole task (5min), with fallbacks at each level so one hang doesn’t stall the pipeline.
Retry with a strategy
LLM failures split into systemic (rate limits, timeouts) and incidental. Back off and retry for rate limits, fail fast on timeouts, and never solve “bad answers” with retries — solve them with evaluation and validation.
Orchestration is a message queue
Multi-step tasks are naturally event-driven: each step’s completion triggers the next. Manage them with a task queue and a state machine instead of asking one LLM call to do everything. Recoverability and observability both improve by an order of magnitude.
Observability: replay a whole agent run
The metrics that matter are not tokens: each decision, which tool was called, with what arguments, what result, how long it took. Trace end-to-end and you can pin failures to a specific step instead of guessing at a black box.
Consistency: external side effects cannot roll back
Transactions can roll back; side effects on external systems cannot. Accept at-least-once semantics with idempotency and compensation, and keep high-impact operations at a human confirmation point.
Wrap-up
The hard part of agents was never the prompts — it’s state, idempotency, timeouts, observability and consistency. You don’t need magic; you need a distributed-systems checklist. And that checklist, senior engineers already have.