title: Slack as the database description: How gild persists gilds, sessions, reasoning, and transcripts entirely in Slack. order: 2
Slack as the database
gild owns no server and no database. Slack is the source of truth. Everything you do in gild is encoded into Slack messages that round-trip and stay human-readable in plain Slack.
The mapping
| gild concept | Slack |
| --- | --- |
| gild (project workspace) | a channel gild-<slug> |
| membership | channel members |
| chat message | a top-level message |
| agent session | a thread (root = the initial prompt) |
| reasoning step / follow-up | a thread reply |
| session complete | a thread reply + an uploaded transcript file |
Dual-channel encoding
To stay both machine-readable and human-readable, gild writes session metadata twice:
- Primary: the Slack message
metadatafield (event_type+event_payload). It is returned by the API and invisible in the Slack UI. - Fallback: a hidden fenced
```gild:metablock in the message text, in case the metadata is ever stripped.
A decoder reads the metadata first, then the fenced block, then falls back to heuristics — so records always survive a round trip.
The local mirror
Agents never touch Slack. gild keeps a local filesystem mirror of the gilds you belong to, and that mirror is the agent-facing read model: a gild summary, recent messages, and each session's files. Agents read this mirror and are never handed Slack credentials.
Why it matters
- Your transcripts live in your Slack — fully readable, exportable, and yours.
- There is no vendor lock-in to a gild-owned data store.
- Anyone on the team can audit a session directly in Slack.