# Decision Points for Embedding AI Agents in Enterprise Systems # Optimistic vs Pessimistic Locking — Concurrency Control for Multi-Agent Systems 🎯 The Hook When multiple agents (or agents and humans) operate on the same resource simultaneously, how do you design the concurrency control? Do you take the optimistic stance — "collisions are rare, detect and retry" — or the pessimistic one — "lock before you touch"? The right answer depends on collision frequency and retry cost. And there is an agent-specific wrinkle: LLM inference time is non-deterministic, making lock hold time estimation harder than in traditional systems 🔑 📋 Overview Optimistic locking assumes collisions are rare. It skips locking during the operation, detects conflicts at write time via version numbers or ETags, and retries on collision. It excels at throughput and latency, but collapses when collisions become frequent. Pessimistic locking acquires a lock before the operation, blocking other agents until completion. It is suited for cases where consistency is paramount, but carries risks of deadlock and lock leakage. In enterprise environments, a hybrid that applies different strategies per resource type is the practical norm 📊 🔍 Decision Points Two axes drive this decision: collision frequency and retry cost. Estimate the concurrent access frequency for each target resource. If the collision rate is below roughly 5%, choose optimistic locking. Whether the operation is idempotent matters too. Idempotent operations make retries safe, favoring optimistic locking. If the operation has irreversible side effects, choose pessimistic locking (or combine with HITL approval). If retry re-computation cost exceeds acceptable bounds — long inference chains, external API side effects — adopt pessimistic locking. When adopting pessimistic locking, always design deadlock prevention measures (timeouts, lock ordering) ⚡ 💡 Key Details Hybrid patterns that mix strategies per resource are critical in practice: Strategy per resource type — Apply optimistic locking to read-heavy resources (knowledge articles, FAQs) and pessimistic locking to write-intensive resources (inventory, account balances). Matching the strategy to resource characteristics, rather than applying one uniformly, is the key. Escalation from optimistic to pessimistic — Run optimistic locking by default and automatically switch to pessimistic when a specific resource's collision rate exceeds a threshold (roughly 10%). Data-driven dynamic switching avoids excessive locking while maintaining safety. Short pessimistic lock with timeout — Set an upper bound on lock hold time (roughly 30 seconds) to prevent deadlock. After timeout, the lock auto-releases and the next agent picks up processing. An agent-specific consideration: LLM inference time is non-deterministic. Measure the P99 inference time and use that as the starting point for TTL configuration 🔄 ⚖️ Trade-offs Retry explosion under optimistic locking is a classic failure. Underestimating collision rates in batch processing where multiple agents update the same Salesforce records leads to cascading retries and system load spikes. Poor estimation translates directly to production incidents 😩 Deadlock under pessimistic locking is equally severe. Agent A locks resource X and requests Y, Agent B locks resource Y and requests X — this circular wait halts the entire system. Unified lock ordering and timeouts are necessary preventive measures. Lock granularity mistakes are common. Locking an entire table blocks processing of unrelated records. Record-level lock granularity should be the baseline. Lock leakage is especially dangerous in agent environments. When LLM inference terminates abnormally without releasing the lock, subsequent processing is blocked indefinitely. Use TTL-based locks (Redis SET ... EX) or lease-based mechanisms as countermeasures ⚠️ 🛠️ Use Cases Inventory management agent (Shopify integration): Multiple agents may decrement inventory simultaneously, so pessimistic locking prevents overselling. Lock TTL is set at 5 seconds accounting for API round-trip time. On timeout, the lock auto-releases and the task returns to the retry queue 📚 Opportunity management agent (Salesforce integration): Multiple agents rarely update the same opportunity's notes simultaneously, so optimistic locking (ETag) is used. When a collision is detected, the agent attempts a diff merge of the notes. Only unresolvable merge conflicts escalate to a human 🏢 Change management agent (ServiceNow integration): Change management records may be edited by a single agent over an extended period, making pessimistic locking appropriate. However, the lock hold time cap is 30 seconds — if LLM inference runs long, the lock is released and re-acquired to prevent blocking 🔧 Practical tip: Start by measuring actual collision rates on production data. Choose your locking strategy based on real data, not assumptions. And in agent environments, make "every lock must have a TTL" an ironclad rule. LLM inference can extend unpredictably, so TTL-free locks are simply not an option 💪 #AIAgents# #EnterpriseArchitecture#