Agent memory as governed data: what an agent remembers, where it lives, and how it is forgotten

Sits at the join of three records and deserves its own design surface: #341 C stores agent transcripts as artifacts with digests in state, #105's entity shape gives a workload state that persists across signals, and #353's first principle makes anything remembered forgettable by construction. Nobody in the agent-infrastructure space has a governed answer to "what does the agent remember"; everyone has an ungoverned one, which is an accumulating liability the operator cannot see, export, or erase. Flowstate is positioned to make memory a declared, bounded, policy-visible resource, because every ingredient already exists or is specified.

The shape

Memory is declared, never implicit. An agent workflow that wants memory across runs says so: a named memory store, a scope (per entity, per tenant, per subject), and a declared retention. Nothing accumulates as a side effect of running. This is the budgets rule (#341 invariant 4) applied to state: unbounded implicit memory is unbounded implicit cost and unbounded implicit disclosure at once.

Three tiers, mapped to existing machinery, no new engine semantics:

1. Within a run: the transcript. Already specified (#341 C): an artifact, digests in state, contents never in history.
2. Across runs of one long-lived thing: the entity shape (#105). A loop: + wait_for_signal: workload whose carried state is its working memory, already bounded by the run-state size checks and already visible through EntityState on Get. What is missing is the vocabulary for an author to say which parts of carried state are memory (persist across Continue-As-New, survive restarts) versus scratch.
3. Across workloads: a memory store as an artifact-backed, content-addressed collection (#341 A's store with a retention discipline), read and written through ordinary task dispatch so task-shape policy, tenant scoping, and egress all apply. A recall is a step; a memorize is a step; both appear in the trajectory. No hidden channel.

Governance properties, each inherited rather than invented:

• Bounded: per-store size and entry caps, compile-refused when absent, exhaustion a first-class outcome (the loop: precedent).
• Tenant-scoped by default, with the negative direction tested (the env-provider lesson: assert tenant A cannot recall tenant B's memory, not that A can recall A's).
• Forgettable: memory entries keyed under the same hierarchy as #353 A's crypto-shredding, so flow shred --subject erases what an agent learned about a person, attested, without touching history.
• Sensitive-aware: a memory write derived from a sensitive: input or a secret is refused or redacted, fail closed, with the containment-shape tests.
• Auditable: what was recalled into a given run's context is part of that run's record (digests, not contents), because a trajectory that omits its retrieved memory is not a trajectory an auditor can trust.

Testable: flow test can seed a memory store, assert what a run recalled and memorized, and prove retention (virtual clock advances past the declared retention, recall answers empty). Deterministic agent-memory tests are the same differentiated story as the scripted LLM responses in #341 C.

Non-goals

Not a vector database, not an embedding pipeline, not a retrieval framework. Providers and rankers are plugins if they are anything; the core owns the governance shell: declaration, scoping, bounds, retention, shredding keys, audit. Not implicit conversation memory bolted onto the llm task; if a loop wants context carried forward, it declares where and how long.

Sequencing

Design here can start now; implementation of tier 3 is behind #341 A (the artifact store). Tier 2's missing vocabulary (memory versus scratch in carried state) can be designed against #105's next slice. Tier 1 lands with #341 C. The shredding-key integration is behind #353 A.2, and the design must be reviewed against it before either lands, per #353's one-custody-design anti-goal.

Start by reading issues #341, #105, and #353, then review the existing EntityState, loop/wait_for_signal, artifact-store, and shredding designs they reference. Use the flow test and flow shred entry points to map the proposed memory tiers, tenant scoping, retention, and erasure behavior. Done means the design resolves sequencing and governance requirements without introducing implicit memory or new engine semantics.