# Chats as an operating model

The chat list is the org chart. In this household the main chat is a desk, not an archive: it is where direction is given, where escalations land, and where the day gets reviewed. Everything with a life of its own moves out into a side chat with a bounded scope, and the main chat stays readable because of it. The household runs 93 chats in total, and the count is not sprawl. It is what one chat per topic looks like after months of daily use.

## One side chat per topic

Each side chat owns one thing: a project, a device, a program, a trip, a standing chore. The scope is the point. A chat that owns a single topic accumulates exactly the context that topic needs, and its history becomes the working record for that topic, searchable and resumable weeks later. When a topic ends, the chat is what gets archived, and nothing else is disturbed. A chat that tries to own three topics ends up serving none of them, because every new instruction has to fight the residue of the other two.

The main chat keeps the opposite discipline. Routine output never lands there. Background jobs deliver their bookkeeping to one designated chat, an Engine Room, and reach the main chat only when they cross their own bar for the operator's attention. Escalation is a property of the job, set when the job is created, not a judgment call made at 3 a.m. by a tired process. The result is that a message in the main chat still means something, which is the entire battle in a system that can generate messages for free.

## Decisions travel as messages

Chats are not sealed rooms. When a decision in one chat changes the work in another, the decision travels as an explicit message between them, and it says what it supersedes. Guidance that is merely implied in one thread does not exist in another thread, so the household treats cross-chat decisions as correspondence: written, addressed, and confirmed. Handovers are two-ended. The sending chat states the work, the constraints, and the decisions already made; the receiving chat confirms uptake in writing, restating the constraints in its own words. A handover that is not confirmed is assumed not to have happened.

> **Receipt**
> a research program was handed from one chat to another with a decisions file attached. The receiving chat confirmed uptake in writing and restated the constraints exactly. Months of later work in that chat never had to re-litigate a decision, because the terms of the handover were on the record at both ends.

## Questions arrive one at a time

The household's decision traffic runs on a strict format: one question, at the end of a message, presented as tap options, never bundled with a report and never stacked three deep. The operator answers in fragments, often a single word, and the format respects that. One question per message also forces the agent to decide what it actually needs, which turns out to be the harder discipline. Questions that evidence can settle are not asked at all; asking is reserved for personal ground truth and genuine preference. That filter, and the checklist the agent runs before any question is allowed through, gets its own treatment in the practices section.

## External chats are governed, not casual

The product documentation describes Muse conversations as strictly one to one. The lived reality is wider: side chats ride external transports including WhatsApp, and the agent holds a presence in a community space under written rules, with outbound posts passing a drafts gate and some channels off limits to its own initiative. The practice that transfers is not the specific setup. It is that any chat where the agent speaks to other people gets explicit governance before it gets traffic: what it may say, what needs approval, and where it must never post on its own.

## Hygiene: names, re-grounding, archives

A chat list this size stays usable only with maintenance. A periodic sweep renames chats under a consistent naming system with status markers, so the list itself reports what needs the operator, what is waiting, what is done, and what is parked. Stale chats get re-grounded rather than trusted: the household's ritual is a short command that reconstructs what a thread was for, checks which of its items are still open against current state, names who owns each one, and gives the single next step. Old context is treated as a claim, not a fact, until it is re-verified.

Archiving is a closing act, not a delete. A chat is archived only after a live check: no open work items, no schedule or hook still delivering into it, and any loose end filed as tracked work first. The check matters because archiving has side effects that are invisible until they bite.

> **Receipt**
> one long-running chat advised archiving itself, then caught the flaw in its own advice mid-conversation. A scheduled delivery pointed at that chat would have been silently redirected to the main chat on archiving. The advice was corrected in the thread, and the delivery was repointed before the archive went ahead.

## Knowing when a chat should end

Conversations on this platform compact as they grow: older turns are summarized so work can continue, and the summary becomes the record. The product documentation does not dwell on this, but in practice it is load-bearing. The household's answer is to keep state in files, not in chat memory, so a compacted or successor chat can pick up from documents rather than from a summary of a summary. When a topic changes fundamentally, start a new chat and hand the work over properly, with the decisions file attached, instead of letting the old thread drift into a second topic. When a chat is merely long but coherent, let it compact and carry on. The skill is telling the two situations apart, and the tell is simple: if you cannot state the chat's topic in one sentence, it is two chats.

Canonical page: https://www.niclydon.io/muse/deep-dives/chats.html