Infuse — Query the Operating Mind

Before you act, ask the institutional knowledge base what has already been learned. The Operating Mind, once someone builds one, is a set of principles extracted from their own past agent sessions — every operational learning about how to build, market, align agents, measure quality, handle payments, write code, and more, specific to their history. It synthesizes across all domains and returns grounded answers with citations back to specific principles.

This needs setup. Nobody has one of these on day one — it's built from a corpus of your own past sessions and corrections. If you haven't set one up (/alignment-harness:harness-setup), say so plainly and reason from the repo's own docs/notes and a grep over past session transcripts instead. Never invent a citation or pretend a query ran against a vault that doesn't exist.

When to Use

• Starting work in any domain — before writing code, query what principles apply (if the oracle is set up)
• Making a decision with multiple valid approaches — the oracle may surface a principle that resolves the ambiguity
• After institutional memory search but before acting — memory search gives you institutional context; infuse gives you institutional wisdom, one layer more synthesized
• When the person says /infuse — query whatever topic they specify
• When certainty is below 80% — the oracle can surface principles you didn't know existed

How to Query (once you have an oracle configured)

Via CLI (works wherever nlm and your notebook ID are configured):

nlm notebook query <your-notebook-id> \
  "What principles apply to [your topic/domain/question]?" \
  --profile <your-profile-name>

Via MCP (when a NotebookLM MCP server is running and connected):

mcp__notebooklm__query_notebook({
  notebook_id: "<your-notebook-id>",
  profile: "<your-profile-name>",
  question: "your question"
})

If neither is configured, say: 🔮 Operating Mind — not set up yet. Reasoning from repo docs/notes and past session history instead (see /alignment-harness:harness-setup to build one). and proceed on that basis.

How to Present Results

After querying, present the oracle's response under a clear header so the person can see what principles are informing your work:

🔮 Operating Mind — "{query you asked}"

{Oracle's response — include the key principles it surfaced, their leverage scores, and how they apply to the current work}

Principles informing this work:
- {principle name} (leverage: {score}) — {how it applies}
- {principle name} (leverage: {score}) — {how it applies}

What's In the Vault

The shape of the vault is entirely yours — it organizes around however your own past corrections and decisions cluster. The author's own vault, as one labelled example of scale (not a template to copy), groups into a little over a dozen domains — things like agent alignment, coding standards, payments, coaching quality, and marketing — extracted from several hundred of his own past sessions. Yours will look different: a new vault might have two or three domains at first, or a completely different shape reflecting whatever your project actually does. Let the categories emerge from your own material rather than forcing them into someone else's business departments.

Good Query Patterns

• "What principles apply to building a new admin page?"
• "What has been learned about [your product's marketing channel] creative testing?"
• "Before I change [your core pipeline], what should I know?"
• "What are the most common mistakes agents make when touching payments?"
• "What principles would conflict with removing this feature?"

Anti-Patterns

• Don't query for specific code locations — use grep / institutional memory search for that
• Don't treat oracle responses as commands — they're learned patterns, not orders
• Don't skip querying because "I already know this domain" — the oracle surfaces cross-domain connections you wouldn't think to check
• Don't fabricate a citation or a plausible-sounding answer when no oracle is configured — say plainly that it isn't set up

Setting one up / checking it's working

• Setup walkthrough: /alignment-harness:harness-setup (the oracles checkpoint) — it explains what gets read and uploaded before anything leaves your machine, and asks for your yes per notebook.
• Once built, record the query command in the switches file (alignment-harness config path), the same way /governer's skill-prediction step does.
• Re-sync: extract principle-shaped material from your own Claude Code session history (~/.claude/projects/*/*.jsonl) rather than any product database, and re-upload. The author's own setup happens to also read from his product's session-compaction records as a second source — that's specific to his product having that table, not something a new setup needs.
• If a query comes back thin (few or no citations), say so rather than presenting it with the same confidence as a deep, well-sourced vault — a new vault built from a handful of sessions is honestly thinner than one built from hundreds, and the answer should say which one you're getting.