Three Surfaces Coexist

"They all retrieve text. That is the single most expensive sentence you can believe about them."

Three Things That All "Retrieve Text"

By the end of this build, three separate retrieval surfaces existed in the same family, and every instinct screamed to merge them:

The brain's own memory — embeddings over a personal vault and conversation history, used to load the right context into an assistant's system prompt and recall past exchanges.
The live co-writing path — embeddings over the notes you are working in right now, feeding model completions while you write.
The corpus engine — deterministic, citable retrieval over a decade of finished, historical writing.

All three take a query and return relevant text. Surely one of them could serve all three jobs?

They're Different Shapes, Not Different Sizes

Look past the interface and the differences are structural. The memory and co-writing paths are judgment-shaped: a model is in the loop by design, they're scoped to a conversation or an active document, and their whole purpose is to feed a language model. The corpus engine is engine-shaped: no model in the path, scoped to a permanent archive, and its purpose is citable results that outlive any conversation. Different lifetimes, different scopes, opposite stances on whether a model belongs inside. Merging them isn't consolidation — it's forcing one to wear the other's constraints.

What Merging Would Actually Cost

Trace it concretely. Fold the corpus engine into the memory system and the engine inherits conversation scoping and a model dependency — goodbye to search that works with the brain down. Fold the co-writing path into the corpus engine and live notes must be permanently ingested and content-addressed just to autocomplete a sentence you're still writing. Each merge takes a surface that was correct for its job and breaks it to fit a neighbor's assumptions. The similarity was always superficial; the constraints were never compatible.

Cost is absorbed downstream, never pushed upstream. When two components look similar, the temptation is to unify them 'to reduce duplication'. But if their constraints differ, unification doesn't remove cost — it relocates it, usually onto the component that was fine. The right move is to let each surface pay its own costs and keep the seams honest. Three clean surfaces with a documented boundary beat one merged thing that serves nobody perfectly.

The Boundary Is Written Down, Deliberately

Because this instinct recurs — someone will always propose "why don't we just unify all the retrieval?" — the boundary lives in a table in the architecture doc, not in anyone's head. Which surface owns which corpus, does which job, has which constraints. The table exists specifically so that the next person to have the unify idea reads why it was rejected before spending a month on it. Writing down why you didn't merge is as valuable as documenting what you built.

Code

Same-looking signatures, incompatible constraints·python

# Three surfaces. Same-looking interface, incompatible constraints.

# 1. The brain's memory — judgment-shaped, conversation-scoped.
def recall_for_prompt(conversation_id: str, query: str) -> list[str]:
    ...  # feeds a system prompt. Model in the loop by design. Ephemeral scope.

# 2. Live co-writing — judgment-shaped, document-scoped, right-now.
def cowrite_context(active_note: str, cursor: int) -> list[str]:
    ...  # embeds notes you're editing THIS MINUTE to feed completions.

# 3. The corpus engine — engine-shaped, archive-scoped, permanent.
def search(query: str, mode: str = "hybrid") -> list[CitableResult]:
    ...  # no model in the path. Citable. Must work with the brain down.

# Merge #3 into #1 -> the engine inherits a model dependency and conversation
#                     scope. Search no longer works when the brain is down.
# Merge #2 into #3 -> a note you're still typing must be permanently ingested
#                     and content-addressed just to autocomplete a sentence.
# The interfaces rhymed. The constraints never did.

Exercise

Find two components in a system you know that look similar enough that someone has suggested merging them. For each, write down its constraints: latency budget, scope, lifetime, dependencies, failure tolerance. Compare the lists. If they differ meaningfully, write the one-paragraph 'why we didn't merge these' note that would save the next person a month.

Hint

The decisive question is never 'do they look alike?' but 'do they honor the same constraints?'. Two things with the same signature and different constraints are two things. Document the constraint mismatch — that's the artifact that actually prevents the bad merge later.

Three Things That All "Retrieve Text"

They're Different Shapes, Not Different Sizes

What Merging Would Actually Cost

The Boundary Is Written Down, Deliberately

Code

External links

Exercise

Progress

Comments 0