We Built Our Org Brain in Notion and GitHub. Here Is Where It Broke.

Every developer has a graveyard of abandoned knowledge systems. Notion databases with 200 pages and no updates since month three. Obsidian vaults with promising graphs that went stale. GitHub wikis that nobody opens. Confluence pages that are wrong and everyone knows it.

The graveyard is not a discipline problem. It is an architecture problem.

Human-maintained knowledge bases collapse under their own weight because the maintenance cost scales with organisational complexity while the value degrades the moment someone stops updating them. The fundamental design flaw: they require humans to create and maintain the graph. That worked when the knowledge was for humans. It breaks when the knowledge needs to serve autonomous AI agents at enterprise scale.

This is the post about what breaks and when, not to dismiss these tools, but to be precise about the boundary where they stop being sufficient.

What Notion and GitHub Actually Give You

To be fair: Notion is genuinely good at what it is designed for. It powers over 70% of Fortune 500 teams. Its Enterprise Search indexes your entire workspace and connected tools, including Slack, Google Drive, GitHub, and Jira, and achieves around 90% accuracy on factual queries against well-organised workspaces. It is the right tool for human knowledge workers finding information.

GitHub is excellent at version-controlled documentation. Commit history, blame, diffs: you always know who changed what and when. For engineering teams, it is the closest thing to disciplined documentation that actually gets maintained.

Andrej Karpathy’s llm-wiki approach, using Claude Code or similar to automatically organise an Obsidian vault with a raw staging folder and LLM-maintained synthesis layer, is genuinely clever and solves the maintenance weight problem for personal knowledge bases. It went viral in April 2026 for a reason: it touched the nerve of every knowledge worker who has watched their Obsidian vault go stale.

The honest limitation Karpathy himself acknowledged: it does not scale to millions of documents. More precisely, it is designed for personal use, measured in hundreds of articles, not enterprise scale.

The Five Places These Systems Break at Enterprise Scale

Break Point 1: They require humans to write things down

The knowledge that matters most in an enterprise is almost never written down explicitly.

Who actually makes decisions versus who formally approves them. What the real dependency chain is versus what the architecture document says. Which engineer is the actual expert on the authentication system even though they are not the listed owner. What the shadow influence patterns are: who needs to sign off informally before anything moves.

This knowledge lives in signals: who participates in which Slack channels, who gets tagged in which Jira tickets, who responds to which incidents. A Notion database indexes documents. These are not documents.

The HR chatbot that quoted an old parental leave policy: that policy was in Notion, correctly filed, accessible. It was never updated when the policy changed because nobody had the update notification set, nobody owned the page, and the person who created it had left the company. This is not a discipline failure. It is a system that depends entirely on human maintenance to stay accurate.

An organisation of 500 people generates thousands of signals every day that contain structural knowledge: who owns what, who decided what, what changed and why. A human-maintained knowledge base captures 2% of that if the team is disciplined. The other 98% evaporates.

Break Point 2: They have no concept of entity resolution

“Sarah Chen” in Salesforce, “sarah.chen@company.com” in Zendesk, “Sarah” in a Slack message, and “SC” in a meeting note are the same person. Notion does not know this. GitHub does not know this. A vector search over these systems treats them as four different entities.

When an agent queries “what is the history of this customer account,” it gets a partial and fractured picture: some records from one system, some from another, none of them linked. The agent is reasoning about four different people who happen to be the same person.

Entity resolution, mapping all surface forms to a single canonical identity, is a prerequisite for useful organisational context at scale. It requires HRIS as the authoritative identity anchor, cross-system alias resolution, and a canonical entity registry. Neither Notion nor GitHub has this. Neither can have it: it requires access to authoritative sources across systems that live outside these tools.

Break Point 3: They give you current state, not temporal truth

Notion shows you what a page says today. GitHub blame shows you who last changed a line. Neither can answer: what was the contract terms when this agent approved that transaction last Tuesday?

This distinction is trivial when humans are the consumers. Humans know that the current page reflects changes made since they last read it. They can ask colleagues for context. They can use judgment.

It is not trivial when agents are the consumers. An agent that approved a transaction last Tuesday acted on the information available at that moment. If the policy changed on Wednesday, the current Notion page is wrong for the purpose of auditing what the agent knew on Tuesday.

Enterprise temporal questions are constant: what were the approval thresholds when this decision was made? Who owned this system when this incident occurred? What was the contract SLA when this breach happened? None of these questions are answerable from a system that only stores current state.

