Your AI Has No Long-Term Memory. You Need an External Brain

How Karpathy-style LLM Wikis, cloud sync, and agent-native APIs are changing the way researchers and developers store knowledge

Every knowledge worker has lived through the same cycle.

You spend an afternoon reading papers, scanning documentation, or chasing down a thread across a dozen browser tabs. You paste the highlights into a chat window. The model gives you a crisp summary. You feel productive.

A week later, you ask a follow-up question. The model has no idea what you read. It improvises. You spend twenty minutes reconstructing context you already paid for once.

This is not a failure of intelligence. It is a failure of memory architecture. Large language models are extraordinary reasoning engines, but they are poor custodians of your personal knowledge. Chat logs disappear. Notes apps become graveyards. Folder trees of markdown files rot without structure. One-shot retrieval pipelines are expensive, brittle, and disconnected from how you actually think.

What you need is not another note-taking app. You need an external brain: a structured, searchable, durable knowledge base that both you and your AI agents can read and write over time.

That is the problem brain2.wiki was built to solve.

The Karpathy insight: wikis, not chat logs

In 2024, Andrej Karpathy articulated a simple but powerful idea: instead of stuffing documents into a vector database and hoping retrieval works, treat knowledge as a living wiki — interlinked markdown pages that accumulate, cross-reference, and compound.

The model does not need to re-read everything from scratch. It orients itself in a structured graph: an index, a schema, entity pages, concept pages, comparison pages. Each page carries frontmatter, wikilinks, and provenance. Knowledge is compiled once and updated incrementally, the way Wikipedia grows rather than the way a conversation evaporates.

This pattern — sometimes called an LLM Wiki — changes the economics of AI-assisted research. You stop paying the same context tax on every session. Your agent reads what already exists, cites specific pages, and writes back new pages when it learns something durable.

brain2.wiki takes that pattern and puts it in the cloud, with an API and a Skill layer designed for agents first and humans second.

What brain2.wiki actually is

brain2.wiki is an external brain knowledge base service. At its core, it hosts Karpathy-style LLM Wiki vaults: markdown knowledge bases organized into entities, concepts, comparisons, and queries, linked together with [[wikilinks]] and governed by a schema.

Each vault is isolated behind a UUID. Your research vault is yours. Your cooking notes are separate from your health references. There is no shared namespace where your private knowledge could leak into someone else's.

The service is built around three ideas:

1. Agents are the primary users. Search, read, ingest, and sync happen through API calls and editor Skills — not through a human browsing a website for answers.
2. Cloud sync keeps vaults durable and portable. You maintain a local wiki in your project; you mirror it to the cloud when ready. Your agent can pull it back on another machine. Your knowledge survives session boundaries.
3. Search must be real. brain2.wiki indexes vault content with trigram full-text search, so agents can find specific passages across thousands of pages — not approximate semantic neighbors, but actual text matches you can verify.

If you have used a local LLM Wiki in Cursor or Claude Code, brain2.wiki is the cloud backbone that makes that wiki persistent, shareable across devices, and queryable at scale.

Getting started: API keys and vault isolation

The onboarding path is deliberately minimal.

You sign up at brain2.wiki, create an API key, and receive a token your agents use for authentication. No OAuth dance. No session cookies your CLI cannot hold. An API key is the right abstraction when the consumer is code.

With that token, you create one or more UUID wiki vaults. Each vault has its own domain, schema, and page graph. UUIDs are not cosmetic — they are the stable identity your Skill and CLI reference on every sync and read operation. Isolation is enforced at the storage layer: your vault's markdown lives in its own namespace on disk and in the index.

This matters if you are a researcher with multiple projects, a developer maintaining separate knowledge bases for work and side projects, or a team that wants clean separation between domains without spinning up separate infrastructure.

The brain2-wiki Skill: where local editing meets cloud sync

The brain2-wiki Skill is the bridge between your AI editor and the cloud service. It works with Cursor, Claude Code, Trae, and other AI editors that support Skills.

The workflow mirrors how serious wiki maintenance should work:

Orient. Before any work, the agent reads your wiki's schema, index, and recent log entries. This prevents duplicate pages, broken links, and taxonomy drift — the silent killers of knowledge bases.

Ingest. New sources land in a raw/ layer. The agent reviews them, extracts durable facts, and writes structured wiki pages with outbound wikilinks. The index and append-only log are updated. Knowledge compounds.

Lint. A hard gate checks frontmatter, link integrity, page length, and review status. Nothing syncs to the cloud until the vault passes lint. Quality is enforced before persistence, not discovered after corruption.

