u/Yuuyake

I've been reading a lot of the Cline Memory Bank discussions, and the thing that resonates is not "the agent needs more context."
It's more like: the agent needs the right kind of context, at the right time, without dragging the whole project history into every task.
Memory Bank-style files are great for:
* project shape

* current status

* gotchas

* what was already tried

* rough direction

Where I start getting nervous:
* old plans that are no longer true

* temporary notes becoming permanent

* team members editing memory in different directions

* context bloat

* no clear source for why a memory exists

The part I want most is provenance. If an agent says "we decided X," I want to know where that came from. Issue? PR? Slack thread? meeting note? previous agent run?

For people using Memory Bank seriously: what do you keep in it, and what do you deliberately keep out?

Do you treat it as evergreen project memory, temporary task scratchpad, team handoff docs, or all of the above?

I've been looking at memory MCPs for agent workflows, and I keep going back and forth.
On one hand, MCP is a great interface. If an agent needs to ask "what do we know about this project/person/task?" then exposing memory through MCP makes a lot of sense.
But memory has a few problems that feel bigger than a normal tool call:
* stale facts

* source links

* user correction

* delete/export

* cross-tool permission boundaries

* deciding what should be inherited by the next session

So now I'm wondering if memory should be split:
* MCP as the read/write interface

* local store/event log as the actual source of truth

* separate UI for inspection, deletion, access logs, etc.

Maybe that's overengineering. But "persistent memory" starts getting scary once it spans tools and agents.
For people using memory MCPs: what has actually held up? Simple file memory? graph/Neo4j/pgvector? app-specific memory? local SQLite?
And what made you stop trusting a memory setup?

I'm working on an Apache-2.0 desktop app for AI work memory, and I would like FOSS/privacy-minded critique before polishing the UX too much.
The problem I'm trying to solve:
AI assistants can be useful, but work memory is usually hidden inside a cloud product or buried in chat history. I want something where the user can inspect what was remembered, where it came from, and why it is being used.
Current direction:
* Windows/macOS/Linux desktop app

* local-first storage with IndexedDB + SQLite

* source-backed memory for people, projects, decisions, and follow-ups

* visible access logs

* human approval before actions

* Apache-2.0 repo

Limits, because this is the part I would want stated clearly too:
* early software

* desktop-only right now

* it only knows what you connect/authorize

* if you use a cloud LLM provider key, model calls still go to that provider

* local model usage depends on your setup

The trust questions I keep coming back to:

1. Should every memory link back to a source?

2. What network boundary should be visible in the UI?

3. Are access logs enough, or should there be a permission manifest?

4. What should delete/export look like?

5. Would reproducible builds matter for this category?

6. What would make you immediately distrust an AI memory app, even if it is open source?

I know AI posts can get sloppy fast, so I'm intentionally asking for trust-model critique rather than "check out my cool app."

I've been thinking about long-term memory for CLI coding agents, and I keep getting stuck on the boundary.
The obvious places:
*global AGENTS.md

* repo-level instructions

* saved sessions

* MCP servers

* notes/docs

* local DB or graph the agent can query

They all solve part of it, but none feels quite right.
AGENTS.md is good for stable preferences. It feels bad for volatile state. Session history is useful but not portable. MCP can expose tools, but memory also needs source trust, decay, and correction. Notes are inspectable but too manual.
The memory I want is not just "remember my coding style." It is more like:
* why this architecture decision happened

* which bug path was already tried and ruled out

* which user/customer report started the issue

* what changed after the last coding session

* which source backs the context being used

My current bias is that durable memory should sit outside the agent runtime, and the runtime should ask for scoped context when needed.
But then the hard question is: how does it know what to ask for without pulling in too much?
For OpenCode users, where would you want this to live? repo files, local agent DB, MCP, external service, something else?
What would make you trust it enough to influence code changes?

I kept trying to build AI workflows where the workflow did everything. Pull data, summarize, decide what matters, remember the state, draft the next step.

It worked in demos and then got messy.

The use case was simple: a daily catch-up.

What changed overnight? who replied? what issue moved? what follow-up is still open? what do I need to handle today?

The workflow part is not that bad:

• pull new events
• summarize
• route important stuff
• create a draft/checklist
• wait for approval

The hard part is the memory around it.

Who is this person relative to the project? Was this already decided last week? Did a later message replace the old plan? Is this urgent, or just new? Where did this remembered fact even come from?

