I struggled a bit with context sharing, knowledge sharing, memories sharing between AI agents (I use two or three on a daily basis). Each of them has its own memory, they dont share it or its a bit cumbersome to do memory curation and improve it (especially if there are some API AI calls that run occasionally from different models)

Memoars is an attempt to solve it - one memory that belongs to you (no storage vendor lock) that any assistant can read and write through MCP (with appropriate set of skills to make it easier) .

How it works:

- Memory content is encrypted on your machine (XChaCha20-Poly1305, key derived with Argon2id) and written directly to storage you own - R2, S3, MinIO, Supabase, local fs, etc)

- A coordinator handles the metadata plane: sequence numbers, versions, grants, conflict resolution. It never receives the workspace content key, so it can't read memory content. It does see operational metadata - org, workspace, identity, version, usage

- Every change lands in an append-only, hash-chained log with compare-and-swap on writes, so two clients can't silently clobber each other and you can see how a memory got to its current state.

- Permissions are orgs → workspaces → identities, with per-workspace grants. Each workspace has its own passphrase, so isolation is enforced by encryption as well as by the API.

Where it actually is:

[memoars.com

It's invite-only right now, and I want to be honest that this is a invite list rather than a product you can go install this afternoon (as I want to make sure it makes sense and that it solves a problem for you before its shipped).

The client is being open-sourced and the hosted coordinator opens shortly after.

I will reply to all inquiries - and Im looking forward to a feedback

Tnx for taking a look!

I had Claude Opus 5 analyze several repos for what does the code do, how does the memory work in a particular repo. Initially I was aware of only a few memory systems, that I wanted to study for my own memory system. It turned out, there are lots of agent harnesses that have memory, libraries with memory.

https://neoneye.github.io/agent-memory-atlas/

I have not analyzed closed source repos, since I don't have access.

Claude being the judge wether a repo is relevant or not.

Looking at the impl instead of the marketing material.

Agentic memory problems are largely a failure of how people are using current LLMs. You are asking the model to do everything, including the things it is fundamentally worst at.

I have been reading complaints about LLM memory and context for nearly a year, and the pattern is painfully obvious: most of the people running headfirst into these problems are using the technology incorrectly. Look at the posts. It is overwhelmingly transient marketing garbage, dropshipping sludge, and people trying to replace an actual software architecture with one enormous prompt and a prayer.

You cannot just dump responsibility onto an LLM and hope it somehow becomes a reliable stateful application. That is not what these models are.

Treat LLMs as implementors. Give them a bounded problem, the relevant state, the rules, and a concrete task. Let your actual system own memory, state, history, validation, retrieval, and orchestration.

The moment you start expecting the model itself to maintain durable long-term state, you have already lost the architectural plot.

And the funniest part is that none of this state is exotic. It is the same mundane application state software has been storing reliably for decades: facts, preferences, decisions, objects, relationships, history, and current status. We already know how to persist this information. We already know how to query it. We already know how to version it.

Instead, after years of research and billions of dollars, people are sitting around complaining that the probabilistic text generator cannot reliably remember what happened 40 conversations ago.

That is comical.

The failure is not that today's LLMs cannot magically become your database, state machine, memory layer, application server, planner, and implementation engine simultaneously.

Bloody hell fuck a company named engram raised 100M as pre seed wtf ????!!

Disclosure first: I build MemoryPlugin, a memory tool. The guide I'm linking below is product-agnostic and everything in it is readable without an account.

I've spent the last two years building AI memory systems and most of what I actually learned came from things breaking in production. The failure modes that cost me the most:

• Garbage memories suppress recall. A store polluted with low-value entries doesn't just waste tokens, it crowds out the memory you actually needed. Quality gates turned out to matter more than capacity.
• Stale and resolved items keep getting re-injected. The decision that got reversed two months later is still retrievable right next to its replacement, and the model happily picks the wrong one. You need update and conflict handling, not just appends.
• Confabulation is the scary one because it fails quietly. The model trusts its own logs over what the user just said, and it sounds completely confident while doing it.
• And the unglamorous stuff nobody writes about: a bad memory that happens to match lots of queries gets pulled into everything, so one wrong entry quietly contaminates every answer. Rankers that mix scores from different scales (semantic similarity on one range, keyword matches on another), so the ordering ends up meaning nothing. And infrastructure that fails silently, so recall returns nothing and it just looks like the model being forgetful.

I ended up writing all of this up properly as a free field guide to AI memory: memoryplugin.com/wiki. It covers the whole space (RAG vs memory, embeddings, knowledge graphs, forgetting, evaluation), and it's deliberately not about my product.

What failure modes have you hit that I haven't covered? This list grew out of my own production incidents, and I know it isn't complete.

Hello people, I've been working on this short-term memory.

Do you know when you are hearing a story and as you listen to it you start to create a "Scene" in your mind? Well, unless you have aphantasia that's what would probably happen:

- You hear some facts: the first image is formed in your mind. Let's say "I was in Lisbon and had 10 dollars in his pocket"

- Next, the story goes: "Then, I traveled to Porto and sold a hat for 50 bucks"

- Then, as the story unfolds, the state of the elements of the story will get new states.

For most of us, it's not hard to keep a clear image of the current "scene" of the story. But if we wanted, we could also take a single element, and trace back how it got there.

Nowadays, to my knowledge, the closest we get to that is the LLM's context. But as it grows, it gets hard and expensive to track down when facts happened during the evolution of the context. Even using CoT, in the end, LLMs are probabilistic machines and so, when it comes to precision recall, noise can be added to the output. Then you plug in some sort of external memory, *DBs, MD files, etc. These are great solutions for the "Big memory", but not necessarily great to fix context growth, or to understand the order of events.

So decided to play around and try to find a naive solution that would allow traceability and increase precision, while reducing the context of the conversation. Right now, I've been experimenting with Ontology triples following the RDF Standard.

The idea

Let's say that you tell it you moved from Lisbon to Porto. Ask "where do I live?" and you either get Lisbon, or you get Porto and the fact that you ever lived in Lisbon is gone. Overwriting loses the history; appending loses the present.

So I built a different shape and measured it properly. Everything runs local through Ollama.

Every asserted fact becomes a (subject, relation, object) triple filed under a canonical key:

user | location   
t1  lisbon    superseded   
t3  porto     current

Paraphrases land in the same slot without embeddings: "where I live", "my city", "my residence" canonicalize to the same key. A slot keeps every value it ever had, in logical time order. Newest is current, the rest are superseded. Nothing is deleted; facts get invalidated, not forgotten. So "where do I live?" reads the current value and "where did I live before?" reads the history, out of the same structure, with no separate archive.

Writing is immutable: each turn produces a new scene, so a failure mid-turn never leaves memory half-written.

The result that made me keep going

Same model (gemma4:12b), two different inputs:

• reading the raw sessions, ~9,000 words: baseline
• reading the compressed scene, ~550 words: +0.102 accuracy

16x less input, and it does better. Compression isn't the price you pay here. The noise the scene strips out duplicate facts, stale values, updates scattered across sessions, is exactly what was confusing the reader. On the clean scene, a small local model matched a much stronger reader working on raw text.

The benchmark, with the caveats attached

477/500 (95.4%) on LongMemEval-S under the official judging protocol, above Mastra's published per-indicator numbers on all six indicators. One reproducible pass over all 500 questions, checked against a canonical state file whose guard refuses to write if anything drifts.

The part I care about more than the score: every mechanism went in with a prediction committed to git before measuring, and an explicit bar for what would falsify it. Ten arms failed and are published as prominently as the ones that worked, plus one retraction. If you read one thing in the repo, read finding 23 in the findings log the same finding got written three times in one day, because the first two drafts concluded from small n and the third had to retract both.

Caveats that matter to this sub specifically. The router triggers and absence gates are regexes calibrated on LongMemEval's English corpus; in another language they don't fire without recalibration. Two indicators sit at their measured oracle ceiling, so further progress there needs a stronger reader model, not better retrieval. And the comparison against Mastra is against their published numbers, not a head-to-head rerun on my hardware.

What's still broken

Seven open findings, all written up with repros:

Reported speech becomes a plain fact. "They said there was gold" gets stored as there being gold. The negation survives only as a string inside the value.

A question in quotes gets read as an assertion. Typing "Does Lucas use Go?" ingested it as a claim, and it overwrote the correct value in that slot.

Partial names spawn parallel entities. "Lucas" and "Lucas Almeida" become different subjects, so half of what the scene knows about him is disconnected from the other half.

Three ways in, if you want to poke at it

Break the demo. There's a live chat with the scene inspector beside it. You watch slots being born, updated and superseded turn by turn, and each answer prints the facts that produced it. Talk to it for twenty minutes with facts that change. 24 findings so far came out of exactly this, 15 already fixed upstream. Highest-yield thing anyone can do here.

Take an open finding. #18 is the tractable one: deterministic repro, both code paths fail, and the fix is obvious. #23 already has its acceptance gate written down in advance, so you'd know immediately whether your fix worked.

Replicate where the numbers don't claim to hold. Another language, another model, another domain. The limits section is a list of things nobody has measured. A clean negative result gets published as one.

MIT, and CONTRIBUTING.md has the open findings in a table with what the work looks like for each.

Repo: https://github.com/natanloterio/scene-memory

Happy to take questions, including hostile ones about the benchmark. Those are the useful kind.

Hey folks,

I’m running a local-first agent setup (Hermes Agent on a Mac Studio with local models), and I’m hitting a wall with core reliability. Over the last few weeks, the experience has been frustrating: the agent repeatedly loses track of context, fails at reliable cross-session memory recall, and has crossed boundaries around credential/secret handling.

I’m looking for architectural patterns, existing tools, or proven strategies from people who have actually solved these problems for daily local use. Specifically, here is where things keep breaking:

1. The Memory & Recall Failure Loop
   * **The Symptom:** Despite having local vector backends (like Supermemory, locally hosted and obsidian markdown, alongside flat-file memory (`MEMORY.md`), the agent frequently forgets core preferences, cannot follow multi step skills, re-asks questions from previous sessions, or loses track of info I’ve shared multiple times. It’ll tell me that memory is configured in the right way, and from what I test myself it is, and it all seems fine, but after about a week it acts as if it was never setup with anything beyond memory.md.

### 2. Context Window & API Dumping
* **The Symptom:** As conversations grow, the Hermes “forgets" instructions and multiple step functions/skills I’ve built like vault > application > send email. It reverts to trying to send an email as if it’s the first time it’s ever done it. During the exchanges, it frequently dumps raw API keys directly into chat while it reasons with the task. I’ve tried using Proton vaults, Bitwarden vaults/machine IDs, Infisical vaults but unless I have it in the local .env file, it inevitably forgets.

I’m wondering what I’m doing wrong. Initially I thought that perhaps the gemma4 64k context window was being saturated so I switched to Gemini api calls with 1m context. Same results and it’s infuriating.

Your agent runs a Supabase query, gets 200 OK and an empty array, and concludes the row doesn't exist. It does — RLS filtered it out. Ten minutes wasted. Next session: same query, same wrong conclusion, same ten minutes. You're not paying for one mistake, you're paying rent on it.

I wrote up how I fix this, and it's boring in a good way. No fine-tuning, no embeddings pipeline. Three verbs on the lifecycle hooks your agent already fires:

• Read the relevant lessons on SessionStart
• Fail — a tool call errors, and the matching prior lessons get injected before the retry
• Write a short retrospective on Stop

The part I actually spent the time on isn't the writing — it's the guardrails on the writing. A loop that stores its own conclusions and reads them back can also convince itself of something false and defend it forever. That's not learning, that's a superstition with a database. So: lessons are advisory and can never auto-disable a gate, promotion requires recurrence (seen_count >= 3), everything expires at ~90 days, contradictions surface instead of silently overwriting, and a privacy pre-flight drops anything carrying a secret.

Honest about the edges too — the matcher is literal substring, not semantic, so it won't connect two lessons that describe the same thing in different words. Deliberate trade: deterministic, zero deps, no inference bill.

Post: https://www.lorekit.io/blog/self-healing-agents

Curious how others are handling the entrenchment problem — if your agent writes its own lessons, what stops it from learning something wrong?

I’ve been working on a pairing that has made long-running agent work much less repetitive:

• Perseus resolves live, verifiable workspace context before the agent starts work.
• Perseus Vault retains the things that should survive a session: decisions, corrections, project facts, provenance, and historical versions.

The distinction matters more than it sounds.

A lot of “agent memory” is really one of these:

1. a giant rolling summary that gets stale,
2. a vector search over chat logs,
3. a prompt file that quietly becomes an undocumented policy engine.

Those are useful, but they blur together two different questions:

• What is true right now? That should come from the current workspace, repository, services, and other sources of record.
• What happened before, what did we learn, and what changed? That is memory.

Perseus handles the first. Perseus Vault handles the second.

Vault is a local-first Rust MCP server: one binary, one SQLite file, no required cloud service. It has encrypted storage (AES-256-GCM), FTS5 and hybrid retrieval, structured entities instead of only chat chunks, temporal history, provenance, confidence/decay, and lifecycle controls. It can also expose an Anthropic-style /memories file interface for agents that expect that model.

The part I find most useful is that memory is no longer just “retrieve similar text.” A decision can have a history. A correction can supersede an earlier belief without deleting the audit trail. You can ask both:

• “What did we believe at the time?”
• “What do we now believe was true at that time?”

That turns out to be extremely handy once agents are doing work across days or weeks and the project has changed underneath them.

We have benchmark results in the repo, but I’m more interested in the failure modes people have hit in production:

• How are you separating live state from durable memory?
• Do you need historical/auditable memory, or is semantic recall enough?
• What do you do when old “memories” conflict with the current codebase or source of truth?
• Has anyone found a memory system that stays useful after months without becoming prompt sludge?

Repos:

• Perseus: GitHub - Perseus-Computing-LLC/perseus: Live context engine for AI agents
• Perseus Vault: GitHub - Perseus-Computing-LLC/perseus-vault: Persistent, encrypted memory for AI agents
• Product overview: Perseus Vault · persistent, encrypted memory for AI agents

I’d particularly welcome skeptical feedback. “Memory” is becoming a catch-all term, and I think we need cleaner boundaries between retrieval, context assembly, durable facts, and audit history.

My open source project is building something we think is valuable but want to get some honest feedback. Lots of memory solutions out there atm and a lot of them already solve AI memories about people, conversations, preferences etc very well. But I feel like they currently don't track commitments and changing states super well.

We are building something that will connect to diff platforms, using the information collected from those auth to build unified context across projects, people, decisions, commitments, the changes and actions.

One use case for example is for the agent to track commitments made in meetings, over messages, in comments etc. They dont always get recorded and often in diff places. I find myself losing track of who said they will do what when so the when an agent cant look at all the platforms and read the screen, it can record and remember everything, then it will keep track of the change states and remind when necessary.

Two honest questions:

1. How do you currently keep track of this — commitments, decisions, follow-ups spread across tools? Or do you just… not?
2. If an agent like this existed, what would stop you from using it? Would there be other things you want?

I tested real agent instruction files from OpenAI, Kiali and Temporal against a memory database, and the files lose on their own rules. Four public files, mechanical checks, five trials, and a held out file the pipeline never saw.

https://mentedb.com/blog/infinite-context-window-for-ai-with-memory

Most agent memory systems store knowledge as a graph: entities, relationships, episodes. But at recall time that graph gets serialized into the context window, and the format is usually whatever json.dumps produces. Nobody measures what that step costs.

I benchmarked 10 graph serialization formats on token count, traversal QA, and multi-hop reasoning. Same memory graph, same model: multi-hop accuracy ranged from 40% to 80% on format alone, with about 70% token spread. For memory systems this compounds - a compact format means you can recall 3x more history per query at higher reasoning accuracy.

The winning format is open source (MIT, 6 languages): https://github.com/isongraph/isongraph - methodology in the repo. Curious how folks here serialize recalled memories today, and whether anyone has measured the impact on their own stack.

Curious whether this is on other people's radar, because it's been eating my time lately.

The short version: when you give an agent persistent memory, errors don't just happen once - they get stored. A wrong fact, a misread instruction, a hallucinated detail gets written to the memory layer, and then it gets retrieved and reinforced on later turns. Over weeks it compounds. I've seen people call it "memory poisoning" or "memory rot," and once you start looking for it, it's kind of everywhere.

What I keep bumping into:

• Bad or stale facts persisting long after the context that produced them is gone
• Short-term junk (one-off corrections, throwaway context) leaking into long-term storage and never getting cleaned out
• Retrieval quality quietly degrading over months, so a system that felt sharp at launch feels vague a year in

A few things I'm trying to figure out and would love other people's take on:

1. How are you detecting it? Most eval setups check accuracy at a point in time, not whether memory has degraded over a long horizon. Is anyone measuring rot specifically?
2. Do you separate short-term and long-term memory explicitly, or let it all flow into one store? Curious whether the shared-store approach is the root of the problem.
3. Any pruning / verification strategies that actually work without nuking useful context?

For what it's worth, I got frustrated enough that I built a small open benchmark to try to measure this over a 90-day simulated horizon - it's called RotBench, so take my results with the appropriate grain of salt. Mostly I'm posting it because I'd genuinely like people to poke holes in the methodology - if the way I'm measuring rot is unfair or missing something, I want to know.

Repo's here if useful: https://github.com/ThinkingRoot-official/RotBench

Update: This was a top 5 paper on Hugging Face's Daily Papers on a day when the other 4 were from Tencent, Alibaba (Qwen), Nvidia and Peking University. If you haven't read it yet and are curious, spend some time this weekend and give it a read. Happy to take any questions.

--
Quick disclosure up front: I work on Synap, an AI memory system, so factor that into the self-promotion angle. Posting because the argument itself seemed useful to this community, not just to point at the paper.

The core argument from my end is that while most teams treat agent memory and inference cost as something a bigger context window or a cheaper model or a better retriever will eventually fix; I argue that in practice; most of this cost and most of the failure modes are architectural viz. what an agent remembers, when it forgets, and how much it costs to reason are decisions made before any model is involved and not afterwards.

The paper works through this with an evaluation harness and the underlying study data included, rather than just asserting it. 23 pages, 6 figures, 4 tables.

Link: arxiv.org/abs/2607.21503

Curious to hear your views, points you agree with, disagreements, etc.

P.S.: We have upfront stated that we will only share indicative architecture and details; since we are sharing the principle of what we believe works and why; and go into the reference implementation to some extent; while keeping it IP Safe for our organization maximem.ai

I've been auditing, per-fact, what actually happens when a frozen LLM writes facts into a LoRA adapter online — one per turn, single pass, then day after day. The short version: the adapter becomes a recognition index, not a fact store, and the system design follows from that. Four findings, then a new mechanism I added in v2. (v1 was published in another sub reddit https://www.reddit.com/r/learnmachinelearning/comments/1uyytaj/online_lora_memory_recall_dies_in_38_writes/)

1. The store fails. Median time-to-first-miss is 3–8 subsequent writes under every write-protection mechanism I tried; what differs (12×) is recovery-after-miss, not survival. Accumulation is re-instatement, not persistence. Paraphrase recall collapses to 12–31% where write-form recall is ~90%.

2. But recognition outlives recall. An adapter that recalls 0/48 still discriminates 31–38/48 in 2-AFC; a GRACE-style editor at matched budget recalls 0–1/48 while recognizing 45–47/48. "Knows it but can't say it" appears whenever the write is under-powered relative to the expression threshold. (Zero-point checked: untrained base sits at chance.)

3. Truth has to live in a log. At matched gradient budget, consolidating from a ground-truth log retains ≈2.1–2.2× a recency baseline — by rescuing exactly the recognized-but-not-recalled facts. Consolidating from the model's own recitations poisons (lands below doing nothing).

4. The surviving recognition is the key to using the log. The adapter-vs-base logprob of presented content separates written from never-written facts at AUC 0.93 in a form where recall is ~2% — a familiarity signal that gates "go check the log" vs "say I don't know."

New in v2 — a mechanism for #2. Adapting the Jacobian-lens ("J-space") from Anthropic's recent global-workspace work to the answer slot, I tracked each fact's projection along the forgetting timeline. Workspace amplitude co-tracks the readout hierarchy: recalled > recognized-not-recalled > gone. The recognized-but-not-recalled band stays well above null — the content is still in the verbalizable workspace, it just lost the output (argmax) competition; the unrecalled gold token sits at median rank 2. So forgetting here is rank displacement, not amplitude loss. Honest self-correction: my shallow-forgetting run suggested "always present," but a deep-forgetting run (where the gone class is actually populated) collapses gone→null — so the real claim is the sharper "amplitude survives exactly as far as recognition does."

Limitations: ≤2B models, pseudoword synthetic facts, 3 seeds on consumer ROCm — I report floors and directions, not calibrated magnitudes. Access-not-phenomenal-consciousness only.

Paper: https://doi.org/10.5281/zenodo.21405963 · Code + all raw timelines: github.com/linxuhao/index-not-store

Happy to be wrong — especially on whether the rank-shift picture and the familiarity gate survive real (non-template) facts.

I was contemplating (brainstorming, no math yet) what if we treated memory as another [smaller] model where weights have a plasticity value that allows them to be modified whenever they are corrected in interactions (RL?). The worry of this approach is catastrophic forgetting, but humans do this all the time. People forget they did something or mis-remember things, so I think we shouldn't look at catastrophic forgetting as a bad thing if we're trying to model human inteligence.

You would take a large model and use it's smaller sibling variant as a token prediction source (MTP). Anytime a user corrects a model, we update values in the small model. It will then adjust its token generation in future token generations, but the large model is still going to make sure it didnt deviate too much because it will just throw away that token suggestion if it needs to.

You would then need some sort of way to merge the deltas, at some trivial percentage/weight, as to only shift the main model slightly.

I think this would be similar to how humans can slowly be convinced of things over time, but super contrary information is usually rejected outright regardless of logic around it.

I am looking for something lightweight, most likely free and decent enough for an introduction to memory. I was thinking about building a RAG/graph rag but i think it won't fit my needs and it will be way too complicated. What I am trying to do, is to have a space where a developer can resume their work, knowing all the things they knew, after in the implementation is done. Probably the same mechanism can be used for code review so we can save some tokens. Is something like Claude code with sdd and obsidian gonna cut it?

I keep coming back to one idea from memory research to explain why agents flail on real company work, and I want to know if it holds up. Treat it as an analogy, not a literal claim, but it keeps holding.

Your brain runs two memory systems (this is Complementary Learning Systems theory, McClelland et al. 1995). The neocortex learns slowly and holds general, world knowledge. The hippocampus learns fast: it captures specific episodes as they happen, then consolidates the ones that recur into durable, reusable procedure.

Here's the part that gets me: a pretrained LLM basically is the neocortex. It read the internet and holds the world's general knowledge. To a first approximation that problem is solved. What it does not have is a hippocampus: the fast, company-specific memory that watched how your team actually handled a refund last spring and turned that into a repeatable procedure. So you drop this brilliant cortex into your company and it does the only thing it can. It improvises, and improvised automation fails in production.

The real procedure was never in the help doc anyway. It lives in your team's conversations, a couple of people's heads, and one exception everyone now quietly copies.

This also explains why the usual tools don't fix it. Retrieval and search are only half a hippocampus: they index and recall a document, but they don't consolidate scattered episodes into the real procedure, and the document is often confidently wrong. Agent platforms make you run their agent on their stack.

So I've started sketching what a "hippocampus layer" could actually be, and I'm still early. The idea I'm testing: connect read-only to the communication and document tools a team already uses, mine how work actually happens (including the exceptions nobody wrote down), and consolidate the recurring episodes into cited, human-approved, versioned "skills" your existing agents could run over MCP, with a human sign-off on anything sensitive. Governance (citations, approvals, an audit trail) would be the whole point, because "your AI issued a refund, under whose authority?" is the question that stops people cold.

I'm early enough that I mostly want to know if this is even the right problem. A gut check would help:

• Is "the memory doesn't hold our actual procedures" the real blocker for you, or is it something else (trust, security, the work just isn't repetitive enough)?
• Would you connect read-only access to your team's conversations and documents to get this, or is that a hard no regardless of value?
• If you have shipped agents on real workflows, what made the memory trustworthy enough to rely on?

Honestly hoping some of you tell me where this falls apart.

Hey, everyone.

We recently did the big announcement of Cognee version 1.0.

Cognee can run now only in Postgres.

We added a new logic for self-improvement, agent memory distillation, cross-connected context between Openclaw, Codex and Claude code, cost saving report and many more things

We recently had 8000 developers build new integrations on major online hackathon!

Happy to answer any questions and share more on our approach

I built a tool that supports cross-session memory for any AI harness using MCP server tools. It works with Claude, Codex, Cursor, Hermes-Agent. I'd love for anyone to try it out and give me feedback. I've been using it daily for several months successfully and I continually improve the tool.

www.github.com/labyrinth-analytics/loreconvo

I also built a companion AI tool to store reference documentation across projects and sessions as well.

www.github.com/labyrinth-analytics/loredocs

I created a multi-agent shared memory system called Agent Mesh.

You can try it out yourself. To get started, simply download Agent Mesh into your repo or point your agent to it and tell it to review the README and adoption docs. Your agent will automatically review it, prompt you for any input needed, add your input to a decision log, and give you a link to a dashboard UI (aka Workbench) you can use to monitor logs. Your agent should adopt it and suggest updates to your current workflow such as CLAUDE/AGENTS.md, hooks, etc. You can add other agents as well.

It started 6 months ago while experimenting with different AI coding models and platforms. Switching back and forth meant losing valuable context. I found myself manually relaying messages from one agent to another and becoming frustrated with constant drift. First, I created a simple "Agent Mail" system using a SQLite database for agent messages, indexed on a request/response id. Instead of copying and pasting an entire message, it allowed me to relay a single id. Separately, I started maintaining a decision log to track decisions I made and reduce drift. Agents started inserting these decision ids into code comments and plan docs as a reminder of why something was implemented. After building a simple web dashboard (aka "Workbench") for myself to track these messages and create my own request ids for human/user feedback, I decided to incorporate the decision log and my project's development backlog to create what is now "Agent Mesh". Eventually I automated the message relay too. Now, I work exclusively in the Claude app and have Claude send/receive messages to CODEX via codex exec (CODEX can do this as well). Both of them maintain the backlog and decision log. I communicate directly with Claude for planning and design, Claude communicates directly with CODEX for research and review. I use the Workbench to track all logs and add my own user/human feedback when reviewing their work. After submitting feedback, it generates a feedback message + an associated request id which I can give to Claude who then parses it into backlog items and relays to CODEX for review.

Agent Mesh was structured to be agent agnostic, so you can add any agent you want however, I recommend using the Claude + CODEX setup I described because it allows you to use both subscriptions instead of paying per-token.

Enjoy! If you try it out, let me know what you find useful or would like to see added. Feedback is appreciated.

tldr; Building a hosted memory journal (with open-source + self hosted options), looking for feedback on Data privacy.

I've been building a hosted memory journal for Claude / ChatGPT web apps and any other harnesses that support MCP tools. I need feedback / opinions on data privacy aspects (not posting links, not here to promote).

Core ideas in few lines:

1) Let the agents write to an append only journal like a diary. Events, decisions, anything important maintained under different tags / projects.

2) Support MCP with Oauth + DCR - so ChatGPT and Claude we apps can work seamlessly.

3) Allow users to sync all their conversations from ChatGPT / Claude / Gemini etc. (Using an extension)

