Building agents that recover instead of merely retrying

Retry is not recovery

Many agent prototypes treat failure as a temporary inconvenience. They retry the same tool call, re-ask the same model or restart the loop. That can work for flaky networks. It does not work for partial progress, contradictory state or tools that have already taken irreversible actions.

What recovery requires

Reliable agent systems need:

• Explicit state — What has been decided, retrieved, written or approved?
• Checkpoints — Where can execution safely pause and resume?
• Tool contracts — What can each tool do, and what can go wrong?
• Approval points — Which actions require human confirmation?
• Observability — Can an operator understand the path that led to failure?

Without these, “agentic” often means “opaque.”

Design for partial success

Real workflows fail in the middle. A useful agent architecture expects incomplete outcomes and designs recovery from them. That may mean rolling back a draft, re-planning from a known checkpoint, escalating to a human or switching to a constrained tool path.

Evaluation for agents

Agent evaluation should not stop at final-answer correctness. Measure recovery behaviour, unnecessary tool use, unsafe actions avoided and the quality of intermediate decisions. A system that reaches the right answer by unsafe thrashing is not production-ready.

Asthra treats agent work as systems engineering with model components—not as unbounded autonomy layered onto a demo script.