DEV Community: linz001

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

linz001 — Tue, 23 Jun 2026 01:42:06 +0000

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:

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.
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.
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:

Sign up at brain2.wiki and create an API key.
Install the brain2-wiki Skill in your AI editor.
Explore featured common brains — health (5,406 topics) and cooking (3,955 topics) — to see search and read in action.
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.

Turn Your Best AI Conversations Into a Blog — and Give Your Model a Memory That Lasts

linz001 — Tue, 23 Jun 2026 01:39:47 +0000

Turn Your Best AI Conversations Into a Blog — and Give Your Model a Memory That Lasts

blogs.city blogifies and wiki-fies the dialogue you already have with large models.

Every week you have conversations worth keeping: a debugging session that finally clicked, a research thread that surfaced the right papers, a design argument you do not want to lose in the chat scroll.

Then the tab closes. The model forgets. Next session starts from zero.

blogs.city exists to fix that loop. Register, connect your AI editor — Claude Code, Cursor, Trae, OpenClaw, or any editor that speaks Skills — and turn high-value exchanges into published posts, wiki pages, and durable body-text memory your model can read back on the next turn.

Not another chat wrapper. Infrastructure that makes LLM dialogue compound.

The missing step: from dialogue to corpus

AI editors are good at now. They are weak at what we already figured out unless you rebuild context every time.

blogs.city sits between the conversation and the archive:

You + LLM talk  →  publish the outcome  →  blog + wiki  →  next session reads the body

The publish Skill accepts Markdown from your editor. Categories resolve automatically. Images and charts land in the right place. Before writing something new, the editor can search and read your existing posts — so the model builds on prior work instead of repeating it.

One pipeline. No copy-paste cleanup. The conversation becomes the record.

Works with Hermes, OpenClaw, and the AI editor you already use

blogs.city is not tied to a single vendor. It ships a publish Skill that any compatible AI editor can load.

Hermes users get a direct fit. Hermes organizes local LLM wikis around ingest, query, and lint — read SCHEMA, scan index, check log, then write. blogs.city exports the same shape into your live blog:

Hermes convention	On blogs.city
`SCHEMA.md`	Auto-generated under `wiki/SCHEMA.md` — domain, tag rules, page thresholds
`index.md`	Auto-generated — Entities, Concepts, Comparisons, Queries
`log.md`	Auto-generated activity log
ingest / query / lint	Publish templates + `wiki-audit` + `wiki-next`

Same mental model on the desk: Hermes on a local wiki tree, blogs.city on your hosted corpus. One user, one discipline — two surfaces, aligned semantics.

OpenClaw and other AI editors connect the same way: issue a personal API token, install the publish Skill, and post from the editor. blogs.city is the receiving end — the place dialogue lands when it is ready to become knowledge on your blog.

Blogify the exchange. Wiki-fy the library.

Not every chat message deserves a post. The ones that do — a resolved concept, a synthesis across sources, an entity page for a tool you rely on — get structured roles:

Page role	What it captures
Source	Digest of an external paper, doc, or URL — the raw edge of your corpus
Concept	A term or idea your threads keep returning to
Entity	A person, product, or tool worth a stable reference page
Synthesis	A query answered across multiple prior posts
Article	Everything else — tutorials, notes, field reports

Categories tell you which topic domain. Page type tells you which wiki job. Links live inside the prose, where they carry meaning — not only in a footer block.

Readers get a normal blog and a Wiki Hub browsable by idea. Your AI editor gets an index it can scan before the next draft.

That is blogification plus wiki-fication: timeline for humans, graph for models.

Body-text memory: what you publish becomes what the model remembers

Chat memory is shallow — truncated, session-bound, often wrong.

Body-text memory is different. Every published post is plain Markdown on disk. The catalog, search, and read APIs expose the full text to your AI editor. Auto-generated wiki/index.md, wiki/log.md, and wiki/SCHEMA.md give offline workflows the same orient step Hermes expects: schema first, index second, then write.

On the next session:

Editor calls catalog — what concepts, syntheses, and entities already exist
Search pulls candidates by keyword
Read loads full body text into context
New dialogue extends the corpus instead of replacing it

The valuable exchange you had last month is not a faded chat log. It is paragraphs the model can quote, link, and contradict on purpose.

That is the long game: your blog is your LLM's external memory — auditable, linkable, yours.

Full blog, ready on day one

Posts, nested categories, tags, archives, comments, RSS. Five built-in themes. Interactive charts in Markdown. Mobile layout, infinite scroll, favorites and reading history. SEO fields on publish. AI-assisted comment screening.

You get a real blog — with the AI wiring where it matters: publish, discover, link, remember.

Your files stay yours

Markdown files on disk. Redis for index speed. Backup and offsite sync. Export to Obsidian Vault ZIP or single-post PDF. Wiki views regenerate from the catalog — never a second source of truth.

The platform runs the house. You keep the keys and the corpus.

Write in your AI editor. Read anywhere.

Web, Windows desktop app, Android, iPhone home-screen PWA — same blog on every device. Dialogue happens in the editor; reading happens wherever you are.

Who this is for

Anyone who already thinks in long threads with a large model — and is tired of re-explaining the same context every Monday.

If your best work lives in chat history today, blogs.city is where it should live tomorrow: on your blog, in your wiki, in body text your model can read back.

Start here

Register at blogs.city.

Connect Hermes, OpenClaw, or your AI editor. Publish the next conversation worth keeping.

Your model talks fast. Give those talks a city to remember.

blogs.city — AI-native blogging. Dialogue in, corpus out.