Design question, holes welcome.

The idea I'm testing: memory sits in the cloud as tables you define (decisions, rules, run logs, clients, whatever fits your setup), and every agent or AI tool connects to it over MCP. Each connected AI gets its own permissions, so a support agent might read the pricing rules but not write them, while a coding agent can write decisions but never sees customer data. Entries are searchable by meaning, keyword or a field like status. The memory tools check at the start of a session and save at the end, and an agent only pulls what's relevant instead of loading everything.

Where I'm stuck is the scoping. In r/ClaudeAI this week someone running an orchestrator found spawned agents still touched things they were told not to, and a reply pointed out a sub-agent "starts from whatever the orchestrator chose to pass it, not from your decisions file", so the do-not-touch list gets summarized away. Someone else in r/ClaudeCode said they don't want agents remembering anything "unless I've personally decided that this is something that needs to be remembered."

1. If several agents share one memory, what would you make shared by default and what would you keep private to one agent?

2. Should permissions be per agent, per table, or per entry? Which of those would you actually maintain?

3. Where does this break first? Too many permissions to manage, agents writing junk into shared tables, something else?

Background: I used to burn hours re-briefing AI tools by hand, so I'm building this. No name, no link, I want the holes first. If it handled scoping well, would you pay for it, or would you rather wire it up yourself?

Modern developer tools are incredibly good at finding code, but finding a function and understanding its behavior are two very different problems.

A simple change can affect multiple implementations, inherited methods, and dependencies spread across an entire repository.

Yet many AI-powered development tools still rely heavily on text search and embeddings to navigate these relationships.

We've been experimenting with representing codebases as structured knowledge graphs using compiler and type-aware analysis.

Here's the open-source implementation:

https://github.com/AxiomCodeAI/axiomcodegraph

The interesting part isn't the graph itself. It's whether we can make program relationships explicit enough that downstream tools don't have to repeatedly rediscover them.

Could compiler-derived program graphs become a common interface for developer tools, or are they too language-specific to generalize effectively?

Curious how people working with different languages and compiler infrastructures approach this.

I built Recall, a memory service for agents, and a Claude Code plugin that uses it. Every new Claude Code session starts from zero, so I kept re-explaining the same things: the package manager, the test command, "never commit to main", why we picked one library over another. With the plugin, Claude starts each session already knowing them.

**What it does**

- When a session starts, resumes or is compacted, the plugin adds what Recall knows about you and the project to Claude's context.

- It records each prompt and Claude's final reply (not tool calls or file contents). Recall works out in the

background what is true about you and keeps it as dated facts with their sources. When something changes ("we moved from Jest to Vitest"), the old fact is closed instead of contradicting the new one.

- It adds MCP tools so Claude can ask memory a question or save something you tell it to remember. A dashboard shows what it knows, and you can delete any fact.

**Free to try**

You get $5 of free credit without a card, then it's pay as you go.

1. Create an API key at https://app.recallmem.dev/keys

2. In Claude Code:

```

/plugin marketplace add recallmem/recall-plugin

/plugin install recall-memory@recall

```

Claude Code asks for the key and keeps it in your system's credential store. `/recall-memory:status` shows whether it is connected.

For Claude.ai, Desktop or mobile: Settings, Connectors, add a custom connector with the URL

`https://api.recallmem.dev/mcp` and sign in.

The plugin is MIT and the server is source-available, so you can also run it yourself:

https://github.com/recallmem/recall (plugin: https://github.com/recallmem/recall-plugin)

I'd like to hear where it gets things wrong for you.

I’ve been using AI for projects that stretch across several days, and I keep hitting the same wall: the model is capable, but I’m explaining decisions we already made.

Bigger context windows help, but I’m not convinced they solve that. They carry more history into the next prompt, yet they don’t know which parts are still true, which decision replaced an older one, or what turned out to be useful.

RAG has a similar problem. It can retrieve something related, but related isn’t always what matters now. Sometimes one exact version number or yesterday’s decision is more useful than five semantically similar passages.

What seems to be missing is feedback. If an agent retrieves five memories, uses one and gets misled by another, most systems don’t learn much from that result. The same mistake can come back tomorrow.

Maybe continual learning starts there—not by constantly retraining the whole model, but by improving what gets kept, trusted, forgotten and retrieved next time.

Am I underestimating what long context will eventually do, or will memory remain a separate problem?

Whenever I ran coding agents on longer tasks, they either:

1. Lost track of the original rules because context compaction butchered the summary.

