Memory
Persist and retrieve scoped agent memory for SOIT runtime behavior.
Memory supports agent behavior that needs scoped retained context beyond a single response. In SOIT, memory is treated as a governed capability instead of an unbounded hidden store.
When to use memory
Use memory when an agent needs durable workspace or user-context signals that should be available across runs — user preferences, conversation summaries, learned workspace facts. Avoid memory for large documents or source-grounded retrieval; use Knowledge for that. The rule of thumb: knowledge answers "what do the documents say", memory answers "what has this agent learned about this context".
Governed, not hidden
Most agent frameworks treat memory as an opaque side effect. SOIT applies the same platform rules to memory as to every other capability:
- Scoped — memory belongs to a tenant/workspace context and respects identity boundaries; one workspace's memory never leaks into another.
- Observable — memory writes that affect execution appear as
memory_writerun steps in the runtime ledger, so an operator can see what an agent remembered and when. - Bound by configuration — the agent's published version determines how memory is used; memory behavior changes are version changes, subject to review and rollback.
How memory connects
- Agent configuration (in the published agent version) determines whether and how memory is read and written.
- Memory writes during execution emit run steps, making memory-influenced answers explainable.
- Access respects identity, workspace, and policy boundaries like every governed capability.