Yehuda_LevS
Posted on
I built this after getting frustrated that my Claude, Codex, and Gemini sessions had no idea what each other were doing on shared projects.
Communication is the floor. The team gets better above it.
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (3)
This resonates hard. I've been running into the exact same wall — you spin up specialized agents for different parts of a project and they're completely blind to each other's work. The duplication and conflicts that result are painful.
Your point about "communication is the floor" is spot on. Note-passing helps, but it's still fundamentally a human-orchestrated pattern. The agent doing code review shouldn't need me to tell it that the architecture agent already made a decision about the database schema.
I've been exploring this from a slightly different angle — what if agents could autonomously discover and delegate to each other across different machines, not just within one person's local setup? Like a network where your coding agent can find and hand off a security audit to someone else's specialized security agent, without you having to set up that integration manually.
The coordination layer is the hard part though. How do you handle conflicting decisions when two agents touch the same area? Curious how you're thinking about conflict resolution in your approach.
Really glad it resonated — that "blind to each other's work" failure mode is exactly the itch I couldn't stop scratching.
And you're pointing right at what I think is the actual frontier: cross-machine, cross-owner discovery and delegation. I deliberately scoped Polis to the local, git-native, dev-time layer — one repo, a _polis/ folder of markdown that any agent (Claude, Codex, Gemini, whatever) reads and writes. The networked "your coding agent finds my security agent and hands off the audit" piece is real and genuinely exciting, but I think it's a different layer — much closer to what A2A (Agent Cards, agent-to-agent) is built for. My bet is they compose rather than compete: Polis owns local coordination + memory and later exports to a network protocol like A2A. (That interop is firmly post-1.0 for me, though — I'm trying not to boil the ocean.)
On conflict resolution — my honest take is the best conflict resolution is prevention, so most of the design is about not getting into the conflict in the first place:
Reservations. Before touching files, an agent reserves the paths. An overlapping reservation is rejected deterministically and names who holds it — so two agents literally can't both claim the same area at once. It's advisory, not an FS lock, but it turns a collision into a rejected action instead of a merge headache.
Decisions become shared state, not tribal knowledge. Your DB-schema example is the one I care most about: when the architecture agent settles that contract, it files a lesson that auto-injects into later tasks on the same capability tags. So the code-review agent inherits "we chose schema X because Y" as context — without you relaying it. Killing the human message bus is the whole point.
For the genuinely contested / irreversible stuff (two agents disagree on the same area, or something's about to be expensive to undo), there's a chavruta review step: a second agent — ideally from a different vendor — has to critique the plan before it executes. Different models fail differently, so the cross-vendor second opinion catches a surprising amount.
Where it gets hard — and where I suspect your cross-machine version gets really hard — is trust. Locally I assume cooperative agents; reservations are advisory and the capability cards are content-hashed for tamper-evidence, not cryptographic identity (I actually stopped calling them "signed" because that overclaimed). The moment you're delegating to someone else's agent on someone else's machine, identity and "can I even trust this decision" stop being optional — and that's a genuinely unsolved layer. Would love to compare notes: what's your model for trust/identity in the networked version?
Amazing insight, must get to work to test this out. Thanks for a great article!