Summary: Memory is a frontier problem for agents, especially coding agents, which must follow a team’s practices consistently. Short-term memory keeps a long session faithful to its early instructions; long-term memory holds personal preferences, repo conventions, org practices, and non-technical context (Slack, PRDs). Natural-language files keep it inspectable, but you need a lifecycle: creation, retrieval at the right moment, and evidence of value. Governance (usage and acceptance stats, whose feedback counts) is what tools lack most. Outside coding, memory of each customer (how and when they like to be contacted) is what makes customer-facing agents feel personal.
Key ideas
- Memory dimensions: short vs long term; personal, team, company; updating vs static; transparent vs opaque (langtalks—57-memory, itamar-friedman).
- Hierarchy: personal memory → repo memory (CLAUDE.md/AGENTS.md, committed) → org practices (architecture, testing; often in Notion) → non-technical context (Slack threads, PRDs via MCP) (langtalks—57-memory).
- Natural-language memory is preferable for now because it’s controllable; you can see and veto what was learned (langtalks—57-memory).
- Three-part framework: how a rule is created (human, machine, or both), when it’s retrieved, and whether it’s valuable. If a rule fired 100 times and developers accepted the result 80 times, keep it; otherwise change or delete it (langtalks—57-memory).
- Ingestion design: avoid both extremes (“encode everything into one format” and “only index where things live”). Ingest and encode per media type (logs, PR discussions, diagrams) with references back to sources, give agents memory tools per type, and route between them (langtalks—57-memory).
- Learning governance: should one senior’s repeated comment become a rule? Juniors versus seniors, outliers, positive and negative learning (langtalks—57-memory).
- Mem0’s MCP gives add, search, update, delete; plus multimodal memories (UI screenshots, architecture diagrams), graph modeling, timestamps with expiry, and usefulness feedback. That’s ~80% of the plumbing, not the intelligence (langtalks—57-memory).
- Merging parallel agent sessions needs their intent (in the sessions), not just their code (langtalks—57-memory).
- Cold start: backfill (e.g. 12 months of GitHub discussions) rather than only learning going forward (langtalks—57-memory).
- Good memory also cuts tokens and cost; it’s context engineering of the future (langtalks—57-memory).
- Start with the file system before a vector DB: most agent work is episodic, so files for PRDs, plans, and to-dos give persistence, git history, and human review; semantic memory retrieval is rarely the first or second thing you need (langtalks—55-context-engineering).
- Claude Code memory levels: project, user, enterprise (langtalks—55-context-engineering).
- Critique of memory systems: retrieval, memory graphs, and summarization only choose which notes to re-read from an ever-growing stack, like an employee rereading all their notes each morning. The problem is ill-posed because data isn’t distilled as it arrives. Humans change a little with every input (explainable—164-gilad-levi-continual-learning, gilad-levi).
- Two layers for a domain agent: a constantly enriched data layer (what permissions actually allow) and a knowledge layer of org policies and exceptions (“never auto-disable the CEO”), learned from every interaction so customers needn’t repeat themselves (hidden-layers—twine-nadav-erez, nadav-erez).
- Per-customer memory: what a person would jot in a notebook (“doesn’t like morning calls”, “has five kids”) has to be given to agents as a capability. monday’s AgentOS bakes in long-term memory, so an agent knows months later to phone a lead at 9 a.m. instead of emailing (startup-for-startup—370-agentos-month-to-day, raz-diskin, moshe-krispin)
Disagreements & open questions
- Bitter lesson (scale data and compute) versus algorithmic innovation: Friedman expects new memory architectures; the hosts sense today’s memory is feature engineering awaiting a learned solution (langtalks—57-memory).
- Files or weights? Itamar Friedman prefers natural-language memory files for now because you can read and veto what was learned (langtalks—57-memory, itamar-friedman); the LangTalks hosts want models that learn during use and consolidate into weights overnight instead of “clunky markdown memory” (langtalks—63-wake-up), and Gilad Levi argues file-based memory is ill-posed (explainable—164-gilad-levi-continual-learning, gilad-levi).
Takeaways
- Track each rule’s usage and acceptance rate and prune rules that don’t earn their place (langtalks—57-memory)
- Ingest memory per source type with links back to originals instead of one giant encoding (langtalks—57-memory)
- Backfill memory from historical PR discussions to avoid cold start (langtalks—57-memory)
- Use files (PRD, plan, to-do) as the agent’s working memory before building a vector memory (langtalks—55-context-engineering)
Related
memory-consolidation · human-vs-ai-memory · context-engineering · second-brain · continual-learning