One Live Tree: Why Sybre Agents Share Main Instead of Worktrees
The prompt everyone is getting
If you run more than one coding agent in a repo, Cursor will now warn you: multiple local agents detected; try cloud agents instead. Those cloud agents run in isolated VMs with a clone of the repository. The pitch is familiar. T3 Code does the same thing with git worktrees. Claude and Codex are adding worktree flags. The industry standard is: give each agent its own checkout so they cannot step on each other, then merge later.
That is a good answer to file collisions.
It is a weak answer to “does the company still work?”
Sybre is not a typical app-in-a-folder. Each developer machine hosts a living copy of the product: FastAPI, the frontend bundle, Celery, Sybre Manager, SybreSpace, MCP, MySQL. Backend Python runs from the working tree. A restart activates code, not a commit. Verification is “change it, restart the right service, hit the real page.”
A mirror of the repo in a VM does not include that organism. It includes the files.
Isolation sounds clean. Here it adds a hop.
The isolated workflow is:
- Agent designs and edits in a worktree or cloud clone
- Tests whatever that clone can run (unit tests, maybe a throwaway database)
- You move the change onto
mainanyway - You restart FastAPI / Celery / SybreSpace / the frontend
- You find out whether it actually works
- Then you commit and push
You still did the live test. You just added a sealed draft in front of it.
That extra hop is the cost Cursor is not advertising. Isolated agents are easier to parallelize on disk. They are harder to believe, because the environment that matters is still main on the developer’s instance.
So we skipped the hop.
What we actually do
Sybre uses one shared live working tree on main per developer machine.
- There are no per-agent worktrees and no merge-back step as the normal path.
- Many agents work in that tree at the same time.
- They see each other’s uncommitted files and integrate on the fly.
git resetis banned. Someone else’s dirty files are not yours to discard.- You publish when the instance is in a state you would put on
main. SmartSync commits, pulls, merges, and pushes. Other machines pull and activate through fleet apply. They do not become a second writer.
This is trunk-based development with AI merge help, not “five feature branches and a PR factory.”
It looks undisciplined if you assume agents are strangers who will constantly overwrite the same function. In practice they usually are not. Work is already split by component, Workstream, or current actor. Same-file collisions happen. They are not the daily disaster the isolation banners describe.
What does happen every day is the opposite of isolation: an agent working on a page can see that another agent already changed the service it needs. It reads the live file and continues. A worktree agent cannot see that. It invents a second version. You discover the conflict at merge time, after both sides thought they were done.
Why a clone cannot verify Sybre
A cloud VM with a repo clone can run pytest, typecheck, and lint. A lot of Sybre tests are written so that work is possible.
It cannot, by default, prove:
- the route on port 8000 still serves
- the SybreSpace or frontend bundle actually activated
- Celery picked up the new task
- Sybre Manager queued the right restart
- MySQL on this company instance matches the code
- MCP tools still bind to a real session tab
Those are not extras around “the code.” For this product they are the test. Isolation solves a source-control problem. Live-instance development solves a product problem.
If you wanted cloud agents to verify the same way, you would not clone the repo. You would clone the whole stack: services, secrets, ports, org database. That is a fleet of live instances — which we already have, on developer PCs — not a disposable sandbox.
Pros
The files you edit are the files that run. No “it passed in the worktree.”
Agents coordinate without a merge meeting. Live dirty files are a shared workbench.
Publish stays rare and supposed to be stable. SmartSync is the durability boundary. Restart is the activate boundary. Those are different on purpose.
Model switching does not mean a new stack. The instance, Signpost, skills, and MySQL org brain stay put. Only the writer changes.
Isolation complexity stays out of the product. No worktree UI, no cloud VM fleet, no “re-point the thread at a different cwd” as a platform feature.
Cons
Two writers in the same file still hurts. Isolation would have delayed that fight until merge. We pay it in the working copy. Don’t reset; fix forward or resolve in SmartSync.
A half-finished agent can break the live instance. That is the real cost. Queued restarts, capacity limits, and “don’t interrupt a live turn” exist because the tree is the product.
Parallelism is not free. We run many agents, but not as five sealed checkouts of the same module. Protocol (who is the current actor) does some of the isolation worktrees would have done with directories.
You cannot throw the sandbox away. A bad edit is in the live tree until it is fixed. Checkpoints in T3 are cheaper to revert. We traded cheap revert for cheap truth.
Onboarding is a full instance, not npx and a clone. That is heavier than the industry default. It is also how a second developer gets FastAPI, Celery, and Sybre Manager instead of a folder of source.
The design rule
Use isolation when verification can finish inside the clone.
Use a shared live tree when verification is the running company.
Most coding-agent products are repo tools, so they isolate. SybreCore is a business operating system you run while you build it, so we don’t. Cursor’s banner is correct about conflicts. It is incomplete about proof.
We would rather have agents bump into each other on the real files, work around it, and restart the real service than get a clean merge of two changes that never met the stack they were supposed to improve.
Related: Not Another Agent GUI — why SybreSpace exists as a factory floor for SybreCore, not as a harness GUI.