Who Owns the Agent's Memory? A Sales Analytics Storyline Built on Established Patterns
A design storyline for a sales analytics department and its tech platform team: what each side builds and runs for agent memory — with every major step justified by an established research or industry pattern (ExpeL, Agent Workflow Memory, Reflexion, STaR, traces-to-datasets, data mesh, MDM), and the composition gap made explicit.
Research date: Sep 27, 2026. This is a design scenario (storyline), not a case study: the organization, people, and numbers are constructed, and every sourced claim is linked inline. Where a step is a judgment call, it is labeled as interpretation or assumption. Method: the memory mechanics were verified against primary sources this session — official Codex memory documentation, the MCP memory-server README, the Hermes Agent README, the installed DeepSeek Harness 0.1.5-rc.1 package tree, and the pattern papers cited below.
TL;DR
A sales analytics department wants agents that stop forgetting: account context, pricing decisions, lessons from lost deals. The storyline assigns the work along one seam — the memory server is generic infrastructure (tech dept); the memory policy is business logic (sales analytics dept) — and justifies every step with a pattern that already exists in research or industry practice. The honest finding: each stage of the pipeline is an established pattern; the composed, human-gated, domain-scoped loop is not yet a standard — that composition is the open slot this storyline fills on paper.
The seam: who owns what
The split follows data mesh’s organizational pattern: “self-serve data infrastructure as a platform” belongs to the platform team, while domain content stays with the domain (Data Mesh Principles, Martin Fowler). OpenAI draws the same line inside its own product doctrine: “Keep required team guidance in AGENTS.md… Treat memories as a helpful recall layer, not as the only source for rules that must always apply” (Codex Memories).
| Tech dept builds and runs | Sales analytics dept builds and runs | |
|---|---|---|
| Owns | Harness standard, memory backend, MCP interface, backup/erasure, injection scanning, metering, benchmarks, plugin supply-chain policy | Fact taxonomy, write-policy prompt, rules files, capture→distill→approve loop, held-out eval set, golden questions, the analytics tasks themselves |
| Does not touch | What the agents remember | Which database runs underneath |
Pattern behind the seam: data mesh’s “federated computational governance” — domain autonomy with global interoperability, policies automated by the platform (martinfowler.com). Analogy: agent memory is Master Data Management for conversation-derived facts — MDM creates “the golden record: one authoritative version of each entity that all systems reference” (Dun & Bradstreet).
Act 0 — The trigger
Four analysts each run AI agents for account research, forecast narratives, and pipeline hygiene. Every Monday they re-explain the same context: “Q3 pricing changed in June; the Meridian account is stall-risk; never quote the old discount list.” Sessions are ephemeral, so yesterday’s corrections evaporate — the exact problem memory systems exist for: “Memories let ChatGPT and Codex carry useful context from earlier work into future work” (Codex Memories). The premise that durable knowledge needs deliberate capture is the same one this blog’s own workflow starts from (Local Repository Memory for Coding Agents).
Act 1 — What Tech builds and runs
Step 1 — One harness standard, MCP as the memory socket.
Pattern: interface standardization. MCP makes memory a swappable tool surface: the official reference server is plain CRUD over a single JSONL file (server-memory README), and the harnesses speak it — DeepSeek Harness ships dsh-mcp-client (verified in the installed @deepseek-ai/dsh 0.1.5-rc.1 dependency tree), Hermes has MCP integration (Hermes README), and Codex’s memory docs explicitly reference chats “that used external context such as MCP tool calls” (Codex Memories). One memory, every agent.
Step 2 — One memory backend, run as infrastructure, starting minimal. Pattern: MDM/golden-record store as a platform concern (D&B); minimal-first adoption — the CRUD-only reference server with no pipeline, no embeddings (server-memory README). Interpretation: start lexical, add semantic retrieval only when measured recall degrades — substring addressing works at ten entries and degrades at fifty, which is why Hermes ships external semantic providers (Evals and Agent Memory).
Step 3 — Governance rails around the store.
Patterns: erasure as a first-class operation — GDPR Art. 17 obliges controllers to erase personal data “without undue delay” (gdpr-info.eu, Art. 17); the server’s delete_entities/delete_observations are those erasure primitives (server-memory README). Write-side hygiene has shipped precedents: Hermes scans memory writes for injection attacks and data-leakage patterns before persisting (Hermes README, per Evals and Agent Memory); Codex redacts secrets and refuses to learn from chats that touched MCP/web search (disable_on_external_context, Codex Memories).
Step 4 — Metering and benchmarks before any backend change. Pattern: benchmark-driven infrastructure decisions. The cost rationale is measured, not felt: memory-augmented retrieval costs on the order of ~7K tokens per retrieval call versus ~26K for full-context injection on LoCoMo (Mem0, “State of AI Agent Memory 2026”, as cited in Evals and Agent Memory). The open suite runs LoCoMo, LongMemEval and related benchmarks across memory backends (mem0ai/memory-benchmarks).
Step 5 — A supply-chain rule for memory plugins. Sourced risk, not an established pattern: third-party plugins execute as trusted code inside the harness process, the harness carries an explicit no-security-audit notice, and community memory plugins are weeks old and version-fragile (DeepSeek Harness Ecosystem, Sep 2026). Policy: source review + version pinning before any plugin runs.
What Tech explicitly does not do: decide what the agents remember. It runs the pipe; the domain writes the policy.
Act 2 — What Sales Analytics builds and runs
Step 1 — Domain-scoped collection. Pattern: the memory stream of Generative Agents (observation, reflection, planning memory), scoped per the blog’s guidance to “scope it by repository, directory, or task type” (Local Repository Memory). Interpretation: a deal-desk scope keeps the corpus small enough for reliable lexical recall (Step A1.2’s degradation point) and keeps the eval distribution matched to real work.
Step 2 — The fact taxonomy and write-policy prompt. Pattern: golden-record definition owned by the business (D&B); atomicity discipline from the reference server’s own suggested prompt — observations “should be atomic (one fact per observation)” (server-memory README). The taxonomy for a sales domain: accounts, contacts, pipeline events, decisions, lessons, preferences.
Step 3 — Rules live in AGENTS.md, memory stays a recall layer.
Pattern: OpenAI’s doctrine, verbatim: “Keep required team guidance in AGENTS.md” (Codex Memories). The discount list version and mandatory citations go in the checked-in rules file; memory never becomes the source of truth for must-always rules.
Step 4 — Capture → distill → approve. Pattern: human-gated promotion — agents propose, humans approve, raw transcripts never auto-promote (Local Repository Memory). The LLMOps incarnation is LangSmith’s traces-to-dataset practice: “Add real traces to a dataset so a failure you saw once becomes a test you run every time” (LangSmith Evaluation docs).
Step 5 — The corpus becomes a held-out eval set. Pattern: ExpeL — “LLM Agents Are Experiential Learners” — extracts insights from success and failure trajectories, and does so from experiences “gathered in the training set” (arXiv 2308.10144): the train/test discipline is built into the founding paper. Derivation (this storyline’s condition): the eval set must be a separate, human-reviewed artifact — never the same file the agent reads at runtime — otherwise the agent is tested on what it has already been told, and the score measures recall of its own notes, not capability.
Step 6 — Self-enhancement loop, scored. Patterns: Reflexion’s three-model loop — Actor generates, Evaluator scores, Self-Reflection writes verbal feedback (arXiv 2303.11366); Agent Workflow Memory induces “commonly reused routines, i.e., workflows” and “selectively provid[es] workflows to the agent” (arXiv 2409.07429); Voyager’s skill library “compounds the agent’s abilities rapidly and alleviates catastrophic forgetting” without weight changes (arXiv 2305.16291). Derivation: a refinement that drops the golden-set score is rolled back — “the eval suite, not the memory file, is the scoreboard” (Evals and Agent Memory).
Step 7 — The specialist end-state (optional, last). Patterns: STaR — “generate rationales… if the generated answers are wrong, try again… given the correct answer; fine-tune on all the rationales that ultimately yielded correct answers; repeat” (arXiv 2203.14465) — and ReST, which formalizes generate→filter→fine-tune→repeat as growing-batch RL (arXiv 2308.08998). Shipped analog: Hermes advertises batch trajectory generation and trajectory compression “for training the next generation of tool-calling models” (Hermes README). Interpretation: reach this level only if the score trend shows levels 1–2 (skills, playbook) saturated.
Step 8 — The analytics tasks themselves. Account entity-resolution against CRM (the MDM use case), meeting-prep briefs, win/loss lessons, forecast-narrative drafting — all business-owned, all consuming memory through the same MCP tools. Assumption: effectiveness targets for these tasks are goals of the scenario; no source claims them.
Act 3 — The federation contract
When lexical search_nodes degrades (Step A1.2’s threshold), Tech swaps the store under the same MCP facade and re-runs the benchmark suite; Sales Analytics re-runs its golden questions and approves or rejects. Nobody rewrites prompts. That is data mesh’s “federated computational governance”: “domain self-sovereignty, interoperability through global standardization… and most importantly automated execution of decisions by the platform” (martinfowler.com).
What is established vs. what is not
| Pipeline stage | Established pattern | Source |
|---|---|---|
| Domain-scoped experience collection | Memory stream | Generative Agents |
| Corpus → distilled insights | ExpeL (train/test discipline included) | arXiv 2308.10144 |
| Corpus → distilled workflows | Agent Workflow Memory | arXiv 2409.07429 |
| Procedural accumulation | Voyager skill library | arXiv 2305.16291 |
| Scored self-correction | Reflexion (Actor/Evaluator/Self-Reflection) | arXiv 2303.11366 |
| Corpus → eval test set | Traces-to-dataset | LangSmith docs |
| Corpus → trained specialist | STaR / ReST | arXiv 2203.14465, arXiv 2308.08998 |
| The composition: domain-scoped → human-gated held-out eval set → scored self-improvement → specialist | Not established as a standard | — |
Two gaps that make the composition non-trivial: (1) memory benchmarks (LoCoMo, LongMemEval, MemoryAgentBench) measure recall and update behavior on generic conversations — none measure “did the specialist get better at the domain from its own corpus” (Evals and Agent Memory); (2) personal-agent tooling ships with no eval gate at all — “growth without measurement is vibes” (Evals and Agent Memory).
Scoreboard (assumptions, not sourced facts)
Fewer repeated context explanations per week; token spend per task trending down against the metered baseline; monthly audit pass rate (duplicates, contradictions); golden-question scores trending up with no regressions. If the memory file grows uncontrolled or contradictions survive audits, the design — not just the content — gets revisited.
Honest limits
- The storyline is design fiction: the organization and its numbers are constructed; the sources justify the mechanisms, not the outcomes.
- Eval sets capture real prompts — they are a security surface and, in a sales domain, a personal-data store subject to GDPR Art. 17 like the runtime memory (gdpr-info.eu).
- Star counts, plugin maturity, and harness APIs move weekly; the DeepSeek Harness specifics here reflect the 0.1.5-rc.1 tree inspected on the research date (Ecosystem report).
Companions: How Evals Meet Agent Memory · Self-Improving Agent Frameworks vs. Smart Memory Management · Local Repository Memory for Coding Agents
Sources
- Codex Memories (official documentation, fetched Sep 27, 2026): https://learn.chatgpt.com/docs/customization/memories
- MCP Knowledge Graph Memory Server README (fetched Sep 27, 2026): https://github.com/modelcontextprotocol/servers/tree/main/src/memory
- Hermes Agent README (Nous Research): https://github.com/NousResearch/hermes-agent
- DeepSeek Harness 0.1.5-rc.1 package tree (inspected in-session;
dsh-mcp-client,dsh-agent-instructions, no first-party memory package) - ExpeL: LLM Agents Are Experiential Learners: https://arxiv.org/abs/2308.10144
- Agent Workflow Memory: https://arxiv.org/abs/2409.07429
- Voyager: An Open-Ended Embodied Agent with Large Language Models: https://arxiv.org/abs/2305.16291
- Reflexion: Language Agents with Verbal Reinforcement Learning: https://arxiv.org/abs/2303.11366
- Generative Agents: Interactive Simulacra of Human Behavior: https://ar5iv.labs.arxiv.org/html/2304.03442
- STaR: Bootstrapping Reasoning With Reasoning: https://arxiv.org/abs/2203.14465
- ReST: Reinforced Self-Training for Language Modeling: https://arxiv.org/abs/2308.08998
- LangSmith Evaluation documentation: https://docs.langchain.com/langsmith/evaluation
- Data Mesh Principles and Logical Architecture (Martin Fowler): https://martinfowler.com/articles/data-mesh-principles.html
- What Is a Golden Record in Master Data Management? (Dun & Bradstreet): https://www.dnb.com/en-us/resources/master-data/what-are-golden-records-in-master-data-management.html
- GDPR Article 17 — Right to erasure: https://gdpr-info.eu/art-17-gdpr/
- mem0ai/memory-benchmarks: https://github.com/mem0ai/memory-benchmarks
- Mem0, “State of AI Agent Memory 2026” (token-cost figures, as cited in the companion post): https://mem0.ai/blog/state-of-ai-agent-memory-2026
- Companions: Evals and Agent Memory · Self-evolving frameworks vs. memory management · Local Repository Memory · DeepSeek Harness Ecosystem