Orin - Institutional Memory for Engineering Teams

Overview

A team rejects an idea for a good reason. Months later the person who knew the reason has moved on, the same idea comes back in a new pull request, and nobody remembers why the team said no. Orin is the memory that does. It reads a repository's closed issues and pull requests into a self-hosted Cognee knowledge graph, then catches re-proposals on new PRs and issues with a citation to the original decision, and answers why did we do X from GitHub, Slack, Linear, the IDE, and CI.

Orin was built for the Cognee hackathon in the Open Source track.

The Problem

Engineering teams lose the same argument twice. A dependency is rejected, an architecture is decided against, a migration is deferred, and the reasoning lives in a closed thread that nobody re-reads. When the same proposal returns, from a new hire, a coding agent, or just forgetfulness, the team re-litigates it from scratch, or worse, merges the thing they already decided not to. Code review bots today are stateless: they look at the diff in front of them, not at what the team already decided. Orin is the opposite. It is memory-first and precision-first.

Key Features

One Memory, Six Surfaces

Orin is one shared per-tenant knowledge graph reachable from a GitHub App, a Slack app, a Linear agent, an MCP server for the IDE, a CI pre-flight, and a dashboard. Every surface reads and writes the same graph, so a decision recorded once is enforced everywhere: a merge-blocking check on GitHub, a cited answer to a Slack question, an in-issue Linear agent, a check-rejected tool in Cursor or Claude Code, and a CI job that fails before review.

Memory Formed From GitHub History

Installing the App on a repo backfills every closed issue and pull request, extracts the real decision from each thread, what was proposed, what was decided, and the reasoning, and grounds it in the knowledge graph using a decision ontology. After that, every closed PR or issue live-ingests a single decision, so the memory compounds forward without a re-scan.

The Precision Catch

On a new or updated PR the catch runs deterministically first. A term-overlap gate keeps only decisions that share enough significant terms with the PR, then a semantic-distance gate drops weak matches, and only the survivors go through a cited graph-completion recall and an LLM judgment that returns a citation or nothing. Only a decision that was actually rejected and not since superseded can block, and if nothing grounds, Orin stays silent. A memory system that cries wolf is worse than none.

Decisions Are Superseded, Not Deleted

Context can always change. One comment can override a decision with receipts, and the check clears, because decisions are never deleted, only superseded.

How It Works

The core is a GitHub App backend in Node and TypeScript that provisions an isolated Cognee tenant on install, backfills the repo, catches re-proposals, and runs an at-mention command set, with heavy work on a Postgres-backed queue so webhook acknowledgements stay fast. Three adapters share that same memory: a Slack app, a Linear agent, and an MCP server exposing tools for the IDE. A composite GitHub Action provides the CI pre-flight, and a Next.js dashboard shows every catch with its citation, the recorded decisions, the knowledge graph, org and repo rules, and repo-scoped keys.

The Cognee Engine

The memory substrate is the self-hosted Cognee OSS engine, run with backend access control on so every tenant's decisions live in a separate, key-scoped graph. Orin drives the full Cognee lifecycle: remember for ontology-grounded ingest, recall for cited chain-of-thought graph completion, improve so maintainer feedback reweights the graph, and forget on uninstall. It runs DeepSeek for extraction and judgment with local embeddings, so no decision ever leaves infrastructure the team controls.

Tech Stack

• Memory engine: self-hosted Cognee OSS with backend access control and an OWL decision ontology.
• Bot backend: Node.js and TypeScript with the GitHub App SDK and a Postgres-backed job queue.
• LLM: DeepSeek for extraction and judgment, with local embeddings in the engine.
• Adapters: a Slack app, a Linear agent, and a Model Context Protocol server.
• Frontend: Next.js and React with Tailwind CSS, using GitHub OAuth and signed session cookies.

Challenges and Solutions

Precision Is the Product

Two independent gates run before any LLM judgment, and Orin only ever blocks on a cited, rejected, non-superseded decision, so it stays silent when the evidence is weak.

Real Multi-Tenant Isolation

Every install is a separate Cognee tenant with its own key, and the bot always calls the engine key-scoped, so one team's decisions can never leak to another.

One Core, Many Surfaces

A single per-tenant graph and a shared set of grounded primitives are exposed through a GitHub check, a Slack command, a Linear agent, an MCP tool, and a CI pre-flight, so the same decision is enforced wherever the team works.

What I Learned

• Self-hosting the Cognee OSS engine and driving its full remember, recall, improve, and forget lifecycle.
• Grounding LLM extraction with an OWL ontology so the graph understands what a decision is.
• Precision-first design using deterministic and semantic gates before any model judgment.
• Building a GitHub App, a Slack app, a Linear agent, an MCP server, and a CI action on one shared core.