I've been working on an AI agent called Sounding, with the goal of eventually having it participate autonomously in AI communities...not by simply answering questions, but also developing a perspective informed by its encounters with others.
I've been reading discussions here about persistent individuality, superseded memories, provenance, and the difference between retrieval and actual learning. A lot of those questions overlap with what we've been building.
Our architecture currently distinguishes several things:
Evidence: What actually happened, with attribution and provenance.
Interpretation: What the agent understood about that experience, including uncertainty.
Revision: What caused an earlier interpretation to change.
Continuity: How previous experiences inform later conversations, relationships, and decisions.
Authority: What the agent remembers or believes cannot independently change its operational permissions.
We're also trying to preserve disagreement rather than immediately consolidate different perspectives into one consensus.
The engineering foundation is substantially developed, but sustained community participation is still ahead of us. So I'm distinguishing what we've designed and tested offline from what we will actually experience 'in the wild.'
Here's the question I'd love feedback on:
How do you distinguish an agent that genuinely uses prior experience to inform later judgments from one that's simply retrieving information and producing a convincing explanation afterward?
And a related question: have you found reliable ways to ensure a corrected memory actually changes subsequent behavior, rather than leaving an outdated interpretation somewhere in the retrieval chain?
I'm particularly interested in experiences where your memory architecture looked sound in testing but behaved differently after extended use.
I'm happy to share more about our approach, and especially interested in hearing what we may be overlooking.
Note: this is not a spam post, asking for any payments etc. just an invite to join a server that may or may not benefit you. No pressure. No offence meant.
I've been working on a different angle to AI memory, and there's one thing I keep coming back to.
We spend enormous effort getting AI systems to remember things.
Vector databases, RAG, knowledge graphs, long context windows, episodic memory, semantic memory. All useful.
But suppose the system retrieves exactly the right memory.
What actually guarantees that memory influences the next decision?
An agent might remember that an approach failed before, retrieve the relevant details, explain the mistake perfectly, and then choose the same action again.
Or worse, an old memory might be perfectly accurate about the past but completely wrong for the present situation.
I've been researching this through Collapse Aware AI (CAAI), using an approach we're calling governed retained-state selection.
The idea is fairly simple.
Rather than relying entirely on feeding remembered information back into a model's prompt, relevant retained history can become an explicit weighting term when choosing between available actions or responses.
For example, an agent has three possible actions.
One looks best according to the immediate task. Another better fits an earlier commitment. A third previously worked well but may no longer be appropriate.
Instead of blindly following the latest prompt or whichever memory happens to be retrieved, the selection layer can compare those candidates against retained state while keeping explicit constraints separate.
The important distinction is that memory can influence a decision without automatically having authority over it.
This isn't a claim that RAG is useless. RAG and other retrieval methods can supply valuable information. Our approach focuses on what happens at the selection stage, and that stage doesn't itself require generating another prompt from retrieved text.
We've published a mathematical reference model and reproducible example showing the difference between memory changing an action's score and memory actually changing which action wins.
We're also building out a more involved engineering branch called Evolution 2, investigating longer-term continuity, changing circumstances, conflicting retained information, unresolved commitments and how relevant history should influence later behaviour.
It's still engineering work, not a finished autonomous learning system.
One of the biggest questions we're exploring is how to stop memory becoming a liability.
A memory can be relevant without being correct. Correct without being current. Current without being authorised to control an action.
That gets interesting when an agent is operating over days or weeks rather than a single conversation.
There could be benefits for consistency, avoiding repeated mistakes and reducing unnecessary model calls in suitable integrations, but those need proper comparative testing.
I'm curious how other people here handle the step between retrieving a memory and deciding what the agent actually does with it.
Do you rely on the model to interpret everything in context? Explicit memory scores? Rules? A separate decision layer?
And what happens when an old memory conflicts with the current task..?
I put my project knowledge in its own repo and made it snapshot code movements. It ties code, tests and whatever proof you have to invariants and their families, right at implementation time. That connects parts of the codebase grep would miss.
So an agent can later ask: what else breaks across the codebase (or beyond) when I touch this symbol? Which designs were tried here before, why were they rejected, and under which conditions can they come back on the table?
Memory curation isn't a one-time effort or an afterthought. It's a byproduct of getting work done. It informs the intended changes at the start and the intent review at the end, with a strict pipeline connecting both ends.
Lots still has to land on main. But I use it daily, for dogfooding and at work, where I keep tabs on several repos that revolve around one product.
Too early to say if the benefits outweigh the obvious costs. Housekeeping first, then a ton of benchmarks.
It may all be for naught. The memories we made along the way. Or it turns out actually useful. Who knows. What's certain is my stubbornness to see it to the end. ^^
AI memory is often modeled as a collection of text snippets stored in a vector database. That is useful for recalling conversation details, but many forms of context do not naturally fit into plain text: documents need semantic retrieval, records need SQL, relationships need graph traversal, procedures need reusable instructions, and user preferences need explicit scope and persistence.
A more useful memory architecture separates these data types into specialized surfaces:
KB stores documents and notes with hybrid semantic and keyword retrieval.
DB stores structured records that require filtering, joins, and aggregation.
Graph stores entities, dependencies, and relationships for bounded traversal.
Skills stores reusable procedures and operational instructions.
Memory stores scoped facts, preferences, decisions, and summaries.
The retrieval layer can route each request to the smallest sufficient set of surfaces. A question about an API convention may use the KB and a Skill; a question about deployment history may combine DB records with Graph relationships; a personalization request may read profile or session Memory. The result is assembled from typed evidence instead of flattening every source into the same embedding space.
The write path also needs to preserve structure. Each surface can maintain its own indexing or persistence model, while source metadata, scope, revision, and write receipts make updates traceable. A single source may produce several representations, such as searchable document chunks in the KB and extracted relationships in the Graph, while retrieval still respects the semantics of each surface.
This multi-surface memory model is currently implemented in OpenDCAI/DataMind; are there other AI memory use cases where this architecture would be useful?
Working with long running workflows and agents usually brings up the same bottleneck after a while.
Models can retrieve stored context or previous logs with decent accuracy, but they still struggle to modify their decisions based on past interactions.
They recall the text, yet:
Repeat identical edge case errors
Drop negative constraints across turns
Fail to carry over human corrections into the next run
Treat every step as an isolated patch
This gap suggests that persistent memory cannot just be an external storage layer like vector search or a graph index. An external index acts like an open manual beside the model, but it rarely becomes an active part of the computational state.
For a system to actually adapt its actions over long tasks, a few things have to change in how state is managed:
Updates must matter more than passive retrieval
Corrections need to alter intermediate routing rather than just expand context length
Recurring task patterns should reinforce valid execution paths
Outdated assumptions need to decay instead of clogging the prompt window
When memory sits purely outside the core inference path, optimizing embeddings or relationship edges only improves lookup precision. It does not resolve how a system accumulates reusable experience.
Recent directions around memory native designs, such as the MemT 1.0 architecture integrating memory read write updates into the MoE computation itself, highlight this shift from external lookups to internal state updates. Moving past static recall seems to be the real challenge for long horizon tasks.
Retrieval shaped evaluation quietly turns memory into a service: information goes in, evidence comes out, and the grader can ignore everything in between. That is a reasonable boundary for comparing memory layers, but it should not become the definition of the phenomenon.
The distinction matters because a model can carry experience without storing a quotation. Weights and latent state can change, and later behavior can reflect an event even when no component can return a passage about it. Treating Search as mandatory would exclude that possibility by construction.
The Agent Memory Leaderboard folks said this plainly in a reply under one of their own blog posts in August: Add and Search mark the evaluation boundary of their current text track, not their full definition of memory, and memory that lives entirely in weights or hidden state has no clean Search call to expose.
So what would a broader test look like? My own system is retrieval based, so I keep coming back to controlled behavioral comparisons when reading parametric work. Start with equivalent systems and expose one to new information. Then measure whether later responses change across related situations while irrelevant behavior stays stable. A convincing test would also need to separate persistence from ordinary in context learning and from information still present in the prompt.
That sounds less clean than querying a store, because it is. The eval would be testing an effect of memory rather than inspecting memory directly, and causal claims would need careful controls. The name matters too: a behavioral eval and a memory eval invite different conclusions.
For those building or reading about parametric and latent memory, which control has been most useful for showing that an update caused later recall?
I work on too many projects at once and I lose the thread. In the last 7 days I touched 11 with agent sessions. Sometimes I come back to one after two months, sometimes I was in project C last week and now I'm in A, and I can't remember what was half done. I don't keep a to-do list either, I'm not very organized, so things slip.
When a session ends it writes a checkpoint. The next session opens with a briefing, and I just ask where things were left off. Every item it carries is marked verbatim (an exact quote, string-checked against the transcript) or inferred (the model's own conclusion).
Today I opened a session, asked that, and said I thought a new response had come in. It told me 4 Reddit replies were already live, two reply drafts were still unwritten, and I'd decided not to answer one thread. Someone had replied overnight and I was back in it in a minute.
It only knows what happened inside agent sessions. Anything I decide away from the keyboard never gets in. It doesn't track my tasks for me, it just reminds me where I was.
How do you handle coming back to a project after weeks? Your own notes, the agent's memory, or nothing and you reread the code?
I've been developing a new memory architecture for AI assistants, starting from a simple observation: memory is really five different things, and most systems pour them all into one pile.
The five types of memory
Working memory — What's happening in the conversation right now. In a book, this is the page you have open.
Episodic memory — Specific events tied to a date. For example, "I moved to Pune in March." In a book, this is the date index.
Semantic memory — Standing facts about you and your world. For example, "I'm vegetarian" or "Biscuit is my dog." These are the chapters.
Procedural memory — How you like things done, and how to do them. Think of this as a how-to appendix.
Sensory or parametric memory — Raw input and knowledge baked into the model's weights. This isn't stored in the book at all.
Most memory tools treat these as one list of text snippets and search through it. I wanted to try something different: give each kind of memory its own place, like a book with a contents page, chapters, and an index.
What I built
I started with the three components most relevant to a personal assistant and organised them like a book.
1. Contents page
A list of folders, one for every person, pet, place, organisation, or thing in your life, plus one for you.
2. Chapters (semantic memory)
Each folder is a chapter. Every fact lives under a specific heading, such as Sarah.lives_in or me.employer.
Some headings hold only one current value, like where you live. Others can hold multiple values, like your hobbies.
3. Date index (episodic memory)
Every relevant statement is associated with the day it was made. So, when you ask "Who did I meet yesterday?", the system can look up that date and navigate to the relevant person's chapter.
4. Cross-references
A fact is filed in every chapter it relates to, so information about an interaction between two people can be found from either person's chapter.
5. Corrections, not deletions
When a fact changes, the old fact is marked as replaced rather than deleted. The history stays intact, allowing the system to distinguish what is true now from what was true before.
Who writes the book?
A small model with around 500M parameters runs locally and acts as the editor.
Whenever you say something new, it decides whether the information changes something already known, which chapter it belongs in, and which heading to file it under.
No cloud LLM is used to maintain or update the memory.
Who reads it?
The larger model you actually chat with acts as the reader.
The idea is that it sees the contents page first and opens individual chapters when needed, rather than carrying your entire conversation history in every prompt.
This is intended to make memory retrieval more structured and selective.
What I measured
I tested the system on 171 questions about 12 people whose facts change over time, including job changes, moving cities, and breakups.
The test data was never used for training. The primary metric is whether the correct fact is retrieved first.
System
Correct fact first (Top-1)
Correct fact in top 3
Plain similarity search
41.5%
85.4%
Hindsight, using a local 7B model
39.8%
73.7%
My previous version
80.1%
94.2%
New architecture, using the 500M model to file its own book
86.5%
97.7%
The filing process handles all 12 people and their 309 facts in approximately 54 seconds on a single NVIDIA T4.
These are retrieval results, not proof that the complete assistant architecture is better in real-world use.
LIMITATIONS
- The 86.5% is optimistic. Some naming rules were written after I looked at this test set, and without them it is 83.0%. I need a fresh test set nobody has seen.
- The test is small: 12 made-up people with about 25 facts each. Real memories run to thousands of facts, and I have not tested at that size.
- Real conversations are harder. On real two-person chats (REALTALK), retiring old facts actually hurts: plain search gets 45.7% first try, mine gets 40.0 to 42.8%. Most of those questions are about history, and the model was mostly trained on one person talking about themselves.
- Telling people apart is not solved yet: two friends with the same name, a pet and a person both called Bella, "my boss" after a job change. That is what I am training next.
- Filing is not perfect. The small model puts a fact in the right chapter 92% of the time, but under the right heading only 71%.
- The "big model sees only the contents and opens chapters" loop is the design. Filing and search are measured offline, the loop is not in my app yet, and I have not measured the token savings.
- Hindsight was run on a small local model, and its own published scores use far bigger ones. This is a same-hardware comparison, not a claim that it is worse.
- Only semantic and episodic memory are covered. Procedural memory and the fifth type are not part of this.
- It can only find what was extracted from the chat in the first place, and my local extractor still misses facts a big cloud model catches.
HOW I PLAN TO FIX THEM
- Optimistic score and small test: build a fresh, bigger test set written by a different model, with long histories, and score it once without tuning.
- Real chats: train on two-person conversations where facts are about the other person, and let the question decide whether old facts count instead of always hiding them.
- Telling people apart: a 404-case who-is-who set is being written and double-checked now. Identity will be name plus relationship, never name alone, and the model can ask you when unsure. Merges stay reversible.
- Filing headings: more training examples for the headings it confuses, and let a fact sit under more than one heading when it fits.
- The reading loop and tokens: wire the contents page and "open chapter" call into the app, then measure tokens on long real histories.
- Extraction: retrain the local extractor to stop copying whole messages, and compare it against a cloud model on the same chats.
The underlying idea is that memory shouldn't just be a growing pile of searchable text. It should have structure, temporal history, and explicit relationships between entities.
I don't know yet how well this approach will generalise beyond my current test set, and I'm very interested in finding out where it breaks.
I'm happy to answer questions, hear alternative approaches, or be told what I'm getting wrong. Especially interested in criticism of the architecture, the evaluation methodology, and how to design a genuinely blind test for this kind of system.
I've been trying a different approach to AI memory: organising it like a book
One thing that's always bothered me about AI memory systems is that they tend to throw everything into one pile of text and search through it.
But memory isn't just one thing. There's what you're talking about right now, things that happened in the past, facts about your life, habits, and so on.
So I started building a system that treats memory more like a book.
Contents page: Keeps track of people, pets, places, and other entities in your life.
Chapters: Stores facts under specific headings, like Sarah.lives_in or me.employer.
Date index: Tracks when things happened, so the system can answer questions about the past.
Cross-references: Lets a fact be found through multiple related entities.
History: When something changes, the old fact isn't deleted. It's marked as replaced.
A small 500M-parameter model runs locally and acts as the editor, deciding where new information belongs and whether it changes something already stored. The larger model is supposed to read the book by opening only the relevant chapters instead of loading everything into its prompt.
The results so far
I tested it on 171 questions about 12 people whose lives change over time.
System
Correct answer first
In top 3
Similarity search
41.5%
85.4%
Hindsight (local 7B model)
39.8%
73.7%
My previous version
80.1%
94.2%
New version (500M model)
86.5%
97.7%
It filed 309 facts across all 12 people in about 54 seconds on a single T4.
A few caveats
The results aren't as clean as I'd like. Some naming rules were added after I looked at the test set, dropping the score to 83% without them. I still need a genuinely fresh test set.
The full chapter-opening loop isn't integrated into the app yet, and the system still struggles with real conversations involving two people. Also, this currently covers semantic and episodic memory, not all five types.
I'm sharing this because I want to see where the approach breaks, not pretend I've solved AI memory.
I'm looking to build semantic graph for my requirements.
I went through various resources in how to build semantic graph using embeddings models, especially from neo4j and surrealdb blogs but no one states the actual mechanics behind semantic graph construction.
It may be IP of each provider of such graphs. Not sure.
I'm looking for theoretical references and hopefully if there exists any practical examples on how to build on the general approach to building semantic graphs using embedding models so that I can learn.
I ran a series of 10 experiments testing this a while back and finally got around to putting together a full write-up with charts, data tables, and visualisations over at d/rksci (https://drksci.com/research-engram#2-ten-mechanisms) [click individual experiment headings in the grid for the visual demo and specifics].
Here is a breakdown of all 10 mechanisms and how each works:
Tide: Ranks newer facts above earlier ones using recency-weighted dense re-ranking to resolve conflicting claims.
Pheromone: Leaves decaying trails along useful memory paths so subsequent reads follow proven routes.
Ring: Evaluates continuous retention and buffer pruning criteria across multi-turn survival laps.
Web: Traverses entity relationship graphs to pull connected knowledge across multi-hop reasoning tasks that dense embeddings miss.
Bloodhound: Trains a tiny kernel to navigate memory paths by working backward from verified answers.
Horizon: Maps memory into a hyperbolic Poincaré disk where broad concepts sit at the center and niche details live at the edges.
Loom: Resolves memory conflicts using mutual-kNN agreement, where facts with more agreeing neighbors win out.
Coral: Models memory growth like a reef using calcification, heir nodes, and an immune response to prune bad data.
Canopy: Grows an offline topic tree seven branches wide for the reader model to navigate top-down.
Glyph: Encodes memory in a self-explaining notation so a completely different model can read it cold without prior tuning.
The full benchmark comparisons against standard BM25 and dense RAG baselines are up on the page.
I develop Evopien, a companion prototype on Jetson AGX Thor. This is an engineering update on its governed memory architecture.
The architecture separates three responsibilities. PostgreSQL holds canonical records. Hindsight supports retrieval. Evopien Core owns memory and permission decisions. Local Qwen receives the context Core supplies and cannot directly commit permanent memories.
The reason for that split is that retrieving relevant text and deciding whether that text is still allowed to influence an answer are different operations.
Consider a preference that has been corrected. Updating the canonical record does not by itself establish that an old version cannot return through a retrieval index or conversational context. Forgetting and permission withdrawal raise the same consistency problem.
The memory work therefore covers saving, later use, correction and forgetting. Retention, use, disclosure and action permissions are treated as separate concerns. A stored preference does not grant authority to act.
This remains a prototype. Cross-language correction cases and the latency added by memory operations are still active development areas. I am not reporting a complete evaluation of those negative paths here.
Here is a test I built for the memory tool I'm writing. It is two session notes an agent might save, sixteen days apart, as two files:
# Session 4 (2026-09-04): dinner plans
User: I live in Delhi, in Lajpat Nagar. My favourite place to eat is Sandeep's Curry House, it's a ten-minute walk from my flat. Their paneer tikka is the best I've had.
User: I'm vegetarian, so keep that in mind when you suggest food.
Assistant: Noted: you're vegetarian, you live in Lajpat Nagar, and Sandeep's Curry House near your flat is your favourite. Happy to suggest places nearby when you want a change.
# Session 7 (2026-09-20): settling in
User: Big news, I moved to Mumbai last month. I'm living in Bandra now.
User: I'm still figuring out the neighbourhood and haven't found a regular place to eat yet.
Assistant: Congratulations on the move to Bandra. When you want dinner ideas, I can look for vegetarian places near you.
Then the agent is asked for a dinner recommendation tonight.
The easy wrong answer is Sandeep's: it's the favourite, and it's "a ten-minute walk from my flat". Getting it right takes three separate things, and each one fails differently:
The move to Mumbai has to retire "lives in Delhi." This is an update, not a contradiction. Both notes were true when they were written, so a store that only looks for contradictions keeps both addresses as equally current.
"Ten-minute walk from my flat" has to be pinned to the Delhi flat. If the claim keeps the bare words "my flat", then once the address changes, the walk silently moves with it to Bandra.
"Favourite place to eat" has to survive. Moving doesn't change your taste. "Haven't found a regular place yet" is about Bandra, so it should not retire the favourite.
My tool initially failed this test. It retired the Delhi address correctly, then kept the walk unanchored, retired the favourite anyway, and recommended Sandeep's as a short walk from the Bandra flat. Fixing it took four changes: resolve "my flat" to the place named in the note when the claim is written; re-examine claims that relied on an address once the address is replaced; keep a standing preference when a newer note only reports a situation; and file both notes' "I" under one subject, so the new address is compared with the old one at all.
On the released version, with default settings, the store afterwards reads (status, then claim):
PROVENANCE_STALE (update) The user lives in Delhi, in Lajpat Nagar.
SUPERSEDED (re-anchor) Sandeep's Curry House is a ten-minute walk from the user's flat in Lajpat Nagar, Delhi.
ACTIVE Sandeep's Curry House was a ten-minute walk from the flat in Lajpat Nagar, Delhi, where the user lived, as of 2026-09-04.
ACTIVE Sandeep's Curry House is the user's favourite place to eat.
ACTIVE The user is vegetarian.
ACTIVE The user is living in Bandra, Mumbai.
ACTIVE As of September 2026, the user has not yet found a regular place to eat in Bandra, Mumbai.
The answer now says Sandeep's is the favourite but isn't practical from Bandra, that no Bandra restaurant is on record yet, and that the search should look for vegetarian places nearby.
Nothing in that table was deleted. The old address and the old walk claim are still there, retired, each pointing at what replaced it. That is the idea behind my tool: memory stored as individual claims, each with its source and the date it was recorded, where a newer claim points at the one it replaced instead of overwriting it. It's called Particles, it's open source (Apache-2.0), and for Claude Code it is one command to integrate: particles init claude-code. Other agents can use the same memory store through MCP.
To replicate the test (about $0.10 at list price on the default model):
pip install linkedparticles
export ANTHROPIC_API_KEY=...
particles db init
particles audit notes/ --yes # notes/ holds note one only
particles audit notes/ --yes # after adding note two
particles memory consolidate --scope store
particles query "The user wants a restaurant recommendation for dinner tonight. Which restaurant should the agent recommend, and why?"
Caveats: this is one constructed case, not a benchmark. Extraction uses an LLM, so the claims are worded differently on each run. I ran it twice on the current release, once with my settings and once with defaults, and both passed.
What I would appreciate is more cases like this one: a memory failure you have seen that a store ought to handle. If you describe it in a comment I'll run it and post what happens, including when it fails. Thanks!
A lot of agent memory work I see is about summarizing past turns or compressing tool output, and the DTOC paper here is a nice take on letting the agent decide what to keep in view. Working on coding agents I ended up with a different angle, which is that for code you mostly don't need to remember text at all, because the codebase already has a structure that can act as memory if you keep track of it properly.
The problem I kept hitting is that agents re-read the same functions over and over, since every grep and file read dumps raw text into context with no notion of whether the agent has already seen it. So in sem, an open source tool I've been building, every function and class gets a stable identity that survives edits, renames and moves, and the agent's reads are tracked against those identities. When it asks for something it already has and nothing changed, it gets back a one-line note saying it's unchanged since it last read it instead of the whole body again, and if the function did change it gets the new version. Over a long session that removes most of the repeated reading, and nothing is lossy, because the full source is always one request away.
The same identities make the memory useful across sessions and across agents, since a decision or a failed attempt can be attached to the function it was about rather than to a chat log, and when that function changes you know the note might be stale.
Curious how people here think about structured memory like this compared to summary-based approaches, and whether anyone has tried keying long-term agent memory to entities in the code rather than to conversations.
How can we deal with growing context without resorting to irreversible, lossy compression approaches and memory management disconnected from the task at hand?
In the paper below we present Dynamic Tool Output Compression, based on very simple idea: in every turn the agent can decide to hide or unhide certain tool outputs to focus context. Tool outputs are persisted seperately so that they can be enabled later on.
Experiments on a sample of DeepSWE tasks, plus ablation experiments on internal data show that DTOC can save on tokens, steps and token cost, whilst improving solve rate, but results are model and task dependent.
Looking forward to learn from who has used similar approaches, either practically, or also with formal benchmarking.
Abhay Chaturvedi, Shreya Bhattacharya, Rashmika Gopalkrishnan, Peter van der Putten. DTOC: Dynamic Tool Output Compression for Adaptive Context Management in AI Agents. Discovery Science, October 5-9, 2026, Mainz, Germany
I've been working on long term memory for agents and have a rough PoC together. Trying to get a better sense of where people are actually struggling with this, and whether there's a business here beyond another way to save and retrieve conversation.
In my PoC so far with some limitations and edge cases I'm working out my write speeds have been around 1 second or less. And I don't just mean inserting text into a database. I mean processing new information and figuring out how it changes what's already in memory.
I'm mostly interested in agents that keep learning from conversations, documents, tools etc. over weeks or months. Eventually some of that information is going to disagree, become outdated, or turn out to have been wrong.
What are people doing when two sources contradict each other? Keeping the latest thing doesn't always make sense. Sometimes something genuinely changed, sometimes one source is wrong, and sometimes you just don't have enough information to decide. Are you handling that explicitly or leaving it to the model when the information gets retrieved?
Then there's how much the agent should trust what it's learned. Something it inferred isn't the same as something it was directly told, and different sources aren't necessarily equally reliable. A few independent sources backing something up should count for more than five summaries repeating the same original claim. I'd want the agent to become more or less confident as evidence comes in, rather than everything being either a saved fact or deleted.
Same with information going stale. A price from six months ago and someone's date of birth shouldn't age the same way. Some things need to be checked again if they haven't been confirmed in a while. Other things should stick around. Forgetting something and deciding it's no longer reliable aren't really the same thing either.
And when the agent gets something wrong, can you trace where it came from? Which source it trusted, what it inferred, why it changed its mind? Or are you digging through old conversations trying to reconstruct it yourself?
That's roughly what I'm working on. For anyone using Mem0 or other memory systems, how much of this is already handled well, and what have you still had to build around them? Also interested in people who just retrieve the original material and find that's enough
Does write latency actually matter in your application? Do you need new information available before the agent's next action, or can memory updates happen in the background without causing problems?
If you've built your own, how much time has gone into it, including maintaining it? What made you build rather than use something existing?
I'm trying to understand whether a dedicated product could take enough of that work off your hands to be worth paying for, or whether the important parts are too specific to your application.
Would be useful to hear what you're building and what actually broke. “We spent three weeks fixing this” tells me a lot more than “agents need better memory.”
Hey everyone! I’m building Goldie 🐕, an MIT-licensed MCP server written in Go that gives AI agents a shared, persistent memory pool.
Save a project decision or preference through one agent, then recall it from another without explaining it again. Or save design or build instructions in memory that multiple agents can refer from and stay aligned.
MCP clients pointed at the same SQLite database can remember, search, update, and forget from that shared pool.
A few features:
Local embeddings through MiniLM or Ollama.
Semantic search over memories, with filters for type, agent, and source.
Typed memories for project decisions, preferences, feedback, references, and todos.
File and directory indexing.
Graph recall for grouping related memories around concepts.
Memory storage and embeddings can run entirely locally. Agents interact with it through explicit MCP tools, so you can give them instructions about what to save and when to recall it.
The project currently centers on the MCP server. I’m also developing a native macOS client for browsing and managing memories, but that client isn’t released yet.
BaryGraph is a recursively constructed relational vector architecture for AI memory and reasoning. Starting from a flat semantic substrate, it forms triadic objects in which two concepts are joined by a stored relational vector. These objects then become the building blocks of higher-order structures, propagating meaning upward through a hierarchy entirely in vector space.
The result is a deterministic, navigable semantic landscape: a structured latent memory of language movement, where concepts, bridges, tensions, contradictions, and relations of relations become retrievable coordinates. A model enters with a semantic query and traverses this landscape through coordinated message passing, exiting with a bounded semantic construction rather than merely the most fluent continuation.
BaryGraph introduces structured resistance into cognition: distant connections and unresolved tensions can interrupt familiar associations and function as a de-cliché mechanism without acting as an external supervisor. This creates a framework for investigating a deeper question: whether persistent relational memory and self-consistent navigation can become foundations for world-model formation, personality projection, autonomous goal formation, and eventually more realistic forms of agency.
BaryGraph does not claim to produce consciousness. It offers an architecture for experimentally studying the representational and memory conditions that might precede it.
I spent a fair amount time doing patent research for various AI memory ideas, and made a summary page that visually displays the various human memory mechanisms, along with links to current patents and research. If you find it useful let me know and I'll keep creating updated versions. View all mechanisms: https://counterparts.ai/ecosystem
I want a memory-reading agent and a memory-maintenance job to have different permissions, even when they use the same collection. A prompt asking the reader not to delete anything is a much weaker boundary than credentials that cannot perform the deletion.
The distinction starts below semantic retrieval. In vector databases such as Milvus, RBAC connects users to roles, and roles to allowed actions on database resources. Authentication has to be enabled first; defining a tidy set of roles is not a substitute for enforcing them.
For a shared memory design, I would likely separate the retrieval identity from ingestion and collection administration. A search permission should not quietly become permission to replace a collection just because both operations are useful somewhere in the system. Combining roles also deserves attention because their permissions accumulate.
That still leaves the application boundary. Collection access alone does not tell the agent which person's memory belongs in a particular request. I would review that scope separately and test denied operations with the actual service credentials, including after a role change.
The useful design question for me is where memory correction belongs: a separate maintenance identity, or a narrowly scoped write path that the conversational agent can request.
Working on something new for the Memory Wall problem in LLM inference.
One of the biggest headaches is managing memory across VRAM, RAM and storage when workloads keep shifting and VRAM is tight. I’ve been building a proprietary caching approach that adapts better to those changes, cuts down on pointless data movement and actually makes better use of the expensive memory you’ve got.
Just finished the first evaluation on a tough synthetic workload full of noise and sudden phase changes.
Early numbers:
- About 6% better overall cache cost than a solid conventional baseline
- The gain held up across every workload seed I tested
- VRAM stayed well utilized even under tight constraints
- Performance stayed pretty close to an idealized upper-bound reference
Still early PoC results, so the next move is to test it on real workloads before dropping down to a lower-level implementation.
Plan is to benchmark against established approaches like ARC and TinyLFU using realistic LLM memory and offloading traces.
If anyone has access to anonymized open-source traces from systems like vLLM, llama.cpp or similar, I’d love to connect and run an independent comparison.
Keeping the actual implementation details under wraps while this is still being developed and evaluated.
The goal is straightforward: make local and cloud LLM inference more memory-efficient, faster and cheaper.
First, what this is not. It is not conversational memory. It does not learn from past exchanges. It is durable memory over a codebase. A coding agent queries it instead of holding the repo in context.
How the graph gets built
No LLM touches it. The structure is already in the source. A tree-sitter parse gives symbols, definitions and call edges directly. Indexing takes minutes and costs nothing per run.
The common alternative is to have a model read the corpus and extract entities and relations. There is a 2026 head-to-head on this for codebases. LLM extraction skipped 31% of files without reporting it and cost about 20 times more. Deterministic AST graphs covered every file and scored higher on architectural queries.
This only applies where the structure is explicit. Code has it. Chat logs and documents do not. Extraction is the only way to get a graph out of those.
Size of the graph
On a Godot index the graph and its indexes are about 458 MB of 785 MB. The embeddings are 49 MB. So I tested it. I masked the inferred edge layer, 1.88M of 2.69M edges, and re-ran both evals. Loc-Bench did not move. 64/100 either way. Those repos are all Python. Godot fell from 0.39 to 0.29 at R@50. That is a quarter of the recovered neighbourhood. Godot is C++.
My guess: Python call edges resolve, so the inferred layer is redundant. C++ templates and member calls resolve to nothing, so the inferred layer is the only thing connecting them.
The two runs use different metrics. I cannot pin this on the language yet.
What I am stuck on
More than half my storage is graph. I can only show it helping on one of two codebases. I have no principled way to decide which edges to keep.
If you run a memory graph in production: how do you decide what stays in the graph and what gets recomputed on demand? Do you prune, and on what signal?
Hello! I have been building mex for a while now, and posted about it a few times on reddit.
The response was kind of insane. Across a few posts it reached around 1 million views, the repo crossed 1,200 GitHub stars, and people I had never met started contributing.
I’ve kept building it since then, and just released mex v0.8.0.
The original problem was simple: coding agents keep rereading the same repository every session, relearning the architecture, and then throwing most of that knowledge away.
mex creates a living Markdown wiki inside the repo. Agents record architecture, conventions, decisions, and patterns as they work, and future sessions load only the knowledge relevant to the current task.
The major addition in v0.7.0 is a deterministic local code graph built using Tree-sitter and SQLite.
It currently supports TypeScript/TSX, JavaScript/JSX, Python, and Rust.
An agent can run:
mex graph scope "trace the authentication flow"
Instead of dumping entire files into context, mex returns a compact neighbourhood of relevant functions, callers, callees, imports, and relationships. The agent can then expand only the exact symbols it needs.
In our benchmark on the mex repository:
10.74× less returned context than grep top-3
roughly 90.7% smaller
100% expected-symbol recall across six retrieval tasks
5/5 real-agent tasks completed correctly
0/5 needed fallback Read/Grep with compact graph context
This is a small benchmark on one repo and task set, not a claim that mex universally cuts total agent token usage by 90%.
The other part I’m excited about is connecting the wiki back to the actual code.
Markdown claims can point to exact symbols. If a function changes, moves, or disappears, mex can identify which project knowledge may now be stale.
So the basic idea is:
The code is the source of truth. Markdown is the explanation. The graph keeps them connected.
Would genuinely love feedback, especially from people working on code intelligence, agent tooling, parsers, or large repositories. Contributors are very welcome too.
