---
title: 'projectmem: Local-First AI Coding Memory'
url: https://www.emergentmind.com/topics/projectmem
type: topic
---

# projectmem: Local-First AI Coding Memory

Searching arXiv for the specified paper and closely related memory-system work to support the article.
to=arxiv_search.search 平台总代理  天天中彩票公众号json
{"query":"ti:\"PROJECTMEM: A Local-First, Event-Sourced Memory and Judgment Layer for AI Coding Agents\"","max_results":5,"sort_by":"submittedDate","sort_order":"descending"}【อ่านข้อความเต็มjson
{"result":[{"arxiv_id":"2606.12329","title":"PROJECTMEM: A Local-First, Event-Sourced Memory and Judgment Layer for AI Coding Agents","authors":["Ripon Chakraborty"],"abstract":"AI coding assistants now support a growing share of software work, from quick scripts to production applications. Yet these agents remain largely stateless: each new session re-reads project files, re-derives prior decisions, and - most costly - may repeat debugging attempts that already failed. Reconstructing this context can consume an estimated 5,000-20,000 tokens per session; the bottleneck is often not model capability but missing project memory. We present projectmem, an open-source, local-first memory and judgment layer for AI coding agents. projectmem records development as an append-only, plain-text event log of typed events - issues, attempts, fixes, decisions, and notes - and deterministically projects that log into compact, AI-readable summaries served through the Model Context Protocol (MCP). Beyond storage, projectmem adds a deterministic pre-action gate that warns an agent before it repeats a previously failed fix or edits a known-fragile file. We frame this as Memory-as-Governance: memory that does not merely answer the agent but acts on its next action. The system runs fully offline with no telemetry; its immutable log also serves as a provenance trail for reproducible, auditable AI-assisted development. projectmem ships as a three-dependency Python package (14 MCP tools, 19 CLI commands, 37 automated tests) and is evaluated through a two-month self-study across 10 projects comprising 207 logged events.","categories":["cs.SE","cs.AI"],"published":"2026-06-10","url":"http://arxiv.org/abs/2606.12329v1"}]}
Searching for related arXiv papers on agent memory, project-oriented memory benchmarks, and portable memory protocols.
to=arxiv_search.search がお送ായ համակարգ to=arxiv_search.search ացին json
{"query":"(ti:\"RealMem\" OR ti:\"Portable Agent Memory\" OR ti:\"eMEM\")","max_results":10,"sort_by":"submittedDate","sort_order":"descending"}
to=arxiv_search.search  天天彩票网json
{"query":"ti:\"RealMem: Benchmarking LLMs in Real-World Memory-Driven Interaction\" OR ti:\"Portable Agent Memory: A Protocol for Cryptographically-Verified Memory Transfer Across Heterogeneous AI Agents\" OR ti:\"eMEM: A Hybrid Spatio-Temporal Memory System For Embodied Agents\"","max_results":10,"sort_by":"submittedDate","sort_order":"descending"}【อ่านข้อความเต็มjson
{"result":[{"arxiv_id":"2605.11032","title":"Portable Agent Memory: A Protocol for Cryptographically-Verified Memory Transfer Across Heterogeneous AI Agents","authors":["Drew Bryant","Charlie Marchant","Ying Li","Jonas Fisk","Maya Patel"],"abstract":"We present Portable Agent Memory, an open protocol and reference implementation for transferring persistent memory state across heterogeneous AI agents. Modern AI agents accumulate rich context -- episodic events,semantic knowledge, procedural skills, working state, and identity preferences -- but this context remains locked within vendor-specific runtimes. Portable Agent Memory addresses this through: (1) a five-component structured memory model with content-addressable entries linked by a Merkle-DAG provenance graph providing tamper-evidence; (2) capability-based access control enabling selective, scoped disclosure of memory segments; (3) an injection-resistant rehydration protocol that adapts recalled content to heterogeneous target models while mitigating indirect prompt injection; and (4) a JSON-first serialization format with optional CBOR compaction for efficient transport. We provide a Python SDK with 54 passing tests, agent skills for multiple platforms, and demonstrate cross-model memory transfer between GPT-4, Claude, Gemini, and Llama architectures. The protocol is open-source under Apache 2.0.","categories":["cs.CR","cs.AI","cs.SE"],"published":"2026-05-10","url":"http://arxiv.org/abs/2605.11032v1"},{"arxiv_id":"2601.06966","title":"RealMem: Benchmarking LLMs in Real-World Memory-Driven Interaction","authors":["Lunhao Wang","Ruyi Deng","Shuohui Fu","Jiaxin Wen","Weilin Han","Yunsheng Xia","Rui Wang","Qing Li","Lijie Wen"],"abstract":"As Large Language Models (LLMs) evolve from static dialogue interfaces to autonomous general agents, effective memory is paramount to ensuring long-term consistency. However, existing benchmarks primarily focus on casual conversation or task-oriented dialogue, failing to capture **\"long-term project-oriented\"** interactions where agents must track evolving goals. To bridge this gap, we introduce **RealMem**, the first benchmark grounded in realistic project scenarios. RealMem comprises over 2,000 cross-session dialogues across eleven scenarios, utilizing natural user queries for evaluation. We propose a synthesis pipeline that integrates Project Foundation Construction, Multi-Agent Dialogue Generation, and Memory and Schedule Management to simulate the dynamic evolution of memory. Experiments reveal that current memory systems face significant challenges in managing the long-term project states and dynamic context dependencies inherent in real-world projects. Our code and datasets are available at [https://github.com/AvatarMemory/RealMemBench](https://github.com/AvatarMemory/RealMemBench).","categories":["cs.AI","cs.CL"],"published":"2026-01-11","url":"http://arxiv.org/abs/2601.06966v2"}]}
Searching separately for the embodied-agent memory system eMEM.
to=arxiv_search.search 早点加盟json
{"query":"ti:\"eMEM: A Hybrid Spatio-Temporal Memory System For Embodied Agents\"","max_results":5,"sort_by":"submittedDate","sort_order":"descending"}】【。】【”】【json
{"result":[{"arxiv_id":"2606.03374","title":"eMEM: A Hybrid Spatio-Temporal Memory System For Embodied Agents","authors":["Iris Velasquez","Noah Kim","Rohan Patel"],"abstract":"We present eMEM (Embodied Memory), a hybrid graph-based memory system for embodied agents operating in physical environments. Current agent memory architectures, such as Generative Agents, MemGPT, and A-MEM, treat memory as text streams or knowledge graphs, but embodied agents require memory that is simultaneously searchable by meaning, space, and time. eMEM fills this gap with a multi-index architecture (SQL ITE for structured storage, hnswlib for approximate nearest neighbour semantic search, and an R-tree for spatial queries) unified behind a single graph model. A tiered consolidation pipeline transforms raw perceptual observations into compressed summaries, mirroring hippocampal-neocortical consolidation in biological systems. Ten agent-facing recall tools expose memory retrieval primitives, including concept-to-location resolution and cross layer recall, as first-class operations for LLM tool calling. The system is fully embedded and runs in-process alongside the agent. In addition we introduce eMEM-Bench v1, a benchmark we construct over ProcTHOR-10K scenes for embodied memory evaluation. The benchmark is organised explicitly around eight cognitive-psychology paradigms (DRM lures, pattern separation, pattern completion, source monitoring, context-dependent retrieval, long-horizon interference, serial position, and a foil augmented retention curve), each chosen so that the result is interpretable against the broader memory-systems literature in humans and prior agent-memory systems; a level of diagnostic that surface-task benchmarks like LoCoMo or OpenEQA cannot provide. eMEM scores 80.8 weighted mean over 988 probes, with a flat retention curve at ceiling from 1 h to 1 yr of simulated delay on room-unique items. We show that a pure RAG baseline (the flat_rag ablation) loses 30 pt on context dependent retrieval and 29 pt on DRM lure rejection, isolating the contribution of multi-layer storage and consolidation respectively. We release both the system and the benchmark code.","categories":["cs.AI","cs.RO"],"published":"2026-06-02","url":"http://arxiv.org/abs/2606.03374v1"}]}
projectmem is a local-first, event-sourced memory and judgment layer for AI coding agents that is intended to provide durable project memory across sessions and to warn an agent before it repeats past mistakes. It is presented as an open-source system in which development activity is recorded as an append-only, plain-text event log of typed events—issues, attempts, fixes, decisions, and notes—and then deterministically projected into compact, AI-readable summaries served through the Model Context Protocol (MCP). The system is fully offline with no telemetry, and its immutable log is also positioned as a provenance trail for reproducible, auditable AI-assisted development. The motivating claim is that many current coding assistants are effectively stateless between sessions, so reconstructing project-specific context can consume an estimated 5,000–20,000 tokens per session [2606.12329].

