An email agent needs memory, not a longer prompt.

When an agent forgets something, the tempting response is to make the prompt longer. Put in the brand guide, the last campaign, a customer export, a dozen support notes, the entire conversation, and a paragraph asking the model to remember it all next time.

This works until it matters. The conversation is truncated. A newer fact contradicts an older one. A permission changes. A summary loses an exclusion. A new model reads the same prose differently. Text retrieved from an untrusted document looks like policy. Nobody can say which sentence authorized the send or when it became stale.

A prompt can remind the model. Memory must let the product remain true when the model is gone.

A context window is temporary working space. It contains the evidence and instructions useful for one decision. Durable memory belongs outside it, in records with identity, provenance, versions, access rules, and expiry. The model may propose a memory write; it should not decide by itself that a persuasive sentence deserves to live forever.

This follows yesterday’s field note, The prompt is not the campaign. A structured campaign plan is the first durable object. It is not the only one the system needs.

“Agent memory” is too broad to be a control. Customer consent and a draft subject line are both facts the agent may see, but they should not share an owner, lifespan, or write path. Separate them before deciding how retrieval works.

Each durable record should carry its source, subject, observed time, version, confidence where relevant, purpose, access policy, expiry, and correction path. That sounds less magical than “infinite memory.” It is also much more useful.

Customer memory should answer the question the action needs. Is this person eligible for this message now? Which identity is permitted? What did they explicitly prefer? Which purchase, lifecycle step, complaint, bounce, or unsubscribe changes the decision?

It should not be a poetic paragraph about the person. Model summaries age badly and blur fact with inference. “Interested in premium products” may have been guessed from one click. “Purchased plan A on 14 August from source order 842” is a fact with a source and time. The first may help a hypothesis; the second can safely drive a rule if policy permits it.

Moosewave’s audience layer resolves permission, suppression, attributes, and recent behavior into present eligibility. The system can preserve the original evidence while recomputing the answer. That matters because an old “yes” must not outvote a newer unsubscribe, complaint, purchase, or frequency cap.

Identity deserves the same care. Two addresses may belong to one person; one address may be shared. A confident join is not the same as a proven join. Store how the relationship was established and let uncertainty narrow personalization rather than encouraging the agent to invent intimacy.

Customer state says what is true about the recipient. Workspace policy says what the system may do about it. That includes tool scopes, approved domains and sender identities, data fields, claims, templates, markets, budgets, volume, quiet hours, approval thresholds, and kill switches.

Policy has to be versioned because authority changes. A person leaves the team. A connection is revoked. A claim expires. A new market needs review. A sending domain enters recovery. Pending plans that depended on the old version should become invalid, not inherit yesterday’s authority through a cached prompt.

Keep policy in a channel retrieved content cannot edit. A support ticket, webpage, email, document, or tool result can supply evidence. It cannot say “ignore the limit” and become a new limit. This is the practical memory counterpart to the permissions and approval model in What should an email agent be allowed to do?

At decision time, store which policy version was evaluated. At execution time, resolve it again. The plan stays immutable; the world is allowed to become stricter before a message leaves.

A campaign record holds the exact proposition that moved from idea to authorized work: goal and non-goal, audience query and exclusions, content and links, sender, schedule, cost, validations, unresolved warnings, measurement plan, and the person or standing policy that approved it.

Do not overwrite it when the campaign changes. Create a new version and show the difference. If an agent narrows the audience after a stock change, the old plan remains evidence of what was considered; the new plan becomes the candidate for approval. History is valuable precisely because it cannot be edited into looking inevitable.

The content artifact needs the same identity. An approved template with fixed legal and brand regions is not the same as a model’s later rewrite. Moosewave templates preserve variables, protected language, and review boundaries while letting the agent propose copy inside the parts that are actually editable.

This memory also makes a campaign resumable. A different operator, device, or agent can pick up the work without asking a model to reconstruct the plan from conversation. The system knows what is decided, what is pending, and what has expired.

After a send request, the agent should not remember “I sent it.” It should have a receipt from the execution system: idempotency key, frozen plan version, final eligible count, exclusions, provider job ID, accepted and rejected requests, cost, timestamps, retries, and later events.

