Your coding agent already learned this: local-first memory with Graft

Andrea Redegalli — Wed, 16 Sep 2026 02:23:18 +0000

Many coding-agent sessions end with an expensive loss: the bug is understood, the fix is shipped, and the useful reasoning disappears with the session.

Graft is an open-source project for keeping that kind of knowledge available locally across later agent work. Its focus is not document ingestion or a hosted chatbot. It is persistent memory for the fixes, decisions, constraints, and project-specific gotchas that agents uncover while solving real tasks.

The workflow is intentionally small

The core loop is three questions:

Have we seen this before? Use graft query for a confidence-gated top result: STRONG, WEAK, or MISS.
What could help here? Use graft retrieve for ranked memories.
What else is connected? Use graft explore to walk semantic and keyword relationships.

When a solution is worth preserving, it can be added as a memory node with a title, body, and keywords:

graft insert \
  --title 'Spring @Valid must also be applied to nested DTO fields' \
  --body 'Without @Valid on the nested field, validation does not cascade into it.' \
  --keyword spring-boot \
  --keyword validation \
  --keyword gotcha

The project documents the intended pattern clearly: search before a non-trivial task, solve normally when nothing useful exists, and save the reusable learning afterward.

Local runtime, not a hosted memory service

Graft’s core runtime is local: a CLI communicates with a local daemon, which uses SQLite storage alongside FTS5 and sqlite-vec. Embeddings run locally through llama.cpp with BGE-M3. The repository states that the default setup needs no SaaS account, external embedding API, or API key.

The retrieval modes are deliberately different:

query uses embedding-based candidates plus lexical verification and confidence gating.
retrieve combines BGE-M3 vectors, BM25 over titles, and BM25 over bodies with Reciprocal Rank Fusion.
explore traverses semantic and keyword relationships using beam search, score decay, and MMR diversity.

This is why Graft is not positioned as a replacement for a vector database. The repository distinguishes bulk document indexing from remembering agent learnings produced during work.

Integrations and current scope

Graft ships as a C11 project with a CLI contract, so agents that can launch a subprocess can use it. The repository lists integrations for Claude Code, Codex, Open Code, Gemini CLI, Claude Desktop, ChatGPT, and custom agents through CLI, subprocess, REST, or MCP.

It also documents profiles for separate memory spaces, plus optional REST, MCP, graph-viewer, and analytics tooling. Knowledge can evolve through supersession: older memories remain inspectable while a newer memory becomes the useful one.

The project is currently an active alpha in the v0.1.x line. Its README lists the local daemon and CLI, SQLite storage, BGE-M3 embeddings, verified recall, hybrid retrieval, graph exploration, profiles, coding-agent skills, and MCP bridge as working today. It also explicitly calls out areas still evolving, including the API surface before 1.0, packaging and platform coverage, remote/shared memory, team workflows, and neural reranking.

If your problem is indexing millions of documents, use the right retrieval stack for that. If the problem is that your coding agent keeps rediscovering the same hard-won lesson, Graft is built for that narrower job.

Repository: https://github.com/AEndrix03/Graft

This post was prepared with AI assistance and reviewed against the repository README.

DEV Community: Andrea Redegalli

Your coding agent already learned this: local-first memory with Graft

The workflow is intentionally small

Local runtime, not a hosted memory service

Integrations and current scope