Reading availability is a hint about a changing world. A reservation is a state transition that needs a single authority to enforce available >= requested. Agents may reason concurrently, but the inventory service must atomically decide which request owns the unit. In a relational store, that can be a conditional update that only decrements a positive balance, a row lock around the check and update, or a properly handled serializable transaction. PostgreSQL's isolation documentation explains the concurrency rules, and its serialization failure guidance says to retry the complete transaction when a serializable attempt fails. Reading once, then trusting the model's plan across a separate write, is not a transaction.

The tool should return a reservation ID, authoritative status and expiry. The agent can promise the unit only after a confirmed reservation, and should phrase earlier text as tentative. If reservation fails, offer alternatives rather than inventing success. A client timeout creates an unknown outcome, so retry with the same idempotency key and reconcile by reservation ID before making another hold. Expired holds must release inventory in one authoritative system. A cancellation request may race a successful commit, so the user needs the actual final status, not just the agent's intention.

For a large system, I would decide whether inventory is held centrally per item, partitioned by item or delegated in bounded allocations to regions. The last-unit case cannot be solved by each region independently decrementing a stale replica. If availability is approximate for browsing, say so. At the commit point, enforce a nonnegative invariant and audit competing reservations. Test two concurrent agents and the timeout-after-commit case. Measure oversells, rejected holds, latency and abandoned holds, not just successful tool calls.

What if we reserve before the user confirms? Then scarce inventory can be hoarded by speculative agent plans. Give holds a short TTL and a capacity budget, or collect intent first and reserve at a clearer point. Two subagents update the same customer case note. Which changes survive? is about merging two edits to one case note. The refund succeeded but the agent crashed. What happens next? covers a refund that succeeded before a crash. This question combines contention for a scarce resource with what the agent is allowed to say before the authoritative write wins.