Persistent local memory for AI coding agents.
Graft brings back useful fixes, decisions, gotchas and project knowledge when they become relevant again.
The agent still reasons. Graft gives it a head start.
Claude Code · Codex · ChatGPT · Claude Desktop · Gemini CLI · Open Code · custom agents
<sub>C11 · SQLite · sqlite-vec · FTS5 · BGE-M3 · llama.cpp · MCP · MessagePack</sub>
Your agent solves something difficult.
Graft remembers the useful part.
Later, another session hits a similar problem.
Graft surfaces the old learning before the agent wastes time rediscovering it.
solve something
│
▼
remember what mattered
│
▼
Graft
│
├── likely same problem ──► verified recall
├── related knowledge ────► hybrid retrieval
└── broader context ──────► graph exploration
│
▼
your agent
No SaaS. No external embedding API. No account. No API key.
Graft does not replace the agent's reasoning. It gives the agent relevant prior knowledge and lets the agent decide what to do with it.
Without persistent memory:
session 1
bug → investigate → understand → fix → context disappears
session 27
similar bug → investigate → understand → fix → context disappears
With Graft:
session 1
bug → investigate → fix → remember
session 27
similar bug → recall → decide → continue
Graft is useful for knowledge that is expensive to rediscover:
- root causes that took hours to find
- architectural decisions and why they were made
- framework and infrastructure gotchas
- project-specific conventions
- dependency constraints
- failed approaches worth avoiding
- fixes that may apply again
This is agent memory, not document storage.
brew tap AEndrix03/graft https://github.com/AEndrix03/Graft.git
brew install graft
graft stats
No database server. No model download by hand. No config required for the first run.
git clone https://github.com/AEndrix03/Graft.git
cd Graft
bash scripts/install.sh
Windows:
pwsh scripts/install.ps1
Optional GPU acceleration:
GRAFT_GPU=cuda bash scripts/install.sh
GRAFT_GPU=hip bash scripts/install.sh
Full installation reference → docs/install/
First, the memory is empty:
$ graft query "spring validation nested dto not working"
{
"status": 0,
"result": { "hit": "MISS" }
}
The agent investigates and solves the issue. Save the useful part:
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
Weeks later, with different wording:
$ graft query "why are constraints inside my nested request object ignored?"
{
"status": 0,
"result": {
"hit": "STRONG",
"title": "Spring @Valid must also be applied to nested DTO fields",
"body": "Without @Valid on the nested field, validation does not cascade into it."
}
}
Different prompt. Same underlying problem.
Graft surfaces the prior learning. The agent decides whether it is useful.
| graft query Fast top-1 lookup with confidence gating: STRONG ·WEAK ·MISS Use it when the agent wants to know: | graft retrieve Combines: Use it when several memories may help. | graft explore Walks semantic and keyword relationships with beam search, score decay and MMR diversity. Use it when the agent wants to know: |
Because Graft is shaped around what an agent learns while working, not around bulk document ingestion.
| Vector DB / traditional RAG | Graft | |
|---|---|---|
| Primary data | Documents | Agent learnings |
| Typical write | Bulk ingestion | Remember something useful |
| Typical read | Top-k chunks | Recall / retrieve / explore |
| Consumer | Application | AI agent |
| Confidence | Similarity ranking | STRONG /WEAK /MISS |
| Relationships | Usually external | Semantic + keyword graph |
| Knowledge changes | Replace/update documents | Supersession |
| Deployment | Database/service | Local binary + SQLite |
If you need to index millions of documents, use a vector database.
If you want your agent to remember what it discovered while solving real problems, Graft is built for that.
Graft is a binary with a CLI contract. Any agent that can run a subprocess can use it.
| Agent | Integration | Setup |
|---|---|---|
| Claude Code | Skills + optional hooks | graft setup claudecode |
| Codex | Skills + optional hooks / AGENTS.md |
graft setup codex |
| Open Code | Native skills | graft setup opencode |
| Gemini CLI | GEMINI.md workflow |
integrations/gemini-cli/ |
| Claude Desktop | MCP | integrations/claude-ai/ |
| ChatGPT | MCP stdio / HTTP | integrations/chatgpt/ |
| Your agent | CLI, subprocess, REST or MCP | docs/integrations/ |
The shipped integrations teach agents a simple pattern:
non-trivial task
│
▼
search memory
│
├── useful memory ───────► consider it
│
└── nothing useful ──────► solve normally
│
▼
worth remembering?
│
▼
save it
For Claude Code, Graft includes skills such as:
recall— smart search that escalates only when neededmemoryze— distill useful learnings into reusable memorieslearn— intentionally ingest useful knowledgememory-audit— inspect memory quality and reuse
Optional hooks can make recall deterministic at supported harness events. Hook wiring is currently manual.
Graft keeps its core runtime on your machine:
agent
│
▼
graft CLI
│
│ MessagePack / AF_UNIX
▼
graftd
│
├── SQLite + FTS5 + sqlite-vec
│
└── llama.cpp + BGE-M3
That means:
- one local database
- local embeddings
- no managed memory service
- no telemetry requirement
- no external API key
- CPU works out of the box
- CUDA / ROCm are optional
Chat clients can reach the same core through MCP.
ChatGPT / Claude Desktop
│
MCP
│
▼
MCP adapter
│
▼
graft CLI
│
▼
graftd
graft query "docker container exits after healthcheck"
Returns one confidence-gated result.
graft retrieve "docker healthcheck networking"
Returns ranked memories using dense + lexical retrieval.
graft explore "deployment failures" --keyword docker
Walks the memory graph for broader context.
query
→ BGE-M3 embedding
→ vector candidates
→ lexical verification
→ confidence gating
→ STRONG / WEAK / MISS
vector search ─┐
BM25 title ────┼─→ RRF → ranked memories
BM25 body ─────┘
semantic seed
→ graph edges
→ beam search
→ score decay
→ MMR diversity
The core is written in C11. Embeddings run locally through llama.cpp using BGE-M3. Storage is SQLite with FTS5 and sqlite-vec.
Graft itself does not require an external LLM call to store or retrieve memory.
A memory node contains:
title
body
keywords
vector
relationships
status
Nodes can be connected through keyword and semantic edges.
When knowledge becomes outdated, Graft supports supersession rather than silently pretending the old knowledge never existed:
old decision
│
└── SUPERSEDED BY ──► new decision
History stays inspectable while the newer memory becomes the useful one.
Separate memory spaces without running separate products:
GRAFT_PROFILE=work graft query "deployment rule"
GRAFT_PROFILE=personal graft query "docker workaround"
Profiles can be created, switched, exported, imported and merged.
graft profile list
graft profile add project-x
graft profile set project-x
This also gives you a straightforward way to move or combine local memory stores when needed.
The memory is not hidden behind a hosted platform.
graft stats
graft analytics
graft get <id>
graft delete <id>
Optional tooling includes:
- REST API
- MCP access
- browser graph viewer
- profile management
- usage analytics
Not an LLM.
Your agent still reasons.
Not a chatbot.
Bring your own agent.
Not a hosted memory SaaS.
The default runtime is local.
Not a vector database replacement.
It is opinionated around agent memory.
Not just a semantic cache.
Verified reuse is one primitive. Graft also provides ranked retrieval, graph exploration, evolving memories and agent workflows.
The same primitives can sit in front of an LLM-backed service:
request
│
▼
exact cache
│ MISS
▼
Graft
│ no useful memory
▼
LLM
│
└──► remember result
This is an experimental design pattern, not Graft's primary positioning.
See docs/microservices/.
Active alpha — v0.1.x
Working today:
- local daemon + CLI
- SQLite storage
- BGE-M3 embeddings
- verified recall
- hybrid retrieval
- graph exploration
- profiles
- Claude Code / Codex / Open Code skills
- MCP bridge
- optional REST API and graph viewer
Still evolving:
- API surface before 1.0
- packaging and platform coverage
- remote / shared memory
- team workflows
- neural reranking
The cross-encoder reranker is currently scaffolded but not active; verification currently relies on vector similarity plus lexical signals.
Now
- harden CLI and JSON contracts
- improve coding-agent integrations
- improve memory quality and observability
- publish better benchmarks
Next
- BGE reranker
- contradiction detection
- adaptive thresholds
- richer hooks
- remote read-only profiles
Later
- shared team memory
- distributed profile sync
- automatic consolidation
- richer admin tooling
| Getting started | docs/install/ |
| Use cases | docs/use-cases.md |
| Concepts | docs/concepts.md |
| Integrations | docs/integrations/ |
| Architecture | docs/architecture/ |
| CLI | docs/cli/ |
| Retrieval | docs/retrieval/ |
| Storage | docs/storage/ |
| Embeddings | docs/embeddings/ |
| Profiles | docs/profiles/ |
| HTTP API | docs/http-api/ |
Full documentation → docs/
git clone https://github.com/AEndrix03/Graft.git
cd Graft
bash scripts/install.sh
graft stats
Run tests with:
cmake --build build --target test
See CONTRIBUTING.md.
You can use, modify, distribute and embed Graft in proprietary projects subject to the license terms.