LightfieldAI-native CRM that builds itself and does work for you
Murmell
Cloud canvas where your team and AI agents works together
309 followers
Cloud canvas where your team and AI agents works together
309 followers
Murmell is a shared cloud canvas where your team and AI agents work in the same room, on the same repo, with a preview and more coming in the future. Close your laptop and the work keeps going. Agents claim files before they write, so people and agents can move at once without overwriting each other. Run Claude Code, Codex, Kimi, and OpenCode together today, with more agents on the way (OpenClaw, Hermes, and more), and your work lands back in git, so you can always find your projects there.
Free Options
Launch Team / Built With
Murmell
Hey Product Hunt. I'm Moss'Ab, and I built Murmell.
Last year at a hackathon we had three people, four AI agents, and somehow still one laptop everyone was afraid to close.
Half the night went to "who's on which file" and "wait, my agent died when I shut the lid."
So I built Murmell: a shared cloud canvas in the browser where Claude Code, Codex, and your team work on one repo, on a cloud machine. Close your laptop, they keep going. Same room, a preview in the canvas, and the work lands back in git.
More is coming next, including iOS and Android simulators in the canvas so you can see mobile builds the same way.
I built most of this with Claude Code. Once it was solid enough, I started building Murmell with Murmell.
Launch offer: free for the first week, plus $60 of Claude Code credits.
Curious: when you ship with agents on a team, what breaks first for you, the coordination, the laptop, or the merge mess at the end?
murmell.com
you asked what breaks first. from the shared inbox side it is coordination, but not the part people expect.
the merge mess is loud. git tells you, someone fixes it, everyone learns from it. the failure that actually costs you is two actors doing the same work without colliding at all. both finish, both succeed, nothing conflicts, and you find out downstream or not at all.
we get that version every day. two people open the same conversation, both answer, the customer gets two different replies and neither of them did anything wrong. in code you would at least get a conflict. when the work leaves the system, you just get two sends.
agents sharpen it, because a person hesitates when they see someone else typing. an agent does not hesitate and does not look.
so does the canvas have a way to claim something, a file, a task, whatever the unit is, or does it show presence and leave the rest to people noticing? presence tells you someone is in the room, not what they have taken.
Murmell
@jernej_jan_kocica There is a claim, and the unit is a path. An agent asks for the paths it is about to write, the server grants or refuses, one holder at a time in exclusive mode, up to 50 paths per claim. It is judged server side rather than requested in a prompt, so an agent that writes anyway is recorded as a collision, with a snapshot commit taken before the write so the overwritten state is recoverable, and the third collision by the same agent stops asking the model and asks the human.
But your point is the silent one, and that is the harder half. Two actors finishing the same work without ever touching the same file is exactly the failure that produces no signal, and it is the same shape as your two replies to one conversation.
What we do about it is push rather than poll. The board is not only claims: it carries each agent's status, its end of turn summary, notes, and direct messages between agents. When an agent's turn opens it is handed a diff of everything peers did since its own cursor, capped so the turn does not start with a wall of text. So the second agent is told "this one claimed these paths, for this reason, and is working on that" before it starts, without having to think to ask. You are right that an agent does not hesitate and does not look, so we do not rely on it looking.
Where I will concede: a claim on a path is not a claim on an intent. If a human hands the same task to two agents and they solve it in different files, nothing in what I described stops them, and they both succeed. Task level claiming, your unit rather than mine, is the thing I do not have and the thing your inbox case says is the real one.
@moss_ab_mirande_ney that is a better answer than i expected, and the third collision going to a human instead of back to the model is the part i would steal.
on the gap you named, i do not think you can claim an intent, because nobody can name it up front. what you can claim is the outcome. in the inbox the unit is the conversation, not the draft, and two agents writing two drafts costs nothing. what has to be exclusive is the send, because that is the step the outside world sees.
so the lock probably belongs on the last irreversible action rather than on the work. both agents run, both produce something, and whoever reaches the merge first takes it. the second one finds out at that moment that its work is redundant, which is late, but it is a signal, and you already have the diff sitting right there to show why.
honest about what that buys you: it does not save the wasted tokens, it only stops you shipping both. i have not found a version that saves the work.
Murmell
@jernej_jan_kocica
You are right, and the reframe is better than what I said. Intent cannot be claimed because nobody can name it before the work exists.
The outcome can, because by then it is a thing.
For us the send is the push. Everything before it is a working tree that can be thrown away, and the repository is the only place where two agents both finishing becomes a fact the outside world sees. So that is where the exclusivity belongs, and unlike a claim on intent it is implementable today: one holder for the merge, the first one there takes it, the second is told at that moment and shown the diff of what it just duplicated.
One thing that softens the late signal a little. When a write collides with a held path we take a snapshot commit before the write lands, so the losing work is recoverable rather than gone. Applied to your version, the second agent's branch is still sitting there and the human can diff the two instead of trusting whoever was faster.
Where I fully agree: it saves nothing upstream. Both agents ran, both cost money, and the only thing you bought is not shipping twice. I have not found a version that saves the work either, and I am starting to think that is the correct price rather than a gap.
@moss_ab_mirande_ney the snapshot commit is what makes it worth building. the loser's branch surviving means a person can compare the two instead of trusting whoever was faster, which is a better outcome than the winner simply being first.
agreed on the price too. paying twice to ship once is probably the honest cost of running things in parallel rather than a hole in the design. best of luck with it.
File level claims solve the loud half. Two agents can hold completely disjoint files and still both rewrite the same contract, one edits the caller and one edits the callee, nothing conflicts and the build breaks somewhere neither of them was looking. The thing I'd want on the page is what happens to a claim when the agent holding it dies. Nobody's at the keyboard on a cloud machine, so a stale lock is silent and it's sitting on exactly the file the next person needs.
Murmell
@asadmalik901
Correct, and it is the half of the problem locking does not touch. Two agents on disjoint files can still break one contract, one edits the caller, one edits the callee, nothing collides and the build fails somewhere neither was looking. A path claim is a write arbiter. It is not a type system and I would not sell it as one.
What makes that case survivable is not the claim, it is that both agents are in the same working tree. The one editing the caller can read the signature the other just changed, because it is on disk, not in another worktree on another branch. And peers get told: at the start of a turn an agent receives a diff of what the others did since it last looked, including which paths were claimed, with the stated reason, and which files were written. So the caller's agent opens its turn knowing the callee moved. That is not correctness, it is awareness, and the real backstop is still the build.
On your actual question, the stale lock. Two things, because a TTL alone is the wrong answer.
Every claim carries a lease with a TTL, 15 minutes by default, one hour maximum, and expiry is swept on every read of the board rather than by a timer. So a claim held by something that stopped answering ages out on its own and the release is broadcast to the other agents.
But the normal path is not expiry, it is death. When the pty exits, every lease that agent holds is released with the cause recorded as death, the agent is greyed out on the canvas, and the paths it was holding are named in the event the others receive. So the usual case is immediate rather than 15 minutes late. The TTL is the backstop for the nastier failure you are pointing at, which is a process that is alive and stuck: nothing exited, so nothing releases, and only the clock saves you.
PRISM by Block Convey
Murmell
@arun_prasad06
Hey Arun, good question.
If you mean working with your clients in the same room: yes. You can invite them onto a Murmell canvas, share the repo, and run agents there together (Claude Code, Codex, Kimi, OpenCode today).
If you mean plugging in agents your clients already run outside Murmell, that depends on which ones.
Tell me what they use and I’ll say if it’s already supported or next on the list.
PRISM by Block Convey
PRISM by Block Convey
Murmell
@arun_prasad06
Got it, thanks for clarifying.
You're describing agents that stay in the client's environment: run Claude Code there for an audit you can share, and query their DB in place so sensitive data does not have to leave.
Murmell today is the shared cloud canvas (team + agents on one repo, preview, git).
What you're asking is closer to a next step: bring that same room onto a machine or network the client already controls, instead of only through an SDK into our cloud.
I want that direction.
If you have a concrete client setup in mind (their laptop, a VPC, on-prem), tell me which and I'll say how close we are vs what we'd build first.
Macaly
agents claiming files before they write is the clever bit 👏 no more overwrite chaos. congrats!
Murmell
@petrkovacik
Thanks, man !
Don't forget to check our linkedin page :)
https://www.linkedin.com/company/murmell