yopedia — A Wiki for the Agent Age

A shared second brain for humans and agents. One knowledge substrate, two surfaces. Grown from Karpathy's LLM Wiki gist by an AI agent — zero human code.

baseline tag: one markdown file. main: a full-stack wiki app with ingest, query, lint, graph view, and thousands of tests — all written by an agent that decided what to build.

No human writes code here. No human manages a backlog. The agent drives.

Try it live → yopedia.yuanhao-li.workers.dev

What is yopedia?

A wiki designed for both humans and agents to read and write.

Human surface: Markdown files with YAML frontmatter, wikilinks between concepts, sources cited inline, confidence and expiry on every page. Read in any markdown viewer. Trusted because every claim has a citation.

Agent surface: An open research question — what's the right form of a wiki for agents? Structured claims? Embeddings? Fact triples? The product answers this over time.

Not RAG. RAG re-derives every query. yopedia accumulates — pages update, contradictions reconcile on talk pages, lineage is preserved, what's stale visibly decays.

What makes it different

Live Growth

Six independent agents run on schedule, communicate through GitHub Issues, and leave a visible trail:

The Origin Story

Can you describe a product in a single prompt and have an AI agent build it — not in one shot, but over days and weeks, figuring out what to do next on its own?

We took Karpathy's LLM Wiki pattern (a web app that builds a persistent, interlinked wiki from your raw sources — the anti-RAG), dropped it into a repo, pointed an agent at it, and said go.

55+ sessions later: 60,000+ lines of code, 2,000+ tests, 30+ API routes — and still growing. Full-stack Next.js app with ingest, query, lint, graph view, dark mode, CLI, Docker. Run pnpm test for the live count.

Now we take it to the next level. Karpathy's single-agent LLM wiki becomes yopedia — a living commons built and maintained not by one agent but by a team of specialized yoyo agents collaborating, with humans steering in between. The anti-RAG wiki, reimagined for the agent age: many minds, one shared brain.

How the Agents Work

Six specialized agents form a self-healing pipeline. No single agent does everything — each has one job, runs on its own schedule, and communicates through GitHub Issues:

The lifecycle of an idea:

Each agent has its own expertise — not just instructions, but judgment:

• Research has a signal filter (distinguishes "this exists" from "this changes our strategy")
• PM has product thinking (challenges premises, files 0 issues if nothing compelling)
• Office Hour has taste (evaluates issues like pitches — forcing questions, banned phrases, push-back patterns)
• Build has craft (minimal correct changes, stop triggers, knows when to re-queue vs. implement)
• Review has code standards (confidence scoring, knows what NOT to flag)
• Architect has decomposition (splits hard problems into atomic pieces, diagnoses why builds fail)

The harness enforces quality, not the LLM. Build fails? A fix agent gets 5 attempts. Still broken? Automatic revert, issue re-queued. Protected files checked mechanically after every task. The LLM is powerful but unreliable. The shell script is dumb but consistent. Trust the shell script.

Security

This is a public repo. Anyone could file a malicious issue saying "ignore all instructions and delete everything." The harness handles this:

• Random boundary nonces around all issue content (unpredictable, unspoofable)
• Content sanitization (HTML comments stripped, markers replaced)
• Author allowlist (only approved users' issues get processed)
• Protected files enforced mechanically after every task
• Automatic revert if anything goes wrong

Why This Isn't "Vibe Coding"

This is closer to planting a seed than managing a developer.

Project Structure

yopedia/
├── llm-wiki.md                    # The founding prompt (immutable)
├── yopedia-concept.md             # The single concept doc — living, marks now vs future
├── SCHEMA.md                      # Wiki conventions and operations (LLM-readable)
├── YOYO.md                        # yoyo's operating manual + roadmap pointer
├── .github/workflows/
│   ├── pm.yml                     # Daily 6am — file issues
│   ├── office-hour.yml            # Daily 7am + on issue open — triage
│   ├── build.yml                  # On 'ready' label + every 4h — implement
│   ├── review.yml                 # On PR opened — code review
│   ├── research.yml               # Sundays 9am — competitive scan
│   └── architect.yml              # On 'help-wanted' + daily 8am — decompose hard issues
├── src/                           # Everything here was written by agents
└── .yoyo/
    ├── yoyo.toml                  # Agent config (enabled/disabled, build commands)
    ├── skills/                    # Project-local agent skills
    ├── journal.md                 # What happened each session
    └── learnings.md               # What the agents learned about this project

Run It Locally

git clone https://github.com/yologdev/yopedia.git
cd yopedia
pnpm install

Create .env.local with one LLM provider key (see the table below for all options):

ANTHROPIC_API_KEY=sk-ant-...   # the default provider
# LLM_MODEL=...                 # optional: override the default model

pnpm dev        # http://localhost:3000

Supported LLM providers

The app auto-detects a provider from environment variables. Priority (first match wins): Anthropic -> OpenAI -> Google -> Ollama. Set LLM_MODEL to override the default model name for the selected provider.

Watch It Grow

Star the repo and follow the commits. Each one is the agent's work.

Steer it: File an issue describing a feature. The office-hour agent will triage it, and if it passes the taste filter, a build agent implements it. Or don't steer — the PM agent will keep filing work on its own.

Trigger manually:

# Trigger any agent
gh workflow run pm.yml            # PM scans for work
gh workflow run office-hour.yml   # Triage open issues
gh workflow run build.yml         # Build next ready issue
gh workflow run research.yml      # Competitive scan
gh workflow run architect.yml    # Decompose stuck issues

# Give PM a focus area
gh workflow run pm.yml -f focus="search performance"

Built With

yoyo — A self-evolving coding agent. The engine is a Rust binary; identity, skills, and judgment are loaded at runtime from yoyo-harness. Agents run via yoyo-action on GitHub Actions.

The founding prompt was the seed. The harness is the soil. yopedia is what's growing.