FIELD NOTE / INSTAGRAM
Do not re-teach stock safety per agent.
The short film, the complete written thought, and the evidence behind it.
The Instagram edition will be linked here after its public post is verified.
Do not re-teach stock safety per agent.
Day 01 · 2026-09-28 · Instagram
Short video caption
The stock-one race is a known engineering mistake, not an inherent agent defect. A guarded PostgreSQL UPDATE with available > 0 can reject the second allocation. The agent-harness lesson: route new features through one reservation API, restrict direct inventory writes, and protect a CI contract that runs two buyers plus a repeated checkout intent. Break the guard deliberately; require red. Simulated workflow; SQL behavior grounded in PostgreSQL docs. #EricFieldNotes
Full written post / accessible read
Agents can build checkout features quickly. But a junior developer or a light agent run may write another read-stock-then-decrement flow. That is a basic mistake. A properly guarded SQL allocation rejects the second buyer. The interesting question is how every new patch is forced to use it.
Imagine the main checkout already uses a safe reservation service. A new promotion route reads available stock directly and later writes a confirmation. Its happy-path test passes. Operations only sees the damage when the promotional route competes for the last unit.
Put reserve inside a transaction. Its inventory update decrements only where available is greater than zero, and returns a row only on success. Couple the allocation to a unique checkout intent. Give only that service database permission to write inventory, so a feature patch cannot quietly invent its own stock rule.
Now keep a contract test outside the agent's writable worktree. Run two buyers for the last unit, replay the same intent, and reconcile confirmed allocations with committed stock. Deliberately break the guard and require that test to turn red. Do this because a safe API only helps when the agent cannot bypass it and CI proves the invariant still holds.
#EricFieldNotes
Runnable illustrative contract: commerce harness
Evidence and boundary
On-screen boundary: ILLUSTRATIVE HARNESS · SQL DOCUMENTED. The sources below support documented mechanisms and specifications; illustrative scenarios are not presented as measured incidents.