[[Presentation]] about [[How to Build a Collective Brain with AI]] at [[Clouds on Mars|CoM]] ![[How to Build a Collective Brain with AI.png]] > An effective mind - human or machine - can’t and shouldn’t hold every detail in working memory. It filters aggressively, abstracts, and encodes, yet stays ready to recover the right detail at the right moment. The leverage was never in how much you know; it’s in how well you administer what you already have. A shared brain extends that principle from one head to many - people, teams, and AI navigating the same legible structure. Not a bigger archive - a better-organized one, built so the right knowledge surfaces for whoever needs it. So the question isn’t how much your organization knows. It’s whether anyone - or anything - can find it when it matters. ## Questions > Can our notes from other tools like Google Keep or OneNote be imported into Obsidian easily, and does such an import make sense? More broadly - how should we approach the topic so as not to do everything "from scratch"? - yes, and without manual work - Obsidian has an official [[Obsidian Importer|Importer]] plugin, which supports both of the named tools directly: [[Google Keep]] (from a Google Takeout package) and OneNote (it logs into a Microsoft account and pulls the notebooks), and besides that Notion, Evernote, Apple Notes, Bear, Craft, Roam, HTML and CSV - if a tool were not on the list, only then manually - it is enough to drop the [[Markdown]] files into a folder and point Obsidian at it, because a vault is an ordinary directory on disk - the bottleneck is always the export, not the import - the [[Obsidian Importer|Importer]] will read only as much as the source tool agrees to let out - as a last resort, export to whatever format the tool gives, and an LLM to convert it to [[Markdown]] - you can even ask it to generate a graph, similar to the [[Karpathy method]] - but "does it make sense" is the more important half of the question, and the answer here is: import, but not into the graph - 5000 notes from [[Google Keep]] dumped in bulk give you an archive, not a second brain - [[Single Source of Truth]] is not the same thing as a dumping ground - I would treat the import as source material in a separate folder: searchable, but outside the structure - a note enters the graph when someone actually uses it and links it - otherwise, from day one you pay the cost of maintaining something nobody has read I have been using Obsidian Sync for 3 years. It handles merge conflicts so-so - it tries to resolve them, it shows me the previous versions and their source. The problem shows up mainly with deletions, because it is hard to find them then. Sync assumes real-time synchronisation above all. Everyone is meant to have access to everything. The most important limit is the 200MB file cap. > In my view the most sensible organisational strategy is for the whole organisation to get GIT at a basic level (I don't know any other sensible method of managing shared files apart from forcing real-time synchronisation, which does not scale well to a bigger team) and to build some tree structure based on submodules - for example for marketing, HR, clients (with a general knowledge base, ongoing projects and presale). In the end the biggest challenge here will be size, because the group will very quickly make a repository of a few hundred gigs and will want to keep PowerPoints, graphics, Excels etc. in it. I will be watching what you work out organisationally and how much resistance/challenge with adoption shows up, because from experience I know that adopting a standard is the hardest part 😁 - **[[Obsidian Sync|Sync]] and [[Git]] are not competitors, just two different functions** - both work for me: [[Obsidian Sync]] keeps the current version on all devices, [[Git]] gives what [[Obsidian Sync|Sync]] does not have - workflow, full history and review (for me a [[git worktree|worktree]] for agents) - I have not once had a merge conflict I would have had to resolve by hand (I have auto set up), and deleted files [[Obsidian Sync|Sync]] restores from settings, in bulk too - these are not arguments against [[Obsidian Sync|Sync]], only against treating it as the only mechanism - in an organisation I would go for [[Version control|version control]] anyway, because the question is not "how to synchronise files", but "how to agree on a change" - **Size is not Obsidian's problem, only that of what you put into it** - [[Single Source of Truth]] does not mean that everything physically sits in one place, only that everything can be found from there - [[Blob|blobs]] (PowerPoints, Excels, graphics) stay on OneDrive or SharePoint, and a link lands in Obsidian - in [[Git]] it is in fact harsher than in Obsidian: [[Blob|a binary]] committed once stays in the history forever, and every subsequent version is a full copy, so the repo swells irreversibly - text and only text, and then those few hundred gigs have no chance of showing up - a tree on [[Git submodules|submodules]] is OK as a direction, but [[Git submodules|submodules]] are a nuisance in everyday work (detached HEAD, double commits) and non-technical people trip over them - I would rather consider a separate repo per domain and a thin vault-index that ties them together with links - **The hardest part is not adopting a standard, but the assumption that a standard gets adopted** - I would sharpen "the whole organisation gets [[Git]]" into "gets [[Version control|version control]]" - [[Git]] itself is dead simple, what is hard is how a team works with it: [[Gitflow|gitflow]] or [[Trunk-based development|trunk-based]], who does the [[Code review|CR]], where we gatekeep and how to bring in people who did not know the tool until now - my presentation is about exactly this - a tool by itself does not solve the problem, because the problem sits in the method - your last sentence in fact holds the answer to why this is so hard :D - "[[Adoption|adoption]] of a standard" assumes that we know the answer and impose it, while others may have a different opinion and be right - I have seen N times how someone introduced a standard top-down and it flopped, because it is a foreign body and long-term it will not take - something else works: show on a small group that the approach helps ([[Lead by example]]), and scale what starts catching on by itself. The role of [[Leadership|leadership]] is building an environment in which those standards emerge as [[Emergent property|an emergent property]], rather than being announced - usually the problem is the direction of change (tool - method, standard - communication), that is, we go about things from the ~~arse~~ wrong end - so before you roll anything out, it is worth asking: "why haven't we been doing this until now?" - from the answer it usually turns out that the imposed standard does not hit the real cause anyway ^jan