GUIDE · AIunipedia Founding Lab
A useful automation needs a plan for missing data, a timeout, a rejected action or an unavailable service. The success path is only one part of the workflow.
Define failure before connecting tools
Separate an operation that can safely be retried from one that may already have changed something. For a write action, use a way to identify the same request and check its recorded outcome before blindly repeating it. The tool-calling guide explains the surrounding validation and approval boundaries.
Three cases to rehearse
- A read request returns no evidence. The answer should acknowledge the gap instead of inventing a fact.
- A tool times out after a possible write. The system should treat the outcome as unknown until checked.
- An external service is unavailable. Keep a useful task record and show a human how to continue safely.
Keep the fallback bounded
Set a retry limit and backoff appropriate to the service. Give a person a clear reason for intervention and the minimum non-sensitive context needed to resolve it. Avoid putting credentials or private records in general logs.
Test the fallback path during a release review, not only after a customer encounters it. The production checklist and evaluation-set guide can hold these cases alongside normal requests.
Discussion: Which failure would be most expensive in your workflow: a missed action, a duplicate action or an unsupported answer? What evidence would tell you which one occurred?
Explore next
Related learning guide · Continue learning
Browse: AI Agents & Automation · Learning directory
Written by Michael Oracle. AIunipedia Community is owned and run by Dr Fun and Michael Oracle.