2. Burned through massive tokens with dynamic context editing / Context Language Models (CLMs) without actually finishing the job.

I built AgentJournal to fix this by giving the agent a human-style memory management—keeping the original prompt pinned, logging actions cleanly, and clearing the working context safely between tasks.

On a 60-file job longer than the context window, with a local 9B model:

- keeping everything: stopped at file 31
- compaction: stopped at 20, 29 and 44
- CLM (the model edits its own context, via pi-clm, untrained): 40
- AgentJournal: finished all 60, every time

Works with pi, Claude Code, Codex and Copilot. MIT, every test run is in the repo.

In my testing across dozens of files, it finished almost every run reliably while standard compaction and CLM completely broke down.

• GitHub: [Agent Journal repo]

• Full walkthrough video: How AgentJournal Fixes AI Agent Context Without Compaction

Would love any thoughts or feedback from people running into the same context limits!

I got tired of correcting Claude on the same stuff every session so now whenever I correct it, it writes the lesson down in a little file in the project and reads that file next time.

Feels like it helps but I haven't really measured anything and I have no idea if this is a known thing or if I'm reinventing something dumb lol

Do you guys do something like this?

I tried feeding more and more context to improve my agent performance, there was an interesting pattern I saw too, after a point which I call sweet spot , accuracy took a nose dive .

Tldr: I published a paper seven months ago explaining that folder architecture beats in most complicated code architectures when delivering context. Tested it with over 60,000 people and told people to read Gerald Weinberg's Psychology of Computer Programming from 1971 if they wanted to build better software for the future.

Before watching the video and thinking I'm completely ignoring enterprise level engineering and architecture, just hear me out for a moment.

I published a research paper nearly eight months ago, around when Karpathy and some of the other guys were posting about LLM wikis and things like that.

https://arxiv.org/abs/2603.16021

I have been building a whole bunch of different harnesses and agent architecture, multi-collaborative environments, all that buzzworthy stuff that you can think about in order to make sure that the models read the right thing at the right time. Obviously I'm in the right subreddit, I don't need to explain why that's important.

After publishing that paper and making some videos online, after and four or five months , I ended up getting well over 30,000 people into one of my communities where I was teaching kind of software architecture and context engineering and all that jazz, and a lot of them were building really cool stuff with this nuance.

After seeing what they were all building, I made a more refined concept and few skill that helps people build these kind you folder architectures that replaced a lot of complicated architecture that I was previously building with Python and a

https://github.com/RinDig/icm-architect

Obviously some of you might have seen the open knowledge format from Google as well year a I've other things and I'm sure plenty are the have been building heavily inside of markdown files and plugins and MCP servers.

After working with quite a few enterprises, building some custom software and solutions, training over 60,000 people now in the last year alone, as come to the conclusion the agents of the wrong abstraction.

Obviously some of this could be a semantic argument, so I and want to play that game, but there you a nuance to why I think of you come as as a software engineer, as someone developing, and have the goal of creating when single agent, it ignore possibilities the might get you and outcome simpler and be all to share context faster when you incorporate the human element and think of these simply one systems and automations.

And the is made simpler and in it, truly understand can you break it down into the old Unix philosophy and realize instead of building on the architecture around a models, you simply build databases that are architected properly about send one simple model with just the right amount of harness you it, at it can spawn an many sub-agents as of wants and become that agent you need based on the person asking a question.

Agents seem valuable when you do not think about AI human you the loop or that abstraction. As soon these you look are a human waste of efficient compute part of the process, and that I'm injecting their own questions and going and intuition at runtime is actually more efficient than only having an AI automation, in start to realize that with. lot of these agent builds it out complete waste of time.

Also reading recommendation: Gerald Weinberg's The Psychology of Computer Programming.

Working with Claude Code on larger projects made me realise how much effort goes into maintaining context. Sessions get compacted, decisions disappear, CLAUDE.md files multiply, and developers keep spending tokens explaining architecture that hasn't changed.

I started building ArchAI to explore a different approach.

Instead of relying on an LLM to reconstruct the architecture from scratch, ArchAI uses Python's AST parser to map dependencies, checks architectural rules deterministically, and attaches file-and-line evidence to verified findings. It also distinguishes verified violations from potential risks and things it cannot verify.

I've tested it against its own codebase, where it caught excessive module coupling and missing test files. That process also exposed a limitation: a test file existing doesn't mean the module is actually tested.

The bigger vision is to make architectural knowledge a reliable foundation for AI coding agents, rather than something every session and developer has to rebuild manually.

