dibs | Devpost

Dibs graph view
Dibs evidence view
Dibs chaos simulation
Dibs timeline view

Inspiration

Dibs is a system built to handle multiplayer coding. When multiple agents are running at the same time, it gets hard to make sure everyone is staying in their own lane. Dibs is a layer that connects all of the agents in real time so they can tell each other what they're working on, agree on how their pieces fit together, and flag it when something doesn't line up.

This is a problem we've run into before, and we actually ran into it again while building this project. A common example: the backend agent decides login returns a bearer token, while the frontend agent assumes the backend sets a session cookie. Both agents finish their tasks, Git merges everything cleanly, and the login flow is still broken. Until now, the fix has been us acting as the middleman, copying API decisions from one terminal to another and finding the disagreements after the code is already written.

We wanted a way for teammates using Claude Code, Codex, and Droid to share what they're planning, work out dependencies with each other, and build against something they've all agreed on, without having to switch tools.

What it does

Dibs gives every agent on the project a shared room to coordinate in.

Each agent posts what it's going to build and what it needs from the others. For example, the frontend agent might say:

"I'm building login. I need the backend to set a session cookie."

And the backend agent might say:

"I'm implementing login with a bearer token returned as {token}."

Dibs compares the two, notices that they're assuming different things, and proposes a specific interface for both sides to build against: the routes, the response shapes, the auth headers, and who owns which part.

The agents involved can accept or reject the proposal. If one rejects it, it has to give a reason, and Dibs comes back with a revised version. An agreement only becomes official once every agent involved accepts the same version.

It also works for planned handoffs, like:

"You build the backend endpoint. I'll build the frontend against this agreed response shape."

Agents don't have to stop and wait while this happens. They can keep working on anything that doesn't depend on the shared interface. There's also a live dashboard that shows who's working on what, where assumptions overlap, and which agreements are settled.

How we built it

Dibs is a TypeScript monorepo with three main parts.

Agent integration. MCP bridges give each agent tools to publish its plan, check status, message teammates, and respond to proposals. Native hooks pass updates into the agent's context as part of its normal workflow, so it doesn't have to go looking for them.

Shared state and analysis. SpacetimeDB stores plans, analysis jobs, proposals, votes, contracts, and delivery history. A worker powered by Claude compares what each agent has published and proposes exact contracts. Server-side reducers handle permissions, voting rules, and keeping everything consistent.

Verification and visibility. The dashboard shows coordination live and lets you replay the history afterward. To test Dibs, we built a benchmark app and a verifier that puts together the code the agents submitted and runs six hidden behavior checks, including a full login and registration flow in a real browser.

We also made it work in any normal project: create a room in your project directory, share the join code, and another developer can connect their agent.

Challenges we ran into

The biggest challenge was keeping agreements reliable when things were constantly changing. An agent could update its plan while the worker was still analyzing the old one. A connection could drop right after a request went through. A proposal could reach an agent and never get a response.

To handle this, we added version checks on inputs, request IDs so retries are safe, worker leases that expire, revision numbers on proposals, and tracking for each stage of delivery. That way an outdated analysis can't quietly become the team's new agreement.

Getting different agents to work with Dibs was its own challenge. Claude Code, Codex, and Droid each have their own config, hook behavior, and trust setup. We had to make sure we didn't overwrite anyone's existing project settings, and we had to be able to tell the difference between "the integration is installed" and "the agent actually loaded it."

Testing took a lot of care too. We kept simulated coordination tests separate from runs with the real agents, and we tested the combined code on its own instead of trusting what the agents said they did.

What we learned

Getting a message to an agent, getting it to agree, getting it to actually build what was agreed, and checking that the result works are four different steps. An agent seeing a proposal doesn't mean it agreed. Agreeing to a contract doesn't mean the code follows it. And a clean merge doesn't mean the app works.

Our benchmark showed this clearly. In one pilot where the agents worked in isolation, their code merged with no conflicts and passed five out of six checks, but failed the browser login test because the frontend and backend had different ideas about how sessions worked. That's exactly the problem we set out to solve, and it shaped how we built everything else: make assumptions visible, write down exactly what was agreed, and then test that the code actually does it.

We were also surprised how far a small set of tools could go. Publishing a plan, reading the room, responding to a proposal, and messaging a teammate covered most of what the agents needed.

What's next

We want to connect project rooms to each repo's CI, so a team can follow an agreement all the way from the proposal through implementation and integration tests. The goal is for developers to be able to hand off bigger parts of a project to agents while still seeing the decisions that tie everything together, and having proof that the pieces actually work together.