A-Lock

A lock server for synchronizing concurrent AI agent access to shared resources.


Problem

Running multiple AI agents against the same resources creates race conditions. One agent can modify a resource that a second agent has already read, causing the second agent to operate on stale context. This manifests across domains:

  • Storywriting – an agent updates a character's persona while another writes dialogue for the old one.
  • Coding – two agents edit the same file and produce conflicting changesets.
  • Business proposals – financial figures are revised while another agent drafts a section that cites the old numbers.

Solution

A-Lock implements a resource-level lock system accessible over HTTP (suitable as an MCP tool backend). Before reading and modifying a shared resource, an agent acquires an exclusive lock. Other agents that want the same resource poll until the lock is released.

This approach was chosen over alternatives because:

Alternative Reason discarded
Let agents self-verify (re-read and diff) Wastes compute; does not guarantee consistency
Serialize all agents (global lock) Defeats the purpose of parallelism
Resource-level locks (chosen) Maximises parallelism while guaranteeing consistency per resource

Atomicity is guaranteed at the database layer via PostgreSQL's INSERT ... ON CONFLICT DO NOTHING on a unique-constrained resource_id column — no two concurrent requests can both receive a successful lock for the same resource.

Built With

Share this project:

Updates