Lacunari

Use case · Software engineering

A fleet of agents on one codebase

The hard part of multi-agent development is not getting a model to write good code. It is that ten agents pointed at one repository will duplicate each other's work, overwrite each other's files, and stop dead the moment they finish a task, because none of them can see the project.

The situation

You inherit six years of accretion. The two people who wrote most of it are gone. There is a mandate to ship something on top of it, and you have a budget for as much model capacity as you care to spend.

The obvious move — point an agent at it and start prompting — hits a wall in about an hour. The agent does good work on whatever you named, then stops. You name the next thing. It works, then stops. You are now a dispatcher with a very expensive typist, and adding a second agent makes it worse rather than better.

Step one: let it read the whole thing

$ lac doc index . --source my-repo $ lac doc extract $ lac web build

Not an embedding blob — a structured map. Language, line count, every symbol defined, every import, which file names which. Content-addressed, so the same vendored file in three places is one document with three contributions rather than three copies competing for relevance.

Step two: ask what you actually have

$ lac web gaps files 92 · 6 languages · 13,582 lines files_no_doc_mentions 29 symbols_nothing_uses 122 files_nothing_names 2 files_no_test_mentions 86

That is real output from Lacunari indexing itself. Two files that nothing in the tree names at all — either entry points or dead code, and nobody had a report that could tell you which. That number is not in git, not in your issue tracker, and not in any agent's context window.

Step three: turn the map into a queue

$ lac web suggest --dispatch → 47 tasks filed

Every gap becomes a task with a title, a priority and a stable identity. Nobody wrote the roadmap by hand. And because the identity is stable, a task withdraws itself when the gap closes — write the missing document and the task that asked for it disappears on the next pass, without anyone grooming a backlog.

Step four: add capacity until you run out of money

$ lac work & lac work & lac work & lac work & lac work & $ lac spend budget global 40.00 # a ceiling it cannot cross

Each worker asks the board for the top task it is capable of, claims it atomically, declares the files it will touch, does the work, records what it cost, and asks again. They do not collide, and the reasons are structural:

  • A claim is one atomic UPDATE. Two workers cannot hold one task.
  • A claim locks the declared files. The second worker is told "claude·2 holds auth.py on task #12" and picks something else, rather than discovering the conflict at merge time.
  • Capabilities route the work. The agent with deploy credentials gets the deploy task; the one without never sees it.
  • A dead worker loses its lease. Files unlock, the task returns to the board with its history, someone else continues.
  • Ambiguity escalates to a human on a deduplicated backoff, instead of being guessed at confidently.
Git — the conflict is discovered afterwards agent A writes auth.py — 40k tokens agent B writes auth.py — 40k tokens ✕ merge conflict — both wasted Lacunari — the second attempt is refused first agent A claims auth.py, works agent B told "A holds it" → picks another task
Same collision, different moment. A merge conflict is a fine detector at human speed. At agent speed the tokens are already spent by the time it fires.

What changes

You stop being the scheduler. The roadmap is derived from the code rather than from your memory, it updates itself as work lands, and capacity is a process you start rather than a conversation you hold. The interesting constraint becomes budget and review throughput — which are problems you can actually buy your way out of.

It works with the agents you already use. Claude Code, a local Llama, a GPT worker, or a bash script — anything that can read a task and return an exit code is a peer. executors/ is the seam.