I think this conversation is collapsing storage, retrieval and memory into one thing. The way I’ve built it, the “brain” has a knowledge layer, three separate memory layers, and a consolidation process that maintains them. None of it belongs to the execution model. The whole system is model agnostic. Claude, GPT, GLM, Qwen, a local model, or whatever comes next can all sit behind the same memory, retrieval and RAG layer. The model is replaceable. The accumulated knowledge and state are not. The knowledge layer is RAG. My first real corpus is 62,638 chunks with roughly a 1.36 GB vector index. I use Nomic embeddings to turn the source material and the query into vectors, FAISS to find the nearest candidates, date-aware recency weighting, diversification to keep near-duplicate material from flooding the result set, and a Qwen3 reranker to score the remaining candidates against the actual question. At that scale, file naming and folders are not really the problem anymore. The hard problem is deciding which five or ten pieces of information deserve to reach the model. Recency matters too. A semantically perfect email from four years ago may be less useful than a nearly identical one from last month. I don’t simply sort newest-first either. Date becomes part of the score with a decay curve. Old information can still win if it is substantially more relevant. Then there are three actual memory layers. Working memory is the current conversation and immediate state. What I said 30 seconds ago should have more authority over the current task than something retrieved from six months ago. This also means you need precedence rules so stale summaries or recalled information cannot override the user’s current instruction. Long-term memory contains facts, decisions, project state, conclusions, relationships, prior outcomes and other information worth recalling later. That gets embedded separately from the document corpus. Recall is not just vector similarity. I score memories using semantic relevance, freshness, novelty, decay and prior access, then inject only a small top slice into context. Persistent memory is different again. These are things that should behave more like operating instructions than recalled facts. User preferences, stable rules, skills, company policies and similar information should not compete with ordinary memories or disappear simply because they have not been mentioned recently. Then there is dreaming, which is the consolidation process. Periodically the system reviews new conversations against existing memory and decides what is worth keeping. New information can be a duplicate, an augmentation of something already known, or a contradiction. Contradiction handling is a much bigger problem than “store everything.” If I said in January that a customer’s target was $10M and in June changed it to $12M, a system that perfectly stores both statements still has a memory problem. It needs to know that the second statement supersedes the first. I keep the old fact for history and provenance, but expire it from normal recall and link it to the new one. That means historical truth is preserved without stale truth competing with current truth. Forgetting matters too. Not every memory should remain equally important forever. Long-term memories can decay. Repeated or reinforced information can strengthen. Old information can remain available without continuing to dominate recall. Then you get to context hygiene. Retrieval can search gigabytes. The execution model should see kilobytes. I intentionally cap recalled memory before it reaches the model. The point is not to prove how much context I can stuff into a context window. The point is to give the model the smallest amount of high-signal context required to answer the current request. That is also why “stores everything” does not tell me much about a memory system. I care about what it retrieves, how it ranks it, whether it understands time, what happens when facts conflict, what decays, what becomes persistent, what gets excluded, and what is allowed into the current context. I also keep RAG and memory separate. A 30 GB email archive, SOP library, customer documents, drawings or research corpus are knowledge sources. They are not automatically memories. The system can retrieve from them when needed without pretending the model permanently “knows” all of it. And because the whole thing sits outside the execution model, I can change models without losing the brain. I can change the embedding model. I can change the reranker. I can change the vector store. I can change the execution model entirely. The accumulated memory, provenance, permissions, conflict history and knowledge remain intact. So I personally would not start a second-brain design with Obsidian vs Computer vs another vault. I’d start with the memory lifecycle, retrieval policy, precedence rules and model-independent context layer. Storage can change. Models can change. The brain should survive both. To me, that is the actual second brain. It is the layer that knows what you know, what changed, what is still true, what matters now, and which parts a given model should see for this specific task.
v3 Is out of my Annual Operating Plan Maker. app.gtmharmony.com This version will take your best cast and automatically create a good and bad scenario for you. The fastest way to create a sensitivity analysis that Finance will want to see. NRR CAC LTV Magic Ratio All in a couple of clicks And it's free. If you want to download the PDFs (they are styled for board reporting), you do have to put in an email but you could easily put in whatever. Take that PDF, put it in GAMA with your company logo and colors? Board Deck. Enjoy!
Thank you! Stay tuned. there are more updates coming. The version now you can create several scenarios, but the new one it will take your best scenario that you enter use that as "Best" and auto create a Good and Bad scenario for you that can all be exported as a print out.
Most ops teams are guessing at unit economics. I built a quick scenario maker so you can stop guessing. https://gtmharmony.lovable.app/ No login required. You can model impact on NRR, CAC, LTV, and payback period. If you download a plan, it asks for your email. If you want the plan and don’t want to put an email in there, put whatever and take the plan. I think this level of detail belongs with the operators. Because operators drive the inputs. That enablement program. Drop CAC by 10% because ramp time fell by 60%. That comp plan you finally got finance to approve. Now you can show the historical baseline and the forward impact in one place. The AI “lift” everyone expects. Treat it like math. Historical baseline. Minus the headcount or time you removed. Plus the software you added. Then see what the model says about CAC, payback, and saturation. If you had 10 SDRs and now you have 1, but you spend an extra $275k in software. Put it in the model. Use real conversion rates. Then look at how fast you burn through SAM, long before you talk about TAM. It’s all math. The basic tenets of operating haven’t changed.
Yeah! That's incredibly helpful. How in the world did you compile this? It's the most comprehensive understanding of LLM crawling I've seen. Super grateful you shared. Thank you!
Cloudfare and Squarespace both allow options that are similar to robots.txt to allow AI crawling. The JS stuff you mentioned though, I had no idea. This is great to understand how LLMs find companies. Seems like the next frontier of finding qualified folks, but how relevant will they be?
AI is such a huge topic. Has anyone been working with clients on FAISS vector databases in lieu of custom models? A use case would be a project generator based of all your previous projects, or a master Rev Ops library in a GPT derived from all your internal docs. I've created an OpenSource and have implemented for a GPT powered employee handbook/onboarding. That gave me the idea for the SOW Rev Ops creator. https://gtmharmony.io/sow if you want to give it a try. You're rate limited on my server, but you can run it locally too.
Github is available at: https://github.com/DurangoDavid/SOW
I'd like to take a look. If you'd like, I've built an SOW/Project builder that will create detailed plan if you input a detailed problem statement and stack. It's free and in beta (and you can run it locally on your own machine), but you can give it a shot a https://gtmharmony.io/sow
