What Happened
The AI decided to create a feature/006-upstream-setup-repo branch during a large implementation. It saw 109 files changing and figured that warranted a branch - reasonable in general software terms, but it doesn’t match how these workspaces work. The sync agent doesn’t auto-create branches, but the implementing session did it on its own.
That’s when the framing crystallized.
The Insight
Thinking about thinking is part of the brain of the company, and drafts are ok to go “live” since we are in a brain. There’s no production to protect - main is the working space.
A marketing calendar, a half-formed strategy doc, a goals draft - none of these are deployable artifacts. Pushing them to main isn’t risky, it’s just where the thinking lives right now.
Branches vs. Conflict Resolution
The sync agent already uses AI to resolve conflicts - it pulls before pushing, and if there’s conflicting info it either resolves a final output with AI logic or asks the user which one to go with. That handles the real problem: two people editing the same thing at different times.
Branches solve a different problem: “should this change go in at all?” That’s a review gate. For brain workspaces, the product pipeline (PB, DD, PRD) already does that job - it’s the human-process version of a PR.
When Branches Would Matter
- If a collaborator explicitly wants to approve changes before they land (e.g., a partner wants to review before it hits main on a shared workspace)
- Repos with a production/live distinction (deployed websites, shipped code)
- Not relevant for solo repos, and not relevant for shared brain repos where everyone’s just working
Even with Multiple Teams
As multiple teams join different functions in a workspace, branching still doesn’t fit. The repo is the thinking. There’s no “staging” for a plan document.
The lesson: git branches solve a review-gate problem, and brain repos don’t have that problem. If the AI starts inventing structure, the structure isn’t always right.