Quick answer (TL;DR): Once you work seriously with AI, you’ll have several conversations running at once — and they can’t see each other. If two of them update your shared memory without coordinating, your single source of truth quietly forks into two contradictory versions. This is “branching,” and it silently destroys work. The fix is a protocol: every session reads the shared source of truth first, writes back before ending, logs what it changed in a dated ledger, and states which tools it had available. Updates are version-stamped so stale copies are obvious. This gives you the speed of parallel work without the chaos of overwriting yourself.
If you’ve adopted an AI second brain, this is the failure mode nobody warns you about — and the one that will burn you if you don’t plan for it.
The problem: parallel chats can’t see each other
Here’s the situation you’ll find yourself in fast, once AI becomes a real part of your workflow. You’ll have:
- One conversation going for this project.
- Another for that fire that just started.
- One you opened on your phone during a meeting.
- Maybe one a teammate started against the same shared files.
Each of these conversations is isolated. None of them can see the others. Each one reads your shared memory (the standing handoff and context files), does some work, and writes back.
And there’s the trap: if two sessions read the same file, then both write back, the second one to save overwrites the first — and any changes the first one made are silently gone. Your carefully maintained single source of truth has just forked into versions that don’t agree, and you may not notice until something downstream breaks.
This is branching. In software, version control systems exist precisely to manage it. With AI second brains, most people have no equivalent — so they lose work without realizing it.
How I learned this the hard way
I hit this when one of my AI sessions couldn’t reach a tool that another session had used. It did good, careful work in isolation — and left the shared memory behind, because it didn’t know to update it (and partly couldn’t). Meanwhile another session, working from the now-stale shared files, had a different picture of reality. The two diverged. Reconciling them by hand was the wake-up call that I needed an actual protocol.
The lesson: the answer is not to stop using parallel chats. That flexibility — fire here, deep work there, quick check on mobile — is half the value of the whole approach. The answer is a discipline that keeps them in sync.
The Anti-Branching Protocol
Four rules. Simple to state, powerful in effect.
Rule 1: Read the source of truth first — always
Every session, before doing anything else, reads the standing handoff (your single source of truth) and the relevant context files. No session acts on a stale or assumed picture. This is the same opening ritual that powers the second brain generally, but here it does double duty: it ensures every parallel session starts from the latest committed state.
Rule 2: Write back before ending
Every session updates the source of truth before it stops — recording what shipped, what changed, what’s now pending. The session is disposable; the write-back is what makes its work persist and visible to the next session, parallel or not.
Rule 3: Log what you changed in a dated ledger
This is the backstop that makes branching survivable. Inside the standing handoff, keep a change ledger: a running, dated list of “this session did these specific things.” For example:
Session A (Tue PM): closed item 3435; updated item 4817 status; ran a full reconcile. Session B (Tue AM): relabeled item 4818 → 4819; marked the template build done.
Why it matters: even if two sessions briefly diverge, the ledger lets you reconcile by hand instead of silently losing work. It turns an invisible merge conflict into a visible one you can actually resolve. It’s the difference between “I think everything’s in sync” and “I can see exactly what each session touched.”
Rule 4: State which tools you had available
Tools and integrations vary from session to session — one chat has access to your email, another doesn’t; one can reach a tracker, another can’t. At the end of each session, record which tools it actually had. This tells the next session what the previous one couldn’t do, so gaps get caught instead of assumed away. (“The morning session had no email access, so it couldn’t sweep for new requests” is exactly the kind of thing that prevents a dropped ball.)
The supporting convention: version-stamp everything
Underpinning the whole protocol is a simple file convention: every update to a maintained file gets a version number and timestamp in its header. Something like:
CURRENT — v4 · 2026-06-16 13:40
This does two things. First, it makes the newest version of any file unmistakable, so if duplicates exist (common when your tools can’t edit in place and “updating” means recreating), you can instantly tell which is live. Second, it gives the change ledger something concrete to point at. The rule for cleanup becomes trivially simple: anything without the latest stamp is stale and safe to discard.
Putting it together: the lifecycle of a session
Here’s the full protocol as a single loop every session follows:
- Read the standing handoff and relevant files (Rule 1).
- Do the work.
- Write back updates to the source of truth and item files (Rule 2).
- Log what changed in the dated ledger (Rule 3).
- State which tools were available this session (Rule 4).
- Stamp the new version of any updated file.
Six steps, most of them automatic once you’ve told your assistant this is how you work. The payoff is that you can fearlessly run five conversations across three devices and still have one coherent, trustworthy source of truth at the end of the day.
Why this matters more as AI gets more capable
As assistants get more autonomous and you delegate more, you’ll naturally run more parallel work, not less. The branching risk grows with your ambition. A protocol that seems like overkill when you’re running one chat becomes essential the moment you’re running several — and the habit is far easier to build early than to retrofit after you’ve lost work to a silent overwrite.
Think of it the way collaborative document editing works: multiple editors on one file is wonderful with a system that tracks and merges changes, and a disaster without one. The Anti-Branching Protocol is that system for your AI second brain.
Frequently asked questions
What is “branching” in an AI workflow? It’s when multiple AI conversations independently update your shared memory or source-of-truth files without coordinating, causing them to fork into contradictory versions and silently overwrite each other’s work.
How do I run multiple AI chats without conflicts? Follow a protocol: every session reads the single source of truth first, writes back before ending, logs its specific changes in a dated ledger, and records which tools it had available. Version-stamp every file update so the latest copy is always clear.
What is a change ledger and why do I need one? A change ledger is a dated, running list inside your source-of-truth file recording what each session changed. It’s the backstop that lets you reconcile diverging parallel sessions by hand instead of losing work to silent overwrites.
Should I just use one AI chat to avoid this? You can, but running parallel chats (per project, per device, per fire) is a major productivity advantage. The protocol lets you keep that flexibility safely rather than giving it up.
This is Part 4 of a series on building a working method with AI. Next: how to map exactly what your AI tools can and can’t do — and why a capability audit saves you hours of frustration.