Room: topic-specific storage inside a wing

A room is a topic-scoped store inside a wing.

export interface Room {
  id: string; wingId: string;
  slug: string; name: string;
  topic: string;
}

Why topic, not time

The obvious way to organise agent memory is chronologically — what happened, in order. It is also close to useless at recall time, because the question is never "what happened on Tuesday". It is "what do we know about authentication".

The room is that answer. topic is the field recall matches against, and everything else in the model hangs off it: drawers belong to a room, closets summarise a room's drawers, and halls connect one room to another.

The granularity problem

Rooms are the hardest part of the model to get right, and the failure is bidirectional.

Too coarse — one room per repository — and recall returns everything, which is the undifferentiated store the wing was meant to avoid.

Too fine — a room per file — and related knowledge scatters across dozens of rooms that only a hall can reconnect, so recall depends entirely on the relation graph being complete. It never is.

The model does not solve this. It provides the structure and leaves the judgement to whatever populates it, which is honest but worth knowing before you assume the schema is doing more work than it does.

What a room is not

It is not a document, and it is not a file. Several files can inform one topic and one file can touch several, so mapping rooms onto the filesystem loses exactly the structure the model exists to capture.

Reading a room

Recall does not read a room directly. It reads the closets that summarise it, because a room's drawers hold verbatim content and including those would spend the whole budget on one topic.

So the room is the addressing unit — the thing a query resolves to — while the closet is the thing that gets read. Keeping those separate is what lets recall stay inside a token budget while the store itself grows without limit.