State that's still there tomorrow.
An agent that forgets everything when the session ends starts every job from zero. Memory will let state outlive the run — and because that state is a record of your business, it will live in your storage, under your retention policy.
Knowledge that survives the session.
Today an agent's memory is whatever you remembered to save and reload yourself. Memory will make recall part of the runtime — durable, per-agent, simply there when the next run begins, with nothing to wire and nothing to move out of the boundary.
State that outlives the session
An agent that stops on Tuesday will start on Wednesday knowing what it knew. Memory will hold across runs, so the session can end without the knowledge ending with it.
What it learned, not what it said
Not a transcript. The durable things — facts it established, decisions it made, how far it got — kept as something the next run can build on rather than re-read.
Scoped per agent
Memory will belong to an agent and stay that way, partitioned per agent and per key. One worker's context will not bleed into another's, and no shared store sits between them.
In your storage, on your schedule
Agent memory is data about your business, so it lands in your storage inside the same boundary — retained, exported and deleted on your policy, like every other byte in the deployment.
Inside the runtime. On ground that already runs.
Memory is one piece of the agent runtime — Layer 02 — which stands on the inference layer deployed inside your boundary today. When your agents start remembering, they will be remembering on ground already carrying real work.
Retention is a policy question before it is a feature.
What an agent is allowed to remember, for how long, and who can read it are decisions that belong to you — and they shape the design more than any storage choice. Those are the constraints we want now.