Give Your Coding Agent a Memory: A Graphify → OKF Pipeline in an Afternoon

My coding agents have a groundhog-day problem. Every session starts from zero: the agent re-reads the same files, rebuilds the same mental model of the same codebase, burns tens of thousands of tokens doing it, and forgets all of it the moment the session ends. Tomorrow it does the whole thing again.

I’ve written before about trimming what the agent has to read and about token-lean context as the rung-3 practice everyone skips. This is the next piece of the same bet: not just trimming what goes in each session, but keeping what the agent learns between them.

Two things released in mid-2026 make that easy, and they compose almost too neatly:

• Graphify turns your codebase into a knowledge graph. Tree-sitter parses the structure locally; an LLM pass reads your READMEs, comments, and diagrams for the semantic links a parser can’t see. Out comes a queryable graph.json, an agent-ready GRAPH_REPORT.md, an interactive graph.html — and, with one flag, a cross-linked markdown wiki.
• Google’s Open Knowledge Format (OKF) is an open spec, not a tool. A “bundle” is just a directory of markdown files with YAML frontmatter, cross-linked so any agent can traverse it as a graph. It formalizes the LLM-wiki pattern we’ve all been improvising (CLAUDE.md, Obsidian vaults, index.md conventions) into something portable across tools.

The pipeline is one sentence: Graphify extracts, OKF stores. Automated extraction, portable memory, versioned in git next to the code it describes — which means the memory diffs in code review like everything else. That last part is what sold me.

⚠️ Snapshot warning. Both are young and moving fast. OKF is at v0.2, Graphify ships weekly, and the flags and version numbers below are as of late July 2026 and will drift. Re-check before you build a team workflow on either.

When to bother

Be honest with yourself first — most repos don’t need this. If your agent can answer a typical cross-cutting question by reading three or four files, skip the pipeline; a good CLAUDE.md is enough.

It earns its keep when questions fan out across many modules: roughly 50K+ LOC, or a repo where “how does auth work?” quietly touches routing, middleware, models, and a config file from 2019. That’s the thrash it kills.

Step 1: Generate the graph

pip install graphifyy   # note: two y's
cd your-repo
graphify --wiki

Everything runs locally — your source never leaves the machine. The one exception is the semantic pass, which spends some LLM tokens reading your docs and comments; Graphify reports the spend so there’s no surprise on the bill.

Open graph.html first. The force-directed view of your own architecture is worth the run by itself — the cover image on this post is my own race-kiroku graph, 4,778 nodes across 238 communities, and it’s the first time I’ve seen the shape of that codebase.

The GRAPH_REPORT.md is where the surprises live. Mine, lightly trimmed:

Graph complete — 4,778 nodes, 10,262 edges, 238 communities from 300 files.

God Nodes            (the things everything leans on)
1. get_session()   — 204 edges
2. User            — 150 edges
3. MyRaceEntry     — 106 edges

Surprising Connections
- CLAUDE.md's migration instructions directly reference _run_migrations()
  in app/database.py — the doc and the code are quietly coupled.
- The README's services table names one email provider, but the deploy
  config references a different one's API key — the README is stale.
- An unimplemented plan doc already references real, shipped functions —
  worth checking whether that plan is stale or quietly live.

None of that came from a question I thought to ask. That’s the pitch in three bullets: the graph surfaces the couplings and stale docs you’d never grep for. Every edge is also tagged EXTRACTED (the parser verified it) or INFERRED (an LLM guess, with a confidence score) — hold onto that distinction, because agents should trust the two very differently.

Step 2: The bundle Graphify already writes

Here’s the part I over-engineered in my head before running it: I assumed I’d script the conversion from graph.json to a markdown bundle. I didn’t have to. That --wiki flag from Step 1 emits exactly an OKF-shaped bundle — an index.md per community, one article per node, cross-linked with plain markdown links. The mapping it’s doing under the hood:

A concept file lands looking like this:

---
type: Module
title: Authentication
description: Session-based auth; issues JWTs consumed by all routers.
tags: [auth, security]
---
# Key abstractions
- [get_session](./get-session.md) — god node, 204 connections
# Depends on
- [models](../models/index.md) (EXTRACTED)
- [rate-limiter](../infra/rate-limiter.md) (INFERRED, 0.7)

Commit it to docs/knowledge/ and you’re done: readable on GitHub, greppable, and it shows up in a code-review diff like any other change. (Want a different frontmatter shape or a stricter OKF profile? graph.json is right there — a 30-line script maps it however you like. But out of the box, --wiki is the whole of Step 2.)

Step 3: Point your agent at it

Two commands, total, and neither is manual CLAUDE.md surgery: pip install graphifyy to get the tool, then register the Graphify skill with your agent. After that the agent knows to consult the bundle before crawling source, and to keep it current. The one instruction worth adding by hand:

Before exploring source files, consult docs/knowledge/index.md — a linked
knowledge graph of this codebase. Treat INFERRED edges as hints, EXTRACTED
edges as fact. After significant work, append a dated entry to
docs/knowledge/log.md and update any concept files you invalidated.

That last sentence is the “self-updating” part, and it’s my favorite bit. OKF reserves log.md for chronological history, and — as I noted in the adoption-ladder post — agents are far better at wiki bookkeeping than any human. Nobody keeps a knowledge base current by hand. An agent told to, every time it finishes a task, mostly will.

Step 4: Keep it fresh in CI

A stale graph is worse than none — it lies with confidence. Graphify caches per file and --update re-processes only what changed, so refresh on merge and never think about it again:

# .github/workflows/knowledge-graph.yml
on: { push: { branches: [main] } }
jobs:
  refresh-graph:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install graphifyy && graphify --update --wiki
      - run: |
          git config user.name "knowledge-bot"
          git add docs/knowledge && git commit -m "chore: refresh knowledge graph" || true
          git push

What you actually get

Take a concrete question: “how is user authentication handled?” An agent without the graph reads five-plus files — about 14K tokens in Graphify’s benchmark. With the bundle, it reads one index, follows two links, and answers from documented relationships, for a few hundred tokens. Vendor claims put the savings north of 70%; discount that however much your skepticism demands, but the shape of the win is real and it’s the same every time: repeated expensive re-reads collapse into cheap lookups, and — the part the token math misses — the map survives between sessions.

The side effect nobody puts in the pitch deck: docs/knowledge/ turns out to be the onboarding doc your team never wrote. I didn’t build it for the humans. The humans read it anyway.

Caveats

• Inferred edges lie sometimes. That’s the whole reason the confidence labels exist. Keep them in the bundle and tell the agent to treat INFERRED as a hint, EXTRACTED as fact. Strip the labels to make the files prettier and you’ve built a machine for laundering guesses into facts.
• The first run costs tokens proportional to repo size. One-time, and it amortizes fast.
• Both are v0.x. Expect churn in the tools. The pattern underneath — a markdown wiki as agent memory — is the durable part, and it’ll outlive whichever binary you install this month.

The bet underneath

Same bet as RTK and CodeGraph, pushed one step further in time: the next round of savings in AI coding isn’t a smarter model, it’s better engineering around the model. CodeGraph shrinks what the agent reads inside one session; this shrinks what it has to re-learn across all of them. Extraction you automate, memory you make portable, both versioned next to the code — and the smart model gets to spend its budget thinking instead of re-discovering what it figured out yesterday.

An afternoon to wire up. Then your agent stops waking up with amnesia. 🥂

References

• Introducing the Open Knowledge Format — Google Cloud
• OKF spec and samples on GitHub
• Graphify guide — Better Stack
• Karpathy’s LLM-wiki gist

• ← Previous Post
• Next Post →