Quick answer (TL;DR): Once an ops team works seriously with AI, several sessions run at once: one person on a lead-routing fix, another on an attribution report, someone checking a sync error from their phone. Those sessions can’t see each other. If two of them update the team’s shared memory without coordinating, the source of truth forks into contradictory versions. We call this “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 could reach. Updates are version-stamped so stale copies are obvious. You get the speed of parallel work without the team overwriting itself.
If your team has adopted a shared AI memory of your stack, this is the failure mode nobody warns you about.
The problem: parallel sessions can’t see each other
Here’s what an ops team’s week looks like once AI is part of it:
- One session working through a HubSpot workflow audit.
- Another handling an urgent “leads aren’t reaching the SDRs” escalation.
- One a teammate opened on mobile during pipeline review.
- One an agency partner started against the same shared files.
Each conversation is isolated. Each reads the shared memory (the standing handoff, the stack map, the workflow files), does some work and writes back.
That’s the trap. If two sessions read the same file and both write back, the second save overwrites the first, and the first session’s changes are gone. The team’s source of truth has forked into versions that disagree, and nobody notices until a stakeholder asks why the routing doc says one thing and the live workflow does another.
This is branching. Software teams have version control for exactly this reason. Most ops teams using AI have no equivalent.
How we learned this
We hit it when one session couldn’t reach a tool that another session had used. It did careful work in isolation but didn’t update the shared memory, partly because it couldn’t. Meanwhile another session, working from the now-stale files, had a different picture of the stack. Reconciling the two by hand showed us we needed an actual protocol.
The lesson: the answer is not to stop running parallel sessions. Being able to work the escalation in one window and the audit in another is half the value. The answer is a discipline that keeps them in sync.
The Anti-Branching Protocol
Four rules. Simple to state, and they change a lot.
Rule 1: Read the source of truth first, always
Every session reads the standing handoff and the relevant files before doing anything. No session acts on a stale or assumed picture of the stack. It’s the same opening ritual that runs the whole system, doing double duty: 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: what shipped, what changed, what’s now pending. The session is disposable. The write-back is what makes its work visible to the next session and the next teammate.
Rule 3: Log what changed in a dated ledger
This is the backstop. Inside the standing handoff, keep a change ledger: a running, dated list of what each session did. For example:
Session A (Tue PM): paused the “Reassign stale MQLs” workflow; updated the routing file; ran the weekly reconcile. Session B (Tue AM): renamed lead status “Working” to “In Progress” in the glossary; marked the round-robin rebuild done.
Even if two sessions briefly diverge, the ledger lets you reconcile by hand instead of losing work silently. An invisible conflict becomes a visible one. It also gives you the change history an auditor, or a new ops lead, will want: who changed what, and when.
Rule 4: State which tools the session could reach
Access varies from session to session. One chat can read the Salesforce reports, another can’t; one has the Slack integration, another doesn’t. At the end of each session, record which tools it actually had. The next session then knows what the previous one couldn’t check. (“The morning session had no access to the ticket queue, so it didn’t sweep for new routing requests” is exactly the note that stops a dropped escalation.)
The supporting convention: version-stamp everything
Under the whole protocol sits a simple file convention: every update to a maintained file gets a version number and timestamp in its header. For example:
CURRENT — v4 · 2026-06-16 13:40
This does two things. It makes the newest version of any file unmistakable, which matters when your tools can’t edit in place and “updating” means recreating. And it gives the ledger something concrete to point at. Clean-up becomes simple: anything without the latest stamp is stale.
The lifecycle of a session
The whole protocol as one loop:
- Read the standing handoff and relevant files (Rule 1).
- Do the work.
- Write back to the source of truth and item files (Rule 2).
- Log the changes in the dated ledger (Rule 3).
- State which tools the session could reach (Rule 4).
- Stamp the new version of every updated file.
Six steps, mostly automatic once the assistant has been told this is how the team works. The payoff is that five people can run sessions across the week and still end up with one coherent, trustworthy description of the stack.
Why this matters more as AI does more
As assistants become more autonomous and teams delegate more, you’ll run more parallel work, not less. The branching risk grows with your ambition. A protocol that feels like overkill with one session becomes essential with several, and it’s far easier to build early than to retrofit after a lost change has caused a routing outage.
It’s the same logic as change management in the CRM itself. Many admins editing one portal works well with change control and badly without it. The Anti-Branching Protocol is change control for the team’s AI memory.
Frequently asked questions
What is “branching” in an ops team’s AI workflow? It’s when several AI sessions independently update the team’s shared files without coordinating, so the source of truth forks into contradictory versions and one session silently overwrites another’s work.
How do several teammates run AI sessions without conflicts? Every session reads the source of truth first, writes back before ending, logs its specific changes in a dated ledger and records which tools it could reach. Version-stamp every file update so the latest copy is always clear.
What is a change ledger, and why does an ops team need one? It’s a dated list inside the standing handoff recording what each session changed. It lets you reconcile diverging sessions by hand, and it doubles as a change history for anyone who later asks why a workflow or definition changed.
Should we just limit the team to one AI session at a time? You could, but parallel sessions (per request, per person, per escalation) are a large productivity gain. The protocol keeps that flexibility safe instead of giving it up.
This is Part 3 of The Ops Operating System. Next: how to map what your AI tools can and can’t actually do in your stack before you rely on them.
No change history in your portal either? Our GTM Systems Audit maps who changed what across HubSpot, Marketo and Salesforce, and where change control is missing.