I linked thousands of local files so AI could search by meaning, not filename. Inside 30 seconds it surfaced a two-year pattern I had never written down. Here is the case for federation over consolidation.
Published on 20 March 2026
I built a bridge between about 5,400 files on a Sunday afternoon, and within 30 seconds the system surfaced a two-year business pattern I had never consciously spotted: hidden across notes that were never meant to be read together.
Most founders I work with are not short of insight. They are short of retrieval. Years of coaching notes, proposals, positioning drafts, and half-finished strategy documents sit in different tools, and when a decision arrives, the right language is rarely in the room at the same time as the data.
Before this rebuild I was my own search engine, and a poor one. I had a GitHub repo called polything-context with dozens of Markdown files (company info, ICP, brand voice, playbooks, pipeline, how to work with me). Every session I started from COO.md and let Claude follow the routing table. It worked, sort of. I still had to know which file held the answer. The unexpected connections, the patterns you do not know to search for, stayed invisible.
One evening I wrote down the honest audit: context lived across my head, prompt defaults, that repo, lost past conversations, Canva, HubSpot, Google Docs, and decisions made mid-chat that never became durable notes. That list was not theatre. It was the map of why I kept re-briefing the same context.
This article is the personal rebuild story: moving thousands of notes into a setup where meaning matters more than folders, and where Claude Skills and practical AI workflows can sit on top of context you already own. The wider point for UK founders at the marketing ceiling, especially bootstrapped teams roughly in the £2-7m range: your answers may already be in your files. The gap is usually infrastructure and narrative continuity, not imagination. You will see why I stopped chasing "one tool to rule them all," what federation looks like in practice, and a short audit you can run this week without buying new software. If you prefer the build narrative first, read how I built an AI prototype in two hours for the mindset that got this experiment moving.
I have spent most of my professional life scaffolding my own neurodivergent brain. That is not a complaint. The spiky profile is real: strong pattern recognition, deep focus on novel problems, and weak tolerance for repeating the same admin process forever. Organisation, routine maintenance, and "where did I save that?" are the valleys.
If you are a founder, you may recognise the shape even without a formal assessment. Big thinking arrives naturally. Systems that capture and replay that thinking usually have to be designed, then redesigned when the novelty wears off.
This piece is about the latest rebuild, and why it may be the last one I need.
There were three moments, stacked, at the end of February and the start of March 2026.
First, I left Mem after three years and more than 3,000 notes. The AI features had always annoyed me: the product kept trying to be clever with my notes in ways that did not match how I think. Obsidian felt like the right move: simpler, local, Markdown-based, ownable. I exported everything in late February and suddenly had a massive vault that was searchable by keyword, but not by meaning, and not wired together the way my mind is.
Second, I watched Nate B Jones' Open Brain material on building a personal MCP server for AI context. His core argument landed hard:
"A memory architecture determines agent capabilities far more than model selection. The people who are 10x more effective with AI have built context infrastructure that does the heavy lifting before they type a single prompt." - Nate B Jones
I was already doing half of that with a For_Claude folder and the polything-context repo. They were still just files. No semantic layer. No way for Claude to understand what was in them without me pointing at each path.
Third, on the evening of 2 March, a mobile chat with Claude. I asked how to compound Obsidian with a vector database, semantic context, and MCP. We worked through the architecture in one sitting. By the end I had a three-layer design (sovereign, shared, waypoints) and a build plan.
The next day I built the whole thing in under an hour. I am not a traditional developer in the classical sense. The stack: ChromaDB, local embeddings, an MCP server, more than 40,000 searchable chunks across about 5,400 files, zero cloud dependency, all on my laptop.
Then the moment that justified writing this. The first serious query across the live system was about patterns in my consulting work. The search pulled at once from coaching notes, marketing strategy documents, product positioning files, and methodology docs. None of those were written to be read as one corpus.
The pattern was unmistakable. Across dozens of client engagements over roughly two years, the biggest breakthroughs were rarely about teaching net-new skills or frameworks. They were about giving people the right vocabulary for problems they already understood but could not yet name.
I had never written that down as a headline finding. It emerged from accumulated context in about thirty seconds. I logged it properly in the build changelog (session fourteen, if you like receipts).
Before building, I audited how scattered my business knowledge really was.
It lived across sixteen separate systems:
None of it talked to anything else.
It took a while to admit that those sixteen islands were not a moral failure. HubSpot is good at pipeline data. GitHub is good at code. Obsidian is good for connected thinking. Things 3 is good for tasks. Canva holds visual IP. The diversity was not the problem. The disconnection was, especially for giving AI useful context.
For years I felt guilty instead. Productivity culture pushes "one tool for everything." If you cannot manage that, the story goes, you are failing the basics. For brains that already struggle with the basics, that story compounds into shame, when the real issue is missing bridges, not missing discipline.
That recognition, more than any diagram, is what I want you to feel when you read "sixteen islands": specific enough to be credible, universal enough to think, that is me. The number is mine. Yours might be eight. The isolation is the point.
Organisational research increasingly treats silos as different coordination problems, not one generic failure. A 2025 piece in the California Management Review on the silo effect in the AI age argues that structural and procedural gaps need different fixes, and that rigid org-chart patches wear out when the work changes. That sits next to technical ideas of federated knowledge graphs, where domains keep local ownership but gain a governed way to query across them. I am not running an enterprise data platform. I am a founder with Markdown files. The rhyme is the same: disconnected is broken, scattered with bridges is viable.
Worth saying plainly: CMR and Actian describe large-organisation coordination and vendor-scale data architecture. What I run is founder-scale Markdown on disk plus a local semantic index. Those links are analogies for the shape of the problem, not a claim that this laptop setup is a governed enterprise knowledge graph.
Finding a file is the shallow problem. Every tool has a search box. The deeper costs compound.
Every new AI session, contractor kick-off, or project sprint was a new hire brief. Not "open this PDF," but reconstruct the narrative: who the client is, what we decided last quarter, why we abandoned an angle, what language finally landed. I measured roughly twenty minutes a session of that reconstruction. The files existed. The story of how they connected did not.
I had written it bluntly in my own notes: every new session starts partially blind, and I end up as the LLM's context manager, burning energy on the wrong job.
Before the federated layer, I burned the first five to ten minutes on a lighter version of the same thing: "Read COO.md, now brand voice, now the client file." With ADHD, that is not a small tax. It is the best activation energy, spent on admin. By the time the model was briefed, I had often lost the thread of what I meant to do. Jones makes the same point: without persistent memory architecture, you spend the opening minutes re-explaining role, projects, and constraints. The goal is shorter, sharper prompts because context is pre-loaded.
Keyword search only returns what you already know to ask. You can search "Bauer" and find Bauer notes. You will not automatically see that the same resistance pattern showed up in three coaching engagements and two positioning projects, in different folders, months apart. The connections stay invisible unless you already suspect them, in which case you hardly need the machine.
When I finally ran semantic search across the full vault, a coaching pattern across more than ten clients appeared in under thirty seconds. The value was never in one note. It was in cross-pollination between client work, reflection, and strategy.
The best thinking often lands mid-conversation: a positioning angle clicks, a strategy shifts, a decision is made. Then it lives in a chat window that expires, a call nobody transcribed properly, or your head. Two weeks later you remember what you chose, not why. You revisit decisions you already made because the reasoning evaporated.
Years of journals, gut reactions about clients, and half-formed strategy live in the same head as commercial judgement. That material is valuable context, but I do not want it dumped wholesale into a model with full write access. Without a permission model, people either over-share (noisy and risky) or under-share (the model stays blind). The three layers exist to break that binary.
Your pipeline notes belong in the CRM. Code belongs in GitHub. Strategy belongs in Markdown and docs. Client assets belong in Canva and Drive. The diversity reflects how work actually happens. Productivity culture calls scattered broken. More often, disconnected is broken, and scattered with bridges is a feature.
The counterintuitive lesson: the answer is not to force everything into one place.
I have had the weekend migration high: notes moved, inbox zero euphoria, then slow decay as real work dragged me back to the tools that actually fit each job. The CRM stays the CRM. Code stays in GitHub. Late-night journal entries stay wherever they are easiest to capture.
Reorganisation can feel like progress. For many neurodivergent founders it scratches the novelty itch while displacing the harder work of using what you already know.
My conclusion: business knowledge should live in more than one place because work itself does. What I needed was not a single monolith. I needed to ask a question and get answers drawn from everywhere that mattered. Federation, not consolidation. Islands stay; bridges carry the post.
That shift connects to how I think about adoption more broadly: treating AI as something you hire and onboard, not a single plugin you bolt on once.
There are four bridges that matter, plus one I deliberately did not build.
This is the core. Keyword search needs the exact term you typed six months ago. Semantic search searches by meaning. I can ask what shows up in positioning work with technical founders and pull from coaching reflections, strategy notes, and product positioning at the same time. The layer does not care that the files live in different folders or use different vocabulary. It connects "technical founders struggle to explain value" with "engineers default to spec sheets instead of outcome stories" as the same class of problem.
Technically that bridge is ChromaDB with open-source embeddings (all-MiniLM-L6-v2 if you want the label), running locally: more than 40,000 chunks across about 5,400 files, private, no API bill.
This is a permissions bridge. What can AI see, reference, and write?
Sovereign layer. Raw thinking: journals, half-formed ideas, personal reflections, gut reactions about clients. Embedded so results can be informed by it, but no AI writes here. Ever. Thinking-behind-the-thinking stays mine.
Shared layer. Strategy documents, client deliverables, marketing frameworks, business plans. Co-created working knowledge. Both I and AI can reference it; where AI writes, it is structured and reviewable, not silent edits to my raw notes.
Waypoint layer. Machine-facing breadcrumbs at the end of a session: what changed, what we decided, what is still open. Each new conversation picks up where the last one stopped instead of starting from zero.
The layers exist because of privacy paralysis. Most teams face a false binary: the AI knows everything, or nothing useful. Layering creates a middle space: the model can pull what it needs, with explicit rules about what it may touch.
Retrieval alone is not enough. When a decision lands mid-conversation, it becomes a structured note: context, reasoning, implications. When a session ends, a waypoint captures what moved and what is unresolved. The vault compounds through use. Each session makes the next slightly smarter. That is the bridge between a static archive and a living system.
The best thinking often happens away from the desk: a walk, the car, a conversation. A Markdown template with frontmatter lets any LLM package a thought for Obsidian: layer tag, routing hint, enough cold-read context for later. Three import routes, each under a minute: paste into Obsidian on the phone, hand off to the next desktop session through MCP, or drop into an inbox folder for processing. The bridge is not exotic hardware. It is making sure an 11pm insight does not evaporate before breakfast.
I am not migrating HubSpot into Obsidian or code into Notion. HubSpot stays HubSpot. GitHub stays GitHub. MCP acts as the postal service between islands. Islands stay where they are. The protocol delivers the right information to the right conversation at the right time. That is what makes this sustainable. You do not have to reorganise your life. You add a search layer that understands it.
For packaging repeatable behaviour on top of that stack, why everyone is talking about Claude Skills is a useful companion read.
Model Context Protocol (MCP) is the glue in plain language. Instead of pasting background into every chat, the assistant retrieves what it needs from the federated brain.
Ask about a client and the search can span pipeline notes, project history, and strategy docs at once. You get an answer stitched from three systems without opening three tabs manually. The prompts get shorter because the context is already in the room.
The write-back bridge is what stops this becoming another abandoned system. Decisions and waypoints accumulate. Client work builds compound knowledge: positioning nuances, language that landed, politics that matter, what failed before. Without persistence, that intelligence leaks between sessions. With it, the engagement compounds instead of leaking.
The hardest part is not the database name. It is the starting problem. People hear "vector database" and "MCP server" and assume they need to be a full-time developer. Today's tooling still rewards technical comfort. The insight underneath is simpler: how you think about knowledge, and whether you can query across it without becoming your own search engine.
Then there is the 80/20 trap. I wrote in my own plan that a simple MCP plus file search might solve most of the pain, and a full vector setup might be unnecessary for everyone. Phase zero was an hour of cloning exports and fixing broken references. That alone cleared roughly half to sixty percent of my context isolation. No embeddings, no vector database. Most people skip straight to the exciting layer because reorganising feels productive. Fix what exists first. If phase one habits do not stick, phase two is a trap.
Maintenance tax is the existential risk for ADHD-shaped brains. Novel architecture gets a weekend of flow. Week eight wants feeding when novelty is gone. I designed real off-ramps: if the simple version does not earn its place, you stop. That is not pessimism. It is how these systems survive.
Sovereignty shows up late for many teams. You pour journals and client notes into a tool, then realise the AI has read-write access to your rawest thinking. Boundaries have to be designed, not improvised after the fact.
Tool paralysis is the last trap. Obsidian, Notion, Logseq, Apple Notes. Pick one that outputs Markdown you can move. The federation layer sits on top. If you change apps later, the files still move with you.
Most founders in my ICP will not build an MCP server this quarter. They will still feel briefing tax when they onboard a freelancer for the fifteenth time. They will still carry competitive advantage in their head because nobody else can see the pattern language. This article's job is not to teach ChromaDB. It is to say your accumulated knowledge is an asset, not a mess, and federation beats consolidation for unlocking it.
Day-one risk, written down honestly: one to two hours a week minimum to feed the system, and it must stay ROI-positive against anything else I could do with that time.
Novel builds get hyperfocus; week eight maintenance does not. So every phase has a real off-ramp. Phase zero was unglamorous: clone Mem exports, fix broken references. That alone removed a large slice of context isolation without embeddings or infra.
If the simple version does not earn its place, you stop. If phase one habits do not stick, you do not build phase two. Most second-brain advice assumes infinite discipline. That is not how my brain works. The system has to justify itself weekly.
Six weeks in, it still does. The thirty-second pattern discovery was the proof point. The daily win is smaller and steadier: opening a conversation where the assistant already knows what I was doing yesterday, saving ten to twenty minutes of cognitive warm-up each time. Across a week that adds up to serious reclaimed attention.
I wish someone had said this plainly years ago.
Your scattered, multi-tool knowledge is not the problem. It is the raw material. The 3,000 Mem notes I exported were not tidy. Coaching reflections were not perfectly tagged. Journals were half-formed. When semantic search finally ran across all of it, a pattern across more than ten clients still surfaced in about thirty seconds. The mess was the moat, because no competitor has that accumulated texture. Nobody can replicate years of working closely with real founders.
Productivity influencers sell the fantasy of one clean system. Founders feel guilty for failing that fantasy, then fail to act because shame is exhausting. The reframe is simpler: heterogeneity is where combinatorial insight lives. CRM data is not the same object as a journal paragraph, and that difference is the point.
Your brain already connects islands unconsciously. A federated, searchable layer makes those links explicit and available on demand instead of only when memory serves.
Monocultures are fragile. A single flattened tool can erase the diversity that makes your knowledge uniquely yours.
If you have eight islands or sixteen, the count is not what matters. What matters is that years of thinking about market, customers, and product are hard to access when someone else needs to act.
Every founder I work with has a variant of this: strategy lives in the founder's head but does not translate to execution; marketing activity runs but impact feels fuzzy; decisions still route through one person because nobody else holds full context; growth plateaus despite a strong product.
The common root is rarely "you need more ideas." It is that accumulated knowledge is not available at the point of decision: a sales call, a brief to a new hire, a board conversation. That is the problem marketing strategy work has to solve when we capture what makes you different in language the market recognises.
Professional services firms see it as partner knowledge stuck in individual heads. Associates lack vocabulary because they never received the narrative. Retrofit and green-energy founders sometimes speak in spec-sheet language while buyers need outcomes. SaaS teams split context across product, sales, and success until churn patterns only appear when someone looks across all three.
The vocabulary insight from my query was not magic. It was what happens when scattered knowledge becomes connected and queryable. You can pursue that with a vector database, or you can start by writing positioning in the customer's words instead of your own. The principle is the same.
Connected knowledge helps you say something specific. That matters even more when outbound marketing is sliding toward the same AI-shaped cadences everywhere; for that wider market picture, see is your marketing becoming a mere facsimile of what it could be. And if you are wondering whether AI can substitute for this kind of deep context, Harvard's trendslop research suggests it cannot.
Open a blank document and list everywhere your business knowledge currently lives: email threads, CRM notes, Notion, Google Docs, the spreadsheet only you understand, the Slack channel nobody reads.
Count the islands. Then ask:
You do not need my stack. You do need a clear problem statement before you buy tools.
Then pick two islands and spend thirty minutes answering one question that genuinely needs both. Time it. That is your disconnection cost in concrete terms.
Two closing points.
If you want help turning that visibility into a plan, the Discovery Diagnostic is a half-day workshop: we map where marketing knowledge lives, where the gaps are, and the twenty percent move that returns most of the momentum. No AI infrastructure required, just clarity on what you already know and how to make it work harder.
Explore more insights and strategies to elevate your marketing approach.
AI speeds up marketing but average output is wallpaper: model collapse, distillation, junior pipeline risk. A leadership problem, not a switch-off-AI debate, plus three checks.
Your value proposition feels right, but conversions aren't happening. Discover why most value props miss the mark despite perfect canvases, and learn a framework to build value propositions that actually convert.
Harvard tested 6 AI models on strategy. All gave the same trendy advice regardless of context. Learn why LLM strategy bias matters for founders and what to do instead.