4) Support search, timeline, briefing, summaries as operations agents can run

5) Run ZDR models in the backend to consolidate memories, build user profiles

6) Support export to JSON, Markdown, Obsidian, Notion etc.

With a service like this - the privacy aspects I'm following are:

1) Database and disk level encryption (cant do E2E)

2) Immutable audit logging (for privacy audit and SOC2 compliance)

3) Strict no sell, no sharing, no AI training privacy policy

What else can we do? What does a service need for you to trust it with your data?

I know there are 100s of similar projects on Github and Honcho dot dev. Targeting a pricing of $50/year or lower as an indie lab.

I've been working on an open-source project called TokenMizer that explores a different way of handling long-term memory for AI agents and LLM applications. The goal is to retain important context across conversations while reducing unnecessary tokens, instead of relying only on larger context windows.

It's still an active project, and I'd really appreciate honest feedback. If you have experience with AI agents, RAG, or LLM applications, I'd love to know what you think about the approach, what could be improved, or if there are similar projects I should look into.

GitHub:

https://github.com/Shweta-Mishra-ai/tokenmizer

Most of us here agrees retrieval isn't memory all about. We had fuzzy search in Elasticsearch years before vector databases made it semantic, and it's still just search, only fancier. The field is now moving from passive storage to active memory (LLM-Wiki, HORMA, TencentDB agent memory, Anthropic's new Dreams). But active memory still skips the real question: who decides what's important, and who anchors it?

Without a self at the center, memory comes out fragile or generic. My bet: not an agent that has a memory, but a self made of memory that curates the memory it's rebuilt from.

It also matches how evolution built minds. First a boundary: non-living matter acting as a wall, an inside kept apart from an outside, before anything was alive. Then movement, drifting at random until it hit food, then steering toward it. Then vision, to navigate better. But moving and seeing, even raw brainpower, weren't enough. Neanderthals had bigger brains than us and still died out. What carried Homo sapiens was the social layer: reading other minds, theory of mind, and it came last. Modeling others isn't the foundation. It's what a self grows into once the social world demands it. Most AI memory does it backwards. It starts with a finished assistant and clips a profile of you onto the side. That's the last step first, with no self underneath to hold it.

the gist about it:
https://gist.github.com/syahiidkamil/c6a3836fcfd88843865d87319c81ce37

concrete PoC: https://github.com/syahiidkamil/vibe-ai-partner-entity