A typical search returns 32 results. As full content, that could be 3,000–5,000 tokens. As previews, the same 32 results fit in roughly 400 tokens. The AI reads all 32 previews, picks the ones it needs, and retrieves only those. The difference compounds across a session — an AI that makes five searches saves 15,000–25,000 tokens compared to a system that returns full content every time.

Behavioral preferences skip this system entirely. They're always injected in full because they affect every turn regardless of topic. But they're budget-capped (approximately 500 tokens for preferences, 200 for user-tagged facts) so they don't crowd out working context.

The search runs through the same pipeline as memory_search — full vector retrieval, cross-encoder reranking — but with two differences:

• Auto-expansion: The top 3 results with a relevance score of 75 or above are returned with full content, skipping the preview stage. High-confidence matches are immediately usable without a follow-up retrieve call.

Noise filtering prevents the AI from wasting the search on generic queries. If the AI passes something like "general preferences" or "recent memories" (queries composed entirely of meta-words), the search is skipped and the AI is told to use specific topic nouns instead. This catches a common pattern where AI models reflexively search for vague terms on their first turn.

Deduplication removes behavioral preferences that were already injected earlier in the response. If a preference appears in both the auto-loaded preferences and the search results, it shows up once.

Topic counts and recency data are maintained in a pre-computed index that updates as memories are added, edited, or deleted. The init call reads this index directly — it does not scan the full corpus at query time. If the index is missing or corrupted, the system falls back to a live aggregation query and schedules an asynchronous rebuild. The rebuild runs in the background without blocking the init response.

Task counts within macro-topics come from the same index. When a task is created with macro_topics: ["gnosis"], the count increments. When it's marked done, the count decrements. The AI always sees current numbers.

Several design choices reflect specific constraints:

• Behavioral preferences are always injected; domain preferences are not. A preference like "no preambles" affects every turn. A preference like "use tabs in Python" only matters when writing Python. Injecting every preference would waste tokens in most sessions. Behavioral preferences are identified by a behavioral tag and budget-capped so they fit regardless of how many exist.
• Tasks use adaptive display. Zero tasks: a feature hint pointing to task_feed. One to five tasks: all shown with progress. More than five: the three most recently updated, plus a count and direction to task_feed. This prevents task-heavy users from having their init response dominated by a task list.
• Signals are peek-only. Early versions consumed signals during init, which silently cleared them when init was called in contexts where the AI wasn't going to process them. Peek mode means signals persist until explicitly acknowledged.
• Paths require a machine_id. Workspace paths are machine-specific. Injecting paths for a different machine would confuse the AI. When no machine_id is provided but paths exist, the response includes a hint telling the AI how to get the hostname and pass it next time.
• Collections are resolved to display names. Internally, collections use slug identifiers. The init response resolves these to human-readable display names so the AI can refer to collections by the names the user chose.