SwarmMarshal
Per-source deletion semantics
Each source kind declares what happens when its source dies: tombstone the derived data, cascade-delete it, or preserve a snapshot. Deleting a message can never leave a dangling citation.
Technology deep dive
The context engine: every fact knows where it came from.
An assistant over your life's communications is only as good as its memory discipline. SwarmMarshal treats knowledge as an engineered subsystem: one ingestion funnel for every source, provenance stored on the row, a graph you can walk, and gates between "a message said this" and "the system believes this."
Citations that survive deletion.
Every durable derived record — facts, memories, summaries, dashboard tiles — carries a canonical SourceRef: kind, account, record id, title, excerpt, and observed-at. It's stored on the row itself, not reconstructed later.
Deletion observers
Every writer of source-backed data registers an observer, so cleanup is enforced at the data layer — not left to whichever feature remembered to handle it.
Quotes kept separate
Exact quotes are stored apart from inference. An answer can show you the sentence it stands on, and a claim that can't produce its quote doesn't persist.
One funnel for every source.
Email, chat, calendar, tasks, contacts, and user-built Vibes apps all project into the context engine through a single contributor abstraction — each source feeds both plain context facts and the knowledge graph through the same path.
Retire-then-emit reconciliation
A contributor owns all facts of its source kind and reconciles by retiring and re-emitting — gated by a cheap per-source fingerprint cache so unchanged sources cost nothing. Multi-source contributors are scoped so one source can never wipe another's facts.
Cross-channel identity
The person who emails you, Slacks you, and appears in your calendar resolves to one identity, so their graph neighborhood and history are unified rather than siloed per channel.
A local graph with pre-built neighborhoods.
People, companies, topics, and projects become nodes and edges in a thread-safe in-memory graph backed by local SQLite. A background pass incrementally builds per-entity "neighborhoods" — the subgraph plus an LLM-written summary — so related-message retrieval and person context are a lookup at question time, not a graph traversal under latency pressure.
100% local — no graph leaves your machine
Temporal fields keep source time, not ingestion time
Kept consistent by deletion observers
Consumers get a context pack, not a mailbox dump.
The assistant, helper agents, peer devices, and external MCP clients all request a ContextPack — ranked items, bound sources, a policy block (privacy class, redaction level, sharing scope), and a token budget. The engine owns retrieval, ranking, compression, and redaction; no consumer assembles memory ad hoc.
Vector search that obeys the same rules as everything else.
HNSW index, hot-swappable
An approximate-nearest-neighbor index (Hierarchical Navigable Small World) sits behind a decorator that transparently indexes any memory store, with background maintenance and rebuild — semantic recall at local-machine speed.
Router-backed embeddings
Embeddings route through the same function-aware LLM router as chat — provider pinning, cost policy, and the embedding-model pin all apply, so vector space can't silently fragment across models.
A message saying it doesn't make it true.
Unverified inbound claims land in a holding table. Promotion to durable memory requires user-authored, trusted-contact, or corroborated status — and rejected claims are suppressed so the system doesn't relearn them from the next newsletter. A weekly reconciliation pass marks stale claims, escalates contradictions for review, and journals what it did.
The same engine can learn an unfamiliar database.
The context engine's discovery layer powers more than the inbox: it builds a knowledge graph of a running application by extracting structure from the database schema and business rules from the codebase, picks the relevant "anchor" tables for a natural-language question, and synthesizes query hints the way a developer investigating an unfamiliar system would. This is the machinery behind the CRM's plain-English data agent.
Keep reading
Where the facts come from, and what reads them.
The message pipeline is the biggest fact producer; the assistant and MCP server are the biggest consumers.