Data ownership and lifecycle
Who owns each kind of data, how memory is scoped, and what happens when a conversation is archived, trashed or deleted.
Every piece of data in the portal is owned through a stable id — never through a display name. Who may read it is decided by the resource’s own visibility rules, or by the knowledge base it is filed under.
Key rules
- Ownership follows a stable id. Renaming a person or a resource never changes who owns what.
- Organisation resources are shared only through their visibility rules.
- Personal data is keyed to the person. Conversations, drafts, memory, attachments and personal resources belong to their user id.
- Admins see aggregate memory use, not its content.
- Deleting a conversation never deletes the artifacts it produced.
Who owns what
| Data | Owned through | Who reads it |
|---|---|---|
| Organisation resources — agents, skills, prompts, knowledge bases, connectors, artifacts | The organisation | Whoever the resource’s visibility rules allow |
| Knowledge and shared memory | The knowledge base it is filed under | Whoever that knowledge base’s rules name |
| Your own memories | A knowledge base you own | You |
| Personal conversations, drafts, memory, attachments and personal resources | Your stable user id | You |
Memory and knowledge share one store. Internally a knowledge base is called a collection: the collection a row is filed under decides who reads it.
Memory scope
Memory is also scoped by agentAgentAgentAn assistant with its own instructions, knowledge, tools and default model. Every chat runs through one — plain chat is an agent that used no tools.Open in glossary:
- A memory that names no agent is read by every agent.
- A statement a model wrote names the agent that wrote it.
- A person’s own memories sit in a knowledge base they own; a shared record sits in one whose rules name its audience.
An admin may observe aggregate memory use, and cannot read the content of anyone’s personal memory. What you can see and change about your own is in Settings › Memory.
Conversation lifecycle
A conversation is active until you trash it. Trash comes with undo, which brings it back as it was. Archive is a separate, independent flag — archiving neither trashes nor restores.
| Behaviour | Rule |
|---|---|
| Trash | With undo |
| Archive | An independent flag, separate from trash |
| Artifacts | Deleting a conversation never touches an artifactArtifactArtifactA file an agent creates for you during a chat — a document, spreadsheet, slide deck or small app — that you can open, download and share.Open in glossary it produced |
How to archive, trash and restore is in Your conversations. What the audit trail keeps, and for how long, is in Audit and cost.
Unsaved code-run files
A code run can write a file that the agent then never saves as an artifact. The row and its bytes are real, and nothing points at them.
The portal sweeps those:
- It looks for artifact files older than a grace period that no artifact version references.
- Each one has its bytes deleted and its row marked deleted.
The grace period is set by the deployment. It exists because storing a file and saving it as an artifact are two separate tool calls; a sweep running between them would delete a file somebody was about to keep. How code runs and the workspace work is in Workspace and code.
Why it works this way
Why never own data by display name?
Display names change. Because ownership follows a stable id, renaming a person, a department or a resource never moves data from one owner to another or breaks a sharing rule.
Why does deleting a conversation keep its artifacts?
An artifact is an organisation resource with visibility rules of its own, and others may already be using it. Deleting the conversation that produced it removes the conversation, not the work somebody saved from it.