Memory
Memory is durable context that should survive a single run.
It is not a hidden provider feature and it is not just a longer chat window.
What A Memory Record Is
Decubed models memory as explicit records with durable identity and scope.
A record can attach to a workspace, folder, thread, or agent and carries text plus metadata that helps the runtime decide when it matters.
Current record kinds include:
- facts
- summaries
- notes
Why Memory Is Separate
Separating memory from thread history gives the product control over what becomes durable recall.
That means the system can keep:
- full thread history for inspection
- targeted memory for future assembly
- clear boundaries around what should be recalled later
Without that split, every long conversation becomes either too sticky or too forgetful.
Recall Policy
Memory should not be sprayed into every prompt by default.
An agent profile can carry a recall policy so the runtime knows:
- whether memory is active
- which scope is eligible
- how much recalled context belongs in the next assembled payload
That makes memory deliberate instead of magical.
Portability
Because memory belongs to the workspace layer, it can stay stable when the execution path changes.
Users should be able to switch between:
- local runtimes
- hosted providers
- linked accounts
without losing the durable context they intentionally kept.
What Memory Is Not
Memory is not:
- raw secret storage
- hidden prompt mutation outside the workspace model
- a replacement for full thread history
It is a durable recall surface with explicit ownership.