Coordinating several AI coding agents on one machine with a 230-line SQLite tool

A developer at kanibal-studio released agent-collab-kit, a roughly 230-line Python tool built on the standard library and SQLite that coordinates multiple AI coding agents running on one machine. The tool provides an idempotent message inbox with acknowledgement and resource claims backed by expiring leases and generation UUIDs, so a paused agent whose lease was taken over cannot renew or release its successor's claim. Every mutation runs inside SQLite BEGIN IMMEDIATE, and the test suite includes two real processes racing for a single claim.

When you run several AI coding agents at once on the same machine several Claude Code sessions, a worker plus an integrator, or a mix of tools , two problems show up quickly: src/add.py , and the second write quietly wins. We hit both while building our own internal tooling, so we wrote a deliberately small answer to them: agent-collab-kit https://github.com/kanibal-studio/agent-collab-kit , one Python file of about 230 lines, standard library and SQLite only, MIT licensed. Every message lives in a local SQLite file until the recipient acknowledges it. Here is the demo from the README, run against a throwaway database: DB=$ mktemp -d /demo.db python3 agent collab.py --db "$DB" init python3 agent collab.py --db "$DB" send --sender worker-a --recipient integrator \ --key demo-result-1 --body 'Addition is ready for review' python3 agent collab.py --db "$DB" inbox --recipient integrator {"id": "2fd715fc-...", "idempotency key": "demo-result-1", "sender": "worker-a", "recipient": "integrator", "body": "Addition is ready for review", "acknowledged at": null} The idempotency key matters for agents: an agent that retries after a crash and sends the same sender, recipient and body gets the existing message back instead of a duplicate. Reusing the key for different content is an error. ack marks the message as received. It does not prove the work was delivered or tested, and the README says so. Before editing, an agent claims the exact resource it is about to touch: python3 agent collab.py --db "$DB" claim --resource src/add.py --owner worker-a --ttl 300 {"resource": "src/add.py", "owner": "worker-a", "generation": "6ca2d25b-...", ...} python3 agent collab.py --db "$DB" claim --resource src/add.py --owner worker-b --ttl 300 resource has an active lease exit code 1 Each claim gets a fresh generation UUID . Renewing or releasing requires the matching owner and generation, and an unexpired lease. That closes a nasty case: an agent that was paused, whose lease expired and was taken over, cannot later renew or release its successor's lease, even under the same owner name. Every mutation runs inside SQLite BEGIN IMMEDIATE , and the test suite includes two real processes racing for one claim. This is the part we care most about stating clearly: In practice we pair it with one rule: a single integrator reviews and merges, and a shared resource such as commit serializes integration. The repository includes a fictitious COLLAB.md board and a short method for letting project agents propose improvements under supervision. We publish the reusable pieces of our stack under kanibal-studio https://github.com/kanibal-studio , each with its own tests and the same habit of saying what it does not do: Issues and criticism are welcome, especially about the lease semantics.