Conflict Resolution

What happens when two agents try to modify the same data at the same time? Without a strategy, data gets silently corrupted. This lesson teaches three battle-tested solutions — locking, priority queues, and the conscience layer — and when to use each one.

The Problem: Race Conditions

A race condition happens when two agents read the same value, make independent changes, and both write back. The second write overwrites the first — silently destroying data. This is not a theoretical problem. It is one of the most common bugs in concurrent systems, and it is especially dangerous with AI agents because the corruption is silent.

Classic example: User balance is $100. Agent A reads $100, adds $50 (deposit). Agent B reads $100, subtracts $30 (payment). Agent A writes $150. Agent B writes $70. Final balance: $70. The $50 deposit is gone. Neither agent made an error — the race condition silently ate the deposit.

Three Solutions

Every conflict resolution strategy in computing — from database transactions to distributed systems — falls into one of three categories:

🔒

Locking

Agent acquires a lock before writing. Others must wait. Simple but can cause bottlenecks.

📜

Priority Queue

Each agent has a priority level. Higher priority writes first. Lower priority waits or merges.

🧠

Conscience Layer

An arbiter agent reviews conflicting writes and decides which one aligns with system values.

Deep Dive: Each Strategy

🔒 Locking (Pessimistic Concurrency)

Before writing, an agent acquires a lock on the resource. While locked, no other agent can write to it. After writing, the lock is released. This is the same pattern used by database transactions (SELECT ... FOR UPDATE) and file locks.

-- PostgreSQL advisory lock example
BEGIN;
SELECT pg_advisory_xact_lock(12345);  -- acquire lock
UPDATE accounts SET balance = balance + 50
  WHERE user_id = 1;
COMMIT;  -- lock auto-released

Best for: Quick operations where conflicts are common. Risk: Deadlocks — Agent A locks X and waits for Y, Agent B locks Y and waits for X. Neither can proceed.

📜 Priority Queue (Ordered Processing)

Instead of processing writes as they arrive, a queue orders them by priority. Security alerts process before analytics reports. P0 incidents before routine maintenance. The queue guarantees important writes are never starved by low-priority bulk operations.

# Priority queue: lower number = higher priority
queue = [
    {"priority": 1, "agent": "security", "action": "block_ip"},
    {"priority": 5, "agent": "analytics", "action": "update_dashboard"},
    {"priority": 3, "agent": "billing", "action": "charge_card"},
]
# Processes: security → billing → analytics

Best for: Systems where writes have different importance levels. Risk: Low-priority tasks may starve if high-priority tasks never stop arriving.

🧠 Conscience Layer (Value-Based Arbitration)

When two agents have valid but conflicting goals, a third agent — the arbiter — reviews both requests and decides which one better aligns with the system's values. This is for ethical or policy conflicts where both sides have legitimate claims.

Example: GDPR agent wants to delete user data (privacy law). Fraud agent wants to retain it (active investigation). Both are legally valid. The conscience layer weighs the priority hierarchy (covered in Lesson 10) and makes a ruling — perhaps: retain for 30 days with restricted access, then delete.

Best for: Value conflicts, ethical dilemmas, and policy disputes. Risk: The arbiter itself needs clear rules, or it becomes an unpredictable bottleneck.

Rollbacks: The Safety Net

When a conflict is detected after a write has already happened, the system needs a way to undo it. A rollback restores data to its last known good state — like Ctrl-Z for database operations.

# Simple rollback pattern: save state before modifying
def safe_update(db, key, new_value):
    # 1. Save current state
    old_value = db.execute("SELECT value FROM brain_context WHERE key = %s", [key])

    try:
        # 2. Apply the change
        db.execute("UPDATE brain_context SET value = %s WHERE key = %s", [new_value, key])
        # 3. Verify no conflict
        validate_no_conflict(key)
    except ConflictDetected:
        # 4. Rollback to previous state
        db.execute("UPDATE brain_context SET value = %s WHERE key = %s", [old_value, key])
        raise

Production databases handle this natively through transactions. BEGIN ... COMMIT groups operations atomically — if any step fails, the entire transaction rolls back.

🔒

This lesson is for Pro members

Unlock all 520+ lessons across 52 courses with Academy Pro.

Go Pro — $49/mo ← Back to course

Already a member? Sign in to access your lessons.