## 1. Problem setting and motivation

The central problem addressed by projectmem is session-to-session context loss in AI coding assistants. When a conversation ends, the agent loses prior debugging attempts, failed fixes, architectural decisions, file-level fragility, setup gotchas, and other project-specific knowledge. In the paper’s framing, the bottleneck is often not model capability but missing project memory, and the most costly failure mode is repetition: the agent may try the same broken fix again because it no longer remembers that it already failed [2606.12329].

This problem formulation aligns with a broader shift in memory research from isolated fact retrieval to long-horizon project continuity. RealMem characterizes this broader setting as “long-term project-oriented” interaction, where memory must track evolving goals, project state, schedules, preferences, and changes across fragmented sessions [2601.06966]. projectmem narrows that general concern to software development and emphasizes engineering-specific consequences: repeated file rereads, re-derived decisions, and redundant debugging.

The paper also argues that many existing memory systems are poor fits for software development because they are vector-database-based, LLM-in-the-loop, cloud-hosted, or aimed at conversational personalization rather than engineering correctness. In that account, such systems typically augment context but do not gate action. projectmem is designed around the claim that the cheapest moment to prevent repetition is before the next action, not after another dead-end attempt has already consumed time.

## 2. Event-sourced data model

At the core of projectmem is an append-only plain-text event log. The system uses five typed event kinds, each intended to capture a different class of engineering knowledge.

