cobrain

cobrain catches the gap between what your team decided and what it's building, and shows the proof !!

Comment

Inspiration

Every team knows this moment: a requirement quietly changes in a Slack thread, the ticket never gets updated, and two weeks later engineering ships something nobody asked for. Decisions are made in chat, written down in tickets, and implemented in pull requests, but nothing connects the three. So nobody can easily answer "what did we decide, what did we ship, and where did they diverge?"

We wanted an agent that doesn't just search company chat, but understands how the pieces relate. That's a graph problem, not a search problem.

What it does

cobrain is a context graph for how a company actually works. It connects Slack and Discord conversations, tickets, GitHub pull requests and docs into one graph in FalkorDB, so it knows a chat thread, a ticket and a PR are all about the same feature.

  • Drift alerts: when a conversation changes a requirement that the ticket or PR doesn't reflect, cobrain posts an alert in the channel, with the evidence.
  • Sprint retros: after each sprint, a structured report of what was decided, what shipped, and where the two diverged.
  • Ask your company: a query interface for questions like "who decided this, is it still valid, and who knows most about it?"
  • Spec generation: turn a drifted feature's graph context into an agent-ready spec.

Every answer and alert shows the graph path and source links behind it.

Note: the prototype runs on a synthetic company and a GitHub repo we own, with mock tickets.

How we built it

  • FalkorDB Cloud as the context layer, with Person, Message, Ticket, PullRequest, Feature, Requirement, Decision and Sprint nodes. Relationships such as ABOUT, STATES, CHANGES, IMPLEMENTS and SUPERSEDES carry the logic.
  • Python connectors for Slack, Discord and the GitHub API, plus mock Linear-style tickets, all normalised to one event format.
  • OpenRouter API to extract requirements and decisions from messages and tickets.
  • Entity resolution in three steps: hard links (ticket IDs, "Fixes #12"), graph proximity (shared people and time windows), then semantic similarity for what's left.
  • Drift detection as a time-ordered Cypher path query: a requirement changed in chat after the ticket stated it, with no later update to the ticket or PRs.
  • A small web dashboard, with an agent that chooses among graph tools to answer questions.

Challenges we ran into

  • Most messages don't name the feature they're about. People write things like: "Let's drop it for v1, too risky." "Can we make it work for contractors too?" "Pushing that to next sprint." A human on the team knows what "it" and "that" refer to. Your system has to work it out. If it links the message to the wrong feature, the drift check runs against the wrong ticket and PR, and the result is wrong.

The two ways it goes wrong -False link: "Let's drop it for v1" gets attached to the Search feature when the team was talking about SSO. The system raises a drift alert on Search that makes no sense, and nobody trusts the next alert. -Missed link: the same message isn't linked to anything. The requirement change in chat never reaches the graph, so the drift is never detected. This is the failure the whole product exists to catch.

What's next for cobrain

  • Phase 1, Retro (the wedge): low-risk, trust-building sprint reports that also produce labelled data for drift detection.
  • Phase 2, Monitor: live drift detection across more tools, such as Linear, Jira, Notion and call recordings.
  • Phase 3, Execute: specs precise enough for coding agents to act on, closing the loop so the company self-corrects.
  • Compounding context: the longer a team uses it, the richer its decision memory becomes.
  • Real organisations: moving from synthetic data to real workspaces, with proper permissions and privacy controls.

Built With

  • agentic
  • ai
Share this project:

Updates

Submission history