What lives where
If that computer burned down tonight, what has to still be true tomorrow.
One question decides it. If that computer burned down tonight, what has to still be true tomorrow?
Whatever answers yes belongs in the record. Whatever is a fact about the machine belongs on the host.
The record
Every table here is something a company would still need after replacing every
computer it owns. supabase/migrations is the schema itself, one migration
per change, and What the tables mean explains what
each table is for. Read the table list from the migrations rather than here, which drifts.
Calendar events are tasks with a span and is_event, which is why there is
no separate table for them. There is no table for a message, which is why no
conversation can reach the record.
Every file a browser opens or sends crosses the company's asset bucket in
Supabase Storage, because the computer that holds the file is on another
network. The conversation and the workspace stay on that computer; the bucket
only ever holds a copy.
| Prefix | What it holds | Who reads it | How long |
|---|---|---|---|
<company>/shared/transfer/ | a messenger attachment copied for reading, named by its digest | the company | seven days |
<company>/person/<member>/transfer/ | a workspace file copied for its owner, named by its path, size and modification time | that member | seven days |
<company>/person/<member>/upload/ | a file the browser put there to send or to save | that member | until the host takes it, seven days at most |
<company>/shared/attachment/ | a file the messenger's own store refused, which the message names here instead | the company | for good |
The host deletes its company's expired copies once an hour. A copy is a cache, so losing one costs a second read from the computer that holds the file.
A person's memory
One SQLite file per subject, each in that subject's protected directory in the
workspace: private/protected/<personID>/memory.db for a person,
circles/<circleID>/.protected/memory.db for a circle, and
shared/.protected/memory.db for the whole workspace. A person's own file
holds what they said and what was said about them, a circle's file holds what
its members share, and the workspace's file holds what everyone shares. The
service writes every file, and the subject's group may only read it. A recall
runs as the reader's own Linux user, so the kernel decides which files open:
their own, their circles' and the workspace's. Data room documents are never
copied in; a recall asks the data room as the reader.
What a conversation says reaches a shared file only when the conversation's people are exactly that file's readers. A room the whole company is in writes the workspace's file, and a room of exactly a circle's readers writes that circle's. A room with anyone else in it writes neither, so nobody adds to a memory they cannot read and nobody reads one about a conversation they were not in. A message kept this way gets a 📝 reaction.
The agent's store
The host's own Postgres, defined in .dependency/blueclaw/migrations/. The
company host package installs and supervises Postgres with the rest of the host
services.
Its tables hold the conversation and its attachments, every run with its steps, events and schedules, the model calls a run made, the people and channel rules projected from the policy, and the audit log.
None of it is a company record. It is the agent's working state: what was
said, what it did, and what it is allowed to touch.
task_event is the ledger the rest of the system trusts: every tool call,
its full input, and every routing decision land there, which is what makes a
failed run diagnosable after the fact.
The relay's state
RELAY_STATE_DIR, which the package sets to /var/lib/internkim-relay, holds
what the relay must survive a restart with: inbound/, the messages the agent has not taken
yet, and questions/, the approval questions still waiting for an answer.
Both empty themselves as the work moves on.
Files
The workspace lives on the host, under the permissions described in
Boundaries. Private space per person, shared space per
circle, and a service-owned area the agent's own machinery uses. The skills
the agent loads ship in the package, from .dependency/internkim-plugin/, and
belong to no company.
Backing the host up is the company's job, and internkim backup does it every
day (Running the host says how). A company on several boxes also keeps a
snapshot sealed to its key off the box every fifteen minutes, which a standby box takes it over from
(Kim Mini). Losing the host loses the agent's memory,
its history, the files and any message still queued, and loses none of the
company's records. That asymmetry is deliberate: keeping the agent's memory
central would mean holding a company's internal knowledge on our side, the
thing this design avoids for messages and mail.