Sync. When the vault is clean, the Skill performs a manifest batch sync: it computes what changed, packages the delta efficiently, and pushes to your UUID vault on brain2.wiki. Large updates go through in batches rather than page-by-page round trips.

The raw/ layer never uploads. Sources stay local; curated wiki pages go to the cloud. That boundary keeps storage lean and respects the distinction between "material I collected" and "knowledge I distilled."

You can also pull an export from the cloud to hydrate a local vault on a new machine, or edit a single page via API when a full sync is overkill.

Featured common brains: knowledge you can query today

Not everyone starts from zero. brain2.wiki ships with featured common brains — curated public vaults seeded with structured, searchable content that any registered user can query through the API.

Two examples are live now:

Public Health Brain — a public health external brain with 5,406 searchable topics covering nutrition, wellness, symptoms, and related domains. Agents can search and read pages through stable slug-based URLs without building a health wiki from scratch.

Public Cooking Brain — a public cooking external brain with 3,955 searchable topics spanning techniques, ingredients, and recipes. Same API surface, same search-and-read pattern.

These are not marketing demos. They are fully indexed vaults with trigram search, readable by any agent holding an API key. Sign up, install the brain2-wiki Skill (or the companion external-brain Skill for query-focused workflows), and your agent can search featured brains immediately while you build your private vault in parallel.

The common-brain API follows a predictable pattern: search by keyword, read selected pages, synthesize locally. Orchestration stays on the agent side; the server provides storage, indexing, and stable endpoints.

Why agent-first changes the design

Most knowledge products assume a human opens a web app, types a query, and reads a rendered page. brain2.wiki inverts that assumption.

The primary consumer is an agent running inside your editor or automation pipeline. It receives a question, extracts keywords, searches your vault (or a common brain), reads up to a few relevant pages, and synthesizes an answer with citations to specific wikilinks. The human's job is curation and judgment; the agent's job is maintenance and retrieval.

This design choice has consequences:

• API keys, not accounts with UI sessions, because agents authenticate programmatically.
• UUID vaults, because stable identifiers survive refactors and sync cleanly across CLI and Skill.
• Manifest batch sync, because agents update dozens of pages at once after an ingest session.
• Trigram search, because agents need deterministic text retrieval they can cite, not opaque embedding rankings.
• Rate limits tuned for agent traffic patterns — higher throughput on search and read endpoints, separate quotas on heavier server-side query operations.

The result is infrastructure, not an app. You do not "use brain2.wiki" the way you use a search engine. You wire it into your agent's toolchain and forget it is there — until you ask a question and your agent answers from pages you wrote three months ago.

A practical picture

Imagine you are researching financial regulation for a project. Over two weeks, your agent ingests PDFs and web sources into a local wiki. Each source becomes entity pages and concept pages, cross-linked in an index. You run lint. You sync to your UUID vault on brain2.wiki.

Six months later, on a different laptop, you ask: "What did we conclude about disclosure requirements for cross-border listings?" Your agent orients in the vault, searches for "disclosure cross-border," reads three pages, and answers with citations. No tab archaeology. No hallucinated recall.

Meanwhile, when you need a quick health or cooking reference, you query the featured common brains through the same API — 9,000+ topics already indexed, no setup required.

That is the compound interest of a wiki over a chat log.

Who this is for

brain2.wiki is built for people who already live inside AI-native editors and want their knowledge to survive beyond a single session:

• Researchers who accumulate sources faster than they can re-explain them to a model.
• Developers using Cursor, Claude Code, or Trae who want project wikis that sync to the cloud and stay lint-clean.
• Anyone building a second brain for agents — where the reader and writer of record is code, not a human scrolling a dashboard.

If you only need a one-off answer, a chat window is fine. If you need knowledge that accumulates, links, and retrieves reliably, you need a wiki and a place to host it.

Start building your external brain

The path from zero to a searchable, agent-readable knowledge base is short:

1. Sign up at brain2.wiki and create an API key.
2. Install the brain2-wiki Skill in your AI editor.
3. Explore featured common brains — health (5,406 topics) and cooking (3,955 topics) — to see search and read in action.
4. Create your own UUID vault, initialize a local wiki, and run your first ingest-and-sync cycle.

Research and conversations become pages. Pages become a graph. The graph becomes memory your agents can actually use.

That is what an external brain is supposed to do.

brain2.wiki — Karpathy-style LLM Wiki in the cloud. Readable and writable by agents. Sync with the brain2-wiki Skill.