If every workflow owns its own memory, they drift. If you throw everything into RAG, old context comes back looking just as confident as new context.

The pattern I'm leaning toward now:

• n8n/workflow layer handles orchestration
• separate memory layer handles people/projects/decisions/open loops
• LLM drafts/reasons
• human approves before anything goes out

Curious how other n8n builders handle long-running state. Postgres? Redis? vector DB? Airtable? CRM? Notion? something else?

This may be obvious, but it helped me:

RAG is for reference material. Memory is for state.

Reference material is docs, PDFs, notes, code snippets, knowledge base pages. It can be old and still useful.

State is messier:

• what changed since last time
• what the user decided
• who a task is about
• which fact is stale
• which source supports a remembered claim
• what the model already tried and should not repeat

If memory is just another collection, it gets noisy fast. Every old summary competes with every new fact. The model sees plausible text but has no idea if it is still true.

What I would want in a local memory layer:

• source pointers
• user-visible access logs
• delete/edit/override
• stale-state handling
• some separation between search results and active memory
• approval before actions that use remembered work context

For people running Open WebUI with tools, skills, MCP, local models etc: where would you put something like this?

Plugin/tool? MCP server? external local service? model-specific memory?

I'm not sure there is a clean answer yet.

MCP has made the tool side of agents feel much cleaner to me. A tool has a boundary. It can call this, read that, mutate this other thing. You can reason about permissions.

Memory feels less clean.

If an agent calls tools all day, it also learns things:

• this person owns that project
• this issue was already decided
• this old plan got replaced
• this source was used for that answer
• this task is still open

Where should that live?

My first instinct was "make memory an MCP server too," but I'm not sure that's enough. Memory has lifecycle problems that normal tools do not: stale facts, source evidence, deletes/overrides, access logs, decay, and maybe permission history.

The options I can see:

• memory as an MCP server, nice and portable
• memory inside each agent runtime, probably smoother UX but less portable
• memory as a local event log/graph, more auditable but more infra
• some hybrid where MCP is the interface and a local app/store handles provenance

I'm leaning hybrid, but not confidently.

If you were installing an agent memory layer, what would make it trustworthy enough? Permission manifest? source link for every memory? signed releases? export/rollback? local-only mode?

Or is this the wrong abstraction entirely?

I've been messing with long-term memory for agents, and I keep running into the same annoying thing:

retrieving the right-looking chunk is not the same as remembering the right state.

RAG is pretty good when the question is "which doc/chunk is relevant here?" But memory gets weirder. The agent needs to know whether an old fact is still true, where it came from, whether something later overrode it, and whether it should even bring it up right now.

That last part surprised me the most. Bad memory is not just forgetting useful stuff. Sometimes it is remembering too much and quietly polluting the run.

The shape that feels least wrong to me so far:

• append events from tools instead of overwriting everything
• extract memories with source pointers
• let old memories decay or compete
• keep an access log so the user can see why something was used
• require approval before actions, because remembered context can still be wrong

Maybe this is obvious to people who have built more of these systems, but I keep seeing "agent memory" collapse back into "vector DB plus summaries," and that feels too shallow.

For people building agents: where are you putting durable memory right now?

Inside the runtime? separate service? MCP server? vector DB? graph/event log?

And what has been the worst failure mode for you: stale facts, noisy recall, missing source links, or the agent using memory way too aggressively?

The more I think about PKM, the less I believe "save everything" is the right end state.

What I keep running into:

• capture is easy
• resurfacing the right thing later is hard
• old notes can be true but no longer useful
• links saved months ago should not all have the same weight
• forgetting might be a feature, not a bug

This came up while testing OpenLoomi, which is an open-source work-memory project. But the broader question feels bigger than one tool: should a second brain have decay?

What do people here think? Should knowledge systems learn to forget, or should forgetting always be manual?

I used to think agent memory was mostly a storage problem: save the messages, embed them, retrieve later.

After building/testing this more, I think that framing is too shallow. The annoying cases are not "can I find an old thing?" They are:

• is this old thing still true?
• did the priority change since then?
• was this a decision, a passing comment, or just noise?
• should the agent surface it now, or leave it alone?

That last one is the part I underestimated. Bad memory is not just missing context. It is also context showing up at the wrong time.

Curious how people here are modeling memory state. Is it a graph, event log, vector store, task state, something else?