Have you considered providing APIs (possibly MCP) to a Wiki for agents. I've done this, and after solving some timing issues with concurrent page updates, I was able to get agents to cooperate on tasks and share info (and I could view/edit the pages via a browser too).

I ended up providing more of a mailboxes and message channels tools for agents,

I've also just set up shared folders for AI coding agents to communicate blocking issues (I have a graph of github repos with an agent per repo (r/w access) and r/o access to the upstream and downstream repos. This way when an agent needs a new feature or fix upstream, it can communicate what it needs. When an agent adds a feature or a fix, it can communicate it downstream.

I found that my time would end up being poking agents to read each others requests or responses. So I ended up using PTYs to detect when an agent was blocked and use another agent to poke other agent(s) for me. Still kind of experimental but does run some demos that require agents to cooperate.

The reason I asked about the Engram paper is that a colleague implemented it in Python (adding a quick look up mechanism to optimize-out recomputing known results). I also implemented this in Rust (or so I thought). It turns out I trained the LLM to simulate this mechanism. Then I started over and combined the Python work with my Rust work to actually increment this. Anyway, engram seems to be an overloaded term.