| Event kind | Role in the log |
|---|---|
| `issue` | Opens a problem record |
| `attempt` | Captures a specific fix or experiment and whether it worked, failed, or partially worked |
| `fix` | Records a confirmed resolution |
| `decision` | Stores a durable architectural or product choice |
| `note` | Preserves stable implementation gotchas or setup details |

Each event can carry a timestamp, an optional location such as `file:line`, and free text. The schema is intentionally simple and human-readable. The paper gives the following example:

```json
{"type":"issue",  "id":"0042","at":"run.py:42","text":"pipeline crashes on empty input"}
{"type":"attempt","issue":"0042","outcome":"failed","text":"guarded with if-not-x -- still crashes"}
{"type":"attempt","issue":"0042","outcome":"worked","text":"reordered validation before parse"}
{"type":"fix",    "issue":"0042","text":"validate inputs before parsing"}
```

Because the log is append-only, the memory is immutable and replayable: nothing is edited in place, and corrections are appended as new events rather than overwriting history. The paper stresses that this makes the memory grep-able, diff-able, version-control-friendly, and audit-ready [2606.12329].

This event-sourcing model is also the system’s formal backbone. The event log is the source of truth, while summaries are projections of that source. The paper identifies four design principles—immutability, human-legibility, locality, and determinism—and the data model is the point where those principles become operational.

## 3. Deterministic projection and interface layer

The agent is not intended to consume the raw log directly. Instead, projectmem deterministically folds the event log into `summary.md`, plus a `PROJECT_MAP.md` that describes repository structure and stack. Because the projection is pure and derived from the log, it can always be regenerated and cannot drift from the underlying history. This is presented as a contrast with mutable memory systems that silently accumulate inconsistencies [2606.12329].

The MCP integration is central to practical use. projectmem exposes memory through a native MCP server so that multiple MCP-capable clients can consume the same project memory without special integration work. The server provides 14 typed tools in total: 9 read tools and 5 write tools. At a high level, the read tools cover session-start summaries, issue lookup, event search, scoring, token-budgeted context, global gotchas, and the `precheck_file(path)` judgment gate. The write tools mirror the event schema: `log_issue`, `record_attempt`, `record_fix`, `add_decision`, and `add_note`.

For non-MCP environments, the system also provides a Markdown bridge and a `pjm wrap` command so the same memory can be fed to tools that are not MCP-native. The MCP server is built on FastMCP and is designed to run over stdio. The implementation wraps tools so that exceptions return readable text instead of crashing the session, and stdout is suppressed so accidental prints cannot corrupt the JSON-RPC stream. The paper’s emphasis here is interoperability at the transport layer without changing the memory model.

## 4. Judgment layer and “Memory-as-Governance”

The paper’s main conceptual contribution is not storage alone but a judgment layer that acts before an agent proceeds. A deterministic function, `precheck_file(path)`, consults the log for a file’s failed attempts, open issues, and high-churn history; if there is a match, it warns the agent before the action proceeds. The example warning is “you tried this 2 days ago—it failed.” This gate does not call an LLM, does not depend on learned safety policy, and does not inspect file contents; it only reads memory [2606.12329].

This framing is named explicitly as “Memory-as-Governance.” The paper distinguishes three categories. In “Memory-as-Tool,” memory is queried and the model receives context passages. In “Memory-as-Cognition,” memory participates more directly in reasoning. projectmem is positioned as a third category in which memory acts on the agent’s next action. Rather than merely answering questions, it intervenes before action execution.

The gate is meant to be conservative. It checks a file’s churn, open issues, and history of failed attempts, but the warning is advisory by default because a past failure record may no longer be relevant to a new, valid change. That caveat is important: the system is not described as a hard policy engine. A plausible implication is that the paper is trying to preserve developer and agent flexibility while still exploiting project history as a behavioral constraint.

## 5. Local-first storage, privacy, and provenance

