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.

Log in or sign up for Devpost to join the conversation.