oll.am's whole elegance is one sentence: frozen infrastructure, disposable products. A product is a thin, throwaway client; the durable value lives in a handful of spines that are built once and never touched again. Today two spines are live and frozen — and there is a third, more valuable than either, that is already mostly built but hasn't been named as infrastructure yet.
Identity and Model, together, get you a competent generic assistant: it knows who's paying and it can call a good model. But its output is the same output every other wrapper produces — generic prose from a generic model. The moment you add a Memory spine, every product can answer from the customer's own documents, with citations. That is the difference between a demo and a thing people pay for repeatedly. This doc extends the ten-option survey in Beyond the Wrapper and the frozen-spine architecture in The Platform — it doesn't restate them; it argues which extension matters most and why it's closer than it looks.
The reason to lead with Memory isn't that it's a good idea — it's that it is already ~90% built. It is not theoretical. It's sitting on a branch and running inside one product, waiting to be promoted from “a thing ollwrite uses” to “a frozen platform service every product uses.”
An oll-memory service sits on an unmerged branch (daf6d7a feat(oll-memory): consolidate ingest+rag+extract). Stack: LlamaIndex + pgvector + nomic-embed-text embeddings; hybrid dense+keyword retrieval fused with RRF; generation delegated to the Model spine.
The ollwrite (Next.js) product already drives it via a server-side BFF (src/app/api/memory/*) with seven capabilities: ingest, search, chat, draft, verify-claims, suggest, and voice-profile.
The browser never sends a collection, ACL, or token. The BFF resolves userId from the Core JWT and derives collection: mem:user:{userId} + acl:[u:{userId}], injecting a service token server-side. A user cannot name another user's corpus — it's architecturally impossible.
A relevance floor (dense cosine ≥ 0.5) drops noise; on a miss the system abstains (abstained:true) instead of fabricating a citation. A claim with no above-floor source is never sent to the model. Inline [n] nodes are drag-to-cite, click-to-focus, and round-trip through markdown export — the citation trust loop.
A public, read-only “bible” workspace (server-side allowlist) is CiteBible — the same engine, rebranded per vertical, with zero code duplication. The corpus is a flag, not a fork.
ingest (paste/PDF → chunks) · search (semantic) · chat (grounded answer with [n]) · draft (bullets → cited paragraphs) · verify-claims (audit a draft → trust chips) · suggest (source guide) · voice-profile (“write in my voice” learned from the corpus).
Sam's brief was to do something more valuable for customers — not more elegant for its own sake. Memory wins on customer value four ways, and each is concrete:
| Reason | Why it matters to the person paying |
|---|---|
| It's not a commodity | Generic LLM output is free and everywhere — every tool has it. Output grounded in the customer's own documents, and cited, is something people pay for repeatedly and trust. That's the line between a toy and a product. |
| It's sticky | A personal corpus is a switching cost. Once your knowledge lives in it, leaving means abandoning it. Stateless tools have no retention moat; a memory does. |
| It composes with everything | ollwrite becomes “write from your knowledge”; the oll.in career agent drafts a CV / cover letter grounded in your real experience docs, cited — the actual magic that makes it personal instead of generic; CiteBible is already a product; any vertical (legal / medical / study / “second brain”) is one workspace flag away. |
| It fits the pay-once story | “Your knowledge, your corpus — pay once, it's yours.” A personal corpus is exactly the kind of durable, owned asset the oll.am positioning already promises. |
Memory doesn't just stand alone — it multiplies the other extension on the table. The sibling doc, The Agent Seam, plans an MCP surface so an external agent runtime can drive oll.am's capabilities. Put the two together with oll-write and you get something neither has alone:
This is the elegance argument restated as a product argument: the same frozen-spine discipline that lets a new product ship in a weekend also lets a new capability — memory — light up every existing product at once. Add the spine, and ollwrite, CiteBible, and the career agent all get grounded output for free.
Sam asked to go back over the initial research and explore other options too — not just land on the favourite. Here's the honest ranked field, with each row's real build-state in the repo today. The two ★ rows are the near-term movers; the rest are sequenced behind them.
| Primitive | What it unlocks | Customer value | Build state today | Effort | Verdict |
|---|---|---|---|---|---|
| Memory spine oll-memory |
Grounded ollwrite · cited career apps · CiteBible · any knowledge-vertical | HIGH personal + cited + sticky |
~90% BUILT — branch daf6d7a + wired in ollwrite; CiteBible proven |
LOW–MED promote branch → frozen svc, own Neon oll_memory |
★ DO FIRST — the elegant completion. |
| Structured extraction oll-extract |
Any input → typed JSON (receipts→CSV, forms/contracts→data) + RAG ingestion of messy PDFs | MED–HIGH | BUILT — 33 tests, on feat/oll-extract (32b4321), unmerged, awaiting your call |
LOW a merge decision |
★ MERGE — the ingestion sibling of Memory. |
| Credits / usage ledger on Core |
Pay-once credit packs across all products · guest credits · lower barrier to the first dollar | HIGH monetization |
STUB — usage.py in-process dict, per-replica, resets on restart (ADR-018 proposed) |
MED durable ledger row on Core |
DO ALONGSIDE — the monetization companion to Memory. |
| MCP gateway agent seam |
oll.am callable inside Claude Desktop / Cursor · the career agent · monetized via the billing spine | MED enabler |
PLANNED — spec'd in the sibling doc | LOW–MED thin wrapper |
COMPOSE — an agent that reads your corpus. |
| Async jobs primitive | Heavy / agentic work — headshots, agent runs, batch rewrites | MED | INLINE only — ADR-014; foto uses a SQLite job store | MED | DEFER — until load demands (ADR-014 stands). |
| On-device Vault WebGPU + local store |
“Nothing leaves your machine, pay once forever” — a local memory store is the on-device twin of the spine | HIGH moat, but later |
VISION — Phase 2; provider swap already coded in the Model spine (arch) | HIGH | PHASE 2 — and the Memory contract makes it a swap, not a rewrite. |
Promoting Memory is a packaging job, because the behaviour already exists and is proven. It's the same lift-and-freeze move that turned specview's modules into the Core spine — additive, respecting the frozen services, no existing service edited in place.
oll-memory — its own Coolify app, Base Directory /services/oll-memory, with its own Neon DB oll_memory (pgvector) per ADR-008 — remote Neon, never a local Postgres, even for dev.mem:user:{userId}), a service token between each product's BFF and oll-memory, plus the relevance floor and abstention. The security surface doesn't change; the browser still never names a corpus.openapi.yaml slice as the single source of truth, gated by Schemathesis in CI per ADR-009, exactly like Core and the Model spine.oll-extract alongside as the ingestion / extraction endpoint family — messy PDFs and forms become clean chunks and typed JSON, feeding the same corpus.The house guardrail is explicit: Phase 0 is the first stranger franc, and nothing net-new starts until it closes. So the fair challenge to this whole doc is: isn't promoting a Memory spine exactly the infrastructure-before-income pattern you're supposed to resist? Here's the honest answer.
So the recommended sequencing keeps both truths:
| Track | Move |
|---|---|
| (a) Keep closing the franc | with what's already live — CiteBible's ignition, the humaniz money path. This stays P0; nothing here jumps that queue. |
| (b) Promote Memory as the near-term platform completion | because it's built and it's what makes the products worth paying for. Low incremental effort, high customer value — the definition of a good next move. |
This is a propose-then-decide, not a done deal. The recommendation is clear; the call is Sam's.
oll-memory (branch daf6d7a) to a frozen platform service now? recommended — the elegant, high-value, mostly-built completion of the three-spine picture.oll-extract (feat/oll-extract, awaiting your call) as the ingestion sibling? — messy input → clean chunks + typed JSON, feeding the same corpus.