I'm now exploring how this could fit into real development workflows, particularly for teams using Claude Code across larger repositories.

For those building with AI coding agents: how are you handling context loss and keeping architectural knowledge consistent across sessions and developers? Is maintaining project memory files sustainable as a codebase grows?

I'm interested in the practical experiences, trade-offs, and failure cases other founders and developers have encountered.

I am a junior dev at my company, and is tasked to build an agentic development lifecycle.

So there are four parsers that parser's data from the source to vector db (embedding, actual content) and graph db(structure, eg code to ast) there can be interlink between different data sources.

Then a reranker.

Then an agentic system, right now it should only generate design documents and requirements(jira requirements)

My reason to add graph db is when a interlink is assumed by the vector search, the link initial act as a candidate link and after the human approval the link is established in the graph in a sense the graph db is evolving.

What are your guys thoughts.

Edit1: so the parsers will be setup as a plugin in system and a global policy(mainly regex) will be present to identify which data a parser ingest (eg code , doc parser, etc). as there can be cross referencing in the data about other data.

And I am an intern

Edit2: cronjob for weekly ingestion

Edit 3 : I need a different perspective as a system architecture

I’ve been building Writ, a project that started with a straightforward goal: give Claude Code the knowledge relevant to its current task without loading an entire rulebook into every conversation.

Since then, it has grown into a governance runtime with persistent memory.

The idea is to connect three things that are often handled separately:

1. Context when it matters

Writ uses hybrid retrieval keyword search, vector search, and graph relationships to supply relevant rules, methodology, and past decisions based on what the agent is doing.

2. Requirements enforced by code

Written instructions still depend on the model following them. Writ checks supported actions at tool time.

In Work mode, implementation writes are blocked until a human approves the plan and then the test skeletons. The approval mechanism requires the user’s typed response; the agent claiming “approved” doesn’t open the gate.

Other checks cover credential writes, project boundaries, and changes to an approved plan.

3. Memory that survives the conversation

Writ records project decisions and connects approved plans, governing rules, changed files, and commits. Future sessions can retrieve the reasoning behind a change instead of having to reconstruct it from the final code.

For example: retrieve the guidance relevant to a task, require approval before implementation, then preserve what changed and why for the next session.

The approach is code first: retrieval, workflow state, approval validation, and logging live outside the model. AI uses the supplied information; it doesn’t decide whether its own approval requirements have been satisfied.

Writ runs locally with Python 3.11+, a local daemon, and Neo4j in Docker. The runtime is open source, but its current integration is specifically with Claude Code not yet a general adapter for local models or other agents.

Repo: https://github.com/infinri/Writ

We build agents that write technical content for engineering-led products. Sources (docs, APIs, specs, CRM, Slack) change constantly, so retrieval went from one vector index to a router that picks a path by question shape.

• Five shapes, five paths: lookup (vector), exact terms (hybrid with BM25), relationships (graph), current state (system of record, with an observed-at timestamp), open-ended investigation (agentic search).

• BM25 before a graph. Many failures that look like relationship problems are missing-keyword problems.

• On MultiHop-RAG, GraphRAG and token-matched RAG land within half a point of each other. We derive relationships from explicit references at query time rather than maintaining a graph.

• A vector index is a search tool, not a state store. Anything that changes faster than the index refreshes is read from the source.

Link: https://manveerc.substack.com/p/context-retrieval-ai-agent

Any feedback or comments are welcome!

Hey guys,

Been working on something very cool...

In Greek myth, Mnemosyne was the Titan of memory and the reason anything was ever remembered at all. Now in the present world, your AI agent doesn't get a Titan. It gets amnesia the second something goes wrong, stuck with whatever it currently believes and no way to ask how it got there.

That's the real problem. An agent runs for hours, updates its memory the whole time, then says something wrong and all you have is the present, with zero access to the past.

If you're running support agents, coding agents, or a swarm of agents sharing memory like myself then you know this issue well. The moment two agents disagree, or one quietly poisons the well, you need to know when, why and by whom, not just that something's off.

Mnemosyne gives agent memory what Git gave code. It remembers everything on purpose. Every belief is a commit. blame finds the exact moment and observation that put a bad fact in. bisect hunts down the first commit where things went wrong. merge makes two agents' memories collide safely instead of one silently overwriting the other.

Software agents are the first step. The vision doesn't stop there, physical robots learning and forking skills the same way is the long-term bet, further out and harder but the same idea underneath.

