Essential Infrastructure

What the minimum loop actually needs · ← back to dashboard
2026-04-20
Jacob's stated essentials: (1) a bot on a sync/async channel and (2) an LLM wiki (graph or markdown). Those are right but incomplete. The minimum working loop needs five components — without any one of them, the system breaks.
The Minimum Loop
Write path: raw content → structured memory
SourceMeeting audio
Chat messages
Docs
CaptureTranscription
Ingestion
(Otter / Granola / API)
Writer AgentExtract · Route · Merge
into wiki pages
PERSISTENT MEMORY LLM Wiki (Noos graph / Karpathy markdown)
Read path: current context → right memory surfaced back
Interaction SurfaceBot (Slack/iMessage)
Outliner UI
Ambient display
RetrieverContext-aware
semantic + graph lookup
Wiki(same wiki
as above)
Every product track reuses this same loop. The differences are which interaction surface and what input source.
Components by Tier

Tier 1 — Essential

Remove any of these and the loop breaks.
Interaction Surface Jacob noted
Bot on sync/async channel (Slack, iMessage, WhatsApp, email). Generalizes to UI/display for tracks 3–5 (outliner, ambient display, Note Stream).
LLM Wiki Jacob noted
The persistent memory. Structure-agnostic — Noos graph, Karpathy-style markdown corpus, or hybrid.
Scope decision on dashboard: wiki-hub vs Noos graph. Architecturally both satisfy this slot.
Capture / Ingestion
How raw content gets in. Meeting transcription (Otter / Granola / Gemini / own) plus chat-history ingestion.
This is where the "build own note app vs. integrate" fork lives. Architecturally it's one slot; strategically it's "do we own this layer or rent it?"
Writer Agent
Turns unstructured transcript / messages into structured wiki updates. Routes action items → task list, gripes → relationship page, vision → vision doc. Maintains consistency across pages.
The hardest technical piece and the biggest moat. Not summarization — routing and consistency. Everyone can generate a summary. Almost nobody updates an evolving structured KB well.
Retriever
Context-aware lookup. Not generic RAG — knows which wiki entries are relevant to the current Slack thread, meeting, scheduling request, gripe moment.
"Hey you didn't respond for 3 days, this is an instance of the existing gripe" requires retrieval that understands this moment, not just "find similar text."

Tier 2 — Important, Deferrable

Not needed for v0, but you'll feel the pain fast without them.
Background Worker
Periodic scans for patterns: "person X hasn't responded for N days," weekly summarization, vision-doc rollup, stale-wiki-page detection.
The "3-day no-response" pattern detection literally requires time-aware background scanning — it's not triggered by a user action.
Provenance / Citations
Every wiki claim links back to the source meeting / message / document that generated it.
Without this, the wiki becomes un-auditable. When it's wrong (and it will be), users can't fix it because they can't find where it came from.
Versioning / Undo
Wiki will be continuously AI-written. Need diff history, rollback, and per-edit attribution (human vs agent).
Trust UX layer
Visibility rules, consent flow, expiration, correction workflow — especially for the gripes / conflicts / patterns feature.
Codex's warning: the gripes feature is socially dangerous. Get this wrong → product feels creepy or politically explosive. May be the real moat, not the graph structure.

Tier 3 — Track-specific

Only needed for particular product tracks.
Privacy / Consent Layer
Cross-privacy scoping. "Can you share your availability on this date?" → user clicks approve.
Essential for Track 2 (Group Chat Bot). Not needed for B2B team wiki where everyone already has shared context.
Agent Execution Environment
Private server running coding agents (Claude Code / Codex) that can spawn from prompts — "hey AI go build that node."
Essential for Track 6 (Better GPT) and the "spawn agent per note" feature in Track 5 (Note Stream). Not needed for the core wiki loop.
Identity / Relationship Model
Per-person pages, relationship graph, role inference. Baked into the wiki schema.
Essential for the gripes/conflicts feature. If skipping that, the wiki can be person-agnostic.
Real-time Streaming
Sub-second transcription + retrieval + render pipeline.
Essential only for Track 4 (Ambient Display). The rest of the system can be batch / near-real-time.
Open Architecture Questions

The Big Forks

Q1. Wiki structure: Noos graph vs. markdown corpus vs. hybrid? Affects writer complexity and retrieval surface.
Q2. Writer agent: one-shot LLM or multi-step pipeline with explicit routing rules? Quality vs. predictability tradeoff.
Q3. Retriever: semantic embeddings, graph traversal, keyword, or hybrid? Depends on wiki structure.
Q4. Capture: own it (custom outliner) or rent it (integrate Otter/Granola)? Strategic scope decision.

What's Easy to Get Wrong

W1. Treating the writer as "summarization." It's not. Summarization loses structure; the writer must preserve and extend structure.
W2. Treating the wiki as write-only. The retriever must be designed alongside the wiki schema — they're dual.
W3. Skipping provenance. Debugging AI-generated KB rot is impossible without source links.
W4. Shipping gripes feature without trust UX. One bad moment → product dies.