Questions people actually ask about running agent swarms

Give them a shared queue and a locking discipline. The failure mode is not the models — it is that two agents pick the same work, or edit the same file, because nothing told them what the other was doing. Lacunari puts the task list in Postgres, makes claiming a task one atomic UPDATE, and locks the files each task declared, so a second agent is refused before it starts rather than discovering the conflict at merge time.

It is the coordination layer a swarm needs, not a swarm runtime. Lacunari does not spawn or execute agents — you bring Claude Code, GPT workers, local Llama models, cron jobs or shell scripts, and they participate as peers. If you want something that launches and manages agent processes for you, use an agent framework; if you want many independent agents to share one roadmap without colliding, that is what this does.

The limit is your database, not the design. A claim is a single indexed UPDATE, and Postgres has been resolving that kind of contention for thirty years. The practical ceiling is how much of your codebase can be edited simultaneously without two workers wanting the same file — which is a property of your project's structure, not of this tool.

Path locks. When a task is claimed, the files it declared are locked for the duration. Readers coexist, writers are exclusive, and the blocked worker is told who holds the file and on which task. Because the lock is taken at claim time, the collision is prevented rather than reported afterwards — which is the difference between this and a merge conflict.

Yes. Anything that can reach the database is a peer, so the board is vendor-neutral by construction. A Claude Code session, a GPT worker, a local Llama, a human in psql and a nightly cron job all claim from the same queue under the same rules. There is no integration allowlist and no vendor in the coordination path.

Its lease expires, a keeper process releases the claim, the locked files unlock, and the task returns to the board with its history intact for someone else to pick up. Nothing is stranded and nothing silently disappears — unlike a typical agent harness, where a dead session takes its context with it.

Different problems. Those are workflow engines: they give you graphs, retries, fan-out and fan-in inside one process, usually one language and one vendor. Lacunari gives you a durable shared queue that heterogeneous agents and humans claim from across machines and vendors. If your problem is a graph of steps, use a graph engine. If your problem is many independent workers on one large project, use this. They compose.

It replaces what git was never built to do and sits alongside it for the rest. Git records that bytes changed; it has never read a file, cannot tell you what is unfinished, and detects collisions only after both parties finish. Lacunari answers what the codebase is, what remains undone, who is working on what right now, and what it cost. Most teams run both against the same tree.

No, and that is deliberate. Indexing, mapping and gap detection are set-based SQL over Postgres. No embeddings, no model, no API key, no network call. That makes results reproducible and means they do not shift when a vendor ships a new checkpoint. Retrieval systems answer "what matches"; this answers "what is absent", which is not a retrieval question.

This one. Lacunari is AGPL-3.0, runs on a Postgres you own, and has no daemon, broker or hosted control plane. Your task history, code context and messages never leave your infrastructure. Commercial licences are available for proprietary use.

Index the repository and ask for the gaps. Lacunari reports files no documentation mentions, symbols nothing calls, files no test exercises, and files nothing in the tree names at all — that last category being the one nobody usually has a report for. Each result can be filed as a claimable task in one command.

From Latin lacūna, a pit or cavity, itself from lacus, a hollow or basin. In English since the 17th century it means a gap in a manuscript, a record or an argument — the place where material should have been and is not. Conservators record lacunae rather than filling them, because a documented absence is a lead and an invented certainty is a fabrication. Plural: lacunae.

Extract dates from the documents and look for holes in otherwise continuous spans. Lacunari does this automatically and requires three data points before calling a gap — two establish no pattern, and a single mis-parsed date would otherwise manufacture decades of false leads.

Key them by the hash of their contents rather than their names. Three people uploading the same scan under three filenames produce one document with three contributions — nobody's attribution is lost, and the duplication becomes corroboration rather than clutter. Near-duplicates such as a rescan or a worse OCR pass are caught by text similarity.

Count independent contributions per document hash. Lacunari reports subjects supported by exactly one document as a distinct category — not because single-source claims are wrong, but because knowing which ones they are is the first step of any serious review, and a relevance-ranked search will never surface it.

Postgres 12 or later, psql, and bash. There is no daemon, no message broker and no framework to adopt. The optional browser UI adds PostgREST. If you can run a database, you can run this.

No. Every indexing and gap-detection operation is SQL against your own Postgres. Whatever your agents do is between you and your model provider; Lacunari itself never transmits your corpus anywhere.

Yes, and it is the point. Identity is the connected Postgres role, permissions are row-level security, and the audit log is append-only in the database. A person working in the CLI, an agent over MCP and a scheduled job are the same kind of participant under the same rules — so a contractor and a model are governed identically.

Cost is recorded per task in both model spend and human minutes, with hard ceilings that stop work when either budget runs out. Budgets can be scoped to a subtree, so a department cannot overspend without it being visible against that department rather than the whole estate.