The product map and graph carry what is shipped, building, paused, and dead — before anyone re-reads the code.
aictx/memory
Your agent knows your code. It doesn't know your product. Your agent knows your code. It doesn't know your product.
Memory keeps the product graph of a codebase: features, decisions, status — anchored to the code. Agents query it on demand and keep it current as the product changes.
Homebrew
brew install aictx/tap/memory npm
npm install -g @aictx/memory The loop
Build the graph once. Query it on demand. Keep it honest at session end.
01 Index once.
memory init creates local storage and prints an
indexing brief. Your agent explores the repo, interviews you for
intent and stage, and saves the initial graph: features,
decisions, gotchas, open questions.
02 Query on demand.
Mid-task, the agent runs
memory query "<question>" and gets a
token-budgeted subgraph — matches, related decisions,
connected open questions. No per-task preloading.
03 Save and sync.
memory save records product-meaningful changes and
refreshes the map. memory sync verifies code anchors
at session end and reports exactly what went stale.
AGENTS.md Generated product map
## Product map (generated — refresh with memory save or sync)
Acme Render — Self-hosted PDF render service for invoice pipelines.
**Building:** webhook-retry-queue — Failed webhooks re-enter a retry queue. — services/billing/
**Shipped:** pdf-render-api — Renders invoice templates to PDF. — services/render/
**Paused:** batch-exports — Nightly bulk export of rendered documents. — services/exports/
**Recent decisions:** retries-run-in-worker · sqlite-over-postgres
**Open questions:** pdf-storage-location — Where do rendered PDFs live long-term?
Use Memory when
You run many projects with AI agents.
Come back to a repo after three weeks and neither you nor the agent remembers what is shipped, what is half-done, or why it was built this way. Code can be re-read; intent, stage, and rationale cannot.
Code for a paused feature looks exactly like code for a shipped one. Stage lives in the graph, not in guesswork.
Decisions are stored with their reasons and survive sessions, branches, and agent switches.
Nodes anchor to path globs. memory sync diffs the
tree and reports which claims need re-verification.
memory status --all prints one row per registered
project: stages, open questions, stale anchors, last sync.
Plain files in .memory/ with a SQLite full-text
index. No embeddings, no cloud, no model API.
Cold-resume context Answers grounded in product reality Git-native memory
Product context on demand.
Instead of re-deriving feature state from code and git history, the agent asks the graph and starts grounded.
Where did we leave batch exports?
Worked for 7m 18s⌄
I need to reconstruct the state of this feature from the code and git history.
Ran
rg "exports|batch|cron"
Read
services/exports/, git log --oneline
Explored 14 files, 5 searches
Where did we leave batch exports?
Ran
memory query "state of batch exports" Memory — product graph batch-exports — paused. Nightly bulk export of rendered
documents. services/exports/
Decision: exports wait on the storage choice. Open question: where do rendered PDFs live long-term?
3 nodes and 1 open question, straight from the graph
