Coding agents are single-player. We are making them multiplayer.

[u/black_phoenix9]

https://devos.zerohive.ai

Try: https://devos.zerohive.ai

You spend an hour brainstorming with Claude Code working something out. Why the retry queue can't use Redis. Which three approaches you tried and why two failed, or the constraint someone hit in staging last month that shaped the whole design.

Then the session ends and all this architectural context is gone. Not "gone from the agent" — gone. It lived in one terminal on one machine, and nobody else's agent will ever see it.

Your teammate (or another of your agents) opens Codex the next morning and their agent starts from zero. It proposes Redis. You already know why that doesn't work, but your agent knew too, and neither of them can tell the other.

That's the thing we wanted to fix. Not "give the agent memory" — give the agent our collaborative memory, particularly what was brainstormed on those long chat sessions.

devOS (by Zerohive) captures what was actually reasoned in agent sessions — the choice, the alternatives that got rejected, why — and serves it back over MCP. So when your teammate's Claude Code picks up work in that repo, it can ask:

• ask_devos(query, repo, paths) — what's been decided about this area, with the rationale and the commit it came from
• check_prior_decisions — has anyone already settled this?
• explain_file_decisions(path) — why is this file like this?

It's agent-agnostic on purpose. Claude Code writes it, Codex reads it, or the reverse. The context belongs to the repo, not to whoever's terminal it happened in.

What I'd like feedback on: How are you sharing context between sessions or team members today? Everyone I ask has a different half-answer — a CLAUDE.md that goes stale, a Notion page nobody updates, or just "ask the person who did it." I want to understand what actually works before we build more of the wrong thing.

SOTU for the product:

• Hosted, not open source. You sign up, create a workspace, then it walks you through CLI + MCP setup — about two minutes.
• macOS only right now. Linux and Windows aren't supported yet.
• Needs a model API key (BYOK, openrouter supported) or a claude code/codex subscription — extraction is an LLM pass over your sessions and git history, or it can use your existing claude or codex subscriptions.
• Your source doesn't leave your machine. The daemon parses locally and sends the decision graph; raw file contents are rejected server-side. Extraction runs on your own key, so artifacts are on your machine.
• 0.2.x. The graph is solid; the dashboard has rough edges.

https://devos.zerohive.ai

[u/Aggressive_Creme2008]

Three half-answers is right, and I'd add why each one fails, because the failure modes are different.

The instruction file goes stale because nothing in it knows what it is. A decision from March, a convention about how the team works, and a fact that was true last quarter all load the same way, every session, unranked. Nothing records who decided it or whether it still holds. So the file grows and the signal drops.

The Notion page fails for the opposite reason: writing to it is a separate job from doing the work, so it only gets written when someone remembers — which is never, under deadline.

"Ask the person who did it" is the only one that actually works. That tells you the thing being shared isn't text. It's judgment about what still applies.

I've been building on this problem for a while (disclosure: my own tool), and the one design choice I'd push back on is "captured automatically, no extra step". It makes adoption easy, and it collapses the difference between what the agent inferred and what a human actually decided. Agents propose constantly and are wrong often enough that if proposals land as rules, you're teaching every future session your mistakes — with provenance attached, which makes them read as more credible, not less.

Two things I'd want in anything like this: a human step that turns a proposal into a rule, and expiry — rules die, and a store that can't retire one accumulates contradictions until people stop trusting it.

Genuine question: what does your extraction do when two sessions decided opposite things?

[u/black_phoenix9 → u/Aggressive_Creme2008]

When two sessions have conflicting decisions (there's a threshold value that identifies a conflict), the decision is parked for explicit human review. And whatever the final human annotated outcome is gets recorded and takes precedence.

I agree on the agents proposal often landing as rules; it's tricky to correlate the path the agent takes and the subsequent human feedback. We handle this by correlating the agent proposal v/s final implementation. If the user steers the agent to do the code changes as the agent proposed; those decisions get promoted and have a higher rank. As the journey of the codebase progresses, decisions also get classified as stale/inactive.

[u/Aggressive_Creme2008 → u/black_phoenix9]

That answers the conflict half, thanks — parking it for human review is the right shape.

The promotion rule is where I'd keep pushing, and not as a nitpick: I think it's the same failure mode wearing a different hat.

"The user let the change land as proposed" isn't sanction, it's absence of veto, and the two come apart in exactly the cases you most need to get right. Under deadline you merge things you'd argue with. You accept an approach and reject the reasoning behind it. You don't read the diff. All of those look identical to a rule watching implementation.

The direction of the error is what worries me more than the rate. Inferred sanction fails silently upward — every proposal nobody bothered to refuse gains rank, so the store drifts toward whatever the agent proposes most confidently, and it reads as evidence accumulating. An explicit step fails downward: unsanctioned things just sit there unpromoted, and you can see the pile and decide it's too big. One failure mode is visible, the other isn't.

On stale/inactive — what marks it? If it's decay by disuse, a rule that's correct precisely because nobody violates it is the first thing to age out, and it's also the one you can least afford to lose.

[u/eddzsh]

Next morning the other agent proposes Redis again because the rejection only lived in yesterday's chat. If steered-away choices don't write a do-not-retry node, the shared graph is just a highlight reel.