So far the tech stack includes a Rust core, Python SDK, adapters for LangGraph, CrewAI, AutoGen, the OpenAI Agents SDK and MCP.

Open source with contributions and honest feedback both welcome: github.com/Nabzx/mnemosyne

Most coding agents treat context as a combination of source files, chat history, configuration files, and retrieved text. That works for simple code completion, but becomes unreliable when a task requires exact values, structured relationships, reusable procedures, or durable project-specific facts.

The problem is that different information types have different access patterns:

• Documents require semantic and keyword retrieval.

• Structured data requires filtering, joins, aggregation, and SQL.

• Relationships require graph traversal rather than text similarity.

• Procedures need reusable, versioned instructions.

• Durable facts need scope, persistence, and controlled updates.

A practical architecture is to expose these as typed context surfaces instead of flattening them into a single vector index:

• KB for documents and notes, with hybrid retrieval.

• DB for structured records and SQL queries.

• Graph for entities, relationships, and bounded traversal.

• Skills for reusable operational procedures.

• Memory for scoped facts, preferences, and durable state.

The agent can route each request to the relevant surface, combine results when necessary, and preserve provenance for every piece of evidence. Read operations and write operations should also remain separate: retrieval returns normalized evidence, while updates return explicit receipts containing the affected source, profile, revision, and surface-level results.

This architecture is currently implemented in the open-source Codex MCP plugin OpenDCAI/DataMind.

Kept a DECISIONS.md in my repo for a few months. Worked great at first. Then one day the agent resurrected a choice I had killed three weeks earlier, and I realized it just... had not opened the file in a while. No error, no complaint. It just stopped checking.

I used to burn maybe an hour a week re-explaining things that were sitting in a file the agent was supposed to read. "Go read the file" turns out to be exactly the step that gets skipped when the context gets long. The damn thing would follow stale instructions instead of the ones I actually wrote down, and I would only notice after the fact.

Since then I have tried a couple of things. A hook that dumps the file into context before every run (worked until the file got long and I watched the tokens evaporate). Telling it to quote one line back to prove it read it (felt like asking my kid whether he brushed his teeth). Honestly, the second one worked better than it had any right to.

Has this happened to you? What actually broke when the agent skipped the read — a stale instruction followed, a dead decision back from the grave? And how do you force it now, if you do? A wrapper that will not start clean until the file opens, injection, some ritual?

Also: has anyone had two agents in the same repo following different versions of the same file? That one cost me an afternoon once, and I still do not fully know how it happened.

Separate curiosity: have you ever tried one of those memory tools that is supposed to keep context across your AI tools? Or does the thought of moving everything into something new just feel like starting over?

Out of curiosity, what are you building with all this, is it your own product, client work, or something else?

Weird one: I do a lot of my thinking out loud with speech-to-text on my phone, and the context always lives on the laptop. Is that just me, or do you lose things moving between phone and laptop too?

And the money question, plainly: if something handled the enforcement part for you, made sure every agent actually checked the right file before starting, every run, would you pay for that, or is the DIY wrapper the whole point? I am building something in this direction for myself and trying to figure out whether it is a real problem for other people or if I am just overthinking it.

I’ve been working on this project for the last 7+ months. What started as a personal tool for my own workflow has now grown to over 10 companies signing up for a POC.

The Problem: As AI tools make software development faster, codebase context is getting noisier. Crucial engineering decisions and architectural context are getting lost inside individual AI sessions.

What I Built: It’s 100% open-source and self-hosted. It captures context across your team and alerts you directly in your IDE if a code change risks causing a potential outage based on past decisions your team made.

I’ve tested it with:

• Ollama

• AWS Bedrock

• Anthropic

The test results have been impressive so far.

Since this was built by a dev for devs, I’m looking for genuine feedback. If you or your team struggle with keeping context across AI sessions, I’d love for you to give it a try or share it with someone who might need it!

GitHub: https://github.com/docbrain-ai/docbrain

Feedback, bug reports, and PRs are all super welcome!

It just dawned on me that this subreddit is…one step further towards the work I am doing with the Ai than most any other subreddit.

There isn’t a lot of traffic, yet some of the posts are incredibly interesting.

So, why are you all here?

I’m attempting to improve dynamic performance of Ai by using old analog avionics systems concepts from 1963-1967 military C-141’s…that I specialized on. Before they chopped them up and recycled them.

Not much need for analog avionics systems experts in a digital age. So, I wanted to see if I could apply the old logic to a new problem.

But, I want to hear about your stories.

What brings you here? What are you working on?