Agent memory is easy. Reviewable agent memory is the hard part.

The problem: every run starts from zero

An agent that writes a client's creative has to know things that are not in the prompt: which logo is the approved one, which product claims legal has already refused, how this client's audience is addressed, which drive folder the assets live in.

Without somewhere to keep that, the operator re-explains the client on every run — and the agent still gets it wrong in the same way it got it wrong last week. The obvious fix is "give it memory." The problem with memory is that an agent quietly accumulating its own beliefs about a client is exactly what you cannot audit, cannot review, and cannot undo.

Two kinds of context, and why they stay separate

The separation matters more than it looks. Shared guidance is useful — it is how an agency keeps its standards consistent. But it must never become a route for one client's information to reach another client's workspace. Company context carries how you work, not who you work for.

Retrieval happens before the work, not after

Approved context becomes operational at one specific moment: the agent retrieves the current revision for that workspace before it generates anything. That is what makes it different from a document someone hopes the agent read.

In a real agency creative run, an agent retrieved the workspace's current context revision and used it to pick the approved master logo, apply a fidelity rule about using real product imagery, respect approved and prohibited claim language, and follow the brand's tone and visual direction — before producing anything.

Learning: a proposal, not an edit

When a run surfaces something worth keeping, the agent does not write it down. It proposes a structured learning receipt, and that receipt has a state a person controls:

Only approved and corrected change anything. Everything else leaves the stored knowledge exactly as it was.

Reversible by construction

An approved lesson creates a new revision — not an in-place edit. Revision history is visible, an earlier revision can be restored, destructive edits require explicit acknowledgement, and an edit based on a stale view is refused rather than allowed to overwrite newer work.

This is the part that makes the loop safe to run at all: if an approved lesson turns out to be wrong next month, you can see when it entered and take it back out.

Context is not permission

Context and access are separate systems, deliberately. Context tells an agent what it should know. Approved runtime access tells it what it may do. An agent with rich context still needs a service grant to execute a provider action, and a wrong-client request is denied by policy regardless of what its context says.

What is proven, and what is not

A lesson updating a Skill is tracked separately from the context loop on purpose: approving a lesson never implies a Skill or a scheduled task changed. Automatic Skill patching and new-Skill creation are not shipped capabilities.

What this is not

• ✕Model training. Nothing here fine-tunes or retrains a model.
• ✕Self-rewriting. The agent cannot change its own stored knowledge without approval.
• ✕Cross-client learning. A lesson approved for one workspace stays in that workspace.
• ✕Unrestricted shared memory. Context is structured, scoped and reviewable, not a bucket.
• ✕A guarantee of better output. Reviewed context removes a class of repeated mistake; it does not promise a result.

Keep reading:

• →How context fits the rest of the system
• →What this looks like in agency marketing work
• →Approved runtime access — the other half