Tracking temporal truth requires every fact to carry valid_from, valid_until, source authority, and last-confirmed timestamp. When a fact changes, the old version is superseded not deleted. Neither Notion nor a Git-based knowledge base has this architecture. Adding it requires rebuilding the storage layer from scratch.

Break Point 4: They cannot coordinate multiple agents acting simultaneously

This break point does not exist for human knowledge workers because humans naturally serialise coordination. You ask a colleague before overwriting their work. You notice when two people are editing the same document. The social coordination layer handles conflicts.

Agents do not have this. When 50 agents operate simultaneously on shared organisational context, they need a storage layer that detects and surfaces conflicts before they corrupt state. Agent A reads that Priya owns the Salesforce connector. Agent B, acting on a slightly stale snapshot, routes an escalation to the previous owner. Neither agent knows about the conflict. The user gets a broken experience.

Notion has no concept of concurrent agent coordination. GitHub’s branching model handles code conflicts but has no semantic conflict detection: two agents making contradictory structural decisions cannot be caught by a merge conflict check.

This is the problem that requires Optimistic Concurrency Control at the storage layer, detecting when two agents acted on conflicting views of the world and surfacing it before downstream consequences compound. It is not something you add to an existing knowledge base. It requires ground-up architecture.

Break Point 5: They have no jurisdiction model

A Notion workspace has no concept of the difference between EU-only data and US-only data. A GitHub repository has no concept of which documents can be combined with which other documents given regulatory constraints.

When an agent retrieves context for a task that spans jurisdictions, such as an EU customer’s data, a US policy document, or a global system dependency, and combines them into a derived artifact, that artifact may have regulatory restrictions that no part of the original system can enforce.

Standard retrieval has no concept of jurisdiction. It returns everything it finds that is semantically relevant. The regulatory problem lives entirely outside the knowledge base.

Where Notion and GitHub Are Still the Right Answer

This is important to say clearly: for human knowledge workers finding and creating information, Notion remains the right choice for most teams. Notion powers over 70% of Fortune 500 teams for good reason. It is excellent at what it does.

GitHub is still the right place for version-controlled code and engineering documentation. The commit history is genuine temporal tracking for code changes. For the problem of “what did our code look like when this bug was introduced,” Git is the correct answer.

The Karpathy llm-wiki pattern is genuinely useful for personal and small-team knowledge management where the knowledge base is measured in hundreds of documents, maintenance by a single person or small team is feasible, and the consumers are humans, not agents.

The boundary where these tools stop being sufficient is specific:

When agents, not humans, are the primary consumers
When the knowledge needs to stay current automatically
  without human maintenance
When multiple agents need to act on consistent context
  simultaneously
When temporal truth matters for audit and compliance
When the organisation operates across jurisdictions
  with different regulatory requirements

What Actually Needs to Change

The problem is not that Notion and GitHub are bad tools. The problem is that they were designed for a world where humans are the primary consumers of organisational knowledge. That world is changing.

The shift from agents-as-assistants to agents-as-operators changes the requirements for organisational knowledge infrastructure at a fundamental level:

Automatic ingestion instead of manual documentation. The knowledge base needs to build itself from signals that already exist: Slack, Jira, CRM, HRIS, email. It should not depend on humans to write things down. The 98% of organisational knowledge that is never documented needs to be captured from behavioural signals.

Entity resolution before anything else. The same person, system, or organisation appearing under different names across different systems needs to resolve to a single canonical identity before any fact is recorded. Without this, every extracted relationship is potentially wrong.

Temporal truth, not current state. Every fact needs valid_from, valid_until, source authority, and last-confirmed timestamp. When facts change, old versions are superseded not deleted. The audit trail answers what was true when, not just what is true now.

Storage-layer conflict detection. Multiple agents acting on shared context simultaneously need a coordination mechanism that detects conflicts before they produce incorrect downstream actions. This is not a feature you add to an existing knowledge base. It is an architectural primitive.

Jurisdiction-aware context. The regulatory data class of every piece of information needs to be tracked at the storage level, propagated through derived artifacts, and enforced before agents act on it.

None of these requirements are met by a human-maintained knowledge base, however well-designed. They require a different architecture entirely, one built from the ground up for machine consumption rather than human consumption.

The graveyard of abandoned knowledge systems is not a failure of discipline. It is a failure of architecture. The tools were built for the problem of helping humans find information. The problem that needs solving now is helping agents understand organisations. Those are different problems and they need different infrastructure.

This is Post 3 in a series on enterprise AI agent infrastructure. Post 1 covers the governed agent runtime. Post 2 covers why agents fail when the context layer is built on RAG and document retrieval. Post 4 covers an honest comparison of enterprise AI agent platforms in 2026.