Double Texting & Concurrency
Stateful agents share a thread — two concurrent runs racing on the same checkpoint will silently corrupt state. LangSmith Deployment provides four built-in strategies for handling concurrent messages: reject, rollback, interrupt, and enqueue. The most dangerous production gap is not choosing the wrong strategy; it is using rollback without guarding against permanent external side effects.
Quick Reference
- →Double texting occurs when a user sends a new message while the agent is still processing the previous one — every stateful agent needs a concurrency strategy
- →Four strategies in LangSmith Deployment: reject (return 409 Conflict), rollback (cancel + delete run, revert state), interrupt (stop run, keep in DB, start new), enqueue (queue and process sequentially)
- →Enqueue is the default strategy — the most conservative and safe choice for most task agents
- →Interrupt stops the in-progress run (status → 'interrupted', kept in DB) and starts a new run — it does not inject mid-stream into a running graph
- →Rollback deletes the original run from the database entirely — the thread reverts to the last checkpoint; choose this only when audit trail is not required
- →External API calls (payments, emails, bookings) are permanent — rollback reverts thread state but cannot undo a committed external side effect
- →Test double-texting explicitly: fire two concurrent runs.create() calls on the same thread and assert the expected run statuses
The Race Condition
In production, this is not an edge case — it is the default. Mobile users tap twice. Correction messages arrive before the first response completes. Without a concurrency strategy, two runs race on the same checkpoint and one of them loses.
Traditional request/response APIs are stateless — each HTTP call is independent. Agent conversations are stateful: every run reads from and writes to a shared thread checkpoint. Two concurrent runs that both read checkpoint C and then write back produce a last-write-wins conflict. One update is silently overwritten. State is corrupted with no error, no log, and no indication to the user.
The concrete sequence: (1) User sends 'Book a flight to NYC' — run 1 starts and reads checkpoint C₀. (2) Before run 1 completes, user sends 'Actually, make that Boston' — run 2 starts and also reads C₀. (3) Run 1 writes C₁ with NYC booking state. (4) Run 2 writes C₁ with Boston intent, overwriting run 1's update. Depending on write ordering, the user either sees two conflicting responses or one response that silently ignores their correction.
Concurrency handling at the thread level requires a persistent checkpoint store coordinated by the deployment infrastructure. The four strategies described here are built into LangSmith Deployment (formerly LangGraph Platform, renamed October 2025). The open-source LangGraph library does not provide this — without the deployment layer you would need distributed locks.