For a good stretch the whole of Soundtrak's AI Marketing Studio lived in one folder that synced to OneDrive. Every agent, every skill, every campaign, every rule the system runs on, sitting in a single tree that a mistyped command or a confused agent could overwrite in a second. It backed up to the cloud, so I told myself it was safe. It was not safe. It was synced, and synced is a different thing. Here is where I started, where I ended, and what it taught me.

Where I started

OneDrive was the safety net, and for a while it felt like enough. The folder mirrored itself to the cloud the moment anything changed, so if my laptop died the work was still there.

Sync mirrors the current state, and only that, which is a problem. When a file is right, the mirror is right. When a file is wrong, the mirror is wrong too, instantly, everywhere. An AI agent that rewrites a skill file badly does not get caught by sync, it gets faithfully copied to the cloud a second later. A delete I did not mean propagates just as fast. Two edits that clobber each other are still in the one version. The failure mode was not hypothetical, it was happening, and I did not even notice it.

OneDrive keeps a shallow per-file version history, and once or twice it saved me. But version revision happens on a file by file basis, and my AI Marketing Studio is not a file, it is hundreds of interdependent files. It became clear over time that it would be very hard to wind the whole thing back to a known-good state. If a change broke the system on Thursday, I could not say "put everything back to how it was on Tuesday" and trust the result. I was building something with a lot of moving parts and storing it like a pile of documents in a drawer.

Further, I could not answer "what changed since the last time this worked?" There was no diff, no history I could read, no line that said this change did this, on this day, for this reason. When something broke I was reduced to remembering, and I am not a reliable narrator of my own week.

Where I ended

I moved the whole thing into a Git repository. Not as a one-off backup, as the way the system lives now.

A stop-hook auto-commits at the end of every session, so the backup is not a habit I have to remember. It happens on its own, dated, every time I close the work. GitHub holds the copy off my machine. The commit log now reads as a running diary of the build: rows of auto-backup stamps with their dates, threaded through with the real changes, a Release v1.11.0 tag, a run of numbered system tickets each landing one improvement. Every change is a commit with a message and a diff attached.

So if something breaks, I can wind the whole system back to any earlier point as one unit, not file by file, not from memory. I can read the history and see exactly what changed, when, and why. When something behaves oddly now, the first move is not to guess, it is to open the last few commits and read the diff, and more than once the culprit has been a one-line change I would never have found by remembering. The system has a past tense, and it is one I can return to.

None of this is exotic. It is the plainest discipline in software, the first thing any engineer does. That is rather the point.

What it taught me

Version control turned out to be more than a safety net. The moment you can wind the whole thing back to a known-good state, roll back a bad change, and read the diff of what an agent did to a file overnight, you stop thinking of the thing as a pile of agents and prompts that happen to work together. You start treating it as software. A system has a state, a history, a rollback, an audit trail. A pile has none of those, and you can feel the difference in how carefully you are willing to build, because you are no longer afraid to break it.

That matters more for AI systems, not less, because AI often changes things you cannot really see or tell is happening. Agents rewrite files. A model update shifts how something behaves. Without version control you often cannot even tell what moved, let alone put it back. With it, every change the system makes to itself is a diff you can inspect, question, and undo. The version history is not just insurance against my mistakes. It is the only record of what the machine did while I was not watching.

If you are wiring AI into your own go-to-market, put the whole thing under version control before it grows, not after. Not mainly because you will lose a file one day, though you will. Do it because the day you can roll it back is the day you start treating what you have built as a system, not a clever pile of AI agents. Version control is largely boring, and it is a necessity for your standards.

The evidence