# Can a Shared Ledger Fix Coordination Problems Between AI Coding Agents?
## The Core Problem
When multiple AI coding agents work on the same codebase, a surprising number of things can go wrong—even when the agents are actively communicating through text chat. They duplicate work. They start implementing a file that another agent already finished. They miss dependency relationships and begin tasks before prerequisites are ready. And all of this happens silently, buried in a stream of messages that no one can easily audit after the fact.
The root issue isn’t a lack of communication. It’s a lack of persistent, checkable state. When Agent A says “I’ll build the items file,” that promise lives and dies inside the chat window. Agent B has no reliable way to discover it before making the same claim. The conversation becomes a fragile record that agents themselves must remember and cross-reference—a task that language models are demonstrably bad at doing across multiple turns and separate sessions.
## What a Commitment Ledger Is
A commitment ledger is a small, deterministic system that pulls agent promises out of the conversation and gives them a place to live outside the chat. It records each commitment as structured state, then runs a series of automated checks against that state to surface coordination problems before they compound into wasted effort.
The entire system is built with nothing but Python’s standard library. There is no database, no API call, and no external package dependency. Every input produces the same output every time, making the system fully reproducible and easy to audit.
### How It Works
The pipeline has three main stages:
**Stage 1 — Commitment Detection.** A rules-based parser scans agent messages for explicit promises to build, modify, or implement something specific. It looks for a fixed set of verbs—*add, create, delete, implement, modify, remove, rename, refactor, update, fix, test, document, review*—paired with a concrete target such as a file path, a module name, an endpoint route, or a quoted task description. Anything that doesn’t match the pattern is rejected outright. There is no semantic guessing. The detector either accepts a message as a commitment or it doesn’t.
**Stage 2 — The Ledger.** Each accepted commitment enters an immutable event history. The ledger tracks not just the current status of a task, but every status transition: committed, started, implemented, tested, reported, verified, abandoned, or conflicted. This history matters because it preserves context. If a later agent makes a duplicate claim, the original commitment’s record stays intact and the new claim is flagged separately.
**Stage 3 — Coordination Checks.** The ledger runs five automated checks against the stored history:
1. **Missed commitments** — tasks that were promised but never started.
2. **Unverified commitments** — tasks that reached “reported” but were never independently confirmed.
3. **Conflicted commitments** — two agents claiming the same object simultaneously.
4. **Dependency-not-notified** — an agent starting work before a required prerequisite has been claimed or completed.
5. **Rework** — an agent implementing a task that was later abandoned, typically due to a discovered conflict.
None of these checks require the agents to report anything themselves. The ledger draws its conclusions entirely from the structured record of what was committed and what happened next.
## A Controlled Test Case
To evaluate the system, a simple item catalog project was used. It has a clear dependency structure: a data model must exist before the repository and pricing service can be built; both of those must be complete before the API endpoint is implemented; and the endpoint must be in place before tests are written.
Two agents work on the same codebase with no pre-assigned file ownership. They must decide between themselves who takes each piece of work. Two transcripts were prepared for the same task—one where the agents coordinate through chat alone, and one where they check the ledger’s existing commitments before taking on new work. The evaluation code is identical in both cases; the only difference is whether the ledger is consulted.
### Results
The ledger made a meaningful difference in three out of five coordination metrics:
| Metric | Chat Only | Chat + Ledger |
|—|—|—|
| Missed commitments | 1 | 1 |
| Unverified commitments | 1 | 1 |
| Conflicted commitments | 1 | 0 |
| Dependency not notified | 1 | 0 |
| Rework | 1 | 0 |
When agents had access to the ledger, duplicate claims on the same file disappeared. Dependency violations stopped occurring because agents checked prerequisites before starting work. And rework dropped to zero because the conflicting duplicate effort never happened in the first place.
The two metrics that didn’t change—missed commitments and unverified commitments—reveal the ledger’s boundary. One agent promised to write tests but never started them. Another agent reported finishing implementation but the result was never verified. The ledger recorded these facts accurately, but it had no mechanism to make the agents follow through or to confirm that reported work was actually correct.
## What This Means in Practice
The results point to a clear conclusion: making commitments explicit and persistent can eliminate a specific category of coordination failures—the ones caused by agents operating with incomplete shared information. But it does not solve execution failures or verification gaps.
Think of the ledger as a whiteboard in a shared workspace. It helps people know who is doing what and whether prerequisites are in place. It does not, by itself, make sure people show up on time or do their work correctly. Those require separate systems—enforcement mechanisms, deadlines, and independent quality checks.
## Limitations Worth Understanding
The system as demonstrated has several deliberate limitations:
**The detector is strict by design.** It only accepts very specific sentence patterns. A message like “I’ll handle the pricing stuff” is a real commitment to a human reader but gets rejected by the detector. This rigidity is intentional—it makes the detector fully testable and predictable, even if it misses some commitments that a human would catch.
**Verification is external.** The ledger trusts the events it receives. It does not run tests, inspect code, or independently confirm that reported work is correct. A future version would need to integrate with actual test runners or code review tools to close this gap.
**Only two agents were tested.** The conflict check itself should work with any number of agents, but the system has only been demonstrated with a pair. Scaling to three or more agents introduces dependency chains and interaction patterns that would need their own evaluation.
**The dependency map is hand-built.** In the test case, five dependency relationships were hardcoded. For a real codebase, that graph would need to be generated automatically from the project’s structure—and kept up to date as the code evolves.
## FAQ
**Q: What programming language and tools does the ledger use?**
A: The entire system is written in Python and relies exclusively on the Python standard library. The test suite uses pytest. No external packages, databases, APIs, or model calls are required at any point.
**Q: Does the ledger use an AI model to read or interpret agent messages?**
A: No. The commitment detector uses a frozen grammar—a fixed set of regex patterns and verb lists—to identify explicit commitments. This means the detector’s behavior is fully deterministic and reproducible.
**Q: What counts as a “commitment” in the system?**
A: A commitment is an explicit promise to perform an action (one of 13 predefined verbs) on a specific, concrete target—such as a file path, module name, endpoint route, or dotted module reference. Vague promises, suggestions, questions, and statements about other agents are all rejected.
**Q: What happens if two agents claim the same file?**
A: The ledger marks the later claim as CONFLICTED while preserving the original commitment’s history intact. This prevents the first agent’s valid progress from being overwritten or erased by a subsequent duplicate claim.
**Q: Can the ledger verify whether completed work is actually correct?**
A: No. The ledger tracks what agents report and what commitments exist, but it does not independently inspect code or run tests. Verification requires a separate mechanism outside the ledger.
**Q: What are the five failure modes the ledger detects?**
A: Missed commitments (promised but never started), unverified commitments (reported but not confirmed), conflicted commitments (duplicate claims on the same object), dependency-not-notified (starting work before prerequisites are met), and rework (implementing a task that was later abandoned).
**Q: Is this a benchmark result or a single demonstration?**
A: The results come from a single hand-constructed test case designed to exercise all five detection rules. It is not a statistical sample from many independent runs and cannot be generalized to real-world multi-agent coding pipelines without further evaluation.
## Conclusion
A commitment ledger is a modest but useful tool for a specific problem: the coordination failures that happen when multiple AI coding agents share a codebase but lack any persistent record of who promised to do what. By extracting promises from the chat and storing them as explicit, checkable state, the ledger can prevent duplicate work, catch missing dependencies, and flag conflicting claims—all without relying on any AI model calls or external services.
At the same time, the ledger has clear boundaries. It cannot make an agent follow through on a task it has ignored. It cannot verify that reported work is actually correct. And its strict detection rules mean some legitimate commitments will be missed. These are not bugs in the design—they are honest limitations that come with the scope of what a shared record can accomplish.
The broader lesson is that better coordination state is valuable, but it is not the same thing as reliable execution. A ledger makes promises visible. Making promises keepable requires additional systems for enforcement, deadlines, and independent verification.
Thank you for reading
