LLMs, GenAI, RAG, agents, evaluation · insight-1559
Re-check preconditions at write time with a version token, not only at read time
- Evidence type
- documented fact
- Difficulty
- hard
- Roles
- ML engineer, Applied AI
- Industries
- aviation
Summary: situation, action, reason, boundary
Situation
An agent reads seat availability or a fare early in a long run and makes the booking change many steps later.
Action
Have the read tool return a version or ETag, pass it back with the write, and let the write fail with a clear conflict error when the version no longer matches, so the agent re-reads and replans.
Reason
Conditional requests make an update apply only when the stored version still matches, which prevents lost updates and returns a precondition-failed status otherwise.
Boundary
Any agent that reads state, reasons for many steps, then writes.
Symptom or risk
The state changed in between, so the write overbooks, uses an old price or overwrites someone else's update.
Exceptions
Append-only writes with no dependency on earlier reads need no token.
Trade-offs
Conflicts cost a retry; the backing API must support versioning.
Pitfalls
Fetching a fresh version inside the write tool silently, which defeats the check.
Lessons and concepts
Claims and their sources
MDN documents that If-Match makes a PUT conditional on the stored resource still matching a client-supplied ETag, preventing lost updates, and the server answers 412 Precondition Failed when it does not.