The Clocktower, and the Day Grep Stops Being Enough

The brain is markdown, and for a while markdown is plenty. You open a sphere, you read a card, you grep for a name. Then the file layer outgrows you. You want to ask a question that spans a hundred cards. You want to search your emails, not just your notes about them. You want the assistant to come online already knowing who you are, without you loading a single file. That is the day grep stops being enough, and it is the day you add the index.

Lararium calls it the clocktower. It is the database half of the system, and its job is precisely the things a pile of markdown cannot do: semantic search at scale, relational queries over your tasks and goals, storage for the big cold corpora, and the watchers that ingest your life so the assistant arrives briefed.

It is also, deliberately, the layer you add last and only when you need it. The brain and soul run on nothing. The clocktower wants a database and an embedding key. You stand it up the day the file layer has proven itself, not before.

The index never replaces the brain

The single most important rule of this layer is the one people break first. Files are canonical. The index is an index on top of them. It makes the brain searchable and it holds the firehose the brain points at. It does not become the brain.

Which means: you do not copy your corpora into markdown, and you do not move your knowledge into the database. The card points at the corpus; it does not eat it. Your ten thousand emails live in the index as rows. The one thing you learned from an email thread lives in the brain as a card that points back at the thread. Cross the streams, dump raw data into cards or lift your durable knowledge into database-only rows, and you lose the property that made the brain worth building: that you can open it and read it.

The shape to reproduce

The architecture is four parts, and the template ships the map for each with the credentials removed:

• An MCP server. The interface the assistant calls to read and write the index: search, recall, remember, the session briefing, tasks, goals. This is how a language model actually touches your database, through a small set of named tools rather than raw SQL.
• A database with vectors. Postgres with a vector extension holds the relational state and the embeddings side by side.
• An embeddings standard, written down. Pick one model and one dimensionality and record it in a reference card. Everything embedded into the same space must use the same model, or similarity search silently degrades. This is the rule that bites hardest, because when it breaks nothing errors, the results just quietly get worse. Write it down and never drift from it.
• Watchers. The ingest jobs that watch your sources, email, messages, calendar, files, the brain repo itself, and feed new signal in. A brain-watcher pulls the brain from git before each pass, so an edit you push from any session lands in the index on the watcher's normal cadence.

The watcher pattern is worth internalizing because it repeats everywhere: read the last watermark, fetch what is new since then, deduplicate, insert, embed, update the watermark. And the discipline that makes it trustworthy: a no-op pass writes nothing. If there is no new signal, the watcher does not bump its watermark or churn embeddings. "The watcher is running" is not the same as "the watcher is producing," so every watcher declares a freshness SLA, the expected maximum age between successful runs, and anything past its SLA alerts. A pipeline that silently stops producing is worse than one that crashes loudly.

The four organs of memory

Most systems that build a memory layer build three organs and stop. Lararium names the fourth, because the fourth is where the magic actually is.

Intake is the watchers, pulling corpora. It is content-blind; it moves signal, it does not judge it.

Carding mines those captures into durable knowledge, turning raw material into general facts worth keeping.

Gating is a scheduled curator that judges staged cards before they go live, so the high-volume, low-density sources, the email threads and web captures, pass through a quality gate before the assistant can retrieve them. Intake is generous on purpose; the gate is what keeps generosity from becoming noise.

The connector is the fourth, and the one worth the whole layer. It is a daily job that reads only the new learning-material delta since its last run, your video transcripts, saved bookmarks, newsletters, meeting notes, through a lens of what you are currently working on, and emits a tiny number of high-precision "this idea maps to that live problem" connections. Nothing else in the system makes that join. Intake is content-blind. The carder mines general facts. The gate only judges what it is handed. The connector is the organ that notices the thing you read this morning is the answer to the thing you were stuck on last week, and tells you.

It has its own doctrine, earned on a real build whose reviews caught nine production bugs before it shipped, and the rules are sharp: a connection that does not name a live problem is a drop, not an output. Value decays with age, so it runs newest-first and throws away anything older than two weeks. And silence is a valid result: most days nothing maps to anything, and the correct emission is zero. An organ that manufactures a connection every day to feel useful is worse than one that stays quiet until there is a real one.

What you build versus what you copy

The schema, the tool surface, and the server config are the map, and they ship. The running server, the watchers, and the database are yours to stand up: this layer is infrastructure you operate, not code you clone. There is no database in the box and no row of anyone's data, by design. When you have it running, the template hands you a retrieval doctrine, seven production-earned rules, to walk as a checklist so your search is good and not merely present.

The order matters, so it is worth repeating: this is the layer you reach for when the file brain has outgrown grep. Not on day one. On the day you feel the file layer straining, which is exactly when the cost of standing up a database is worth paying.

Next in the series: the agents, and one assistant that dispatches a whole team.