Keep probability outside system invariants
Production agent architecture separates durable state and side effects from probabilistic reasoning. Queues, tool services, policy, approvals, traces, retries, and recovery must remain correct even when a model times out or chooses poorly. This page owns one search job: design state, queues, tools, and recovery for a production agent. It does not promise a universal product ranking, an undisclosed benchmark, or hands-on results that are not present in the evidence ledger.
Give developers a source-led, reproducible answer for how to design state, queues, tools, and recovery for a production agent, with explicit version and stop conditions. In practice, that means separating documented behavior from inference, naming the consequence of being wrong, and defining the evidence that would change the decision.
For the production agent architecture decision, the surrounding Agentic Engineering: Build Systems, Not Demos guide defines the nearest architectural boundary and prevents this page from absorbing a broader search job.
Use a durable transition ledger
Model the system with a state-transition ledger containing run ID, goal, current state, pending action, idempotency key, tool request and result, approval, retry count, checkpoint, terminal state, and recovery owner. The artifact should be portable enough for another engineer to inspect without relying on a private chat transcript or the memory of the person who ran it.
For production agent architecture, the source ledger uses current first-party material from Anthropic and OpenAI to define documented concepts and interfaces. Those sources do not prove performance on this site's hypothetical setup, so every comparative or operational conclusion remains tied to the recorded artifact and a local verification step.
After the production agent architecture evidence is recorded, use Agent Observability: Traces That Explain Failure; it covers the adjacent implementation handoff without duplicating the protocol here.
Persist, isolate effects, and recover
The order matters for production agent architecture. Starting with tooling or a score before the evidence boundary is defined makes later results hard to interpret. Keep each step small enough that its input, authority, output, and failure state can be reviewed independently.
- Define terminal states, invariants, and human escalation before implementing the successful agent path.
- Persist state outside the model conversation and route side effects through typed, policy-checked tool services.
- Use queues, timeouts, idempotency keys, checkpoints, and bounded retries to make partial failure recoverable.
- Trace decisions and side effects, then test replay, cancellation, duplicate delivery, tool outage, and rollback.
Record the exact production agent architecture configuration and environment beside the artifact, but do not invent a version number in evergreen copy. At execution time, pin the tested release, preserve command output or trace evidence, and stop when the next action requires new authority or an unverifiable assumption.
Production agent execution path
Design for duplicate and partial execution
For production agent architecture, the architecture flags three recurring risks for this family: agentic language replaces a concrete control loop, state and recovery paths are missing, and observability cannot explain a failure. They are not abstract caveats; each can make a polished result unusable for the decision this page owns.
- At-least-once queue delivery can repeat a tool action unless the effect has an idempotency boundary.
- A model-generated summary is not a durable transaction record and may omit pending or completed effects.
- Retries can magnify cost and damage when they repeat the same hypothesis without new evidence.
Treat a production agent architecture failure label as the start of investigation, not as an explanation. Preserve the case, identify which evidence or control was missing, and rerun one changed condition at a time. That discipline separates a tool limitation from a bad task definition, weak context, an unsafe permission, or a broken test harness.
Verify state, effects, and recovery
Verification for “design state, queues, tools, and recovery for a production agent” needs a stopping rule that another engineer can apply. The checks below favor direct artifacts and observable state over confidence, verbosity, or vendor reputation. A failed check keeps the conclusion provisional even when the generated output appears convincing.
| Check | Evidence to retain | Stop condition |
|---|---|---|
| State | Every run has an authoritative durable state | Conversation text is the only memory |
| Effects | Writes are idempotent or safely compensatable | A retry can duplicate external action |
| Recovery | Timeout, cancellation, and escalation paths are exercised | Only the happy path reaches a terminal state |
Run the production agent architecture gate against both an expected success and at least one denied, malformed, or recovery path. Store disagreements and residual risk beside the result. If the evidence cannot distinguish a system failure from an evaluation failure, improve the instrument before using its score to approve a release.
When the production agent architecture gate exposes a neighboring problem, continue with Agentic AI: Definition, Boundaries, and Examples and carry this page's evidence record into that step.
Production readiness gate
Ship only explainable terminal behavior
Ship the architecture when every run can be located, explained, stopped, resumed or closed without reconstructing state from model prose. Keep high-consequence effects behind explicit policy and approval. This rule applies to the documented search job, not to every use of production agent architecture. A different repository, data boundary, model, tool set, or consequence requires a new dated check.
End the production agent architecture record with the owner, next review trigger, and one of four outcomes: proceed within the tested boundary, reduce scope, gather missing evidence, or reject the approach. This preserves a useful negative result and prevents scheduled editorial copy from implying an experiment that was never run.