“We’re progressively disclosing that information when we use that agent, but if we don’t use it, it’s not part of our overall memory. And that could be good and bad — but what we’re able to do is have a lot more detailed memory for that specific function, and invoke it when the agent runs. It’s distributed intelligence, distributed memory.” — Lou
Session context: 2026-04-30_Mastermind — Lou’s explanation of how memory in the functional agent architecture differs from Claude’s global memory, and why that distinction matters for both depth and control.
Core Idea
Most people think about AI memory as a single layer: what the AI knows about you. Claude’s built-in memory works this way — a central store that Claude retrieves from when it decides something is relevant. This architecture is convenient, but it has three problems: you don’t own the data, you can’t control what gets retrieved when, and the memory isn’t deep enough for specialized functions.
Lou’s distributed memory model solves all three. The principle: every agent folder contains its own memory folder. When that agent runs, its memory loads — highly specific, contextually rich, optimized for that function. When the agent isn’t running, its memory doesn’t enter the conversation.
The contrast with platform-managed memory:
- Claude’s memory is global and probabilistic. It might remember that you prefer a certain tone; it won’t reliably recall the specific decision criteria you’ve developed for one workflow over 6 months of use.
- Distributed memory is local and deterministic. The writing team agent loads writing-specific memory every time it runs. The proposal agent loads proposal-specific memory every time it runs. No contamination between functions.
The three properties Lou named: depth (more detailed memory for that specific function), scope control (it doesn’t pollute context when the agent isn’t running), and portability (if you switch LLMs, the memory travels with the folder — cd to the folder and the memory is there).
The tradeoff is real: global memory occasionally retrieves something surprisingly relevant across contexts. Distributed memory won’t make unexpected connections across functions. Lou acknowledged: “Sometimes it’s like, oh, if I only could remember that, whereas Claude does remember the whole thing and has some chance that it’ll retrieve the thing.” The right answer depends on what you’re optimizing for: depth and control (distributed) vs. serendipitous cross-context retrieval (global).
The practical implication: for any business process where the memory requirements are substantial and domain-specific — coaching conversations, client history, writing style, research patterns — distributed agent memory will outperform global memory because it can hold more, hold it more precisely, and apply it reliably.
Don Back’s connection: his research university white paper is an early form of this. The research lives locally, travels into new conversations via the CLAUDE.md resolver, and is deeply specific to that client type. When he’s not doing institutional work, that knowledge isn’t cluttering other conversations.
Practical Application
Implement distributed memory in your agent folders:
-
For each agent folder you build, create a
memory/subdirectory alongsideskills/andtools/. -
Structure the memory folder with at least two files:
patterns.md— recurring decisions, preferences, and non-obvious rules the agent has learned about your way of workinghistory.md— notable past runs: what worked, what didn’t, what edge cases came up
-
After each major agent run, spend 2 minutes updating the memory. What did you change in the output? What would you want the agent to do differently next time? Write it in plain language.
-
When building the agent’s system prompt, explicitly tell it: “Before starting, read your memory folder. Apply everything you’ve learned about how I work in this context.”
-
Never rely on the agent to update memory automatically. Agent-managed memory is useful but needs human review. You’re the quality gate.
Coaching Question:
“Which of my most-used AI workflows would benefit from a dedicated memory — one that accumulates everything I’ve learned about how to do that specific thing well, and loads it automatically every time?”
Related Insights
- Insight - Ambient Intelligence — Build a Skill in Every Folder to Make Your Entire Knowledge Base Alive — the foundational folder-as-intelligence architecture; distributed memory is the memory layer in that architecture
- Insight - The Resolver Pattern — Your CLAUDE.md Is a Pointer File, Not a Knowledge Store — the portability principle that makes distributed memory valuable: memory travels with the folder, not with the platform
- Insight - Forked Skills as Context Isolation — Run Sub-Agents Without Polluting Your Conversation — the same isolation principle applied to agent execution; distributed memory is the same principle applied to agent knowledge
- Insight - Persistent AI Memory via MCP - Building a Cross-Session Intelligence Layer — the complementary approach using MCP for cross-session memory; distributed agent memory solves the depth and portability problems that MCP doesn’t address
- Insight - Design AI Systems for Maximum Composability and Minimum Context Pollution — the design philosophy this architecture operationalizes: each component carries only its own context
Evolution Across Sessions
This establishes a new insight extending the ambient intelligence and local-first architecture threads. Prior sessions have covered how to create persistent memory (2025-07-24, MCP), how to avoid context pollution (2026-03-12), and how to build portable AI infrastructure (2026-04-23, resolver pattern). Distributed agent memory synthesizes these: memory should be as local as the function it serves, as deep as that function needs, and as portable as the folder it lives in. Future sessions should test: does distributed memory actually produce measurably better outputs over time, or does the manual update discipline break down?