Running multiple coding agents locally is a recipe for a merge

Murmell, a cloud-based coding platform, enables multiple AI agents to collaborate on a shared canvas with persistent sessions, file claiming, and real-time collision detection, addressing common issues in local agent workflows. The platform uses a proxy on the container's loopback to secure provider keys, and its snapshotting system reduces token costs. This approach signals a shift toward distributed, multi-agent orchestration in software development.

Running multiple coding agents locally is a recipe for a merge I've been digging into Murmell, and it’s a pretty radical departure from the typical VS Code extension approach. Instead of an agent living inside your IDE, Murmell treats coding like a collaborative cloud canvas. Think Google Docs, but instead of just humans typing, you have a swarm of agents running on their own dedicated cloud machines. The "Cloud Canvas" Architecture The core concept here is that each canvas is its own isolated environment. This solves several massive headaches I've run into with my own AI workflows: Persistent Sessions: Unlike running a script on your laptop, these agents live in the cloud. You can kick off a complex refactor, close your MacBook, go for a run, and when you come back, the dev server is still running exactly where it left off. True Multi-Agent Collaboration: This is where it gets interesting for anyone doing serious prompt engineering or agentic workflows. They use a "file claiming" system. Before an agent touches a file, it takes an exclusive lease on that path. If another agent tries to edit it, it gets a denial that actually tells it who holds the lease and for how long. Real-time Collision Detection: Instead of finding out an hour later that an agent messed up your utils.py via a massive Git merge conflict, Murmell uses a watcher to flag writes in real-time. If an agent writes inside someone else's claimed territory, it shows up as a collision on the canvas immediately. Security and Infrastructure One of my biggest gripes with giving agents access to my local environment is the security risk. If an agent gets compromised or leaks a key, it's game over. Murmell handles this using a proxy on the container's loopback. The agents never actually touch your provider keys; they only see a temporary token. The proxy swaps that token for the real API key only when the request leaves the container. This means even if a token is leaked, it’s useless outside that specific environment. Practical Deployment and Use Cases This isn't just a playground; it's a deployment-ready environment for agentic development. If you are building a team of specialized agents—say, one for frontend, one for backend, and one for testing—you can actually see them working on the same canvas. You can see their cursors, watch their terminal output, and even jump into their session to fix a hallucination mid-task. The infrastructure side is also clever. They've implemented a snapshotting system similar to Obsidian's way of handling data, which helps save on token costs by storing the terminal conversation history efficiently. When a VM shuts down, it snapshots the entire state and restores it when you reconnect. For anyone trying to move beyond simple Copilot usage and into building actual LLM agent workflows, this kind of distributed, cloud-native approach is likely where the industry is heading. It turns coding from a solitary act into a managed, multi-agent orchestration. Next Vibe-coding is destroying my work-life balance → /en/threads/8182/