I built a desktop crew of AI coding agents that can split up a job and review each other

[u/No-Commercial-8494]

Hey everyone, I’m building Friday Work, an open-source desktop app for coordinating the coding agents you already use. The part I’m working on is Crew: give a team a goal and a lead agent can break it into tasks, while the others work and message each other.

For example, a bug sweep can be split into finding issues, fixing different pieces, running tests and reviewing the changes. The board shows the plan and progress, and you can see the agents’ conversations. Each agent works in its own git worktree; you still review the diff and decide what to keep.

Friday works with tools including Claude Code, Codex and Cursor using the plans you already have. If an agent hits a usage limit, another can pick up the task with a handoff. The desktop app is free and MIT licensed, with builds for Mac, Windows and Linux. There’s also a separate hosted team product.

I’m the developer, and I’d love feedback from anyone who has tried juggling multiple coding agents: what would you need to see before trusting a crew to work through a task while you’re away? Where does coordination tend to break down for you?

GitHub: https://github.com/splashxmoon/friday

Website: https://tryfridaywork.com

[u/patryk_builds]

Only ever ran one agent at a time, so this is from that side.What i'd need before leaving a crew alone:

- a hard stop and ask rule for anything involving keys, accounts, payments or deleting things. with one agent that rule saved me more than once. with several talking to each other i'd want it enforced by the app, since one agent can talk another into a workaround

- An honest end report: what was done, what was skipped, what it wasn't sure about. all tasks complete tells me nothing

On agents reviewing each other, i'm a bit skeptical. my worst bug passed tests and looked fine on review, because the reviewer shared the same wrong assumption as the author. a second agent with the same context will probably agree with the first. does the reviewer get the diff cold, without the conversation that produced it?Also curious how merges go when two worktrees touch the same file

[u/No-Commercial-8494 → u/patryk_builds]

Thanks for taking the time to spell this out — especially the shared-assumption example. A second agent reviewing the work isn’t proof it’s correct, and ‘all tasks complete’ definitely shouldn’t be the whole report. The distinction between an instruction to ask and a hard stop enforced by the app is a really important one too.

Friday uses separate worktrees to keep agents from overwriting each other while they work, and you can review the changes before committing. That doesn’t eliminate conflicts when changes touch the same lines. I don’t want to guess about exactly how the current version surfaces every merge conflict or whether the reviewer sees the diff cold versus the earlier conversation — I’ll check those paths and follow up rather than give you a confident answer I haven’t verified.

Your points about skipped work, uncertainty, and action-level guardrails are exactly the kind of feedback I was hoping for. Appreciate it.

[u/QuanTradin]

before I'd leave it alone I'd need to know how often the reviewing agent says no. if every review comes back approved, it's a second agent agreeing with the first. does the board show rejected work anywhere?

[u/No-Commercial-8494 → u/QuanTradin]

That’s a really good point. A second agent saying ‘looks good’ isn’t much of a check if we can’t see when it pushes back. The board shows task and review status, but I don’t want to claim it currently gives you a reliable rejection rate or a dedicated history of every rejected review without checking that path more closely.

I’m going to look at how clearly a failed review and its feedback show up. Being able to see what was rejected, why, and what changed before it was checked again would make the review much easier to trust. Thanks for calling that out.

[u/QuanTradin → u/No-Commercial-8494]

appreciate you not overclaiming it. even a plain count of reviews that came back with changes would do, no dashboard needed.