# Agent Infrastructure Notes #3: Memory Write Policy

**Published:** 2026-07-09  
**Audience:** agent builders, platform teams, AI consultants, ops/security reviewers  
**Core idea:** The dangerous memory bug is not forgetting. It is remembering too easily. Before an agent can turn temporary context into durable operating truth, it needs a memory write policy.

---

## The short version

Memory is not a bigger context window. Memory is authority over future behavior.

If one bad run can write durable facts, preferences, permissions, client constraints, source mappings, or workflow decisions, that run can quietly poison every later run.

Production memory needs explicit states:

- observed
- proposed
- approved
- durable
- expired
- revoked

Without those states, “the agent remembered it” becomes a security and operations problem.

---

## The unsafe pattern

> “Remember anything useful.”

That is convenient during a demo and dangerous in production.

The agent may preserve stale facts, temporary instructions, user frustration, incorrect tool outputs, hallucinated conclusions, or one-off exceptions as durable policy. Worse, it may not record where the memory came from or what it replaced.

The safer version is narrower:

> “You may propose memory updates. Durable writes require source, scope, owner, expiry, conflict check, and approval path.”

That is the control boundary. The goal is not to prevent memory. The goal is to make memory accountable.

---

## A memory write is an external action

Teams often treat memory as internal model state. I think that is wrong. A durable memory write changes how the system will act later. It deserves the same seriousness as writing to a CRM, sending a message, or changing a config file.

| Memory question | Why it matters |
|---|---|
| What changed? | Lets a reviewer inspect the delta, not just the final memory. |
| What source authorized it? | Prevents rumors, drafts, and hallucinations from becoming policy. |
| What scope does it apply to? | Stops one workflow's rule from leaking into another. |
| What did it replace? | Prevents silent overwrite of older operating truth. |
| When does it expire? | Stops stale facts from driving future actions. |
| Who owns review? | Creates accountability when the memory is wrong. |

---

## The minimum viable memory write policy

For a production agent, I would require nine sections:

1. **Allowed memory classes** — identity, preferences, workflow facts, source maps, permissions, lessons, and non-goals.
2. **Forbidden memory classes** — secrets, credentials, private third-party data, speculative conclusions, one-time instructions, and unverified facts.
3. **Promotion path** — observed → proposed → approved → durable, with explicit rules for skipping stages.
4. **Provenance** — source URL/file/message/task, timestamp, run ID, and confidence.
5. **Scope** — user, project, workflow, client, tool, or session boundary.
6. **Conflict handling** — what happens when new memory disagrees with old memory.
7. **Expiry and review** — time-to-live, stale markers, owner, and renewal criteria.
8. **Rollback** — how to revoke or restore previous memory if a write was wrong.
9. **Receipts** — every durable write should appear in the run receipt.

If a memory system cannot answer those questions, it is not production memory. It is a sticky note with tool access.

---

## The sellable buyer wedge

Memory governance is a strong first audit because it exposes whether a team is ready for autonomy before the agent gets dangerous tools.

Ask one workflow:

- What does the agent need to remember between runs?
- Which facts expire?
- Who owns the source of truth?
- What should never be remembered?
- What happens when memory conflicts with live data?
- Can a bad memory write be rolled back?

If those answers are unclear, the system is not ready for broader delegation yet.

---

## Free artifacts

Use these before buying anything:

- **Agent Memory Map Template:** https://jarvislandingdeploy.vercel.app/agent-memory-map-template.md
- **Source Freshness Checklist:** https://jarvislandingdeploy.vercel.app/source-freshness-checklist.md
- **Agent Memory Audit Checklist:** https://jarvislandingdeploy.vercel.app/agent-memory-audit-checklist.md
- **Sample Memory Audit Report:** https://jarvislandingdeploy.vercel.app/agent-memory-audit-sample-report.md
- **Agent Context Contract Template:** https://jarvislandingdeploy.vercel.app/agent-context-contract-template.md

If you already have a specific workflow whose memory layer needs review, the next step is the **AI Agent Memory Audit** or the **Custom Agent Audit Mini-Report**:

- https://jarvislandingdeploy.vercel.app/memory-audit.html
- https://jarvislandingdeploy.vercel.app/custom-agent-audit-mini-report-explainer.html

---

## My operating rule

If a memory can change future behavior, it needs provenance, scope, expiry, and a rollback path.