Remix.run Logo
arctide 2 days ago

The way I see it, having lots of agents that work together across different computers is mostly about a sync-up problem dressed up as something else. Loopsy is a clean tool for sending messages, but I get tripped up on which agent has control of a file at any moment, and what happens when two terminal sessions write to the same file within half a minute.

I really need a tool that locks files for editing rather than just one for sending messages. Should the second machine's agent wait its turn until the file is free, or should it create its own branch of the file to merge later? With Loopsy, what we're getting is more like a mailbox system, but in my own setup, the lock would be the right approach in most cases.

I have a single rule listed in CLAUDE.md that just reads, "do not modify child project files from parent context." This is because the parent git repository only contains meta-files and automation, and the agent constantly forgets it during sessions, especially when switching machines. After about ten weeks, I added .sync-conflict-* files to my .syncignore.

todience 2 days ago | parent [-]

Yeah that’s valid. Loopsy as it is is a coordination layer not a concurrency layer. There’s no file locking primitive at the moment. What is there is a task queue protocol which gets you close by having one agent claim a task while others wait.

For single files we’d need to build the lock key mechanism on top of the Loopsy context store.