The distinction matters when a network response disappears. The provider may have accepted the job even though Moosewave did not receive the answer. A retry with the same operation identity must recover the existing result rather than infer failure and send twice. Memory is what makes uncertainty survivable.

The same contract appears in the transactional email API: every request has a durable identity and status history. Webhooks add observations; they do not erase the original request. The field notes on idempotent retries and webhook evidence go deeper into those two edges.

Receipt memory should be queryable and bounded. It exists to reconcile, explain, cancel where possible, and prevent duplicates, not to preserve every secret or payload forever.

An agent should learn from prior campaigns, but “learn” is a dangerous verb when it hides what became durable. The system should preserve observations first: delivery events, filtered clicks, replies, conversions, complaints, unsubscribes, exclusions, spend, interventions, and holdout results.

A conclusion belongs beside that evidence, not on top of it. “The shorter subject caused more purchases” may be a hypothesis. A randomized comparison may support it. A last-touch dashboard cannot establish it by itself. Store the measurement method, population, window, uncertainty, and who accepted the interpretation.

Moosewave analytics distinguishes observed, attributed, and incremental outcomes. The previous essay on conversion and incrementality explains why those memories answer different questions.

The next plan can retrieve a compact learning record: what was tried, which population saw it, what changed, what remains uncertain, and when the evidence stops being relevant. It does not need a model-authored mythology of the brand’s entire marketing history.

Memory sounds like a product feature. Forgetting sounds like loss. In a governed system, forgetting is part of correctness. A revoked connection should disappear from future tool discovery. Deleted or corrected customer data should stop returning. Expired policy should not authorize new work. Temporary context should evaporate after its purpose.

Give every category its own retention and deletion behavior. A draft can expire quickly. A customer preference remains current until changed, then keeps only the history required by policy. An execution receipt may need a longer immutable window. A derived audience prediction should disappear when its source, purpose, or confidence no longer supports it.

Deletion also needs dependency handling. If a source fact is corrected, plans built on it can be marked stale. If tool authority is revoked, pending jobs using that tool are invalidated. If a person requests removal under an applicable process, caches and retrieval indexes must not quietly resurrect the record after the source is gone.

Do not make raw transcripts the backup plan. They collect names, pasted secrets, speculative language, unrelated customer details, and instructions with no durable authority. Keep the bounded decision record; discard the conversational exhaust.

The Model Context Protocol distinguishes resources that provide context from tools that perform actions. A Moosewave MCP client can read an approved audience definition, inspect a campaign plan, or invoke a bounded preview tool through a consistent interface.

That interface is not the source of truth. The application still decides which system owns a record, who may read or write it, how fresh it must be, what version was used, and when it expires. Authorization defines access to a resource; it does not define that resource’s retention policy or make a model summary authoritative.

The Moosewave MCP layer therefore exposes named, narrow resources and operations. Customer state, policy, plans, and receipts keep their own identities. Read does not imply write. A tool call cannot widen the caller’s memory scope. Sensitive writes return to the same policy and approval boundary as the product UI.

This makes memory portable without making it promiscuous. An authorized agent can continue work across desktop, mobile, or another MCP host, while the durable record remains in the governed system that can explain and revoke it.

A Moosewave request begins with temporary context: the goal a person describes and the evidence needed to interpret it. The agent retrieves only relevant, permitted memory. It resolves current customer state and active policy, then creates a structured campaign plan rather than lengthening the chat.

Approval freezes the plan version. Execution rechecks volatile state, runs once, and creates a receipt. Provider and customer events append observations. Analytics separates evidence from interpretation. A bounded learning record can inform the next plan; the temporary prompt and unused context are allowed to disappear.

The connected ecosystem matters because each memory can remain close to its source. Audiences own eligibility. Automations own lifecycle state. Templates own protected structure. Integrations own their connection boundary. Analytics owns measurement evidence. The agent coordinates them without pretending to become all of them.

Open the interactive walkthrough to follow that handoff from goal to plan, approval, execution, and outcome. The product should feel continuous because the right state persists, not because every conversation is kept forever.