Strands

Time slices answer "what happened" along time. But the mind asks another way too: "everything we've ever said about that thing" — a question that cuts across time, not along it. Strands are the semantic layer built for that question: one keyword, woven through every slice that carries it.

How it works

Every slice carries tags in its frontmatter — keywords like wedding-speech or running. When a slice closes, those tags are woven into one global file: memory/episodic/strands.json.

Each key in that file is a strand (one tag); each value is the list of relative paths of every slice carrying that keyword — "the whole history of that thing," across time:

{
  "wedding-speech": [
    "2026/06/22/1400",
    "2026/07/01/0915",
    "2026/07/08/1630"
  ],
  "running": [
    "2026/06/22/1400"
  ]
}

The paths are relative, and each one walks you straight to a slice directory. A strand plus the slice paths it points to is the complete history of that thing — no more, no less.

Derived, not authored

There is no separate authoring step for strands. Tags are maintained by the turn analyzer during each turn's housekeeping — it reads the conversation, classifies the topic, writes the tags, and prefers reusing existing tags so the same concept merges across languages and phrasings. When a slice closes (and when an in-progress slice saves a snapshot), updateStrands weaves each tag into the index: append the path, deduplicate, write back.

The weave is merge-first: before a tag creates a new key, it is normalized (trimmed, ASCII-lowercased, full-width forms folded to half-width, inner whitespace collapsed) and matched against existing keys — so Apex and apex land on the same strand instead of splitting one topic in two. Only a genuinely new tag creates a new key.

Tags weave into strands. You never write a strand directly.

Keeping the index clean

An append-only index rots: typos split one concept across two keys, and a tag used once a year ago stays forever. So on every slice close, a consolidation pass (consolidateStrands) runs in two stages:

1. Deterministic pruning (always runs). Strands that never became threads are pruned — concretely, ones carrying very few slices, all of them stale. A strand survives with enough slices or at least one recent slice, so a genuinely new topic is never pruned on the day it appears. This stage needs no model.
2. A model merge pass (only once the index has grown past 25 strands). Normalization catches mechanical duplicates, but semantic duplicates — a typo in a name, the same concept under two names — need judgment. The model reviews the index and proposes a from→to merge map (at most 30 merges per pass, precision over recall: when in doubt, do not merge); the engineering layer then unions the path lists and drops the redundant keys.

The whole pass is defensive: any failure returns the index unchanged — a slice close never breaks because consolidation did.

How strands are read

The index is not write-only; it feeds every conversation through several paths:

• The memory-topics menu. The system prompt carries a Memory topics block: strands sorted by most recent activity, each annotated with when it was last seen. When you mention one of them, the main agent knows it is time to ask recall.
• The recall pipeline. The recall colleague receives the strand list up front and uses readStrand to trace a matching strand to every slice that carries it. Strands are recall's topic axis; timeline windows are its time axis. See Recall.
• The timeline projection. Every timeline reconcile resolves each entry's strand membership, so the timeline index itself records which strands pass through which slices.

Deliberately thin

Related

• Time Slices — the episodic record itself: what happened, by time
• The Timeline — the catalog on the time axis; strands are the topic axis
• Recall — the colleague who searches along both axes
• The Memory Model — where strands sit in the full memory architecture