I’ve been using a personal second brain for many years. I started with OneNote and pivoted to Obsidian due to the linking feature. Since then, I have built a full net of knowledge for my personal life, but not only that: I also manage my solo business with Obsidian, such as my CRM or everything knowledge-related to my company.
But what if you want the same approach for a bigger company, enterprise scale with lots of information internally, but also available externally? How do you manage knowledge in that context, with multiple writers, lots of consumers, and always up to date? Though enterprise knowledge management isn’t something new, a self-curating LLM Wiki that Andrej Karpathy shared in a short gist went viral, and it showed what’s possible for a small personal, auto-updated knowledge wiki. But it’s not working at enterprise scale, and also, there’s no verification process or versioning happening.
In this article, we go from a personal brain to an enterprise company brain and show the feature differences, what enables them, and how agents help us not only read context but also write and update information. We explore how agents write on their own branches (with changes that don’t collide and with collisions where humans review and decide). Everything is accompanied by two showcases at the end that compare the two brains and their scale.
How it Started: Enterprise Knowledge Management
If we look at the history of six decades of knowledge management, we see that it’s not something entirely new, but the way we work, from foundational to wikis, over to graphs and now LLM-enhanced, is interesting:
For my personal knowledge brain, I use a graph to connect my personal notes for my personal life, school, and even work. It started with Roam, but you can use any linked note-taking app such as Obsidian or Logseq. I’d suggest using an open file format like Markdown plaintext files, so your knowledge is not tied to the tool.
If we assess what a single-user connected graph system looks like, we can then compare its limitations and how it compares to enterprise knowledge management. A personal system stands for:
- A place to capture and collect “knowledge” for long-term retention (an open format that still works in 100 years)
- Idea creation, a place where we can curate and write knowledge
- Understanding and learning new things through interlinking notes (building the graph below)
- Knowledge retrieval and getting insights from connections that have been written over years
- Templates to automate common note structures, integration with knowledge capturing tools (e.g. Obsidian Web Clipper)
There are probably many more, but these are the essence of what a personal system should provide you.
Limitations of a Personal Knowledge Brain
There are real practical limitations and disadvantages a personal brain has over a company and enterprise brain. There are no multi-user capabilities, or hardly any, with just local Markdown files (you’d need to sync them with CRDTs or find another way), but ultimately, text files or Markdown files are not made for it.
The graph also has no types or way to guarantee that a data type is persistent. It’s unstructured, “free-flow” text. Linked notes (mostly Zettelkasten) are provided with limited semantics between the notes and the relations between them. This is what Sergei Simonovi says as well, noting that this can lead to “friction points when working with a large number of notes”.
If we have not 1000s, but millions of notes, we need an index for fast retrieval, we might need embeddings/clustering, and we need something that scales with the company size and all types of data (TXT, CSV, APIs, JSON, etc.).
Enterprise Knowledge Management Scale: Multiple Users, Concurrent Writes, Auto Update
Surprisingly maybe, all of the requirements we have for a personal brain, we also have for a business. We need to retrieve last month’s/year’s sales numbers, we want to learn new insights from an ever-changing business environment (new laws, new provided data we can use), and we want to share with internal and external stakeholders.
But it’s on a much bigger scale. We need to work with multiple users and bigger, more sophisticated data sets. We can’t just copy-paste from a website. We need data pipelines, a data warehouse.
We want automation, as well as governance. In a sense, you can imagine replacing some custom software products like CRMs or ERPs that need dedicated systems and SW, especially CRMs, which gather all sorts of context, from customers combined with inputs from the sales reps on when they called last, what the customer said, what their temperature is right now (hot/warm/cold), etc. If that can be gathered from notes of sales reps automatically, or from dedicated logs from the phone if approved, or similar, these states can be managed in a company brain, and it is a good example of what we need.
Features of such an Enterprise Company Brain
An enterprise company’s brain needs multiple users to write to it concurrently, and we need automation. This is where agents join the picture, and agents play a big part, but not the only one. Being able to version state when multiple concurrent users write is key, or you need a storage system that can handle all requests and the volume.
Agents-First Governance for Auto-update Context
Agents are very good at capturing information in any format. Agents should give us the comfort of doing that autonomously. We want them to read defined locations with information that can be valid for a company brain. Staying with the CRM example, all customers from the database should be automatically updated every day, calls and docs should be ingested and updated, deals and contracts should be related and attached to each customer, and so on.
But how do they write new context to the company brain?
Versioned: with Branches
That’s where we need branching. Not only because 100s of AI agents adding knowledge at once will trip over each other, but also because every change can be reviewed before it lands. Without that, a company brain fed by agents drifts into noise. Auto-changing a wrong phone number, or a hallucinated deal status, can lead to an untrustworthy state in a few weeks.
So we give each agent its own branch and its own private copy. It writes there, and then its changes get merged back into the main branch, exactly like a GitHub pull request. Nothing lands on the “real” version until it’s approved. Humans can review and decline certain merges, or revert them later, and you get a full history of who changed what.
On top of that, agents and humans can work at the same time without corrupting anything. This avoids conflicts and lets multiple agents work in parallel. Branches are also great for long-running tasks, since they can run concurrently and merge back when they’re done. So you get verification and multi-concurrency in one go.
More generally, a requirement for a useful company brain is that it stays continuously up to date, correct, and enriched (see CRMs that are always stale, missing, or incorrect, so humans patch by asking colleagues, but agents act directly). Branches are what make “continuously updated” and “still correct” work together.
Cheap Storage, Accessible for Everyone: Object Storage
We need an open space where data can be written, where we can version our data. The best place, one that is affordable in price, is object storage. Besides its easy setup and ease of use, it also allows using open formats such as Apache Parquet or other open file formats (you can also use open table formats if you like, with added database features on top of files) in a place for anyone to read the information with the right access, unlike piping the data into a proprietary database format.
There’s no database server to run either: your whole graph is a bunch of files.
Consistency with Agents: Typed Graph
So how do we make sure that agents write the information grepped from various sources in a consistent way? Unlike the Obsidian Markdown example, where we link them with [ [wikilinks] ] and data is stored free-flow, we can use a typed graph. Meaning the data is stored in a graph linked like Obsidian, but typed with a datatype. So the system you use makes sure that the agents consistently write a number for a client’s phone number, or that dates are aligned, etc.
These types act as data contracts for agents on how to store, but also how to retrieve the right information. It’s also key for agents to avoid writing bad data. Instead of separate tables, a typed graph stores everything as a graph (dots and lines). Dots are things (a person, a company, a deal). Lines are how they connect (this person founded that company). It’s basically the “connections” view in Obsidian, or how a social network knows who’s friends with who.
“Typed” means it has rules. Every dot and line has a defined shape you write down first (a Person must have a name, and a FoundedBy line only connects a person to a company). So nothing unrelated can sneak in. Think of it like a form with required fields vs. a blank notebook where anyone writes anything.
We can store graphs as code. Here’s an example of the node Organization:
Explained in Obsidian terms: a graph link is a connection you declared (“A links to B”), while an embedding is a resemblance the model inferred (“A reads like B”). A company brain that holds both can retrieve on meaning and on typed relationships, not just on vector similarity alone.
Together with branches that are versioned, being able to revert certain changes or decline them altogether, built on an open and standard storage layer such as S3, R2, or others, we can increase the quality and consistency a lot.
This is something we’ve tried to keep in check with Master Data Management (MDM), where we used Excel for stewardship of data, but human-powered, which was always the bottleneck: domain experts were already the busiest, and now they get one more job, to check if the data was correct and approve it. With agents, we can accelerate this process, if we have quality documentation and up-to-date files the models can verify against.
Also, there’s no absolute truth, and agents can also surface contradictions that naturally happen in the data. Maybe one piece of documentation says the last call for a client was last month, while a log entry shows something else. In such a system, the human can always intercept and change the data too, same as the agents would.
It’s a continuously shared understanding that is developed together with the agents and the whole company.
Do We Need Ontologies?
But with graphs, we can model data with more accuracy and more detail. This is one advantage. We can model world knowledge into ontologies, and combine them with the enterprise data, which helps the model get more domain understanding with the right “connected” world+local and business knowledge.
The graph is the most generalized version of an ontology, Ragnor says. Text links linearly to other texts. A graph has many categories. Agents need an understanding of the domain (what’s a customer -> connection to data model etc.). An ontology is a world of objects that connect together, and the graph that connects it all, with indexes, embeddings, and the open storage format.
These ontologies are especially helpful for company brains, as they help find a common denominator across different departments. Personal Obsidian knowledge brains don’t need them, but they can still be helpful if you want to add the complexity.
A graph can be represented as a table, JSON, etc., but a table can’t be converted back into a graph, so you still get the tabular format if you need it. A16z argues that the reason using agents hasn’t worked so far was “a lack of proper data context”, and that “Enterprise data today is still incredibly disparate and messy”, which is why data agents struggle to answer basic questions.
And why not use a relational database? Andrew reframes the problem: Postgres is 40-something years old, and was made due to compute and other restrictions of its time. A design from first principles for agents that need lots of interconnected, real-world knowledge combined with our data is essentially a graph, not a tabular format. Combined with ontologies that describe the entities in the world, this can be extremely powerful for context.
Showcase: Managing CRM with Obsidian, and with Multiple Agents
Let’s look at the personal brain versus the enterprise company brain.
Personal Brain with Obsidian
The example of a CRM is chosen somewhat illustratively, as I have built and manage my own CRM system within Obsidian. I use a note for each client, and then, with a dedicated #hashtag, bring them together in one table. I use the Frontmatter (metadata of a Markdown file in the header) to attribute each client: how active everyone is, and who I need to reach out to.
With different views such as Sales Funnel or overview, I can then see different things. Sales Funnel with Kanban View - based on the same data as the above table:
Company Brain with OmniGraph
If we expand this to a company brain with agents writing, everything versioned, stored in an open format, here’s the example with OmniGraph: it uses Lance as the open columnar storage format on object storage (your graph is just files in a bucket you own, no database server), DataFusion as the query engine, and builds the typed graph with git-style branches on top.
I took my own Obsidian CRM and rebuilt it as a Company Brain at company-brain-crm (adapted from the vc-os cookbook example), a company brain for my company, SSP Data, scaled up to a fictional 50-person version that does a lot of outreach for data-engineering articles and consulting.
Every field from my Obsidian frontmatter got a type added: my Hotness: 5-Cold becomes hotness: enum(hot, warm, cold) that the system enforces (an agent physically can’t write “5-Cold-ish”), my ## Log section becomes Interaction nodes (call / email / meeting / note), and my #crmssp tag becomes the Company node type itself.
The whole CRM is three files you commit to git: schema.pg (4 node types — Company, Person, Deal, Interaction — and 7 edge types):
queries/crm.gq with the recurring questions, written as typed, lintable stored queries:
and seed.jsonl (the data — one JSON line per node or edge):
Run it with make init && make seed, and you have a 98-node / 123-edge CRM, locally on your disk, no database needed. You can swap the path for an s3://… bucket and the exact same flow runs on object storage. From there, every view I had in Obsidian, such as the sales-funnel kanban or the follow-up table, is a stored query you invoke by name (sales_funnel, hot_prospects, company_log). Every result of this demo is captured in DEMO.md, such as the sales funnel as a query result, the same data as my Obsidian kanban above.
The context layer is versioned, diffable, and reproducible from a clean checkout, exactly like the rest of your infrastructure.
How Do Agents or Users Get Context Out?
How does an agent (or a colleague) actually get context out of this? It’s via calling a query. Take the question my Obsidian backlinks could never answer across 50 people’s networks: “who can warm-intro us at a target company?”
The result is one traversal: teammate → knows → contact → works at target:
Writing back to the CRM
And now the write-back side, which most context layers or agents can’t do yet, but which OmniGraph supports. A CRM goes stale the day nobody updates it, so in this demo two agents keep it fresh, and neither writes to main directly. Commands from the repo you can try, such as make agents, run them:
Auto-Merge
The two changes touch different rows, so both merges are clean and go through without human verification and are auto-merged. There’s three-way and row-level merging, one atomic commit each:
Conflict Handling
The interesting case is when writers disagree (make conflict in the repo): the inbox agent flags Nordbahn as hot (“CEO replied today”) while a CRM-hygiene agent downgrades the same row to cold (“no touchpoint in 60 days”). The first merge lands, and the second is blocked:
Nothing is published, and there’s no silent last-write-wins. Instead, a human (or a policy/data contract) decides. And because every write records an actor (--as agent-inbox), omnigraph commit list gives an audit trail where “who set this client to cold, and when?” has an actual answer. You can find the full captured run of both cases, the auto-merge and the blocked conflict, in the repo.
This is a fictive demo, with very little data to illustrate the concept, but I hope you got the gist of how this enables totally different context-related use cases, and eases life with auto-merge and agent help to update stale documentation and context.
If you want another personal second brain example, and an application with OmniGraph as a personal life ontology, this showcases a typed graph to answer questions like:
- Who haven’t I talked to in a while that I want to?
- What did Sarah recommend that I haven’t read yet?
- What do I still owe Theo?
- What’s on my mind about parenting / work / health?
Building Enterprise Brains, and What’s Next?
I hope you got a good understanding of the difference between a personal wiki and a fully automated LLM wiki where agents write back. And why features such as versioned branches, open-format object storage, and types help form a graph that describes rich context much better than plain text or scattered, outdated documentation ever could, especially with the help of agents: collecting and scraping useful information, but also updating existing context and raising awareness where contradictions in the data have been made.
This new approach is worth remembering for building an enterprise company brain. It’s not only embeddings you search by similarity, but also typed, declared knowledge plus inferred similarity, versioned like code, so a hundred agents can write to it while humans keep it from drifting into noise, by reviewing what merges back to the main branch.
In the end, it’s the same bet I made when I moved my personal brain to plain Markdown. Open files outlive every tool that reads them, and a company brain stored as open files in your own bucket will survive whatever CRM or wiki is used today. What’s new is that the files now carry types, history, and a merge workflow, so the knowledge no longer depends on one careful owner. My Obsidian vault needs me, the single user. An enterprise company brain, a graph database designed for agents, kept fresh by agents and reviewed by humans, mostly needs someone to hit “merge”.
This difference compounds and can be the key to managing ever-growing information, moving from a wiki you maintain to an enterprise brain your company actually uses.
If you want to get started, the omnigraph-cookbooks are the fastest path. Feed one to the agent of your choice and get ready-to-run graphs with real seed data (company brain, VC operating system, pharma and industry intel). And for a deeper discussion, co-founders Andrew and Ragnor talk it through with Stanislav Kozlovski in why agents need typed graphs to coordinate.