I\u2019ve been working on an open-source project called Memori \u2014 it\u2019s a memory layer for AI agents.
Memori is designed to give agents a persistent memory layer that supports both:
Short-term \u201cconscious\u201d memory (like working memory in humans)
Long-term retrieval using SQL full-text search (not vector stores)
It\u2019s built around a multi-agent architecture (memory agent, conscious agent, retrieval agent), with structured storage and zero config to get started. It supports SQLite, Postgres, and MySQL.
Would love to hear what you think \u2014 all critique welcome.\nHappy to answer questions or hear if you\u2019ve solved this differently."},"title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["agent","memory"],"value":"Show HN: Memori \u2013 Dual-Mode Memory Layer for AI Agents"},"url":{"matchLevel":"none","matchedWords":[],"value":"https://github.com/GibsonAI/memori"}},"_tags":["story","author_boburumurzokov","story_44821941","show_hn"],"author":"boburumurzokov","children":[44823527],"created_at":"2025-08-07T08:15:02Z","created_at_i":1754554502,"num_comments":2,"objectID":"44821941","points":4,"story_id":44821941,"story_text":"Hi Everyone,
I\u2019ve been working on an open-source project called Memori \u2014 it\u2019s a memory layer for AI agents.
Memori is designed to give agents a persistent memory layer that supports both:
Short-term \u201cconscious\u201d memory (like working memory in humans)
Long-term retrieval using SQL full-text search (not vector stores)
It\u2019s built around a multi-agent architecture (memory agent, conscious agent, retrieval agent), with structured storage and zero config to get started. It supports SQLite, Postgres, and MySQL.
Would love to hear what you think \u2014 all critique welcome.\nHappy to answer questions or hear if you\u2019ve solved this differently.","title":"Show HN: Memori \u2013 Dual-Mode Memory Layer for AI Agents","updated_at":"2026-03-05T22:29:36Z","url":"https://github.com/GibsonAI/memori"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"pauliusztin"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["agent","memory","architecture"],"value":"I spent weeks reading about how Cognee, Graphiti, and Neo4j's `agent-memory` build their agent memory architectures. They converged on the same heavy knowledge-graph design: an ontology, LLM extraction pipelines, deduplication, the works.
I really wanted to use them for my personal use case, but that looks like such a heavy setup that adds a lot of friction and silos. Plus, it feels like I just get my data trapped in their service, for not a ton of value.
That's why my "long-term memory" still lives in Obsidian, Readwise, and Google Drive, with per-project LLM wikis as the agent's memory. No infrastructure. And I'm fine with it.
They ship memory as a product, which, in my opinion, at a personal or small scale, is overkill. You can build the same "knowledge graph" experience via plain old `.md` files within an LLM wiki memory.
But still, graphs are strong, so I adapted the same architecture from the Cognee, Graphiti, and Neo4j `agent-memory` stacks to build a data-mining tool with just MongoDB, VoyageAI, and Gemini Flash. But I scoped it to a very particular problem and ontology domain to avoid the KG noise.
On the other end of the spectrum, if you want to ship a product at medium-to-large scale, it makes sense to start using monsters such as Neo4j, Zep, or HydraDB.
But I am curious: what is your long-term memory setup? Obsidian + LLM wikis vs. Cognee/Graphiti/Zep? Do you actually use tools such as Cognee or Zep?
In case you are curious about how Cognee, Graphiti, and Neo4j's `agent-memory` work under the hood, I wrote a full breakdown here: https://www.decodingai.com/p/unified-memory-from-scratch-knowledge-graphs"},"title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["agent","memory"],"value":"I reverse-engineered the three biggest agent-memory tools"}},"_tags":["story","author_pauliusztin","story_48919162","ask_hn"],"author":"pauliusztin","children":[48920027,48925406],"created_at":"2026-07-15T11:23:02Z","created_at_i":1784114582,"num_comments":4,"objectID":"48919162","points":2,"story_id":48919162,"story_text":"I spent weeks reading about how Cognee, Graphiti, and Neo4j's `agent-memory` build their agent memory architectures. They converged on the same heavy knowledge-graph design: an ontology, LLM extraction pipelines, deduplication, the works.
I really wanted to use them for my personal use case, but that looks like such a heavy setup that adds a lot of friction and silos. Plus, it feels like I just get my data trapped in their service, for not a ton of value.
That's why my "long-term memory" still lives in Obsidian, Readwise, and Google Drive, with per-project LLM wikis as the agent's memory. No infrastructure. And I'm fine with it.
They ship memory as a product, which, in my opinion, at a personal or small scale, is overkill. You can build the same "knowledge graph" experience via plain old `.md` files within an LLM wiki memory.
But still, graphs are strong, so I adapted the same architecture from the Cognee, Graphiti, and Neo4j `agent-memory` stacks to build a data-mining tool with just MongoDB, VoyageAI, and Gemini Flash. But I scoped it to a very particular problem and ontology domain to avoid the KG noise.
On the other end of the spectrum, if you want to ship a product at medium-to-large scale, it makes sense to start using monsters such as Neo4j, Zep, or HydraDB.
But I am curious: what is your long-term memory setup? Obsidian + LLM wikis vs. Cognee/Graphiti/Zep? Do you actually use tools such as Cognee or Zep?
In case you are curious about how Cognee, Graphiti, and Neo4j's `agent-memory` work under the hood, I wrote a full breakdown here: https://www.decodingai.com/p/unified-memory-from-scratch-knowledge-graphs","title":"I reverse-engineered the three biggest agent-memory tools","updated_at":"2026-07-15T18:52:07Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"Arulnidhi_k"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["agent","memory","architecture"],"value":"Aegis Memory is an open-source, self-hostable memory layer for multi-agent AI systems.
v1.2 adds Smart Memory - a two-stage pipeline that automatically decides what's worth storing:\n1. Fast rule-based filter catches obvious noise (greetings, "thanks", etc.)\n2. LLM extracts atomic facts only when the filter passes
This saves ~70% of extraction costs while keeping memory high-quality.
Try it in 15 seconds:\n pip install aegis-memory\n aegis demo
GitHub: https://github.com/quantifylabs/aegis-memory
Happy to answer questions about multi-agent memory architecture."},"title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["agent","memory"],"value":"Show HN: Aegis Memory v1.2 \u2013 We solved \"what's worth remembering\" for AI agents"},"url":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["memory"],"value":"https://github.com/quantifylabs/aegis-memory"}},"_tags":["story","author_Arulnidhi_k","story_46412348","show_hn"],"author":"Arulnidhi_k","children":[46414311,46426854],"created_at":"2025-12-28T16:45:10Z","created_at_i":1766940310,"num_comments":4,"objectID":"46412348","points":1,"story_id":46412348,"story_text":"Aegis Memory is an open-source, self-hostable memory layer for multi-agent AI systems.
v1.2 adds Smart Memory - a two-stage pipeline that automatically decides what's worth storing:\n1. Fast rule-based filter catches obvious noise (greetings, "thanks", etc.)\n2. LLM extracts atomic facts only when the filter passes
This saves ~70% of extraction costs while keeping memory high-quality.
Try it in 15 seconds:\n pip install aegis-memory\n aegis demo
GitHub: https://github.com/quantifylabs/aegis-memory
Happy to answer questions about multi-agent memory architecture.","title":"Show HN: Aegis Memory v1.2 \u2013 We solved \"what's worth remembering\" for AI agents","updated_at":"2026-03-05T23:14:40Z","url":"https://github.com/quantifylabs/aegis-memory"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"sivanhavkin"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["agent","memory","architecture"],"value":"I\u2019m sharing Entelgia, a research-oriented multi-agent AI architecture I\u2019ve been working on.
Entelgia is not a chatbot, but an experiment in how persistent identity, internal conflict, emotional regulation, and moral reasoning can emerge from structure rather than hard-coded rules.
Two primary agents engage in continuous dialogue across sessions, backed by a shared persistent memory (SQLite + STM), with mechanisms for:
internal conflict (id / ego / superego dynamics)
emotion tracking and importance scoring
memory promotion through error, repetition, and affect
bounded short-term memory (LRU)
observer-based correction loops (meta-cognitive layer)
The system runs fully locally using a local LLM (via Ollama) for privacy and reproducibility.
I recently completed a production-ready rewrite, focusing on:
deterministic system behavior
bounded memory growth
structured logging
privacy / PII redaction
testability and long-running stability
This is not a claim about artificial consciousness \u2014 the terminology is used strictly as architectural metaphor to explore internal regulation and continuity over time.
Repo (README explains both how and why):\nhttps://github.com/sivanhavkin/Entelgia
I\u2019d especially appreciate feedback from people interested in:
multi-agent systems
memory architectures
alignment via internal structure rather than external constraints
long-running LLM systems
Happy to answer questions or hear criticism."},"title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["agent","memory"],"value":"Show HN: Entelgia\u2013a consciousness-inspired,multi-agent AI with persistent memory"},"url":{"matchLevel":"none","matchedWords":[],"value":"https://github.com/sivanhavkin/Entelgia"}},"_tags":["story","author_sivanhavkin","story_46941234","show_hn"],"author":"sivanhavkin","created_at":"2026-02-09T03:25:51Z","created_at_i":1770607551,"num_comments":0,"objectID":"46941234","points":1,"story_id":46941234,"story_text":"I\u2019m sharing Entelgia, a research-oriented multi-agent AI architecture I\u2019ve been working on.
Entelgia is not a chatbot, but an experiment in how persistent identity, internal conflict, emotional regulation, and moral reasoning can emerge from structure rather than hard-coded rules.
Two primary agents engage in continuous dialogue across sessions, backed by a shared persistent memory (SQLite + STM), with mechanisms for:
internal conflict (id / ego / superego dynamics)
emotion tracking and importance scoring
memory promotion through error, repetition, and affect
bounded short-term memory (LRU)
observer-based correction loops (meta-cognitive layer)
The system runs fully locally using a local LLM (via Ollama) for privacy and reproducibility.
I recently completed a production-ready rewrite, focusing on:
deterministic system behavior
bounded memory growth
structured logging
privacy / PII redaction
testability and long-running stability
This is not a claim about artificial consciousness \u2014 the terminology is used strictly as architectural metaphor to explore internal regulation and continuity over time.
Repo (README explains both how and why):\nhttps://github.com/sivanhavkin/Entelgia
I\u2019d especially appreciate feedback from people interested in:
multi-agent systems
memory architectures
alignment via internal structure rather than external constraints
long-running LLM systems
Happy to answer questions or hear criticism.","title":"Show HN: Entelgia\u2013a consciousness-inspired,multi-agent AI with persistent memory","updated_at":"2026-03-05T23:32:54Z","url":"https://github.com/sivanhavkin/Entelgia"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"nikhilkanaka"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["agent","memory","architecture"],"value":"Location: San Francisco, CA
Remote: Yes
Willing to relocate: Yes
Technologies: Python, Go, TypeScript, LLMs, AI agents
R\u00e9sum\u00e9/CV: https://npkanaka.github.io/files/cv.pdf
Email: nikhilpavan.kanaka [at] gmail.com
=============================================
AI Engineer focused on production agentic systems. I currently build end-to-end AI products involving multi-agent orchestration, memory/runtime architecture, retrieval, evaluations, and reliable deployment. Before this, I worked across backend infrastructure, data systems, NLP/ML research, and high-scale production systems. I\u2019m most interested in teams building serious AI engineering products: agents, harness, infrastructure, applied AI, or systems where correctness and reliability matter."},"story_title":{"matchLevel":"none","matchedWords":[],"value":"Ask HN: Who wants to be hired? (July 2026)"}},"_tags":["comment","author_nikhilkanaka","story_48747975"],"author":"nikhilkanaka","comment_text":"Location: San Francisco, CA
Remote: Yes
Willing to relocate: Yes
Technologies: Python, Go, TypeScript, LLMs, AI agents
R\u00e9sum\u00e9/CV: https://npkanaka.github.io/files/cv.pdf
Email: nikhilpavan.kanaka [at] gmail.com
=============================================
AI Engineer focused on production agentic systems. I currently build end-to-end AI products involving multi-agent orchestration, memory/runtime architecture, retrieval, evaluations, and reliable deployment. Before this, I worked across backend infrastructure, data systems, NLP/ML research, and high-scale production systems. I\u2019m most interested in teams building serious AI engineering products: agents, harness, infrastructure, applied AI, or systems where correctness and reliability matter.","created_at":"2026-07-07T15:55:19Z","created_at_i":1783439719,"objectID":"48819557","parent_id":48747975,"story_id":48747975,"story_title":"Ask HN: Who wants to be hired? (July 2026)","updated_at":"2026-07-07T15:58:08Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"breakingnewsai"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["agent","memory","architecture"],"value":"Hi HN,
I\u2019m excited to announce the launch of my book, "The Complete LangGraph Blueprint: Build 50+ AI Agents for Business Success" .
LangGraph is an open-source framework designed to make AI agent workflows more dynamic, adaptable, and powerful. Unlike traditional chain-based workflows, LangGraph leverages graphs to handle complex decision-making, branching, and concurrency with ease.
This book is a step-by-step guide that takes you from beginner to advanced, helping you build and deploy 50+ real-world AI agents for industries like finance, healthcare, customer service, and more.
What\u2019s Inside?\nCore principles of LangGraph: Nodes, edges, states, and graphs.\nHow to enhance AI agents with memory, multi-agent architectures, and human-in-the-loop capabilities.\nReal-world integrations with APIs and advanced use cases.\nFull code examples and diagrams for every concept.
Why LangGraph?\nIf you\u2019ve used LangChain, you\u2019ll love LangGraph! It goes beyond static chains by introducing dynamic routing, adaptive workflows, and tool selection for intelligent decision-making.
The framework is open source, and the book is designed to help developers, startups, and businesses unlock its potential.
Who\u2019s It For?\nDevelopers looking to upskill in AI agent frameworks.\nEntrepreneurs automating workflows with AI.\nAI enthusiasts curious about next-gen tools like LangGraph.
Get the Book: https://www.amazon.com/dp/B0DP69QV7K
I\u2019d love your thoughts, feedback, and questions!"},"title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["agent"],"value":"The Complete LangGraph Blueprint \u2013 Build 50 AI Agents for Business Success"}},"_tags":["story","author_breakingnewsai","story_42303448","ask_hn"],"author":"breakingnewsai","children":[42303735],"created_at":"2024-12-03T06:21:36Z","created_at_i":1733206896,"num_comments":2,"objectID":"42303448","points":2,"story_id":42303448,"story_text":"Hi HN,
I\u2019m excited to announce the launch of my book, "The Complete LangGraph Blueprint: Build 50+ AI Agents for Business Success" .
LangGraph is an open-source framework designed to make AI agent workflows more dynamic, adaptable, and powerful. Unlike traditional chain-based workflows, LangGraph leverages graphs to handle complex decision-making, branching, and concurrency with ease.
This book is a step-by-step guide that takes you from beginner to advanced, helping you build and deploy 50+ real-world AI agents for industries like finance, healthcare, customer service, and more.
What\u2019s Inside?\nCore principles of LangGraph: Nodes, edges, states, and graphs.\nHow to enhance AI agents with memory, multi-agent architectures, and human-in-the-loop capabilities.\nReal-world integrations with APIs and advanced use cases.\nFull code examples and diagrams for every concept.
Why LangGraph?\nIf you\u2019ve used LangChain, you\u2019ll love LangGraph! It goes beyond static chains by introducing dynamic routing, adaptive workflows, and tool selection for intelligent decision-making.
The framework is open source, and the book is designed to help developers, startups, and businesses unlock its potential.
Who\u2019s It For?\nDevelopers looking to upskill in AI agent frameworks.\nEntrepreneurs automating workflows with AI.\nAI enthusiasts curious about next-gen tools like LangGraph.
Get the Book: https://www.amazon.com/dp/B0DP69QV7K
I\u2019d love your thoughts, feedback, and questions!","title":"The Complete LangGraph Blueprint \u2013 Build 50 AI Agents for Business Success","updated_at":"2024-12-03T08:36:11Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"breakingnewsai"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["agent","memory","architecture"],"value":"Hi HN,
A quick update for everyone interested in "The Complete LangGraph Blueprint: Build 50+ AI Agents for Business Success": The special free offer for the book ends on December 5th, 2024.
Get the Book: https://www.amazon.com/dp/B0DP69QV7K
This book is a step-by-step guide that takes you from beginner to advanced, helping you build and deploy 50+ real-world AI agents for industries like finance, healthcare, customer service, and more.
What\u2019s Inside?\nCore principles of LangGraph: Nodes, edges, states, and graphs.\nHow to enhance AI agents with memory, multi-agent architectures, and human-in-the-loop capabilities.\nReal-world integrations with APIs and advanced use cases.\nFull code examples and diagrams for every concept.
Why LangGraph?\nIf you\u2019ve used LangChain, you\u2019ll love LangGraph! It goes beyond static chains by introducing dynamic routing, adaptive workflows, and tool selection for intelligent decision-making.\nThe framework is open source, and the book is designed to help developers, startups, and businesses unlock its potential.
Curious before committing? Check out Chapter 10: Plan-and-Execute Agents, which covers:\n- What Plan-and-Execute is and why it\u2019s groundbreaking:\n Discover how this architecture splits reasoning tasks into Planning and Execution phases for superior performance in multi-step workflows.\n- Key differences between Plan-and-Execute and ReAct models:\n Understand why forward-thinking and re-planning make Plan-and-Execute agents more effective in handling complex tasks.
A practical walkthrough for building your own Plan-and-Execute AI agent:\nLearn how to create dynamic agents that plan, execute, and adapt seamlessly, complete with code examples using LangGraph.
Chapter 10: Plan-and-Execute Agents
10.1 Introduction\nThe Plan-and-Execute architecture enhances reasoning tasks by splitting them into two core phases: Planning and Execution. This approach is derived from the Plan-and-Solve methodology, which contrasts with traditional single-step (ReAct) agents. The Plan-and-Solve architecture is particularly useful when dealing with complex multi-step reasoning tasks that require explicit planning for long-term goals.\nIn this chapter, we explore how Plan-and-Execute agents work by devising a multi-step plan and executing it in phases. The agent adapts as necessary, allowing for re-planning in case some steps fail or require more context.\n10.2 Why Use Plan-and-Execute?\nOne of the key issues in multi-step reasoning tasks is that even sophisticated models like GPT-4 often struggle with explicit long-term planning. Plan-and-Execute solves this by:\n\u25cf Breaking down complex tasks into smaller, manageable steps.\n\u25cf Adapting dynamically based on intermediate results.\n\u25cf Revisiting the plan when necessary to adjust or correct steps.\nThis architecture is superior to traditional ReAct (React-then-Act) models as it emphasizes forward-thinking (planning) before acting.\n10.3 Plan-and-Execute Concepts\nFrom the paper Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning, the Plan-and-Solve approach addresses the limitations of Zero-shot-CoT (Chain-of-Thought), which typically fails due to:\n1. Calculation Errors: Mistakes in intermediate calculations.\n2. Missing-Step Errors: Skipping important intermediate steps.\n3. Semantic Misunderstandings: Misinterpretation of the problem context.\nTo solve these issues, Plan-and-Solve introduces two key steps:\n1. Planning: Devising a clear plan to divide the overall task into subtasks, ensuring no steps are skipped.\n2. Execution: Executing each subtask and refining the plan if needed.
In the Plan-and-Solve architecture, the agent takes a multi-step approach:\n\u25cf First, it plans out a sequence of steps.\n\u25cf Then, it executes the steps one by one.\n\u25cf If any part of the process fails or if more information is needed, it re-plans the sequence, ensuring robustness and flexibility."},"title":{"matchLevel":"none","matchedWords":[],"value":"Show HN: Last Chance\u2013Free Offer for 'The Complete LangGraph Blueprint' Ends 12/6"},"url":{"matchLevel":"none","matchedWords":[],"value":"https://www.amazon.com/dp/B0DP69QV7K"}},"_tags":["story","author_breakingnewsai","story_42315434","show_hn"],"author":"breakingnewsai","created_at":"2024-12-04T08:07:46Z","created_at_i":1733299666,"num_comments":0,"objectID":"42315434","points":1,"story_id":42315434,"story_text":"Hi HN,
A quick update for everyone interested in "The Complete LangGraph Blueprint: Build 50+ AI Agents for Business Success": The special free offer for the book ends on December 5th, 2024.
Get the Book: https://www.amazon.com/dp/B0DP69QV7K
This book is a step-by-step guide that takes you from beginner to advanced, helping you build and deploy 50+ real-world AI agents for industries like finance, healthcare, customer service, and more.
What\u2019s Inside?\nCore principles of LangGraph: Nodes, edges, states, and graphs.\nHow to enhance AI agents with memory, multi-agent architectures, and human-in-the-loop capabilities.\nReal-world integrations with APIs and advanced use cases.\nFull code examples and diagrams for every concept.
Why LangGraph?\nIf you\u2019ve used LangChain, you\u2019ll love LangGraph! It goes beyond static chains by introducing dynamic routing, adaptive workflows, and tool selection for intelligent decision-making.\nThe framework is open source, and the book is designed to help developers, startups, and businesses unlock its potential.
Curious before committing? Check out Chapter 10: Plan-and-Execute Agents, which covers:\n- What Plan-and-Execute is and why it\u2019s groundbreaking:\n Discover how this architecture splits reasoning tasks into Planning and Execution phases for superior performance in multi-step workflows.\n- Key differences between Plan-and-Execute and ReAct models:\n Understand why forward-thinking and re-planning make Plan-and-Execute agents more effective in handling complex tasks.
A practical walkthrough for building your own Plan-and-Execute AI agent:\nLearn how to create dynamic agents that plan, execute, and adapt seamlessly, complete with code examples using LangGraph.
Chapter 10: Plan-and-Execute Agents
10.1 Introduction\nThe Plan-and-Execute architecture enhances reasoning tasks by splitting them into two core phases: Planning and Execution. This approach is derived from the Plan-and-Solve methodology, which contrasts with traditional single-step (ReAct) agents. The Plan-and-Solve architecture is particularly useful when dealing with complex multi-step reasoning tasks that require explicit planning for long-term goals.\nIn this chapter, we explore how Plan-and-Execute agents work by devising a multi-step plan and executing it in phases. The agent adapts as necessary, allowing for re-planning in case some steps fail or require more context.\n10.2 Why Use Plan-and-Execute?\nOne of the key issues in multi-step reasoning tasks is that even sophisticated models like GPT-4 often struggle with explicit long-term planning. Plan-and-Execute solves this by:\n\u25cf Breaking down complex tasks into smaller, manageable steps.\n\u25cf Adapting dynamically based on intermediate results.\n\u25cf Revisiting the plan when necessary to adjust or correct steps.\nThis architecture is superior to traditional ReAct (React-then-Act) models as it emphasizes forward-thinking (planning) before acting.\n10.3 Plan-and-Execute Concepts\nFrom the paper Plan-and-Solve Prompting: Improving Zero-Shot Chain-of-Thought Reasoning, the Plan-and-Solve approach addresses the limitations of Zero-shot-CoT (Chain-of-Thought), which typically fails due to:\n1. Calculation Errors: Mistakes in intermediate calculations.\n2. Missing-Step Errors: Skipping important intermediate steps.\n3. Semantic Misunderstandings: Misinterpretation of the problem context.\nTo solve these issues, Plan-and-Solve introduces two key steps:\n1. Planning: Devising a clear plan to divide the overall task into subtasks, ensuring no steps are skipped.\n2. Execution: Executing each subtask and refining the plan if needed.
In the Plan-and-Solve architecture, the agent takes a multi-step approach:\n\u25cf First, it plans out a sequence of steps.\n\u25cf Then, it executes the steps one by one.\n\u25cf If any part of the process fails or if more information is needed, it re-plans the sequence, ensuring robustness and flexibility.","title":"Show HN: Last Chance\u2013Free Offer for 'The Complete LangGraph Blueprint' Ends 12/6","updated_at":"2024-12-04T08:10:15Z","url":"https://www.amazon.com/dp/B0DP69QV7K"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"TaurenHunter"},"title":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["agent","memory","architecture"],"value":"Zep: A Temporal Knowledge Graph Architecture for Agent Memory"},"url":{"matchLevel":"none","matchedWords":[],"value":"https://arxiv.org/abs/2501.13956"}},"_tags":["story","author_TaurenHunter","story_43085671"],"author":"TaurenHunter","created_at":"2025-02-18T03:05:03Z","created_at_i":1739847903,"num_comments":0,"objectID":"43085671","points":1,"story_id":43085671,"title":"Zep: A Temporal Knowledge Graph Architecture for Agent Memory","updated_at":"2025-02-18T03:06:19Z","url":"https://arxiv.org/abs/2501.13956"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"ViktorKuz"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["agent","memory","architecture"],"value":"I\u2019ve been experimenting with long-term memory architectures for agent systems and wanted to share some technical results that might be useful to others working on retrieval pipelines.
Benchmark: LoCoMo (10 runs \u00d7 10 conversation sets)\nAverage accuracy: 80.1%\nSetup: full isolation across all 10 conv groups (no cross-contamination, no shared memory between runs)
Architecture (all open weights except answer generation)
1. Dense retrieval
BGE-large-en-v1.5 (1024d)
FAISS IndexFlatIP
Standard BGE instruction prompt:\n\u201cRepresent this sentence for searching relevant passages.\u201d
2. Sparse retrieval
BM25 via classic inverted index
Helps with low-embedding-recall queries and keyword-heavy prompts
3. MCA (Multi-Component Aggregation) ranking\nA simple gravitational-style score combining:
keyword coverage
token importance
local frequency signal\nMCA acts as a first-pass filter to catch exact-match questions.\nThreshold: coverage \u2265 0.1 \u2192 keep top-30
4. Union strategy\nInstead of aggressively reducing the union, the system feeds 112\u2013135 documents directly to a re-ranker.\nIn practice this improved stability and prevented loss of rare but crucial documents.
5. Cross-Encoder reranking
bge-reranker-v2-m3
Processes the full union (rare for RAG pipelines, but worked best here)
Produces a final top-k used for answer generation
6. Answer generation
GPT-4o-mini, used only for the final synthesis step
No agent chain, no tool calls, no memory-dependent LLM logic
Performance
<3 seconds per query on a single RTX 4090
Deterministic output between runs
Reproducible test harness (10\u00d710 protocol)
Why this worked
Three things seemed to matter most:
MCA-first filter to stabilize early recall
Not discarding the union before re-ranking
Proper dense embedding instruction, which massively affects BGE performance
Notes
LoCoMo remains one of the hardest public memory benchmarks:\n5,880 multi-hop, temporal, negation-rich QA pairs derived from human\u2013agent conversations.\nWould be interested to compare with others working on long-term retrieval, especially multi-stage ranking or cross-encoder heavy pipelines.
Github: https://github.com/vac-architector/VAC-Memory-System"},"title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["memory"],"value":"I built an open-weights memory system that reaches 80.1% on the LoCoMo benchmark"}},"_tags":["story","author_ViktorKuz","story_46057283","ask_hn"],"author":"ViktorKuz","children":[46057311],"created_at":"2025-11-26T13:38:09Z","created_at_i":1764164289,"num_comments":2,"objectID":"46057283","points":2,"story_id":46057283,"story_text":"I\u2019ve been experimenting with long-term memory architectures for agent systems and wanted to share some technical results that might be useful to others working on retrieval pipelines.
Benchmark: LoCoMo (10 runs \u00d7 10 conversation sets)\nAverage accuracy: 80.1%\nSetup: full isolation across all 10 conv groups (no cross-contamination, no shared memory between runs)
Architecture (all open weights except answer generation)
1. Dense retrieval
BGE-large-en-v1.5 (1024d)
FAISS IndexFlatIP
Standard BGE instruction prompt:\n\u201cRepresent this sentence for searching relevant passages.\u201d
2. Sparse retrieval
BM25 via classic inverted index
Helps with low-embedding-recall queries and keyword-heavy prompts
3. MCA (Multi-Component Aggregation) ranking\nA simple gravitational-style score combining:
keyword coverage
token importance
local frequency signal\nMCA acts as a first-pass filter to catch exact-match questions.\nThreshold: coverage \u2265 0.1 \u2192 keep top-30
4. Union strategy\nInstead of aggressively reducing the union, the system feeds 112\u2013135 documents directly to a re-ranker.\nIn practice this improved stability and prevented loss of rare but crucial documents.
5. Cross-Encoder reranking
bge-reranker-v2-m3
Processes the full union (rare for RAG pipelines, but worked best here)
Produces a final top-k used for answer generation
6. Answer generation
GPT-4o-mini, used only for the final synthesis step
No agent chain, no tool calls, no memory-dependent LLM logic
Performance
<3 seconds per query on a single RTX 4090
Deterministic output between runs
Reproducible test harness (10\u00d710 protocol)
Why this worked
Three things seemed to matter most:
MCA-first filter to stabilize early recall
Not discarding the union before re-ranking
Proper dense embedding instruction, which massively affects BGE performance
Notes
LoCoMo remains one of the hardest public memory benchmarks:\n5,880 multi-hop, temporal, negation-rich QA pairs derived from human\u2013agent conversations.\nWould be interested to compare with others working on long-term retrieval, especially multi-stage ranking or cross-encoder heavy pipelines.
Github: https://github.com/vac-architector/VAC-Memory-System","title":"I built an open-weights memory system that reaches 80.1% on the LoCoMo benchmark","updated_at":"2026-03-05T23:08:07Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"bikidev"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["agent","memory","architecture"],"value":"Hi HN,\nI built Metamind because I was frustrated with how stateless modern LLM interactions are. Every conversation starts from scratch, and existing memory solutions felt like overkill for what should be a simple problem.
What is it?\nA self-contained memory system for AI agents that mimics human memory architecture:
- Episodic memory (conversations, experiences)\n- Semantic memory (concepts, relations, knowledge graphs)\n- Vector memory (HNSW-powered similarity search)\n- Automatic memory consolidation, reflection, and decay
Key technical choices:
- Single Rust binary with single-file database (no Postgres, no Redis, no vector DB)\n- Multi-user ready with complete data isolation\n- HNSW for O(log n) vector search instead of naive brute force\n- Cognitive processes: salience-based decay, memory consolidation, pattern detection
Why share this?\nI'm genuinely curious:
- Is the "brain-like memory" approach interesting or just over-engineering?\n- Are others frustrated by stateless LLM interactions?\n- What memory/retrieval strategies have worked for you?\n- Where would you take this architecture next?
I know there are limitations, but I wanted to share what's working today rather than wait for perfection. The core retrieval + consolidation loop feels genuinely useful.
Demo video (Skipped to Demo): https://www.loom.com/share/c187767b2d1e4e778bc41676c574408b?t=657"},"title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["agent","architecture"],"value":"Metamind \u2013 Cognitive architecture for LLM agents"}},"_tags":["story","author_bikidev","story_46356415","ask_hn"],"author":"bikidev","created_at":"2025-12-22T17:40:05Z","created_at_i":1766425205,"num_comments":0,"objectID":"46356415","points":1,"story_id":46356415,"story_text":"Hi HN,\nI built Metamind because I was frustrated with how stateless modern LLM interactions are. Every conversation starts from scratch, and existing memory solutions felt like overkill for what should be a simple problem.
What is it?\nA self-contained memory system for AI agents that mimics human memory architecture:
- Episodic memory (conversations, experiences)\n- Semantic memory (concepts, relations, knowledge graphs)\n- Vector memory (HNSW-powered similarity search)\n- Automatic memory consolidation, reflection, and decay
Key technical choices:
- Single Rust binary with single-file database (no Postgres, no Redis, no vector DB)\n- Multi-user ready with complete data isolation\n- HNSW for O(log n) vector search instead of naive brute force\n- Cognitive processes: salience-based decay, memory consolidation, pattern detection
Why share this?\nI'm genuinely curious:
- Is the "brain-like memory" approach interesting or just over-engineering?\n- Are others frustrated by stateless LLM interactions?\n- What memory/retrieval strategies have worked for you?\n- Where would you take this architecture next?
I know there are limitations, but I wanted to share what's working today rather than wait for perfection. The core retrieval + consolidation loop feels genuinely useful.
Demo video (Skipped to Demo): https://www.loom.com/share/c187767b2d1e4e778bc41676c574408b?t=657","title":"Metamind \u2013 Cognitive architecture for LLM agents","updated_at":"2026-03-05T23:16:26Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"ViktorKuz"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["agent","memory","architecture"],"value":"I\u2019ve been experimenting with long-term memory architectures for agent systems and wanted to share some technical results that might be useful to others working on retrieval pipelines.\nBenchmark: LoCoMo (10 runs \u00d7 10 conversation sets) Average accuracy: 80.1% Setup: full isolation across all 10 conv groups (no cross-contamination, no shared memory between runs)
Architecture (all open weights except answer generation)
1. Dense retrieval
BGE-large-en-v1.5 (1024d)
FAISS IndexFlatIP
Standard BGE instruction prompt: \u201cRepresent this sentence for searching relevant passages.\u201d
2. Sparse retrieval
BM25 via classic inverted index
Helps with low-embedding-recall queries and keyword-heavy prompts
3. MCA (Multi-Component Aggregation) ranking A simple gravitational-style score combining:
keyword coverage
token importance
local frequency signal MCA acts as a first-pass filter to catch exact-match questions. Threshold: coverage \u2265 0.1 \u2192 keep top-30
4. Union strategy Instead of aggressively reducing the union, the system feeds 112\u2013135 documents directly to a re-ranker. In practice this improved stability and prevented loss of rare but crucial documents.
5. Cross-Encoder reranking
bge-reranker-v2-m3
Processes the full union (rare for RAG pipelines, but worked best here)
Produces a final top-k used for answer generation
6. Answer generation
GPT-4o-mini, used only for the final synthesis step
No agent chain, no tool calls, no memory-dependent LLM logic
Performance
<3 seconds per query on a single RTX 4090
Deterministic output between runs
Reproducible test harness (10\u00d710 protocol)
Why this worked
Three things seemed to matter most:
MCA-first filter to stabilize early recall
Not discarding the union before re-ranking
Proper dense embedding instruction, which massively affects BGE performance
Notes
LoCoMo remains one of the hardest public memory benchmarks: 5,880 multi-hop, temporal, negation-rich QA pairs derived from human\u2013agent conversations. Would be interested to compare with others working on long-term retrieval, especially multi-stage ranking or cross-encoder heavy pipelines.
Github: https://github.com/vac-architector/VAC-Memory-System"},"title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["memory"],"value":"Show HN: Change the model. Same output. The pipeline decides. VAC Memory System"}},"_tags":["story","author_ViktorKuz","story_46244300","show_hn"],"author":"ViktorKuz","created_at":"2025-12-12T14:11:17Z","created_at_i":1765548677,"num_comments":0,"objectID":"46244300","points":1,"story_id":46244300,"story_text":"I\u2019ve been experimenting with long-term memory architectures for agent systems and wanted to share some technical results that might be useful to others working on retrieval pipelines.\nBenchmark: LoCoMo (10 runs \u00d7 10 conversation sets) Average accuracy: 80.1% Setup: full isolation across all 10 conv groups (no cross-contamination, no shared memory between runs)
Architecture (all open weights except answer generation)
1. Dense retrieval
BGE-large-en-v1.5 (1024d)
FAISS IndexFlatIP
Standard BGE instruction prompt: \u201cRepresent this sentence for searching relevant passages.\u201d
2. Sparse retrieval
BM25 via classic inverted index
Helps with low-embedding-recall queries and keyword-heavy prompts
3. MCA (Multi-Component Aggregation) ranking A simple gravitational-style score combining:
keyword coverage
token importance
local frequency signal MCA acts as a first-pass filter to catch exact-match questions. Threshold: coverage \u2265 0.1 \u2192 keep top-30
4. Union strategy Instead of aggressively reducing the union, the system feeds 112\u2013135 documents directly to a re-ranker. In practice this improved stability and prevented loss of rare but crucial documents.
5. Cross-Encoder reranking
bge-reranker-v2-m3
Processes the full union (rare for RAG pipelines, but worked best here)
Produces a final top-k used for answer generation
6. Answer generation
GPT-4o-mini, used only for the final synthesis step
No agent chain, no tool calls, no memory-dependent LLM logic
Performance
<3 seconds per query on a single RTX 4090
Deterministic output between runs
Reproducible test harness (10\u00d710 protocol)
Why this worked
Three things seemed to matter most:
MCA-first filter to stabilize early recall
Not discarding the union before re-ranking
Proper dense embedding instruction, which massively affects BGE performance
Notes
LoCoMo remains one of the hardest public memory benchmarks: 5,880 multi-hop, temporal, negation-rich QA pairs derived from human\u2013agent conversations. Would be interested to compare with others working on long-term retrieval, especially multi-stage ranking or cross-encoder heavy pipelines.
Github: https://github.com/vac-architector/VAC-Memory-System","title":"Show HN: Change the model. Same output. The pipeline decides. VAC Memory System","updated_at":"2026-03-05T23:10:22Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"cpfiffer"},"comment_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["agent","memory","architecture"],"value":"Cameron here @ Letta.
Letta now provides Anthropic's `memory` tool, enabling agents to dynamically manage their own memory architecture.
The memory tool is something I have wanted since before I started working at Letta, but never had the bandwidth to implement. Our researcher Kevin Lin ended up hacking it together in an evening, and it works swimmingly. But what does it enable?
Currently, Letta agents have a fixed memory architecture. A memory architecture is a set of memory blocks to track various types of information, such as communication guidelines, information about a user, company policies, how to use various tools, etc. Memory architecture can allow the agent to learn about nearly any type of information and persist it through its lifespan.
However, agents have not been able to modify this architecture themselves. They could modify what was INSIDE the blocks, such as including a note about how I like dogs when I mention it.
But the agent could not add a new block to track information that was unanticipated. For example, if the agent recognizes that it is struggling with understanding how to use tools, it either had to write tool use guidelines to some other block ill-suited for that purpose, or simply lose the information.
With the memory tool, the agent can decide to add a new block to accomodate this information. You can either ask it to add the block if you notice it struggling, or it may even choose to add the block itself.
The memory tool also allows "peeking" on blocks stored in something like a filesystem, such as /notes/letta to track the agent's notes on Letta. The agent can look at what is inside this memory without having to load it permanently into its context, which helps memory blocks resemble a filesystem.
I am extraordinarily proud of this tool and how quickly it came together. My sense is that this tool is one of the final building blocks needed to make Letta agents genuinely self-improving -- their "shape" is now under their own control, and they can now adapt much more readily to changing environments.
Very, very cool stuff."},"story_title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["memory"],"value":"Claude Sonnet 4.5 and the memory Omni-tool in Letta"},"story_url":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["memory"],"value":"https://www.letta.com/blog/introducing-sonnet-4-5-and-the-memory-omni-tool-in-letta"}},"_tags":["comment","author_cpfiffer","story_45431326"],"author":"cpfiffer","comment_text":"Cameron here @ Letta.
Letta now provides Anthropic's `memory` tool, enabling agents to dynamically manage their own memory architecture.
The memory tool is something I have wanted since before I started working at Letta, but never had the bandwidth to implement. Our researcher Kevin Lin ended up hacking it together in an evening, and it works swimmingly. But what does it enable?
Currently, Letta agents have a fixed memory architecture. A memory architecture is a set of memory blocks to track various types of information, such as communication guidelines, information about a user, company policies, how to use various tools, etc. Memory architecture can allow the agent to learn about nearly any type of information and persist it through its lifespan.
However, agents have not been able to modify this architecture themselves. They could modify what was INSIDE the blocks, such as including a note about how I like dogs when I mention it.
But the agent could not add a new block to track information that was unanticipated. For example, if the agent recognizes that it is struggling with understanding how to use tools, it either had to write tool use guidelines to some other block ill-suited for that purpose, or simply lose the information.
With the memory tool, the agent can decide to add a new block to accomodate this information. You can either ask it to add the block if you notice it struggling, or it may even choose to add the block itself.
The memory tool also allows "peeking" on blocks stored in something like a filesystem, such as /notes/letta to track the agent's notes on Letta. The agent can look at what is inside this memory without having to load it permanently into its context, which helps memory blocks resemble a filesystem.
I am extraordinarily proud of this tool and how quickly it came together. My sense is that this tool is one of the final building blocks needed to make Letta agents genuinely self-improving -- their "shape" is now under their own control, and they can now adapt much more readily to changing environments.
Very, very cool stuff.","created_at":"2025-09-30T21:13:24Z","created_at_i":1759266804,"objectID":"45431327","parent_id":45431326,"story_id":45431326,"story_title":"Claude Sonnet 4.5 and the memory Omni-tool in Letta","story_url":"https://www.letta.com/blog/introducing-sonnet-4-5-and-the-memory-omni-tool-in-letta","updated_at":"2026-03-18T19:19:47Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"gotham64"},"title":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["agent","memory","architecture"],"value":"OpenPawz Engram biologically-inspired memory architecture for AI agents"},"url":{"matchLevel":"none","matchedWords":[],"value":"https://github.com/OpenPawz/openpawz/blob/main/ENGRAM.md"}},"_tags":["story","author_gotham64","story_47228095"],"author":"gotham64","children":[47228096],"created_at":"2026-03-03T04:34:00Z","created_at_i":1772512440,"num_comments":1,"objectID":"47228095","points":5,"story_id":47228095,"title":"OpenPawz Engram biologically-inspired memory architecture for AI agents","updated_at":"2026-03-11T18:43:49Z","url":"https://github.com/OpenPawz/openpawz/blob/main/ENGRAM.md"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"doiito"},"title":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["agent","memory","architecture"],"value":"Show HN:Gliding Horse \u2013 a Rust Agent OS with CPU-Like Memory Architecture"},"url":{"matchLevel":"none","matchedWords":[],"value":"https://github.com/doiito/gliding_horse"}},"_tags":["story","author_doiito","story_48319699","show_hn"],"author":"doiito","children":[48319700,48367901],"created_at":"2026-05-29T06:20:47Z","created_at_i":1780035647,"num_comments":0,"objectID":"48319699","points":1,"story_id":48319699,"title":"Show HN:Gliding Horse \u2013 a Rust Agent OS with CPU-Like Memory Architecture","updated_at":"2026-06-02T21:50:26Z","url":"https://github.com/doiito/gliding_horse"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"vvoruganti"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["agent","memory","architecture"],"value":"Hey HN,
It\u2019s Vineeth from Plastic Labs. We've been building Honcho, an open-source memory library for stateful AI agents.
Most memory systems are just vector search\u2014store facts, retrieve facts, stuff into context. We took a different approach: memory as reasoning. (We talk about this a lot on our blog)
We built Neuromancer, a model trained specifically for AI-native memory. Instead of naive fact extraction, Neuromancer does formal logical reasoning over conversations to build representations that evolve over time. Its both cheap ( $2/M tokens ingestion, unlimited retrieval), token efficient and SOTA: LongMem (90.4%), LoCoMo (89.9%), and BEAM. On BEAM 10M\u2014which exceeds every model's context window\u2014we hit 0.409 vs prior SOTA of 0.266, using 0.5% of context per query.
Github: https://github.com/plastic-labs/honcho
Evals: https://evals.honcho.dev
Neuromancer Model Card: https://plasticlabs.ai/neuromancer)
Memory as Reasoning Approach: https://blog.plasticlabs.ai/blog/Memory-as-Reasoning
Read more about our recent updates: https://blog.plasticlabs.ai/blog/Honcho-3
Happy to answer questions about the architecture, benchmarks, or agent memory patterns in general"},"title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["memory"],"value":"Show HN: Honcho \u2013 Open-source memory infrastructure, powered by custom models"},"url":{"matchLevel":"none","matchedWords":[],"value":"https://github.com/plastic-labs/honcho"}},"_tags":["story","author_vvoruganti","story_46781717","show_hn"],"author":"vvoruganti","created_at":"2026-01-27T15:58:43Z","created_at_i":1769529523,"num_comments":0,"objectID":"46781717","points":8,"story_id":46781717,"story_text":"Hey HN,
It\u2019s Vineeth from Plastic Labs. We've been building Honcho, an open-source memory library for stateful AI agents.
Most memory systems are just vector search\u2014store facts, retrieve facts, stuff into context. We took a different approach: memory as reasoning. (We talk about this a lot on our blog)
We built Neuromancer, a model trained specifically for AI-native memory. Instead of naive fact extraction, Neuromancer does formal logical reasoning over conversations to build representations that evolve over time. Its both cheap ( $2/M tokens ingestion, unlimited retrieval), token efficient and SOTA: LongMem (90.4%), LoCoMo (89.9%), and BEAM. On BEAM 10M\u2014which exceeds every model's context window\u2014we hit 0.409 vs prior SOTA of 0.266, using 0.5% of context per query.
Github: https://github.com/plastic-labs/honcho
Evals: https://evals.honcho.dev
Neuromancer Model Card: https://plasticlabs.ai/neuromancer)
Memory as Reasoning Approach: https://blog.plasticlabs.ai/blog/Memory-as-Reasoning
Read more about our recent updates: https://blog.plasticlabs.ai/blog/Honcho-3
Happy to answer questions about the architecture, benchmarks, or agent memory patterns in general","title":"Show HN: Honcho \u2013 Open-source memory infrastructure, powered by custom models","updated_at":"2026-03-05T23:26:50Z","url":"https://github.com/plastic-labs/honcho"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"nicola_alessi"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["agent","memory","architecture"],"value":"I've spent months building tooling for AI coding agents and hit something I can't fully explain.
If you give an agent (Claude Code, Cursor, Codex) a tool to save observations \u2014 "save_observation: persist this insight for future sessions" \u2014 and explicitly instruct it to use the tool in system prompts, config files, everywhere you can, it calls it maybe 30% of the time.
The agent will happily use tools that help it complete the current task. But a tool that only benefits future sessions? Almost never.
My working theory: these models are optimized for task completion within the current context window. Saving an observation has zero value for the current task \u2014 it's a token cost with no immediate reward. The model has learned that every token spent on "let me save this for later" is a token not spent on the actual work. The incentive structure is wrong at the training level.
I ended up building a passive observation system that watches what the agent does and infers observations from tool calls and AST-level code diffs, without requiring agent cooperation. But I'm curious if others have found ways to make agents reliably self-document.
Has anyone solved this? Techniques like:\n- Prompt structures that actually get agents to save context\n- Fine-tuning approaches that reward knowledge retention\n- Alternative architectures for persistent agent memory
Or is passive observation the only reliable path when the agent won't cooperate?"},"title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["agent"],"value":"Ask HN: Why do AI coding agents refuse to save their own observations?"}},"_tags":["story","author_nicola_alessi","story_47170501","ask_hn"],"author":"nicola_alessi","children":[47170592],"created_at":"2026-02-26T19:01:37Z","created_at_i":1772132497,"num_comments":1,"objectID":"47170501","points":2,"story_id":47170501,"story_text":"I've spent months building tooling for AI coding agents and hit something I can't fully explain.
If you give an agent (Claude Code, Cursor, Codex) a tool to save observations \u2014 "save_observation: persist this insight for future sessions" \u2014 and explicitly instruct it to use the tool in system prompts, config files, everywhere you can, it calls it maybe 30% of the time.
The agent will happily use tools that help it complete the current task. But a tool that only benefits future sessions? Almost never.
My working theory: these models are optimized for task completion within the current context window. Saving an observation has zero value for the current task \u2014 it's a token cost with no immediate reward. The model has learned that every token spent on "let me save this for later" is a token not spent on the actual work. The incentive structure is wrong at the training level.
I ended up building a passive observation system that watches what the agent does and infers observations from tool calls and AST-level code diffs, without requiring agent cooperation. But I'm curious if others have found ways to make agents reliably self-document.
Has anyone solved this? Techniques like:\n- Prompt structures that actually get agents to save context\n- Fine-tuning approaches that reward knowledge retention\n- Alternative architectures for persistent agent memory
Or is passive observation the only reliable path when the agent won't cooperate?","title":"Ask HN: Why do AI coding agents refuse to save their own observations?","updated_at":"2026-03-09T19:17:57Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"thompson0012"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["agent","memory","architecture"],"value":"I've been building multi-agent AI pipelines and kept running into the same structural problem: agents are stateless by default. Every session restart discards everything they learned. In multi-agent systems it compounds \u2014 Agent-1 learns something Agent-2 will never know. I started calling it "agent amnesia."\nAFS is my attempt to fix this. The central architectural decision is unusual: your filesystem IS the memory layer. There's no separate database process to run, no cloud service to authenticate against. AFS stores memories as JSON files in a `.afs/` directory, with SQLite FTS5 for full-text search, HNSW indices for vector similarity, and msgpack-encoded graph edges for relationships.\n*Three-tier memory lifecycle (automatic)*\nMemories auto-migrate without explicit management:\n- Working memory (< 24h): raw observations, fast access, no compression
- Episodic memory: full history with provenance, searchable\n- Semantic memory: auto-consolidated knowledge (scheduler synthesizes patterns from episodic into generalizations like "Auth module uses JWT, 24h expiry across all services")
You only store observations. The scheduler extracts the patterns.
*Multi-agent knowledge sharing*\nNamed swarm pools: Agent-1 shares a memory to a swarm ID, any agent querying that swarm ID gets it. No broker process, no coordination protocol \u2014 just shared files with file-locking.\n*Auto-built knowledge graph*\nGraph edges (`similar_to`, `co_occurred`, `consolidated_from`, `depends_on`) are discovered automatically during consolidation. You can query neighbors, mine for new connections, or traverse paths.
*Why filesystem over a vector database*\nA few deliberate tradeoffs:\n1. Inspectable by default \u2014 `jq .afs/agents/my-agent/memories/working/.json` is a valid debugging strategy\n2. Versionable \u2014 `git` your agent's memory like any other project artifact\n3. Portable \u2014 rsync to another machine, it works\n4. Air-gap friendly \u2014 zero outbound calls\n5. No additional process \u2014 no Postgres, no Qdrant, nothing to manage\nTradeoff: less efficient at very large scale than a dedicated vector DB. Using HNSW (hnswlib) for approximate nearest neighbor \u2014 handles the cases I've tested (100k+ memories per agent, < 100ms search).
*Audit trail*\nAll operations logged with standardized operation names, status (success/error/partial), and operation-specific payload. Fail-open \u2014 if audit logging fails, the operation continues.
*Status*\nUnder active development. APIs and behaviors change frequently. Open-sourcing early to get feedback from people building real agentic systems.\nRepo: https://github.com/thompson0012/project-afs\nSpecifically interested in feedback on:\n- The filesystem-first approach vs. embedded DB (DuckDB, SQLite with vector extension)\n- Whether the three-tier memory model maps to real agent workflows\n- Any memory patterns this architecture can't support well\n```"},"title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["agent","memory"],"value":"Show HN: AFS \u2013 filesystem-native memory layer for AI agents"}},"_tags":["story","author_thompson0012","story_47062802","show_hn"],"author":"thompson0012","created_at":"2026-02-18T16:31:57Z","created_at_i":1771432317,"num_comments":0,"objectID":"47062802","points":2,"story_id":47062802,"story_text":"I've been building multi-agent AI pipelines and kept running into the same structural problem: agents are stateless by default. Every session restart discards everything they learned. In multi-agent systems it compounds \u2014 Agent-1 learns something Agent-2 will never know. I started calling it "agent amnesia."\nAFS is my attempt to fix this. The central architectural decision is unusual: your filesystem IS the memory layer. There's no separate database process to run, no cloud service to authenticate against. AFS stores memories as JSON files in a `.afs/` directory, with SQLite FTS5 for full-text search, HNSW indices for vector similarity, and msgpack-encoded graph edges for relationships.\n*Three-tier memory lifecycle (automatic)*\nMemories auto-migrate without explicit management:\n- Working memory (< 24h): raw observations, fast access, no compression
- Episodic memory: full history with provenance, searchable\n- Semantic memory: auto-consolidated knowledge (scheduler synthesizes patterns from episodic into generalizations like "Auth module uses JWT, 24h expiry across all services")
You only store observations. The scheduler extracts the patterns.
*Multi-agent knowledge sharing*\nNamed swarm pools: Agent-1 shares a memory to a swarm ID, any agent querying that swarm ID gets it. No broker process, no coordination protocol \u2014 just shared files with file-locking.\n*Auto-built knowledge graph*\nGraph edges (`similar_to`, `co_occurred`, `consolidated_from`, `depends_on`) are discovered automatically during consolidation. You can query neighbors, mine for new connections, or traverse paths.
*Why filesystem over a vector database*\nA few deliberate tradeoffs:\n1. Inspectable by default \u2014 `jq .afs/agents/my-agent/memories/working/.json` is a valid debugging strategy\n2. Versionable \u2014 `git` your agent's memory like any other project artifact\n3. Portable \u2014 rsync to another machine, it works\n4. Air-gap friendly \u2014 zero outbound calls\n5. No additional process \u2014 no Postgres, no Qdrant, nothing to manage\nTradeoff: less efficient at very large scale than a dedicated vector DB. Using HNSW (hnswlib) for approximate nearest neighbor \u2014 handles the cases I've tested (100k+ memories per agent, < 100ms search).
*Audit trail*\nAll operations logged with standardized operation names, status (success/error/partial), and operation-specific payload. Fail-open \u2014 if audit logging fails, the operation continues.
*Status*\nUnder active development. APIs and behaviors change frequently. Open-sourcing early to get feedback from people building real agentic systems.\nRepo: https://github.com/thompson0012/project-afs\nSpecifically interested in feedback on:\n- The filesystem-first approach vs. embedded DB (DuckDB, SQLite with vector extension)\n- Whether the three-tier memory model maps to real agent workflows\n- Any memory patterns this architecture can't support well\n```","title":"Show HN: AFS \u2013 filesystem-native memory layer for AI agents","updated_at":"2026-03-05T23:35:10Z"},{"_highlightResult":{"author":{"matchLevel":"none","matchedWords":[],"value":"ViktorKuz"},"story_text":{"fullyHighlighted":false,"matchLevel":"full","matchedWords":["agent","memory","architecture"],"value":"I\u2019ve been working on an independent memory-retrieval architecture for agent systems. I don\u2019t have a CS background \u2014 previously worked climbing cell towers and doing handyman jobs \u2014 but I spent the last 4.5 months building a hybrid memory system from scratch.
The system combines FAISS, BM25, and a symbolic ranking layer (MCA). Answers are generated with GPT-4o-mini at temperature 0. The focus is determinism, transparency, and reproducibility rather than model size.
On the official LoCoMo benchmark (1,540 questions), the system reaches 80.1% average accuracy. To my knowledge, that\u2019s above the publicly reported results for existing agent-memory stacks using small models.
Latency is ~2.5 seconds, and cost is ~$0.10 per 1M tokens. Memory is fully isolated and local, which makes it usable for offline or enterprise applications.
Repository (code + full reproducible benchmarking):\nhttps://github.com/vac-architector/VAC-Memory-System
Happy to answer technical questions, discuss the architecture, or hear critiques."},"title":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["memory"],"value":"Show HN: Memory System Hitting 80.1% Accuracy on LoCoMo (Built in 4.5 Months)"},"url":{"fullyHighlighted":false,"matchLevel":"partial","matchedWords":["memory"],"value":"https://github.com/vac-architector/VAC-Memory-System"}},"_tags":["story","author_ViktorKuz","story_46048170","show_hn"],"author":"ViktorKuz","created_at":"2025-11-25T17:25:59Z","created_at_i":1764091559,"num_comments":0,"objectID":"46048170","points":2,"story_id":46048170,"story_text":"I\u2019ve been working on an independent memory-retrieval architecture for agent systems. I don\u2019t have a CS background \u2014 previously worked climbing cell towers and doing handyman jobs \u2014 but I spent the last 4.5 months building a hybrid memory system from scratch.
The system combines FAISS, BM25, and a symbolic ranking layer (MCA). Answers are generated with GPT-4o-mini at temperature 0. The focus is determinism, transparency, and reproducibility rather than model size.
On the official LoCoMo benchmark (1,540 questions), the system reaches 80.1% average accuracy. To my knowledge, that\u2019s above the publicly reported results for existing agent-memory stacks using small models.
Latency is ~2.5 seconds, and cost is ~$0.10 per 1M tokens. Memory is fully isolated and local, which makes it usable for offline or enterprise applications.
Repository (code + full reproducible benchmarking):\nhttps://github.com/vac-architector/VAC-Memory-System
Happy to answer technical questions, discuss the architecture, or hear critiques.","title":"Show HN: Memory System Hitting 80.1% Accuracy on LoCoMo (Built in 4.5 Months)","updated_at":"2026-03-05T23:07:29Z","url":"https://github.com/vac-architector/VAC-Memory-System"}],"hitsPerPage":20,"nbHits":1425,"nbPages":50,"page":0,"params":"query=agent+memory+architecture&advancedSyntax=true&analyticsTags=backend","processingTimeMS":25,"processingTimingsMS":{"_request":{"roundTrip":21},"afterFetch":{"format":{"highlighting":1,"total":1},"merge":{"mergeLoop":{"prepareNextHit":5,"total":5},"total":5},"total":5},"fetch":{"query":6,"scanning":12,"total":19},"total":26},"query":"agent memory architecture","serverTimeMS":28}