From Karpathy's LLM Wiki to the Company AIOS: Why Every Organisation Needs Its Own Knowledge Graph

Andrej Karpathy floated an idea recently that landed harder than most. The pitch was simple. Every person should have their own LLM wiki. A structured, machine-readable folder of context about who you are, what you know, what you have done, and what you are currently working on. Drop it into any model and the model becomes useful to you specifically, not to a generic user.

It is a clean idea. It is also, in my view, the missing piece behind every failing enterprise AI rollout.

Because what is true for a person is more true for a company. And nobody has been saying the quiet part out loud: the future is not better foundation models. The future is custom company LLMs grounded in custom company knowledge graphs.

What Karpathy Was Actually Pointing At

The LLM wiki idea works because of one observation. Large language models are general intelligence engines. They reason brilliantly. But without context, they reason about nothing in particular. Give the same model a structured wiki about you and your work and suddenly its output is sharp, personal, and useful.

The wiki is the trick. Not the model.

Now scale that observation up. A company is not one person. It is dozens or thousands of people, each with their own context, projects, decisions, customers, and history. Most of that context lives in fragments. Slack threads. Google Drive. Notion. Email chains. Salesforce. HubSpot. Jira. Recorded meetings. The heads of people who have been there long enough to know how things actually work.

This is the same problem Karpathy described, but multiplied by every team, every system, and every year of operating history. The model is not the bottleneck. The structured context is.

Personal Wiki, Organisational Graph

Where I think the framing needs to extend is at the company level. A personal wiki can be flat. A folder of markdown files. The volume is small enough that flat works.

A company cannot be flat. The information has relationships. A customer is connected to deals, conversations, support tickets, contracts, and the team members who own them. A decision made in a leadership meeting last quarter is connected to a roadmap change that is connected to engineering tickets that are connected to a launch that is connected to revenue. Flatten any of that and you lose the meaning that makes the data useful in the first place.

This is why the right structure for organisational context is a knowledge graph. Nodes for the entities your business actually cares about. Edges for the relationships between them. Metadata for context. The graph holds the shape of the company in a form an AI model can traverse.

Karpathy's personal wiki idea, scaled to the org level, becomes a unified company knowledgebase backed by a custom knowledge graph.

Cloud-Hosted Data Is the Substrate

The other half of this is where the data lives. A personal wiki sits in a folder on your laptop. An organisational graph has to live somewhere that every system, every employee, and every AI agent can read from and write to. That means cloud-hosted, accessible by API, governed, and versioned.

Most companies already have the raw inputs in the cloud. Salesforce, HubSpot, Google Workspace, Microsoft 365, Notion, Slack, Linear, Stripe, your data warehouse. The information is there. What is missing is the layer that pulls it together into a single graph, normalises the entities, maps the relationships, and exposes it to AI.

When we build an AIOS for a client, this is one of the first things we ship. We pull from every cloud source the team already uses, we build a knowledge graph that models the business, and we host it as the substrate every downstream agent reads from. The cloud data stays where it is. The graph sits above it, indexing and connecting, and acts as the brain.

Why Custom Company LLMs Are the Endpoint

If you grant that organisational context belongs in a structured graph and that the graph should be queryable by any AI model, the next question is what model.

The default answer today is whatever foundation model the team is using. Claude. ChatGPT. Gemini. You wire the graph in via RAG or tool calls and the model reasons against your data. That works well, and for most engagements that is exactly what we build.

But the trajectory is clear. The companies investing seriously in AI right now are heading toward custom LLMs. Not custom in the sense of pretraining from scratch. Custom in the sense of fine-tuned on the company's own data, instruction-tuned for the company's own workflows, and deployed with the company's own knowledge graph wired in by default.

A custom company LLM trained on your own knowledge graph, your own decisions, your own writing, your own product, will outperform a generic frontier model on your work every single time. It will use your terminology correctly. It will reason about your customers the way your best operators do. It will draft in your brand voice without prompting. It will know what is true about your business at any point in time because the graph keeps it current.

This is the endpoint. The foundation models become the substrate. The knowledge graph becomes the company's brain. The custom LLM becomes the operator that speaks for the company on every surface.

The AIOS as the Container

This is what an AI Operating System actually is. It is not a single product or a single agent. It is the container that holds all of this together.

An AIOS has three pillars. A knowledge graph and ML audit that models the company and surfaces where AI pays off. A unified company knowledgebase that every team, tool, and agent reads from and writes to. And a layer of production agents and automations that ride on top, grounded in the same context.

Karpathy's wiki is the personal version of pillar two. We extend that idea across the entire organisation and then build the other two pillars around it.

The companies winning with AI in 2026 are the ones that have moved past the experiment phase and built this stack. The companies still pasting documents into chat windows are not behind by months. They are behind by an architecture.

What This Looks Like in Practice

A few patterns we ship into client AIOS engagements that follow from this thinking.

**The knowledge graph is the diagnostic, not just the substrate.** When we map a company into a structured graph in the first month of an engagement, the graph itself reveals where the highest-ROI automations sit. Bottlenecks, knowledge gaps, redundant workflows, and orphaned data all become visible. You cannot find them on a whiteboard. You can find them in a graph.

**The knowledgebase is single source, multiple entry points.** Sales reads it. Ops writes to it. Support queries it. The leadership team reviews it. Agents pull from it. The same brain serves every surface, so the company stops drifting against itself.

**Cloud data stays where it is.** We do not migrate Salesforce. We do not rip out HubSpot. We do not force you off Google Workspace. The graph indexes everything in place. Lock-in to any one vendor becomes a non-issue because the AIOS sits above the stack.

**Custom LLM work compounds.** Once the graph exists and once the agents are running against it, every interaction generates new structured context. The system gets sharper the longer it runs. A custom company LLM trained against this graph six months in is meaningfully more capable than one trained against a snapshot today.

The Takeaway

Karpathy is right that personal LLMs need wikis. He is also pointing, whether he meant to or not, at the entire trajectory of enterprise AI. The wiki at the personal scale is a folder. At the organisational scale it is a knowledge graph. At the operational scale it is an AIOS. And at the endpoint it is a custom company LLM grounded in all of the above.

If you are running a company in 2026 and you do not have this stack, you are not behind on AI features. You are behind on AI infrastructure. The agents you can buy off the shelf today will only ever be as smart as the context you can hand them. Build the context layer and everything else compounds.

That is the work we do at Sentry AI. If you want to see what a knowledge-graph-backed AIOS looks like in production, the [MacroActive AIOS](/use-cases/macroactive-aios) and [TEA AIOS](/use-cases/tea-aios) case studies are good places to start.