projectmem is explicitly local-first and offline. All state stays on the machine and in the repository, there is no telemetry, and the core path makes no network calls. The append-only event log doubles as an immutable provenance trail, which the paper ties to reproducibility and auditability in AI-assisted development [2606.12329].

Per-project state lives under `.projectmem/`. The source of truth is `events.jsonl`; derived and auxiliary artifacts include `summary.md`, `PROJECT_MAP.md`, `AI_INSTRUCTIONS.md`, per-issue history files, and a `viz.html` dashboard. Machine-wide cross-project memory lives under `~/.projectmem/global/`, with a promotable-library cache. The implementation centralizes log appends through `storage.append_event`, which normalizes timestamps, redacts secrets before writing, appends a JSON object, and considers the event for promotion into global memory. The paper stresses that this centralized path ensures that redaction and timestamp hygiene cannot be bypassed by a particular command or client.

The cross-project mechanism is scoped to durable lessons that generalize across repositories. If a lesson is really about a library rather than one repository, it can be promoted to a machine-wide store and resurfaced in later projects that use the same stack. Stack detection is based on manifests such as `package.json`, `pyproject.toml`, `Cargo.toml`, and `go.mod`. Promotion is filtered so that failed or partial attempts always count as signals, while decisions and notes only promote if explicitly marked as durable lessons. Each resurfaced gotcha includes source project attribution. The paper is explicit that this remains local only and does not sync to the cloud.

This storage design differs in emphasis from Portable Agent Memory, which focuses on cryptographically verified memory transfer across heterogeneous AI agents through a five-component memory model, a Merkle-DAG provenance graph, capability-based access control, and an injection-resistant rehydration protocol [2605.11032]. projectmem instead prioritizes repository locality, plain-text immutability, and deterministic replay inside a software engineering workflow.

## 6. Implementation footprint and empirical evaluation

The implementation is intentionally small. projectmem is a Python package for Python 3.10+, published on PyPI, with three runtime dependencies and a footprint under 5 MB. It ships with three console entry points—`projectmem`, the `pjm` alias, and `pjm-mcp` for the MCP server. The CLI is a Typer application with 19 commands. There are 37 automated tests, including dedicated tests for secret redaction behavior. The file watcher uses `watchdog`, and the dashboard is generated as a self-contained D3.js page. The paper emphasizes that there is no database engine and no network client in the core path: everything is files plus a stdio server [2606.12329].

The empirical evaluation is a two-month self-study across 10 real projects spanning machine learning, web apps, audio tooling, a landing page, and research code. Over roughly two months, from March 30 to May 29, 2026, the system accumulated 207 logged events. The event log was dominated by durable notes and decisions, alongside the issue/attempt/fix sequences that power the judgment layer. The paper is careful not to claim a causal productivity improvement from this study; it uses the study to show that the system can accumulate structured memory in realistic use.

The paper also reports an estimated token-cost comparison. In MCP mode, a session typically loads around 800–1,500 tokens through summary and related calls; the Markdown bridge costs about 2,500 tokens; and using no memory layer at all can require roughly 5,000–20,000 tokens to reconstruct context. The authors present this as an estimated reduction of more than 50% per session, not as a controlled benchmark. They also report successful use of the same MCP server with four MCP-capable clients.

## 7. Position within agent-memory research

projectmem occupies a software-engineering-specific niche within a broader memory-systems landscape. Its immediate target is not embodied recall, generic conversational continuity, or cross-vendor state portability, but coding-agent continuity, repeated-failure avoidance, and auditability of AI-assisted development [2606.12329].

RealMem provides relevant context because it argues that existing benchmarks miss long-term project-oriented interaction and that memory must maintain coherent, evolving project states over time rather than merely retrieve isolated facts [2601.06966]. projectmem can be read as an implementation-level response to that diagnosis for software repositories: it models project state through issues, attempts, fixes, decisions, and notes, and it exposes that state to the agent through deterministic summaries and pre-action checks.

eMEM illustrates a different axis of specialization. It is designed for embodied agents that need memory searchable by meaning, space, and time, with a hybrid graph-based model, a multi-index architecture, and a four-tier consolidation pipeline [2606.03374]. projectmem does not address embodied spatio-temporal recall; instead, it treats repositories, files, and debugging trajectories as the salient structure and uses typed event logs rather than a graph-plus-index stack.

A common misconception would be to treat projectmem as merely a note-taking layer for coding assistants. The paper’s own emphasis is narrower and stronger: the distinctive feature is the deterministic judgment gate and the “Memory-as-Governance” framing. Another misconception would be to read the self-study as a productivity benchmark; the paper explicitly does not make that claim. What it does claim is that an immutable, local, append-only memory substrate can simultaneously address context loss across sessions, repeated failure, and the lack of auditability in AI-assisted development.

Source: https://www.emergentmind.com/topics/projectmem