Where OpenFloor sits
Where we sit next to the tools teams already run.
Three questions
Only one of these can hold four people and six agents at one repository.
| OpenFloor | Dust | Slack with a coding agent | Cursor, Devin, Codex CLI, Claude Code | |
|---|---|---|---|---|
| Several people in one live session | Yes. A durable room: presence, drafts as they are typed, and one shared prompt queue. | In chat, not on the code. | In the channel, not in the work. | No. One seat. |
| Several agents on one repository | Yes. Two runs at a time, each in its own container at a pinned commit. | Not the unit of work. Code is one connector among many. | One agent per invocation, each with its own branch and pull request. | One agent, one working copy. |
| What the room sees while a run is going | Everything. Reasoning, commands, and file edits stream to every member mid-run. | The answer, once it is written. | Posted updates, not live state. | Only the person at the keyboard. |
| Two agents reach for the same file | Caught before it lands. Runs integrate one at a time into one candidate branch under your checks. | Cannot happen; nothing is writing the repository. | Found after the fact, as a merge conflict. | Nobody notices until the second push. |
| Who can merge | The owner, and only behind a draft pull request. Checks run in the sandbox first. | Not applicable. | Whoever opened the pull request. | Whoever is at the keyboard. |
Every one of these is good at what it is for. The line we draw is narrow: when several people dispatch agents at the same repository at the same time, something has to hold the session and be able to say no. That is what we build.
The first study should be yours.
If your team runs agents in parallel on one codebase, tell us what you run and where it breaks. A human replies within one business day.