Production agent architecture
Our agent is too unreliable to operate
The harness—not the model—owns reliable production behavior.
Non-deterministic answers are only one source of agent failure. Lost work, duplicated effects, ambiguous state, unreconstructable incidents, and unsafe retries are failures of the runtime around the model.
Reliability comes from explicit control flow, contracts, checkpoints, idempotent effects, telemetry, and recovery. Prompting the model to behave consistently cannot supply those operating guarantees.
See the Production Agent Architecture pillar →
Decisions that make behavior operable
- Control flow: Keep lifecycle, budgets, approvals, and effects deterministic; use model judgment only inside bounded steps.
- Contracts: Validate tool requests, results, state transitions, timeouts, and failure states explicitly.
- Effects: Give consequential calls idempotency keys and explicit commit boundaries so retries do not duplicate work.
- Recovery: Record checkpoints and cancellation events so interrupted runs can be replayed from known state.
- Evidence: Preserve decisions, attempts, outcomes, and request identity well enough to reconstruct an incident.
Read the reliability path
- The harness is the product; the model is a component — establish the runtime ownership boundary.
- Choose workflows where determinism is cheap, agents where it is expensive — keep deterministic control where the path is enumerable.
- Durable execution is the recovery contract for long-horizon agents — treat checkpoints and replay as correctness contracts.
- Idempotency is the cheapest reliability you will ever buy — prevent retries from duplicating external effects.
- Telemetry should preserve decisions, not just events — retain enough evidence to reconstruct behavior.
Proof and limits
Review the contracts around your agent
A focused review traces one consequential trajectory through control flow, tools, state, authority, verification, effects, and recovery to identify the missing contracts and sequence remediation.