It is a Sunday afternoon in July, and Felix is sitting in front of a grey box that hums softly beside his router in the living-room cupboard. The box is a NAS (Network Attached Storage, a small always-on storage server for the home), and on it sit three terabytes of his professional life. Proposals, contracts, minutes, scanned invoices, photos of whiteboards, a handful of Excel files that someone started years ago and never finished. Everything there. Nothing findable. Next to it, mostly in sleep mode, stands a Mac mini with an Apple Silicon chip, which Felix will need later for the compute-intensive tasks, but we will get to that when the time comes.
Anyone who read the first episode of this series already knows Felix. Back then he spent four hours searching for a presentation he had given years earlier, the one with the image of three nested circles, and could not find it, because his operating system’s full-text search indexed every word but understood none of them, and the folder structure he had followed had changed three times since the file was saved.
And because this is meant to be an honest piece, I should say upfront: we are not actually tinkering with Felix’s NAS today. This article is the blueprint, not the finished building: the map on which every station is marked, with the decisions at each fork in the road and the traps that have caught others. The implementation follows in the next part; this is where the thinking happens.
Why Everyone Suddenly Wants This (and Almost Nobody Gets It Right)
Before we start, briefly the question: why is this even an issue? The software firm Atlassian surveyed around 12,000 knowledge workers and 200 executives in 2025 and found that teams spend on average a quarter of their working week purely searching for information. At the same time, according to the consultancy McKinsey, 88 percent of all organisations now claim to use AI in at least one function, yet only 7 percent have actually deployed it broadly across their operations. Between “tried it once” and “our AI knows our business” there is a gap that almost everyone falls into. The reason is rarely the model. It is the knowledge the model can access.
This is the point at which the term everything revolves around enters the picture: RAG, short for Retrieval Augmented Generation. Rather than feeding an entire three terabytes into a language model every time a question is asked (which is technically impossible and would be expensive), you first build a meaning index. When a question is asked, the system looks it up there, pulls out the three or four genuinely relevant passages, and presents only those to the model, which then has real evidence as a foundation and can base its answer on it. This does not prevent hallucinations entirely; which is why citations and Felix’s test set are essential later on. The conceptual tour through this principle is in the first article; here we focus on the architecture.
A word on the title, because it draws a deliberate contrast. For years, the term “Second Brain” has haunted the productivity scene: the idea that if you only file everything neatly in Obsidian, Notion, or another note-taking app, you have a second brain. Anyone who has tried this knows: what you mostly get is a second chaos. Storing is not the same as retrieving. The path from Second Brain to real knowledge management runs precisely across this difference. Already in 1945, American engineer Vannevar Bush articulated the real problem: not storing knowledge, but creating a retrievable connection. That is exactly what RAG addresses.
What such a personal knowledge store looks like when connected to a chatbot is what the second episode of this series showed through the example of Mark, who connected his Obsidian store to a small bot in the boiler room and queries it via Telegram. Felix’s task is the other half: the archive problem. At the end, we will tie both threads together.
Before Any Tool Gets Installed: Tidy Up
There is a temptation with projects like this to start immediately: install software, pour documents in. Felix resists it, and that is the first smart decision. A RAG pipeline is only as good as what goes in at the front. So he starts with an audit.
His Synology NAS runs a built-in tool called Storage Analyzer that generates a report: which file types are stored where, how many are duplicates, which folders are bloated. For hunting down duplicates he uses a small, fast command-line tool called fclones, but, importantly, exclusively in read mode. Backup first, check, then perhaps delete later. A RAG system that trips over half-ghost files and triplicate drafts will give confused answers later.
More important than tidying up, however, is the second exercise: sorting by confidentiality. A simple traffic-light system from the Mark article is something Felix borrows and reuses here. Green means harmless personal documents, which may run locally or even through a cloud service. Yellow covers customer and personal data, which Felix processes exclusively on-premise. Red is everything that must not leave the house, and it does not go into the pipeline at all.
There is more behind this than caution. The German data protection authorities have set out some principles in their guidance on AI and data protection that pay dividends here. Two are decisive for the build. First: the permissions of a source document must be preserved all the way to the displayed answer. A shared search index must not “forget” that a particular file was only meant for the accounts department. Second: if a document is deleted from the original, that deletion must propagate everywhere: to the text chunks, to the vectors, to the caches. For backup copies this is a matter of the retention cycle, not immediate access. Anyone who does not plan for this from the outset is building a data-protection problem that will be nearly impossible to untangle later.
Station 1: OCR. From a Photo of Text to Text
Here we go. The first station of the pipeline is the one that gets glossed over in most RAG explanations and yet carries everything: OCR (Optical Character Recognition, the machine conversion of images into machine-readable text).
Why is it needed? Because Felix’s archive is not made up of clean text files. There are scanned contracts, photos of whiteboards, PDFs with two-column layouts and tables that run across the page. A language model can do little with a scan that is essentially just a photo of letters. So every document is first translated into clean, structured Markdown (a simple text format in which headings, lists, and tables are marked with straightforward characters).
This is where Felix makes his first real decision, and it follows the traffic-light logic. For the cloud option there is Mistral OCR from the French AI company Mistral, now in its fourth version. It is good, fast, and cheap, at roughly 1.75 to 3.50 euros per thousand pages, depending on whether you are in a hurry or use the cheaper batch mode. But the documents leave the house. For Felix’s green documents that is fine; for the yellow ones it is out of the question, and the red ones never enter the pipeline at all. And the fully self-hosted version of Mistral is an enterprise offering with an individual contract, and not an option for the living-room cupboard.
For the yellow documents he therefore needs local tools, and in 2026 there are pleasingly good ones. His workhorse will be Docling, an open-source project from IBM Research under the permissive MIT licence. Docling is less a pure text recogniser than a document understander: it handles document structure and reading order even on multi-column pages, preserves tables, and delivers clean Markdown at the end. For scanned pages it uses, depending on configuration, a local character recogniser such as Tesseract or RapidOCR, both time-tested with decent German recognition. Digitally created PDFs where the text is already embedded take the fast route via a lean extraction tool with no OCR at all.
A detail Felix only comes to appreciate later: he has his pipeline note, alongside each text snippet, which file it came from and which page. Without these footnotes his system could later give answers but not say where they came from. An answer without a source is, for contracts, roughly as valuable as a rumour.
To try it out, Felix runs two old scanned invoices through Docling. The first comes out cleanly. The second gives him pause: a table with line-item prices is shifted by one column: unit price and total price are swapped in the Markdown. Exactly this kind of error is the reason why the audit and a verification step are not bureaucratic luxury. A misrecognised value will later be cited with the same self-confidence as a correct one.
An honest limitation here: handwriting. For Felix’s photos of whiteboard notes in his own hand, the locally practical tools do not yet deliver quality he can rely on. He notes these files in a separate list for later: either for a dedicated handwriting recogniser or for manual transcription.
Station 2: Chunking. The Art of Cutting at the Right Moment
Now every document exists as clean Markdown. But a 40-page manual is not placed into the index as one chunk, not because a model cannot handle that much text (it can, and we will come to that later), but because a single giant chunk is useless for search: it dilutes every meaning into mush. It has to be cut, and this cutting is called chunking (dividing a text into smaller, self-contained pieces: the chunks).
This sounds trivial but is the point where many self-built systems quietly fail. Cut too coarsely and three topics end up in one chunk, blurring the meaning. Cut too finely and a sentence loses the context that makes it comprehensible. The definition of a contractual term may be on page 5; it is used on page 47. Cut carelessly and the system never finds both passages together.
Many guides circulate a rule of thumb: a thousand characters per chunk, a hundred characters of overlap with the next. As a starting point that is workable, but the number is worth treating with scepticism. A thousand characters in German, depending on the text, is only about 200 to 300 tokens (the small word and syllable units in which a language model computes). There is no universal ideal value. Those who want quick factual answers often do better with smaller chunks; those looking for analytical connections do better with larger ones.
There is an elegant refinement that Felix keeps in the back of his mind, even though he does not implement it immediately. Anthropic’s research team showed in 2024 that retrieval accuracy improves significantly if each chunk is prefixed, before storage, with one or two sentences of context: a kind of mini-summary revealing what the overall document is about. In their own test corpus this reduced the number of failed retrievals by 49 percent in combination with lexical search, and by 67 percent with subsequent reranking. These numbers should be read correctly: they are the relative reduction of misses on specific datasets, not a guarantee for Felix’s archive. And it is not cheap: the additional context must first be generated for every single chunk; clever prompt caching lowers the cost but does not eliminate it, and with half a million chunks that is a noticeable item in the initial indexing bill.
Station 3: Embeddings. How a Machine Pours Meaning into Numbers
Now comes the part that feels most like magic yet is pure mathematics. Every text chunk must be put into a form with which a machine can calculate similarity. That form is an embedding: a long list of numbers (a “vector”) that positions the meaning of a text in a mathematical space.
The trick: texts with similar meaning receive similar number lists and lie close together in this space; texts with entirely different content lie far apart. “Dog” and “cat” are neighbours; “dog” and “tax return” are not. When Felix later asks a question, his question is translated into the same numerical language, and the system simply searches for the nearest neighbours.
The translation is handled by a specialised embedding model, and there are choices. Those who want maximum quality from the cloud reach for models from OpenAI, Google, or Voyage. Those who, like Felix, want to keep as much as possible local have good candidates in 2026: EmbeddingGemma, a very small model from Google that runs even on modest hardware (free under Google’s Gemma terms of use, which is not quite the same as a classic open-source licence), or Qwen3-Embedding in its smallest variant under the Apache 2.0 licence. Both handle German decently; whether they run smoothly on the NAS or better on the separate Mac mini depends heavily on CPU, RAM, and architecture. Reliable throughput figures for home hardware barely exist, and I am not inventing any here.
A word of caution about rankings: there is a public leaderboard for embedding models called MTEB, and it is useful, though it changes constantly, the scores are partly self-reported by vendors, and a stable “Germany winner for July 2026” simply does not exist. Felix therefore does what I would recommend to anyone: he builds a small test set of twenty real questions about his own archive and checks which model answers his questions best. Your own test beats any external leaderboard.
Two technical parameters are worth knowing. First, dimensions: the length of the number list. More dimensions mean finer distinctions in meaning, but also more storage and slower search. Felix does a quick calculation: 500,000 chunks at 768 dimensions each produce roughly one and a half gigabytes of pure vectors, no problem for his NAS. At 3,072 dimensions it would be four times as much. He chooses the smaller number, which EmbeddingGemma delivers anyway. Conveniently, modern models support a technique called Matryoshka (named after Russian nesting dolls): you can trim the number list to fewer dimensions afterwards without retraining a different model. Whether the existing database supports this directly depends on the vector index; often the index at least needs to be rebuilt. Second, the iron rule that has tripped up many people: you must use exactly the same model for searching as for indexing. Use a different model and every result is nonsense.
Station 4: The Vector Database. And the Trap You Should Not Fall Into
All those number lists have to go somewhere, in a way that lets you find the nearest neighbours to a search vector at lightning speed. A regular database that compares exact values fails here: with thousand-dimensional number lists there is never an exact match, only more or less close. That is what the vector database is specialised for, with geometric proximity at its core.
Felix’s choice falls on pgvector. This is not exotic, stand-alone software but an extension for PostgreSQL, one of the oldest, most boring, and most reliable databases in the world. That is precisely the appeal: one database, one backup, one system he already knows. For his half-million chunks this is more than sufficient; pgvector is used in production with far larger volumes.
And now the trap. There are convenient all-in-one offers from the big cloud providers (Amazon, Microsoft, Google) and specialised services like Pinecone that take all the work of this pipeline off your hands. Tempting. But you should understand exactly what you are signing up for. You often hear the warning that you will “never get your vectors back out”. To be honest, that is overstated: most services do offer a data export. The real catch lies elsewhere: what is not portable is the finished search index, the ranking logic, the entire operational machinery, and above all, everything is tied to the chosen embedding model. Switch providers and you have to recalculate everything anyway.
The real treasure Felix is guarding is therefore not the vectors. It is his original documents, the clean Markdown, the chunks with their identifiers, and the “recipe” by which he produced them. As long as he keeps this on his own systems and versions it, no provider in the world can lock him in.
Station 5: Hybrid Search. When Meaning and Keywords Work Together
Now comes the moment that shows why pure semantic search alone is not enough. It is brilliant at finding conceptually related things. But it is remarkably poor at hitting exact strings. And Felix’s archive is full of them: project numbers, article codes, proper names. If he searches for FB-2019-047, semantic proximity is no help. He wants exactly that string.
For this there is the old, venerable keyword search, whose best-known modern representative is an algorithm called BM25. The “25” is, by the way, a version number from the research labs of the 1980s and 90s, not the year 2025, a charming misconception that stubbornly persists. Such methods score a match on three things: how often the search term appears in the chunk, how rare it is in the entire archive (a rare “FB-2019-047” counts more than a common “project”), and how long the chunk is. Felix will not implement full academic BM25 directly (that would require an additional extension), but PostgreSQL’s built-in full-text search is close enough for his purposes.
The real art is combining both worlds, which is called Hybrid Search. You run the semantic search and the keyword search in parallel, each producing its own ranking, and then merge the two with a surprisingly simple method called Reciprocal Rank Fusion. You do not even need to make the different scores of the two systems comparable; you simply add the reciprocals of the ranks. A chunk that appears high in both rankings shoots to the top of the combined list.
A concrete example from Felix’s archive makes it tangible. Searching for a proposal with the number FB-2019-047, the correct document lands in first place in the keyword search but only eighth in the semantic search. A thematically similar but wrong proposal reaches first place in the semantic search but barely appears in the keyword search. The fusion adds both together and the exact document with the right number wins through. Precisely the kind of search Felix used to fail at regularly is now solved in milliseconds.
Technically this is no great feat in PostgreSQL: you add a second, text-based search column alongside the vectors, with the German language configuration so that “läuft” and “laufen” are recognised as the same word. Those who want genuine BM25 later can extend PostgreSQL with an extension like pg_search. One quirk remains either way: the German stemmer does not decompose compound words. “Schneckenradsatz” does not automatically find “Schneckenrad”. Those with many such compounds build a small custom synonym dictionary from their own inventory, which often works better than adding another large search system alongside.
Station 6: Reranking. The Strict Examiner at the End
Hybrid Search delivers a solid shortlist of around twenty candidates. But the ranking is not yet perfect. For more demanding archives the last quality stage is therefore reranking: a specialised model that reads question and candidate together one more time and evaluates very precisely how well this particular passage actually answers this particular question.
The difference from the previous search is subtle but important. During indexing, question and text were translated into numbers separately: fast, but coarse. The reranker reads both together at the same table and picks up nuances, negations, details that the coarse vector comparison misses. This costs more computing time, which is why it is only applied to the last twenty candidates, not to all half a million.
Here too Felix has the choice between cloud and local. The market leader is Cohere’s reranker, good and multilingual, but the data leaves the house again. Running locally, models such as bge-reranker or a small Qwen reranker are a better fit for Felix’s yellow documents. He chooses bge-reranker-v2-m3. How fast it is on his specific hardware is impossible to say in general. Reliable figures for home hardware simply do not exist, and I am not inventing any here. Realistically, rating just twenty candidates is enough, and that task falls to the Mac mini, not the NAS.
The Assembly: How the Plan Comes Together
Now everything comes together into a picture. On the indexing side the chain runs through once: a nightly job collects new and changed files from Felix’s folders, sends them through OCR, cuts them into chunks, translates those into vectors, and writes them into the database. On the query side, with every question the reverse journey runs: translate question, Hybrid Search, reranking, and the three best chunks go together with the question to a language model, which formulates an answer with filename and page number as the citation.
And here is where honest advice parts ways from marketing hype. You can programme all of this yourself, and anyone who goes via tools like n8n (software for visually assembling automation workflows) and an AI coding assistant will understand every cog in the end. For Felix this is the right path, because only this way does he retain control over the two things that are about to matter: the permissions filter and the deletion logic. His own small pipeline, comprising Docling, EmbeddingGemma, PostgreSQL, the fusion of full-text and vector search, and the reranker, is the actual system.
There are ready-made, open-source toolkits that include a complete RAG pipeline, such as AnythingLLM or Open WebUI. But Felix deliberately uses one of these not as a second, parallel pipeline, but only as a user interface. Open WebUI receives his question and forwards it to Felix’s own RAG endpoint: a defined interface, not a competing system. Two pipelines with overlapping data would be a maintenance nightmare.
This order, understand first and then present a ready-made interface, is my recommendation to anyone implementing this blueprint. Understanding and convenient operation are two different things, and the interface must never bury one under the other.
At the end of the blueprint stands a connection point that draws the arc back to Mark from the second episode. In front of the finished pipeline, a small API (a defined request address through which one programme can speak to another) will later allow the archive to be connected as a capability to Mark’s bot in the boiler room. Then Felix could one day query his archive from the sofa via Telegram. The data grave would become a conversation partner. But precisely this transition is the most delicate point in the whole plan. And one more thing belongs here, because it was promised in the data-protection chapter: the permissions filter. The query chain is not simply “question → search → answer”. Between “search” and “answer” sits a step that checks: who is asking, and what are they allowed to see?
Four rules before Felix puts his archive on the network
- No direct port forwarding of the NAS to the internet; access only via a secured, encrypted channel.
- Authentication before every request. Nobody queries the archive anonymously.
- Permission filter before retrieval: every chunk carries document ID, path, owner, and access rights as metadata; the search runs only over what the querying party is allowed to see.
- Track deletions via stable document IDs: active data and index immediately, backup copies over their retention cycle; when a backup is restored, the deletion markers are reapplied.
Anyone who takes these four rules lightly turns their private memory accidentally public. The difference between a tool and a data leak.
One question remains, which you have to ask honestly: how would Felix know that such a system works and does not merely look impressive? Answer: through a small ritual that belongs in every such blueprint. He writes down twenty real questions to which he knows the correct answer and the correct source file (exact numbers, date questions, questions spanning multiple documents) and deliberately includes a few questions whose answer is not in the archive. After every change he runs this set through. Does the system find the right page? And, almost more importantly, does it honestly say “not found” when it does not know something, instead of making something up? These twenty questions are Felix’s weekly smoke test.
Felix’s Reference Stack at a Glance
So that the blueprint does not fragment into a string of “either … or” decisions, here is the configuration Felix settles on at the end of the afternoon, one of many possible ones but a concrete one:
- NAS (Synology): stores the original documents and runs PostgreSQL with the pgvector extension as the database.
- Separate Mac mini (Apple Silicon): handles the compute-intensive steps: OCR, generating embeddings, and reranking. It does not run continuously but is woken for the nightly indexing run if the model and network configuration support Wake-on-LAN; otherwise via a scheduled task or manual start, then put back to sleep.
- OCR: Docling for structure and reading order, with Tesseract as local character recogniser for German scans.
- Embedding model: EmbeddingGemma at 768 dimensions, locally runnable and free under Google’s Gemma terms of use.
- Search: PostgreSQL’s built-in full-text search for exact terms plus vector search for meaning, merged via Reciprocal Rank Fusion.
- Reranking: bge-reranker-v2-m3, applied only to the last twenty candidates.
- Interface: Open WebUI in a container, exclusively as the display layer for Felix’s own RAG endpoint, not as a separate pipeline.
- Update cycle: no permanent file watcher, but a nightly NAS scheduled task that collects changed files and wakes the Mac mini for the job.
Apart from the first OCR test, nothing is in production on this Sunday, but every component has been decided, and that is the actual purpose of a blueprint.
When You Don’t Need Any of This
At this point comes perhaps the most important insight of the whole article, and it contradicts its own construction: RAG is not a cure-all, and often it is simply superfluous.
Today’s language models have enormous context windows (the amount of text a model can process at one time), up to a million tokens, roughly three-quarters of a million words. Anthropic, the company behind the model Claude, published a handy rule of thumb in 2024: if the entire knowledge base is smaller than roughly 200,000 tokens, about 500 text pages, just throw it all into the model and skip the pipeline. A single twenty-page contract with one question goes directly into the model, not into a database. In Claude’s Projects feature, however, there is no published fixed page count: RAG kicks in automatically as project knowledge approaches the respective context limit, which depends on the model and the content.
The reason RAG does not die out anyway is partly purely economic: with the same model and linear token billing, a retrieval context of ten thousand tokens costs roughly one percent of the input cost of a context with a million tokens. Those who query the same large corpus a hundred times a day will find this adds up enormously. And partly it is a matter of attention. There is a well-documented phenomenon called Lost in the Middle: models find information at the start and end of a long text more reliably than in the middle. A large context window is not the same as usable attention over the full length. You should therefore believe neither “large context window solves everything” nor “models find nothing in the middle”: the truth lies between the two and depends on the case.
Felix’s decision rule is therefore simple: one document, one one-off question? Direct to the model. Hundreds of documents, recurring questions, constantly new material, and you don’t even know which file holds the answer? Then, and only then, is the full pipeline worth it.
One more warning that belongs in every such blueprint because it is so often ignored. Convenient tools like Google’s NotebookLM tempt users to simply upload company knowledge. But for free private accounts: if you give feedback on an answer, associated content can be reviewed by humans. Such a private account is not a sensible choice for confidential client data. For enterprise offerings you would need to separately verify the data processing agreement, data location, administrative controls, and specific contract terms; you cannot rule them out categorically. For Felix, the local solution remains simply the clearest path to data sovereignty. That is ultimately not a technical argument but a decision about control.
Looking over the Fence: Why Companies Face the Same Problem, Just Bigger
One might think this is all just a hobby for tech enthusiasts with too much Sunday time. It is not. What Felix is solving on a small scale is, on a large scale, one of the most pressing questions facing the German economy.
Germany’s Federal Statistical Office has calculated that over the next fifteen years around 13.3 million working people will reach retirement age, barely a third of all those currently in employment. The birth-rate cohorts following them cannot replace them numerically; the fertility rate fell to 1.32 children per woman in 2025, the lowest since 1997, while the absolute number of births at around 654,000 reached the lowest figure of the post-war era. At the same time, KfW reports that 57 percent of SME owners are 55 or older and that by 2029 more businesses are planning closure than succession. Every working day, experienced minds leave the labour market, taking their knowledge with them if nobody has made it retrievable first.
Just how much rests on this specialist knowledge is shown by a company like Vacuumschmelze from Hanau, a company that has been a world leader in magnetic materials for over a hundred years. In June 2026 the US group Energy Fuels agreed to acquire the company for a notional equity value of around 1.9 billion dollars; the transaction has not yet closed, with completion expected in early 2027 pending regulatory approvals. Plant, patents, and customer relationships are part of the deal, of course, but the real value lies in a craft that has grown over generations and cannot be replicated in any reasonable time. It is precisely this craft that is at risk of quietly retiring away in Germany’s SME sector.
Against this backdrop, Felix’s project is not a hobby but a template. The ability to store knowledge in a way that a machine can find it at the right moment is an increasingly relevant technical competence. The logical building blocks are the same as Felix’s: the chain of OCR, chunking, embedding, Hybrid Search, and reranking remains the same at its core, whether in the living-room cupboard or in a data centre. What makes the corporate version harder is not the scale alone but the surrounding infrastructure: identity management, tenant separation, auditability, high availability, governance. But the core is learnable, and that is the point.
Conclusion. And an Open Question
At the end of this Sunday, the grey box in the living-room cupboard is still humming softly, and apart from a first OCR test on two invoices, it is still exactly the data grave it was that morning. But on Felix’s notepad there is now something that was not there before: a complete blueprint. Every station is marked, every fork decided, every trap flagged. Three terabytes in which nothing could be found will not become a finished memory in one afternoon, but the path to it is no longer a wall of fog. Felix needed no magic technology for this, only an understanding of a few free tools, a little care around confidentiality, and the discipline to choose the simple solution at the right moments. The blueprint for the librarian is ready; moving in is the work of the coming evenings.
Because this too remains honest: a Sunday afternoon is enough for the plan and perhaps for a first prototype over a single folder. The full initial indexing of three terabytes, with scans, tables, half a million chunks, permissions, and duplicate checks, runs over subsequent nights, and the tidying up will probably take longer. That is not a weakness of the plan but its honesty.
What is truly remarkable is not the technology. It is that all of this, things for which companies commission six-figure consulting projects, fits in principle on two small devices in your own home network, under the control of a single person, with data that does not need to leave the house. That is democratisation in the literal sense: knowledge that yesterday was reserved for large organisations is today within reach of any curious person with a NAS and a few free evenings.
In the next part, Felix leaves the drawing board: we will actually set up precisely this reference configuration, starting with a single project folder and the twenty questions from Felix’s test set, to see where the blueprint holds and where reality corrects it.
There is a question that has stayed with me since I worked through this blueprint. If searching stops being work, if every piece of information becomes immediately and effortlessly retrievable, do we lose something? The laborious act of finding also had a side effect: while searching, you stumble across things you were not looking for, you remember anew, you sort things out in your mind. A perfectly retrievable memory removes this friction. Perhaps that is pure gain. But perhaps forgetting and searching again was also a quiet form of thinking that we are now automating away. Felix does not know yet. And honestly, neither do I.