Sidegraph

Give an AI coding agent the mental model of a project that an experienced engineer carries — what exists, how it is connected, why it is built this way, and what was already tried — served task-aware, within budget, before the first grep; and make that why survive rebuilds, refactors, and time.

Coding agents broke an old equilibrium: code is now produced faster than anyone accumulates the understanding of why it is the way it is. The reasoning that shaped each change happens once — inside a session — and is discarded with its context window. You pay for the tokens, keep the diff, and throw away the judgment.

Half of a project's knowledge is derivable: what the code does, how it's connected — an agent excavates that with grep, cheaper with every model generation. The half that decides projects is not: why it's built this way, what was tried and abandoned, which constraint from outside the code forced the shape. That information isn't in the artifact at all. No future model will recover it, because it exists exactly once — at decision time — and then evaporates: people leave, sessions end, the ticket from three years ago is never found. Sidegraph keeps that half and serves it back.

Deciding whether this is worth your team's time? Read the engineering whitepaper first. It states the idea, walks one real decision chain end to end, reports what running it showed, and gives a fit test you can apply to your own repository before installing anything.

Quickstart

Works cold: no existing ADRs required. No API key — the core loop is fully local (one optional docs-analysis feature uses one; it's marked below).

# 1. Install the graph engine and build a graph over your repo (code or markdown)
uv tool install "graphifyy==0.9.6"       # double "y" — that's the PyPI name; CLI is `graphify`
cd /path/to/your/repo && graphify update .

[mcp] is an optional extra on graphifyy (uv tool install "graphifyy[mcp]==0.9.6") — it adds Graphify's own MCP server, a deeper structure-query layer over the same graph. Sidegraph only ever reads graph.json, so the plain install above is all it needs.

# 2. Inside a Claude Code session in that repo: install the plugin — MCP server + all
#    four hooks, wired automatically.
/plugin marketplace add SantyagoSeaman/sidegraph
/plugin install sidegraph@sidegraph

# 3. Install the CLIs + MCP server, then bootstrap the store in your repo
#    (creates .sidegraph/, prints setup instructions). In a terminal it also asks
#    whether to install a git hook that rebuilds the code graph after each commit,
#    merge and branch switch; `sidegraph-init --remove-hooks` takes it out again
uv tool install sidegraph        # from PyPI — puts sidegraph-init / sidegraph-mcp / … on PATH
sidegraph-init

# Prefer running straight from git instead of PyPI? Swap step 3 for:
#   uvx --from git+https://github.com/SantyagoSeaman/sidegraph.git@main sidegraph-init
#   `@main` moves only when a release is cut. It is still a mutable ref: a later cache refresh can
#   install a newer one. Pin a tag or a SHA for CI.

4. Name your domains — turns the graph's communities into a described table of contents. Tell your agent "name my domains" (or run /sidegraph:name-domains) and review its proposed grouping (larger graphs may get 2–3 alternatives). CLI alternative for scripted/CI use: sidegraph-domains bootstrap + sidegraph-ratify — see naming your domains.

Then record your first decision in a session — "record a gotcha: … anchor it to <function or heading> in <file>" — and watch it come back at the top of the context next time the agent works near that code.

Already have ADRs or design specs? sidegraph-bootstrap --host claude-code previews, imports, anchors, and proves one record through retrieval — see the Bootstrap guide. Full setup (hooks, env vars, Codex, and the source-checkout path for contributors): quickstart and installation.

Why

For the team — the senior engineer who never quits: what leaves with a person is not code, it's the map of dead ends. Onboarding a new engineer and a new agent session is the same problem, solved once. Settled questions stay settled — reopening one is a deliberate supersede with a reason, not amnesia.

For the project — documentation that knows when it's stale: unlike a wiki, the memory is anchored into the code and flags its own decay when the code moves on. Before an agent edits, retrieval puts the decisions and dead ends already recorded for that code in front of it, at whatever speed the agent works.

For the process — a sidecar, not a reform: it sits beside whatever spec/ADR flow you already run, capture is a byproduct of ordinary sessions, and the single ritual is a ratification gate. Provenance on every record (who decided, when, on what evidence) is a ready audit trail for the era of agent-made decisions.

One honest boundary: this is not "cheaper agents in general." Memory pays off where it replaces reading prose and where the answer isn't in the code at all; on a large monorepo where two greps answer the question, it costs more than it saves.

Three kinds of tools circle this problem, and each misses it:

• Agent memory (mem0, Letta, Graphiti) remembers conversations — not decisions bound to code entities.
• Code graphs and indexers (Serena, Potpie, repo maps) know what calls what — not why it's built this way or what was learned the hard way.
• ADR markdown records the why — as prose in a folder nobody opens at the moment it matters, with no link to the code it concerns.

None of them can answer: "which decisions touch this function — and how did they evolve?" Sidegraph is built for exactly that question.

OKF standardizes portable knowledge bundles, not decision memory; sidegraph-export-okf projects the full store, history included, into an OKF v0.1 bundle any OKF consumer can read.

How it works

 you work a session ──▶ Stop hook nudges the agent to distill durable decisions
                                │ propose_decisions / propose_domains (secrets redacted)
                                ▼
                        you ratify / drop  ──▶  append-only decision log,
                                                 committed with your repo
                                                        │
 next session ◀── SessionStart TOC            anchored to entities in the
 of named domains ◀── get_task_context ◀────── engine's graph (read-only);
 mistakes first        drill_down             re-anchored after refactors
 Read / Edit / Bash read ──▶ the file's records delivered in the call (once per file per agent)

Subagents get the memory too: on Claude Code a hook appends the decisions for the files a subagent's brief names to that brief, and on Claude Code and Codex another hook tells each new subagent that decision memory exists and how to ask it.

Two layers age differently: the structure layer (the code graph — entities, dependencies, communities: the what) and the decision layer on top (the why). The graph is disposable — the engine regenerates it from source at any moment. The memory must never be — so it lives in a separate store that nothing regenerates, and re-anchors itself as the code moves. The unit of memory is an entity, never a line of code: functions, classes, modules, document headings. Line numbers shift with every edit; entities persist through them.

On top of both sit named domains: each is a described area — title, WHY-IT-EXISTS summary, optional subdomains — so the agent's first read of a session is a table of contents it can answer from, not a bare community listing. A domain's membership anchors to durable entities, not volatile community ids, so it survives a fresh clone and a graph rebuild. See docs/concepts/mind-model.md.

What gets stored

Append-only is a feature: a reversed decision is closed and superseded, never deleted — "tried before, abandoned because…" stays retrievable via get_entity_history.

Facts follow the same append-only and ratification rules as decisions; ratifying or dropping a decision carries its still-pending facts along in the same verdict. Details: docs/concepts/data-model.md and docs/guides/capturing-decisions.md#facts-the-evidence-layer.

MCP tools

CLIs: sidegraph-bootstrap (reviewed cold-start import and production proof), sidegraph-init (initialize the store), sidegraph-domains (bootstrap/name domains), sidegraph-ratify (gate drafts), sidegraph-sync (re-anchor after a rebuild), sidegraph-compact (archive closed decisions/domains), sidegraph-verify (lint store integrity; --against <git-ref> for CI). See docs/guides/ci-cd-maintenance.md for GitHub Actions recipes built on sidegraph-sync --check/sidegraph-verify. Reference: docs/reference/.

Works on code and on docs

Anchor decisions to functions and classes — or to headings in your architecture markdown (LLM-free graph build, non-git folders supported). sidegraph-bootstrap parses existing ADRs and design specs into anchored decisions deterministically, no LLM.

An optional semantic pass (graphify extract, one API key, cached per file) goes a layer deeper on documentation: prose becomes concept nodes and thematic clusters, giving retrieval a richer graph to anchor against. Walkthrough: docs/guides/semantic-docs.md.

Trust & privacy

• Everything is local. Sidegraph reads your repo and the engine's graph.json (strictly read-only) and writes small human-readable JSON records inside your repo, plus a local, gitignored index it can always rebuild. Two things sit outside the store: the git hooks that sidegraph-init can install to keep the graph fresh (a helper and three hooks under .git/hooks/) and one cache file, sidegraph/launch-commit, under ${XDG_CACHE_HOME:-~/.cache}. SECURITY.md lists every write. Nothing leaves your machine — no network calls, no remote telemetry, no account. Sidegraph does keep local usage diagnostics in that gitignored index (which stored memory was shown, and which files a session touched afterwards) so you can see which memory was shown and which files those sessions then touched; they never travel, and SIDEGRAPH_TELEMETRY=off disables them.
• Secrets don't enter memory. Proposed decisions and facts pass redaction before they are stored. A ratification gate controls which of the agent's drafts become trusted memory. Under the default manual policy a person ratifies them. A proposal is stored first and waits as proposed until then. If you answer yes to sidegraph-init's question (or set SIDEGRAPH_RATIFY_POLICY yourself), eligible records ratify themselves at write time with a stamp that says so: lessons, gotchas, and standalone facts under auto-low-risk, and also ADRs, constraints, and domains under auto-all.
• Nothing is silently rewritten. The store is append-only; every change of mind is recorded as a supersession with its reason.

The engine underneath

Entity extraction and graph construction come from Graphify (its LLM-free build covers both code and markdown); Sidegraph never re-implements them or writes into the engine's output. The engine is optional at runtime: without a graph, records anchor to file paths and domains and retrieval still works, but symbol-level anchors, communities, and moved-code resolution need it (see the operations reference). Everything the engine produces is derived and regenerated on every rebuild; everything Sidegraph stores is deliberate and permanent, and it is trusted only once ratified (by a person, or by the opt-in policy). Own the memory, rent the graph.

Status

Pre-1.0: interfaces may still move. Not a code indexer, not general agent memory, not a graph engine — decision memory over a rented graph, and nothing else.

Documentation

Getting started · Concepts · Guides · Reference · Integrations (Graphify · Claude Code · Codex) · Verify your setup · Operations · Pilot kit · Engineering whitepaper

License

Apache-2.0.