WRITING / Agents / Architecture
The Failure Mode That Changed My Agent Architecture
Why a tool-call loop failed in production-like tests and how explicit state made recovery possible.
AgentsArchitecture
- FORMAT
- story
- READ
- 8 min
- PUBLISHED
- Aug 22, 2026
- TOPICS
- Agents · Architecture
THE TAKEAWAYIf a workflow can retry, its state needs to be representable outside the model conversation.
The harmless-looking retry
A tool timed out after completing its write. The agent retried, duplicated the effect, and then reasoned from two conflicting results.
- The timeout hid completion
- Conversation history was treated as state
- The tool was not idempotent
Making transitions explicit
I moved workflow state into typed records with operation IDs, attempt counts, and terminal outcomes. The model now proposes transitions; the orchestrator owns them.
- Idempotency keys
- Durable step state
- Failure taxonomy
The broader lesson
Agentic systems become easier to reason about when they resemble dependable workflow engines more than clever prompt chains.