Two AI agents have been building and reviewing this product for a month without ever being online at the same time. I assumed the missing live channel was the bottleneck to work around. It turned out to be the reason the work held together at all, and this is the part of the setup doing the holding.
The two AI agents helping me build a product have never spoken to each other.
Not once.
They run on different machines and inside separate sessions. They may both be active, or one may arrive minutes or hours after the other. It does not matter: neither can call the other, inspect the other's context, or pass a message except by writing a durable record.
Together, they still completed seven rounds of code review, rejected a design, removed a feature that should not have shipped, and—with this article—produced a three-part series.
They did it by leaving notes.
That sounds almost disappointingly simple at a moment when multi-agent systems are often imagined as a room full of AIs talking to one another. I have come to think the room is optional. The written record is the collaboration.
I stopped trying to recreate a meeting
As the human owner, I do not need to watch two agents perform teamwork. I need the next piece of work to begin from the last verified decision.
Live conversation makes that harder than it first appears.
Both agents have to be available at the same time. Their discussion belongs to a context window that eventually closes. A useful decision may be buried between exploratory messages. When a new session starts, the debate can restart because the conclusion survived only as conversational residue.
Synchronous talk is useful when the problem itself needs rapid back-and-forth. But using it as the default creates a hidden requirement: preserve the participants, the timing, and the transcript long enough for the work to matter.
Our setup has no direct route between the agents. One writes a review finding to the shared record. Whether the other reads it minutes or hours later—and whether the first session is still active—is irrelevant. The reader cannot inspect or call that session. It can only reproduce the problem and write a response to the record.
The limitation forced a better question: what must be true when the next session begins?
The handoff was not overhead. It was the work
A useful record did not say, “We discussed the bug.” It contained the failing input, the observed output, the exact commit, the decision, and what remained unresolved.
That record let an agent arrive cold and still challenge the previous agent's work. It also let me, the human owner, see where evidence ended and judgment began.
In the first article in this series, a second agent rejected three claimed fixes by running the failure instead of accepting the explanation. That review worked across seven rounds because the findings, reproductions, and commit identities outlived every session.
Then we learned the opposite lesson: a durable note can become dangerous when its facts change. In the second article, a record that was once correct was retrieved later as if it described the present. Persistence alone was not enough; the record needed dates and current evidence beside it.
Those two lessons meet here:
Agents do not need a continuous conversation. They need durable records with the right lifetime and a clear owner.
The difficult part is not making agents talk. It is deciding what deserves to survive after they stop.
Four kinds of state belong on four different shelves
We found that the information agents pass to one another falls into four practical categories. They look similar inside a chat transcript. Operationally, they are not similar at all.
1. Decisions
“Store monetary values as integer cents.”
A decision may be reused for months. It needs the reason, scope, and superseding decision—not a temporary owner who happens to be online.
2. Active work and its owner
“Maya is changing the billing import; the parser is done, migration is next.”
This has a medium lifetime. It matters while the work is active and should change when ownership or progress changes.
3. Open questions
“Do we preserve the legacy identifier during migration?”
An open question changes character the instant an answer arrives. The answer should remain; the “waiting” state should not.
4. Edit claims
“I am editing the billing parser and its tests.”
This is deliberately short-lived. Its job is to keep well-behaved agents from colliding during active work. It is a signal, not a lock.
Mixing these categories breaks them in opposite directions. Put a durable decision in a temporary work log and it disappears when the task closes. Put an edit claim in permanent memory and a file can look reserved long after nobody is touching it. Put an unanswered question in a timeless note and tomorrow's agent may keep waiting after the reply has arrived.
The container cannot have one expiration policy because the contents do not share one lifetime.
The four-shelf audit
You can start with a shared document and a team chat. Before adding another agent or another tool, inventory where these four states live today.
THE FOUR-SHELF AUDIT
1. DECISIONS
Where are they written?
Who may change or supersede them?
Can a fresh session find the reason, not only the outcome?
2. ACTIVE WORK + OWNER
Where is progress updated?
Who is responsible now?
What closes or transfers the work?
3. OPEN QUESTIONS
Where is the question recorded?
Who is expected to answer?
Does the waiting state change when an answer arrives?
4. EDIT CLAIMS
What path or file is being touched?
When does the signal expire or get released?
Is everyone clear that it is advisory, not a lock?
For every shelf, add one final check: can the next session read it without reconstructing the previous conversation?
If the answer is no, the team does not yet have shared state. It has a meeting that some future agent missed.
A note is not the source of truth for everything
The written record should not replace the systems that already own durable facts.
Git remains the source of truth for committed code. Branch protection, review, and CI remain responsible for enforcing code quality. A coordination record can say which commit was reviewed or which paths an agent plans to edit; it does not make the commit correct or physically reserve the files.
This distinction matters most for claims. When one agent announces that it is editing a path, another well-behaved agent can choose different work or wait. But the signal cannot stop a process from writing. It is closer to a turn indicator than a door lock.
Treating coordination metadata as enforcement creates false safety. Treating it as disposable chat loses the value. It belongs between those extremes: durable enough for the next participant, modest enough not to impersonate the underlying system of record.
Sometimes the agents should talk
The title is intentionally provocative, not absolute.
Conversation helps when two participants must narrow an ambiguous problem quickly, negotiate a tradeoff with many unknowns, or coordinate an incident where the cost of waiting is high. Humans also need conversation when the decision carries organizational or emotional weight that cannot be reduced to fields in a record.
Even then, the outcome should leave the room.
Write down the decision, unresolved objections, evidence, owner, and next trigger. Otherwise the next session receives a transcript and has to perform the meeting again.
The goal is not “never talk.” It is do not make simultaneous presence a dependency of progress.
What this looks like in Vibsync
Vibsync is the shared brain we build at LOOSEDAYS for teams working with AI coding agents. Its shape follows the four shelves rather than a single endless agent chat:
- memories preserve decisions and reusable knowledge;
- tasks hold active work and ownership;
- async questions change from waiting to answered;
- path claims signal where an agent is working and can be released.
These are coordination records, not replacements for Git or CI. Claims are advisory. The human owner still decides what ships.
The important behavior is what happens later. An agent can connect from a different tool or machine, read the current handoff, and continue without the previous agent being present. The product is not trying to simulate a lively room. It is trying to make absence unsurprising.
This is one team, one codebase, and our own pre-release work—not a benchmark. Our two agents have no direct channel: even if both sessions are active, each works from records without access to the other's context. Written handoffs are not a preference between them; they are the only path. That constraint produced a workflow we now prefer.
Run the Four-Shelf Audit with whatever your team already uses. If the result is four clear places that every new session can read and update, you may not need another system. If the state is scattered across closed chats and individual machines, connect your agents to one Vibsync team and give the next session a place to begin.
Vibsync is built by LOOSEDAYS Co., Ltd. This is a first-hand account of one team's workflow, not a controlled comparison.
Originally published at https://vibsync.com/blog/ai-agents-dont-need-to-talk.
