Forem: Charles Wu

I Built a Knowledge Base That Thinks — Inspired by Karpathy’s LLM Wiki

Charles Wu — Thu, 30 Apr 2026 02:15:07 +0000

Notes pile up and go stale. This tool updates your knowledge base automatically — inspired by Karpathy’s LLM Wiki.

Key Takeaways

Inspired by Karpathy’s LLM Wiki, ex-brain is an open-source CLI that compiles new information into existing knowledge pages, extracts timelines, and builds entity links automatically — so your notes stay current instead of just piling up.
The search layer uses seekdb’s native hybrid search (BM25 + vector similarity in one query), with built-in AI functions for embedding and reranking — no external retrieval pipeline needed.
Ships with a built-in MCP server so Claude can read, write, search, and compile your knowledge base directly.

Andrej Karpathy’s LLM Wiki dropped a simple idea: store knowledge as plain text, let an LLM understand and update it. Garry Tan’s GBrain ran with the same concept. Both projects prove that LLM + local storage is a surprisingly powerful combination for personal knowledge management.

But after using them, I kept hitting the same wall: notes pile up, nothing gets updated, and finding connections between pieces of knowledge requires me to do all the work. So I built ex-brain — a CLI tool that compiles, links, and evolves a personal knowledge base using LLMs.

What ex-brain Does

At a high level, ex-brain provides four mechanisms that standard note-taking tools don’t:

Smart compilation — New information updates existing knowledge instead of just appending to it
Automatic timeline extraction — Events are pulled from text and organized chronologically
Entity linking — Relationships between people, companies, and concepts are detected and cross-referenced automatically
Hybrid search — Keyword precision and semantic understanding in one query, powered by seekdb

The result: a knowledge base that behaves less like a filing cabinet and more like a memory that keeps itself current.

The Problem with “Just Take Notes”

Tools like Notion and Obsidian are great at storing information. They’re terrible at keeping it current. You write a note about a company’s Series A in March, their new CEO in June, and their Series B in August — and six months later, you have to read all three notes and mentally reconstruct the current state.

AI-powered alternatives like Mem or Granola add summarization, but the intelligence is a black box. You can’t control how it categorizes, what it prioritizes, or when it decides something is outdated.

The human brain doesn’t work this way. When you learn that a company raised a Series B, you don’t file it next to the Series A note — you update your mental model. The Series A becomes history. The Series B becomes current state.

ex-brain applies the same principle to a knowledge base.

Mechanism 1: Compiled Truth

Run a single command to feed new information into an existing knowledge page:

ebrain compile companies/river-ai \  
"River AI closed Series A, $50M" \  
--source meeting_notes \  
--date 2024-05-20

The LLM analyzes the information type — is this a status change (funding stage moved from Seed to Series A), a new fact (founded in 2020), or an event (product launched)? — then applies the right update strategy:

The compiled page always reflects current truth:

## Status
- **Funding Stage**: Series A (Source: meeting_notes, 2024-05-20)
- **Valuation**: ~$50M

## History
- Previously Seed (until 2024-05-20)

## Facts
- Series A led by Sequoia
- Founded 2020

No manual reorganization. No stale information buried in a page you’ll never re-read.

Mechanism 2: Timeline Extraction

Time is the axis that makes knowledge useful. ex-brain extracts events from compiled pages and structures them chronologically:

ebrain timeline extract companies/river-ai

[ 
 {  
   "date": "2024-05-20",  
     "summary": "Series A closed, $50M",  
       "detail": "Led by Sequoia" 
        }, 
         {   
          "date": "2024-06-15",  
            "summary": "Sarah Chen appointed CEO" 
             }
           ]

Date parsing handles ISO, natural language (last week, yesterday), and localized formats. Timeline extraction runs automatically during compilation — every compile that contains an event adds it to the timeline.

Mechanism 3: Entity Linking

A piece of knowledge is rarely about one thing. “Ali Partovi is the founder of Neo” connects a person, an organization, and a role. ex-brain uses LLMs to detect these relationships:

ebrain put people/ali-partovi --file notes.md

# Detected:
# - Ali Partovi founder_of Neo
# - Ali Partovi invested_in [other companies]

When a new entity is detected, the system creates a stub page for it automatically:

# people/sarah-chen

## Facts
- **CEO_of** [River AI](companies/river-ai): appointed June 2024

The knowledge graph grows organically as you add information. No manual tagging, no predefined ontologies.

Mechanism 4: Hybrid Search with seekdb

Single-mode search breaks down fast in a knowledge base. Full-text search is precise but misses semantics — search “funding” and you won’t find “financing round.” Vector search understands meaning but can be noisy — search “Sequoia” and you might get results about trees.

ex-brain uses seekdb as its search and storage layer. seekdb is an AI-native database that unifies vector search, full-text search, and scalar filtering in a single engine. One query combines BM25 keyword matching with vector similarity — no need to stitch two retrieval systems together.

# Keyword search
ebrain search "River AI Series A"

# Semantic queryebrain query
 "Which companies raised funding recently?"

Under the hood, seekdb supports multi-stage retrieval: vector and full-text indexes recall candidates independently, then results are fused via weighted combination or Reciprocal Rank Fusion (RRF), with optional LLM-based reranking for precision.

ex-brain adds a scoring layer on top:

Semantic relevance (85%) — vector similarity
Freshness (10%) — recently updated content ranks higher
Type weight (5%) — people pages get a slight boost

Why seekdb

Several properties made seekdb the right fit for this project:

Embedded mode, zero ops. seekdb runs as a single database file — no server process, no Docker container. For a local-first personal tool, this is the lightest possible deployment. It runs comfortably on 1 CPU core and 2 GB of memory.

Native hybrid search. Vector search (HNSW, IVF, and quantized variants), full-text search (BM25 with phrase and boolean matching), and scalar filtering — all in one engine with multi-stage ranking pipelines.

Built-in AI functions. AI_EMBED generates vector embeddings in SQL. AI_COMPLETE runs text generation. AI_RERANK applies reranking models. These work with OpenAI, DashScope, or custom model endpoints. Embedding, retrieval, and inference happen inside the database — no external pipeline needed.

SQL-compatible. seekdb is built on the OceanBase engine and speaks MySQL-compatible SQL. Standard CREATE TABLE, CREATE INDEX, and query syntax. Full ACID transactions with real-time write visibility.

Multi-model data. Vectors, text, scalars, JSON, and GIS data coexist in the same engine. ex-brain stores structured metadata (page properties, entity links) and unstructured content (text, embeddings) in one database.

Here’s the core integration code:

// Connect — it's just a file pathconst
 db = await BrainDb.connect("~/.ebrain/data/ebrain.db");

 // Create a vector collection
 const pages = await db.getOrCreateCollection({ 
  name: "ebrain_pages", 
   embeddingFunction: createBrainEmbeddingFunction(settings.embed),});
   // Hybrid search
   const hits = await pages.hybridSearch({ 
    query: { whereDocument: { $contains: "funding" } }, 
     nResults: 10,
     });

MCP Integration

ex-brain ships with a built-in MCP server. If you use Claude, connect it in one step:

{ 
 "mcpServers": {  
   "ebrain": {   
      "command": "ebrain",   
         "args": ["serve"] 
            } 
             }
             }

Claude can then read pages (brain_get), write pages (brain_put), search (brain_search), compile new information (brain_compile), and create links (brain_link) — directly against your local knowledge base.

Get Started

# Installbun
 install -g ex-brain

# Initialize
ebrain init
# Create your first page
ebrain put companies/river-ai --type company --content "
River AI is an AI analytics platform.
Founded 2020."

# Compile new information
ebrain compile companies/river-ai \ 
 "River AI closed Series A, Sequoia led" \  
 --source news \  
 --date 2024-05-20

 # Search
 ebrain search "River AI funding"

 # Start MCP servere
 brain serve

What’s Next

ex-brain is early-stage. The compilation logic isn’t perfect, timeline extraction occasionally misses events, and entity detection produces false positives. But the core idea works: knowledge should update itself when new information arrives, not just accumulate.

A few directions worth exploring: conflict detection when new information contradicts existing records, confidence decay for stale data, bidirectional propagation when linked entities change, and batch compilation for high-volume ingestion.

If you’re interested in building knowledge tools — or if you just want a second brain that actually keeps up — check out ex-brain.

About seekdb

ex-brain’s storage and retrieval layer is powered by seekdb — an open-source, AI-native database that unifies vector search, full-text search, structured data, and built-in AI functions in a single engine. Whether you’re building RAG pipelines, semantic search, or AI agent applications, seekdb handles storage and retrieval without the need to stitch together multiple systems.

If you’re building an application that needs storage + semantic search + AI inference, give seekdb a try:

Website: https://www.seekdb.ai/
GitHub: https://github.com/oceanbase/seekdb
Install: pip install -U pyseekdb
Docs: https://docs.seekdb.ai/seekdb/seekdb-overview/

How to Write Workflow Skills: Patterns and Best Practices Distilled from 7 Top Projects

Charles Wu — Wed, 29 Apr 2026 02:15:20 +0000

Five patterns distilled from Skills at OpenAI, Google Labs, obra, and more.

What Is a Skill?

A Skill is a folder centered around a SKILL.md file, using YAML frontmatter + Markdown body format. When an LLM determines a Skill is needed, it invokes the skill tool to load it. The entire content of SKILL.md is injected into the conversation context as a tool-result, and the LLM autonomously decides how to execute the instructions.

my-skill/
├── SKILL.md          # Main file (required)
├── scripts/          # Executable scripts (optional)
├── references/       # Detailed reference docs (optional, load on demand)
├── resources/        # Templates, checklists, etc. (optional)
└── examples/         # Examples (optional)

Key Mechanism: A Skill is essentially “knowledge injection” — it doesn’t dynamically generate new tools. Instead, it injects instruction text into the LLM’s context, and the LLM executes those instructions using existing tools (bash, read, edit, etc.).

Frontmatter: The “Facade” That Determines Whether a Skill Gets Loaded

Required Fields

How You Write description Determines Load Rate

# Good description — includes trigger phrases and keywords
description: >
  Deploy applications and websites to Vercel. Use when the user
  requests deployment actions like "deploy my app", "push this live",
  or "create a preview deployment".

# Good description - defines temporal position
description: >
  Use when implementing any feature or bugfix, before writing
  implementation code

# Bad description - too vague
description: Helps with deployment stuff

Core Principles:

List trigger phrases: Write in the things users might actually say (“deploy my app”, “push this live”)
Define temporal position: Explain “before/after what” (e.g., “before writing implementation code”)
Include product keywords: If covering a large platform, list all product names

Optional Extended Fields

Extended fields observed across the 7 Skills:

Five Patterns (Author’s Synthesis)

Pattern 1: Linear Workflow

Applicable Scenario: Operations with clear steps like deployment, installation, or migration.

Representative: openai/skills — vercel-deploy1

Structure:

# Title
## Prerequisites
## Quick Start (Main flow: Step 1 → 2 → 3)
## Fallback
## Troubleshooting

Key Techniques:

Decision Rule: If your Skill can be described as “first do A, then do B, finally do C”, use the Linear pattern.

Pattern 2: Decision Tree + Load-on-Demand

Applicable Scenario: Large platform selection, product navigation, problem diagnosis.

Representative: openai/skills — cloudflare-deploy2

Structure:

# Title
## Authentication (auth prerequisite)
## Quick Decision Trees
### "I need to run code" (classified by user intent)
### "I need to store data"
### "I need AI/ML"
## Product Index

Key Techniques:

Decision Rule: If your Skill covers a knowledge domain with 10+ branches, each with extensive detailed documentation, use the Decision Tree pattern.

Advanced: The same knowledge domain can be split into two Skills:

Navigation type (cloudflare): Selection only, no operations
Operational type (cloudflare-deploy): Includes auth, commands, troubleshooting

Pattern 3: Loop Iteration

Applicable Scenario: TDD, code review, design review — processes requiring repeated execution.

Representative: obra/superpowers — test-driven-development3

Structure:

# Title
## The Iron Law (core principles that cannot be violated)
## Red-Green-Refactor (loop body)
### RED — Write a failing test
### Verify RED — Confirm it actually fails
### GREEN — Write minimal code
### Verify GREEN — Confirm it passes
### REFACTOR — Clean up
### Repeat (back to RED)
## Common Rationalizations
## Verification Checklist (exit conditions)

Key Techniques:

Decision Rule: If your Skill requires the LLM to repeatedly execute a “do → verify → improve” cycle, use the Iteration pattern.

Pattern 4: Baton Loop (Cross-Session Persistence)

Applicable Scenario: Long-term projects requiring multiple iterations across sessions.

Representative: google-labs-code/stitch-skills — stitch-loop4

Structure:

# Title
## Overview (baton mode overview)
## The Baton System (baton file specification)
## Execution Protocol (6-step execution protocol)
### Step 1: Read the Baton
### Step 2: Consult Context Files
### Step 3: Generate
### Step 4: Integrate
### Step 5: Update Documentation
### Step 6: Prepare the Next Baton ⚠️ (Critical!)
## File Structure Reference
## Orchestration Options

Key Techniques:

Decision Rule: If your Skill needs to persist across multiple sessions or requires multiple Agents to collaborate, use the Baton Loop pattern.

Differences from Pattern 3:

Pattern 5: Multi-Phase + Checkpoints + Skill Orchestration

Applicable Scenario: Complex multi-week processes requiring Go/No-Go decisions at key milestones.

Representative: deanpeters/Product-Manager-Skills — discovery-process5

Structure:

# Title
## Key Concepts (+ anti-patterns)
## Phase 1: Frame the Problem
### Activities (which sub-Skills to invoke)
### Outputs (phase deliverables)
### Decision Point 1 (checkpoint: YES/NO + time impact)
## Phase 2-6... (repeated structure)
## Complete Workflow (end-to-end timeline)
## Common Pitfalls
## References (list of cited sub-Skills)

Key Techniques:

Decision Rule: If your Skill spans multiple days/weeks with clear phase divisions and Go/No-Go decision points, use the Multi-Phase pattern.

Special Pattern: Thinking Framework (Controlling “How the LLM Thinks”)

Applicable Scenario: Security audits, code review, architecture analysis — scenarios requiring deep thinking.

Representative: trailofbits/skills — audit-context-building6

Structure:

# Title
## Purpose (positioning: controls thinking mode, not behavior)
## When to Use / When NOT to Use
## Rationalizations
## Phase 1: Initial Orientation
## Phase 2: Ultra-Granular Function Analysis (core)
### Per-Function Checklist
### Cross-Function Flow Analysis
### Output Requirements (format + quantitative thresholds)
### Completeness Checklist
## Phase 3: Global System Understanding
## Stability Rules (anti-hallucination rules)
## Non-Goals (explicitly forbidden actions)

Key Techniques:

Decision Rule: If your Skill requires deep analysis rather than quick execution — controlling “thinking quality” rather than “operational steps” — use the Thinking Framework pattern.

Universal Writing Techniques

Four Tactics to Prevent LLM Laziness

Three Effective Teaching Methods

Three Principles for Safety and Boundaries

Three-Layer Knowledge Architecture

Layer 1: Frontmatter (~100 tokens) → LLM scans all Skills’ descriptions to decide whether to load
Layer 2: SKILL.md body (<5K tokens) → Core instructions, decision trees, process steps
Layer 3: references/ and resources/ (load on demand) → Detailed docs, examples, checklists; LLM reads via read tool as needed

Token Budget (Rule of Thumb):

Which Pattern Should You Use?

What does your Skill need to do?
│
├─ Execute an operation with clear steps
│ └─ → Pattern 1: Linear Workflow
│
├─ Help users choose the right direction among many options
│ └─ → Pattern 2: Decision Tree + Load-on-Demand
│
├─ Repeatedly execute "do → verify → improve" in a single session
│ └─ → Pattern 3: Loop Iteration
│
├─ Sustain a long-term project across multiple sessions
│ └─ → Pattern 4: Baton Loop
│
├─ Span multiple days/weeks with phase divisions and Go/No-Go decisions
│ └─ → Pattern 5: Multi-Phase + Checkpoints
│
└─ Require LLM to perform deep analysis rather than quick execution
  └─ → Special Pattern: Thinking Framework

Quick-Start Templates

Minimal Viable Skill (Linear Pattern)

---
name: my-skill
description: "[One-sentence description of what it does + when to trigger]"
---

# Skill Name

[One-sentence description of core principles + safe defaults]

## Prerequisites
- [Prerequisite 1]
- [Prerequisite 2]

## Steps

### Step 1: [Action]
[Specific command]

### Step 2: [Action]
[Specific instruction]

### Step 3: [Action]
[Specific instruction]

## Troubleshooting
| Issue | Solution |
|-------|----------|
| [Problem 1] | [Solution] |

Loop Iteration Skill Template

---
name: my-loop-skill
description: [Description of what it does + when to trigger]
---

# Skill Name

## Core Principle
[The iron law]

## The Loop

### Phase A - [Action]
[Specific instruction]

### Verify A
[Verification command]

### Phase B - [Action]
[Specific instruction]

### Verify B
[Verification command]

### Repeat
Back to Phase A.

## Rationalizations
| Excuse | Reality |
|--------|---------|
| "[Excuse 1]" | [Rebuttal] |

## Completion Checklist
- [ ] [Condition 1]
- [ ] [Condition 2]

Quick Reference: 7 Skills Analyzed in This Article

Built a Skill using these patterns? I’d love to see it — drop a link in
the comments.

👏 Clap if this helped · 🔔 Follow for more Agent engineering content

References

[1] openai/skills — vercel-deploy: https://github.com/openai/skills/tree/main/skills/.curated/vercel-deploy

[2] openai/skills — cloudflare-deploy: https://github.com/openai/skills/tree/main/skills/.curated/cloudflare-deploy

[3] obra/superpowers — test-driven-development: https://github.com/obra/superpowers/tree/main/skills/test-driven-development

[4] google-labs-code/stitch-skills — stitch-loop: https://github.com/google-labs-code/stitch-skills/tree/main/skills/stitch-loop

[5] deanpeters/Product-Manager-Skills — discovery-process: https://github.com/deanpeters/Product-Manager-Skills/tree/main/skills/discovery-process

[6] trailofbits/skills — audit-context-building: https://github.com/trailofbits/skills/tree/main/plugins/audit-context-building/skills/audit-context-building

[7] Agent Skills Open Standard: https://agentskills.io/

[8] anthropics/skills — Official Template: https://github.com/anthropics/skills/tree/main/template

[9] anthropics/skills — Specification: https://github.com/anthropics/skills/tree/main/spec

[10] openai/skills: https://github.com/openai/skills

[11] obra/superpowers: https://github.com/obra/superpowers

[12] google-labs-code/stitch-skills: https://github.com/google-labs-code/stitch-skills

[13] deanpeters/Product-Manager-Skills: https://github.com/deanpeters/Product-Manager-Skills

[14] trailofbits/skills: https://github.com/trailofbits/skills

[15] openclaw/clawhub: https://github.com/openclaw/clawhub

[16] VoltAgent/awesome-agent-skills: https://github.com/VoltAgent/awesome-agent-skills

[17] travisvn/awesome-claude-skills: https://github.com/travisvn/awesome-claude-skills

The Database Bottleneck You Never Saw Coming: Why 50ms Will Make or Break Your AI Agent in 2026

Charles Wu — Tue, 28 Apr 2026 01:59:07 +0000

The uncomfortable truth about AI infrastructure that nobody is talking about — and why your stack might be optimizing for the wrong metric

In February 2026, a machine learning engineer at a well-funded fintech startup discovered something that kept her awake at night.

Her AI-powered ad recommendation system was technically “working.” The vector database was returning results. The embedding model was generating similarities. The API was responding with HTTP 200 codes.

But the advertisers were seeing creative assets that were 2 seconds stale.

In programmatic advertising, 2 seconds is a lifetime. User intent has shifted. Inventory has been sold. The ad the AI thought was perfect was targeting a context that no longer existed.

The culprit? Not the embedding model. Not the ranking algorithm. Not even the API layer.

The humble CDC (Change Data Capture) synchronization link between their SQL database and their vector store.

This is the story that isn’t being told in the AI revolution conversations. While everyone obsesses over model benchmarks, context windows, and prompt engineering, a quiet infrastructure crisis is brewing. And it’s going to determine which AI products survive 2026 — and which become expensive demos that never reach production.

The database is back. And after 15 years of commoditization, it’s becoming the most strategically important piece of your AI infrastructure again.

I spent the last year analyzing how 7 enterprise teams — from autonomous vehicle startups to Fortune 500 fintechs — are rebuilding their data layers for the AI-native era. What I found surprised me, frustrated me, and ultimately convinced me that we’re witnessing one of the most significant infrastructure shifts since the cloud transition.

This is Part 1 of that story. Part 2 (coming next week) covers the emerging solutions: new safety mechanisms, unified architectures, and the “Agent-First” design philosophy that will define the next decade of data infrastructure.

But first, you need to understand why everything you thought you knew about database selection might be wrong.

Part 1: The Identity Crisis — Who Is the Database Actually For?

Let me ask you a question that sounds simple but isn’t:

Who is your database designed to serve?

For the last 40 years, the answer has been obvious: humans. More specifically, human database administrators who write SQL, human application developers who read API documentation, and human DevOps engineers who configure instances through web consoles.

Every major database architecture makes assumptions about its user:

They have an email address (for account creation and verification)
They can wait 3–10 minutes for a new instance to provision
They understand complex logic like two-phase commit, isolation levels, and eventual consistency
They can manually reconcile data inconsistencies when systems drift out of sync
They will read PDF documentation, fill out forms, and open support tickets when something breaks

AI Agents are not humans.

Your AI Agent cannot:

Check its email for a verification code
Wait 5 minutes for a new database instance to spin up while a user is actively chatting
Read a 50-page PDF and understand that one footnote on page 34 changes everything
Manually fix data inconsistencies between three separate systems (MySQL for transactions, Elasticsearch for search, Pinecone for vectors)
Explain to you why it made a particular decision that broke your data model

An Agent operates in what I call the Perceive-Reason-Act-Reflect loop:

Perceive: Read current state from the database
Reason: LLM processes information and decides next action
Act: Write operation back to the database
Reflect: Read results and evaluate success

A single task might execute this loop 20–50 times. Each iteration requires database interaction. And here’s where traditional database assumptions catastrophically break down.

When a human queries a database, they run maybe 5–10 queries total, with seconds or minutes between each one. If one query takes 200ms, they don’t even notice.

When an Agent executes 20 queries in a tight loop to complete one user request, that same 200ms latency becomes 4 seconds of cumulative waiting. In a conversational AI interface, 4 seconds of silence feels like abandonment. Users don’t think “the database is slow” — they think “this AI is broken.”

The paradigm has completely flipped:

Traditional Databases AI-Native Data Infrastructure Built for human DBAs Built for AI Agents Optimized for throughput (queries/second) Optimized for latency (end-to-end time) “Read the docs and figure it out” Programmatic self-discovery via structured interfaces Separate systems for different data types (SQL + Vector + Search) Unified engine for relations, vectors, and full-text Human-driven configuration and tuning Agent-driven, API-first operations with auto-scaling

This isn’t an incremental upgrade. This is a fundamental inversion of database design philosophy — from human-operable to machine-native, from storage-centric to cognition-centric, from “how do we make the DBA’s life easier” to “how do we make the Agent’s life possible.”

And most engineering teams haven’t realized the shift is happening.

Part 2: The Five Generations — How We Got Here (and Why Generation 4 Is Breaking)

To understand where we’re going, you need to see the full evolutionary arc. I’ve mapped five distinct generations of data infrastructure, each defined by the dominant application pattern of its era:

Generation 1: OLTP Dominance (Pre-2010)

The Killer App: E-commerce and electronic payments

The Problem: “How do we keep our users’ money safe when they buy something online?”

The Solution: MySQL, Oracle, PostgreSQL. Row-optimized storage. ACID transactions at all costs. The database as the “source of truth” for financial systems.

The Mental Model: Trust the database with everything. If it committed, it happened.

Generation 2: OLAP Separation (2010–2020)

The Killer App: Business intelligence and data analytics

The Problem: “We have terabytes of data in our OLTP system, but running analytics queries crashes the production database.”

The Solution: Hadoop, Spark, data warehouses. Columnar storage. Batch processing. ETL pipelines that extract data nightly, transform it, and load it into separate systems for analysis.

The Mental Model: Yesterday’s data is good enough for tomorrow’s business decisions. (T+1 latency was acceptable.)

Generation 3: HTAP Convergence (2020–2024)

The Killer App: Real-time personalization and fraud detection

The Problem: “By the time our batch process identifies the fraud, the money is already gone.”

The Solution: OceanBase, TiDB, CockroachDB. Hybrid Transactional/Analytical Processing. Row storage for writes, columnar for reads, inside the same system.

The Mental Model: Analyze data as it arrives, without waiting for the ETL batch job.

Generation 4: Vector-Native (2024–2025)

The Killer App: LLM-powered applications and semantic search

The Problem: “Users want to search by meaning (‘comfortable cafe for a business chat’), not just keywords.”

The Solution: Pinecone, Milvus, Weaviate. Purpose-built vector databases with HNSW/IVF indexes for approximate nearest neighbor search.

The Mental Model: Find similar things, not just exact matches. Embeddings capture semantic relationships.

But here’s where the wheels fall off.

Every team I interviewed that built on the Generation 4 stack eventually hit the same wall. They were running three separate data systems:

MySQL/PostgreSQL for transactional data and business logic
Elasticsearch for full-text search and filtering
Milvus/Pinecone for vector similarity and semantic search

And then they wrote “glue code” — hundreds or thousands of lines of application logic trying to:

Keep these three systems synchronized
Decide which system to query first
Merge results from multiple systems
Handle the inevitable inconsistencies when one system’s CDC lagged behind

One engineering lead described it to me as: “Three databases, three failure modes, three 3AM pages. And good luck explaining to your CEO why the AI recommended a product that sold out 5 seconds ago because our CDC was behind.”

This architecture works for proofs-of-concept. It fails spectacularly in production when:

You need sub-100ms response times
You require strong consistency across data types
You’re trying to build agent systems that make 20–50 database calls in a single task

Generation 4 was the right solution for the wrong problem. It solved “how do we do vector search” but created “how do we do hybrid search with low latency and strong consistency.”

Part 3: The 50ms Problem — Why Latency Is the New Throughput

Let me say something that sounds wrong at first, but will save you months of architectural pain:

In the AI Agent era, latency matters more than throughput.

Repeat that: latency > throughput.

For 30 years, database optimization focused on a single metric: “How many queries can we process per second?” (QPS). This was the right metric for web applications, where thousands of humans are clicking around dashboards and product pages.

For human-facing applications, 200ms query latency is “reasonable.” Users barely notice. Throughput is what matters because you need to serve thousands of concurrent users.

AI Agents don’t generate load like humans do. They generate latency like chains.

Consider a typical agent workflow for a restaurant recommendation:

Loop 1:
  - READ: Get user's location and preferences (50ms)
  - REASON: LLM identifies intent (500ms-3s depending on model)
  - ACT: WRITE search query parameters (50ms)
Loop 2:
  - READ: Get candidate venues from database (50ms)
  - REASON: LLM evaluates options (500ms-3s)
  - ACT: WRITE refined filters (50ms)
Loop 3:
  - READ: Get detailed venue data (50ms)
  - REASON: LLM checks availability and preferences (500ms-3s)
  - REFLECT: READ final candidates (50ms)
  - REASON: Final ranking (500ms-3s)
  - ACT: WRITE recommendation (50ms)

This single request might involve 6 database round-trips.

Now do the latency math:

Per-Query Latency × 6 Queries Cumulative Agent Latency 20ms (optimized) 120ms (imperceptible) 50ms (good by human standards) 300ms (noticeable delay) 100ms (acceptable for web) 600ms (feels sluggish) 200ms (common for hybrid queries) 1.2s (feels broken)

That “reasonable” 50ms lag that humans barely notice? To an Agent doing 20 queries to complete a task, it’s a full 1 second of cumulative waiting.

In a conversational AI interface, 1 second of silence between messages is an eternity. Users don’t think “the database is slow.” They think “this AI is dumb,” or worse, “this AI is broken,” and they leave.

The Bottleneck Migration

But here’s the really counterintuitive insight: as LLMs get faster, the database becomes MORE important, not less.

Follow this timeline:

2024: GPT-4 in the cloud takes 3–5 seconds per inference

Database latency (50–200ms) is lost in the noise
“The model is the bottleneck” ✓

2025: Groq-optimized LLMs run at 100–500ms per inference

Database latency (50–200ms) is now 20–50% of total time
The database is becoming the bottleneck 🔶

2026: On-device LLMs (Llama-3–8B, etc.) run at 10–20ms per inference

Database latency (50–200ms) is now 2–10x slower than the “slow part”
The database IS the bottleneck 🔴

There’s an infrastructure evolution rule that has held true for 40 years:

When one layer of the stack gets dramatically faster, the next layer becomes the new bottleneck.

Disks got faster (HDD → SSD) → CPU became the bottleneck
Networks got faster (1Gbps → 100Gbps) → Serialization became the bottleneck
LLMs got faster (5s → 100ms) → The database is becoming the bottleneck

The teams that are ahead of this curve are already optimizing for P99 latencies under 20ms. They’re treating 50ms as a bug, not a feature.

Because in 12–18 months, when on-device models are standard, having a 200ms database will feel exactly like trying to stream 4K video over dial-up internet.

Part 4: The Data Freshness Crisis — Why “Eventually Consistent” Is Eventually Broken

There’s a second latency problem that’s even more insidious than query latency: data synchronization latency.

Remember that fintech team with the 2-second CDC lag? Here’s why it was catastrophic for their AI system:

Their AI was making decisions based on stale data.

The sequence of failure looked like this:

User browses products (triggers inventory decrement in SQL database)
SQL database is authoritative source of truth
CDC process replicates change to vector database (2-second delay)
AI recommendation engine queries vector database: “What should we show this user?”
Vector database returns products that matched the user’s interests
One of those products just went out of stock 1.5 seconds ago
User clicks recommendation → sees “Out of Stock” error → abandons session → never returns

The AI didn’t make a bad decision. It made a good decision based on bad data.

This is the fundamental problem with the “three separate systems” architecture of Generation 4:

Your SQL database has the truth NOW
Your vector database has the truth 2 seconds ago
Your search index has the truth 5 seconds ago
Your application is trying to merge these timelines like a time-travel movie with plot holes

For the AI agent use case, “eventually consistent” is actually “eventually wrong.”

Because agents operate at machine speed — they’re not waiting 30 seconds between queries like a human browsing a website. They’re making decisions in milliseconds based on the data they read. If that data is 2 seconds stale, the decisions are being made on a reality that no longer exists.

The three requirements of AI-native data infrastructure:

Write-Visible: As soon as a transaction commits, new queries must see the updated data (no replication lag windows)
Persist-Available: Data must be queryable immediately in all indexing formats (vector, text, relational) without waiting for background jobs
Predictably Fast: P99 latency must be bounded even under high concurrency, because agents don’t back off when the system is stressed — they pile on more requests

Traditional databases separate these concerns. You write to the SQL database, wait for the CDC job, wait for the vector index update, wait for the search index reindexing. The “freshness gap” is measured in seconds. AI agents make hundreds of decisions in those seconds.

What’s at Stake

Let me bring this back to ground level and explain why this matters for your next architecture decision.

If you’re building RAG (Retrieval-Augmented Generation) applications, the data layer will determine whether you ship a demo or a production product.

The demoable version uses:

PostgreSQL for structured data
Pinecone for vectors
Elasticsearch for text search
200 lines of Python to glue them together
500ms latency (but you only test with 10 items, so it feels instant)
“Works on my machine” energy

The production version doesn’t work. Because:

The glue code becomes 2000 lines of complexity
The 500ms becomes 2 seconds at scale
The “eventually consistent” becomes “consistently wrong” when the CDC lags during a traffic spike
The 3AM pages start coming faster and faster

The AI-native generation of databases (OceanBase 4.4.2, Lakebase, seekers) approach this differently:

One system. Three query interfaces. Single transaction boundary. When you commit, the data is visible for vector search, full-text search, and SQL queries simultaneously.

That architectural shift — from “three systems with glue” to “one system with multiple access patterns” — is the difference between a prototype and a production system.

In Part 2 (publishing next week), I’ll cover the emerging solutions to these problems:

Data Branching: Giving AI agents “sandbox” databases where they can experiment without risking production data (then merging changes after human review)
The Unified vs. Specialized debate: Why the “best tool for the job” approach might be the worst choice for AI applications
Agent-First Design: What it means to build infrastructure that AI agents can discover and operate autonomously
A decision framework: How to choose the right data architecture for your specific AI use case

The Bottom Line for Part 1

Database infrastructure has gone through five distinct generations, each solving the dominant problem of its era:

OLTP: Make transactions reliable
OLAP: Enable batch analytics
HTAP: Enable real-time analytics
Vector-Native: Enable semantic search
AI-Native: Enable AI agents to interact with data safely, quickly, and autonomously

Generation 4 (separate vector databases) created a “glue layer complexity” problem that breaks production systems.

The two metrics that matter for AI agents aren’t the ones we optimized for in the web era:

Latency, not throughput: 50ms × 20 queries = 1 second of waiting
Freshness, not eventual consistency: “2 seconds behind” means “2 seconds wrong”

As LLMs get faster (3s → 100ms → 10ms), the database becomes the bottleneck. The teams that realize this now and optimize for sub-20ms P99 latencies will have a 2–3 year head start.

The infrastructure that wins won’t be the one with the highest benchmark score in isolation. It’ll be the one that eliminates the most architectural complexity while meeting the latency and consistency requirements that AI agents demand.

What Do You Think?

Is your team feeling the database latency pain yet? Have you hit the “glue layer” complexity wall with separate vector and SQL databases? Or are you still in the “the LLM is the slow part” phase?

Drop a comment — I’d love to hear what your production monitoring is actually showing.

And if this resonated, Part 2 drops tomorrow with the solutions: data branching, unified architectures, and the practical decision framework for choosing your AI-native data infrastructure.

Follow me on Medium for weekly deep dives into the infrastructure layers that actually determine AI product success.

Building RAG & Knowledge Bases with seekdb: Three Paths, One Stack

Charles Wu — Mon, 27 Apr 2026 12:57:54 +0000

The real headache in RAG isn’t retrieval or generation — it’s the layer in between. Where does the data live? How do you keep it in sync? Who glues it all together? seekdb and Dify are both open-source. Your RAG stack — from storage to orchestration — can be self-hosted, auditable, and customizable, without locking you into closed services. This post walks through three paths, all built on one stack: RAG from scratch with seekdb, Dify + seekdb, and a knowledge base desktop app. Pick the one that fits and get it running.

Where seekdb Fits in the RAG Pipeline

A typical RAG pipeline looks like: load documents → chunk → embed → store; at query time: retrieve → (optionally) rerank → feed to LLM → generate. If your storage is a patchwork of MySQL + vector DB + full-text engine, you end up managing sync, multi-source queries, and fusion yourself. seekdb’s role: one database that holds relational data, vectors, and full-text in the same place. Write once, index automatically; one hybrid query returns results. You can use in-database AI functions for embedding and reranking when needed, so storage and retrieval live in one layer with less glue code.

Three paths we’ll cover:

RAG from scratch with seekdb — Best if you want full control over the pipeline or already have a Python/app stack.
Dify + seekdb — Best if you want Dify for orchestration and UI and seekdb as the knowledge-base backend, collapsing the stack to Dify config + seekdb storage.
Knowledge base desktop application — Best if you want a local, multi-project desktop app with seekdb as the backend and a custom frontend.

Path 1: RAG from Scratch with seekdb (Summary)

Deploy and create tables
Run seekdb in Embedded or Client/Server mode. Create a table (or Python collection) with vector + full-text columns, and create a VECTOR INDEX and FULLTEXT INDEX.
Load documents
- Read docs (PDF, TXT, MD, etc.) → chunk them (by paragraph, by length, with overlap, etc.).
- For each chunk, call your embedding model to get a vector (use seekdb’s in-database AI functions, or compute in your app and insert into seekdb).
- INSERT into seekdb: each row has chunk text, vector, and any metadata you need (source, doc id, segment id, etc.).
At query time
- Turn the user question into a query vector (same embedding).
- Use hybrid search: vector_query + full_text_query(optional) + relational filters (e.g. by knowledge-base id), and take top_k candidates.
- Optional: rerank with seekdb or in your app → pass the final context to your LLM to generate the answer.
Things to watch
- Chunking strategy and chunk size directly affect recall; pick one and tune from there.
- If you use in-database AI for embedding/reranking, you save a round-trip to external services.
- For full steps and code, see https://docs.seekdb.ai/seekdb/build-a-rag-system-with-seekdb/

Path 2: Dify + seekdb — Collapse the RAG Stack (Both Open-Source)

Dify handles workflow orchestration, knowledge-base setup, and the chat UI. The data source can be seekdb: Dify’s pipeline does “upload/parse → chunk → embed → write,” while storage and retrieval happen in seekdb — with strong consistency, hybrid search, and in-database AI. Dify and seekdb are both open-source, so the whole RAG stack can be self-hosted, audited, and extended. Good fit if you care about data and architecture ownership.

Configuration idea (check your Dify version for exact UI):

In Dify, set the knowledge base data source to seekdb (or wire seekdb via Dify’s supported vector store/API).
After you upload documents, Dify parses and chunks them, calls the embedding service, and writes into seekdb. At query time, Dify sends the query to seekdb, gets hybrid-search results back, and passes them to the LLM node for the final answer.

Result: no separate sync scripts or multi-database juggling — the stack is just “Dify config + seekdb.” For details, see https://en.oceanbase.com/blog/24316625920

Path 3: Knowledge Base Desktop App — Local, Multi-Project

If you’d rather skip Dify and want a local knowledge base desktop application (multiple projects, multiple docs, local search): use seekdb as the backend and a desktop client (e.g. Tauri or Electron + your frontend) to connect to seekdb’s API. The flow is the same: parse → chunk → embed → write to seekdb; at query time use hybrid search and show results or feed them to a local LLM.

There’s an official guide: https://docs.seekdb.ai/seekdb/build-kb-in-seekdb/ — it outlines the stack and steps.

Which Path to Choose?

Once you’ve got RAG or a knowledge base running with seekdb, you might wonder where it goes next. In the next post we’ll take seekdb beyond text: multimodal and agents — think travel assistant, image search, TEN+PowerMem voice assistant — and how the same stack extends to those scenarios.

Repo: https://github.com/oceanbase/seekdb (Apache 2.0 — Stars, Issues, PRs welcome)
Docs: https://docs.seekdb.ai/seekdb/seekdb-overview/
Discord: https://discord.com/channels/1331061822945624085/1331061823465590805
Dev.to: https://dev.to/seekdb
Press: https://www.marktechpost.com/2025/11/26/oceanbase-releases-seekdb-an-open-source-ai-native-hybrid-search-database-for-multi-model-rag-and-ai-agents/

Building RAG or an AI workflow? What’s the one thing you wish your database did better — or didn’t do at all? Drop it in the comments. We read them, and the next features we ship often come from exactly those pain points. Open source only gets better when people say what’s broken.

seekdb Core Features: Hybrid Search & AI Functions

Charles Wu — Mon, 27 Apr 2026 12:49:48 +0000

Vector search finds “what it’s like.” Full-text search finds “what it says.” Relational filters handle “who” and “where.” With seekdb, you can combine all three in a single query and run embedding and reranking inside the database. The fusion logic (e.g., RRF) and the AI Functions API are open on GitHub (https://github.com/oceanbase/seekdb) — you can review, modify, and send PRs. This post walks through how it works and how to use it in RAG and knowledge-base setups, and how you can contribute.

1. Hybrid Search: Why One SQL Beats Multi-Stage Retrieval

The usual approach: hit a vector store, hit a full-text store, and then normalize, fuse scores (e.g., RRF), and rerank in the application layer. The catch: extra network hops, custom fusion logic, and filter conditions that can drift between systems (e.g.,“only this user’s data” has to be expressed in both stores).

seekdb’s hybrid search is different: one table has both a vector index and a full-text index. One query sends vector conditions, full-text conditions, and relational filters, and the database does the fusion and ranking. You get:

Consistency — Filters are defined once. No “vector side filtered, full-text side didn’t.”
Low-latency — No application-layer fusion hop; results are ranked inside the DB.
Simplicity — No glue code for multi-stage retrieval.

In SQL, you typically use DBMS_HYBRID_SEARCH.SEARCH() with full_text_query, vector_query, and optional relational filters to get relevance-ranked results. The Python SDK’s hybrid_search() supports more options (e.g., separate top_k for vector/full-text, filter expressions). Fusion is often done with RRF (Reciprocal Rank Fusion), combining vector similarity and full-text scores into one ranking.

2. How to Configure and Tune Hybrid Search

Schema — The table needs a VECTOR column (with a VECTOR INDEX) and text columns you want to search (with FULLTEXT INDEX). When you insert a row, both indexes are updated; no extra sync step.
Queries — Pass both vector (or column name + query vector) and full-text query string, and add relational filters (e.g. WHERE user_id = ?) as needed.
Tuning — On the vector side: top_k and similarity thresholds. On the full-text side: tokenization and match mode. When merging with RRF, watch the ratio of results from each side so one doesn’t dominate (the docs have examples and suggested ranges).

Community experience (e.g. Experience seekdb’s Hybrid Search) shows that semantic + keyword together is more reliable than vector-only or full-text-only, especially with proper nouns, numbers, and code.

3. AI Functions: Embedding, Reranking, and LLM Inside the Database

Hybrid search alone isn’t enough for RAG — you still need embedding, reranking, and an LLM. Doing all of that in the app via remote services adds latency and dependencies. seekdb’s AI Functions move part of that into the database: call in-DB embedding and rerank at write or query time, and even LLM inference and prompt handling, so the “retrieve → rerank → generate” pipeline is shorter and some logic lives in the DB.

Embedding — Vectorize text at write time or at query time; no need to call an external API from the app before writing.
Reranking— Rerank hybrid search results with a model inside the DB, cutting down app-layer round-trips.
LLM / Prompt — Run simple inference or prompt templates in the DB for rule-heavy flows; keep complex chat in your application LLM.

Compared with “everything via external services”: in-DB AI reduces network hops and centralizes permissions and config; it fits when you care about latency and privacy and are fine using seekdb’s built-in or configured models. If you’re already tied to external embedding/LLM services, you can keep them and use seekdb purely as the retrieval layer.

For details and configuration, see seekdb docs.

4. Summary: What You Gain

Once you’re comfortable with these, the next step is RAG and knowledge bases: use seekdb for storage and retrieval, and Dify or your own front end for chat and workflows. The next post will cover getting started with building RAG and a knowledge base using seekdb and Dify.

Repo: https://github.com/oceanbase/seekdb (Apache 2.0 — Stars, Issues, PRs welcome)
Docs: https://docs.seekdb.ai/seekdb/hybrid-search/
Discord: https://discord.com/channels/1331061822945624085/1331061823465590805
Dev.to: https://dev.to/seekdb
Press: https://www.marktechpost.com/2025/11/26/oceanbase-releases-seekdb-an-open-source-ai-native-hybrid-search-database-for-multi-model-rag-and-ai-agents/

If you or your team are building an AI application/workflow— what do you expect from a database? Let’s chat in the comments.

Our team is building some cool new features, and we might just solve your pain points. Open source is about collaboration — share your challenges and let’s build better together!

We Built an Agent That Analyzes Itself — Here’s What We Learned

Charles Wu — Mon, 27 Apr 2026 12:40:53 +0000

When your Agent’s footprints become team insights, something interesting happens.

The Problem Nobody Talks About

Your team builds an AI Agent. It works great. People use it every day — in Slack, in DingTalk, in Discord.

Then what?

The conversations vanish into chat history. The queries disappear after execution. The insights stay trapped in individual sessions.

Over time, nobody can answer:

What questions do people ask most?
Where does the Agent fail repeatedly?
What patterns hide in thousands of interactions?

We faced this exact problem. And the answer wasn’t “add more analytics.” The answer was: build an Agent that analyzes itself.

Meet bubseek — an insight Agent that turned our scattered footprints into team intelligence.

What Is bubseek?

One-liner: A self-driven insight Agent built on bub (Agent framework) + seekdb (AI-native database).

What it does:

Accepts natural language requests (“Track AI trending projects this week”)
Connects to data sources autonomously (GitHub, Slack, internal systems)
Defines views, executes analysis, generates reports
Stores everything in seekdb — including its own execution traces
Analyzes its own traces to produce team insights

The twist: bubseek doesn’t just consume data. It consumes itself. Every interaction becomes fuel for understanding how the team works.

Why We Built It

The Old Way: BI Ticket Backlog

Team member: "I need a dashboard for GitHub trending"
 ↓
Product manager: "Add to backlog"
 ↓
2 weeks later: "Requirements unclear, need refinement"
 ↓
1 month later: Dashboard shipped (wrong metrics)
 ↓
Repeat.

Small requests get deprioritized. Big requests take forever.

The bubseek Way: Conversation, Not Queue

Team member: "Track AI trending projects, update daily"
 ↓
bubseek: "Got it. Setting up GitHub → seekdb → daily report"
 ↓
Next morning: Report arrives in Slack
 ↓
Team member: "Add vLLM mention analysis"
 ↓
bubseek: "Updated. Next report will include it"

Response time: From “weeks” to “seconds.”

The Building Blocks

bubseek combines two projects:

bub (Agent Framework)
- Hook-first architecture: core stays minimal, features as plugins
- Tape system: immutable execution trace (every thought, tool call, result)
- Skills engine: extendable tool library
seekdb (AI-Native Database)
- SQL + vector + full-text search in one database
- Lightweight: runs on 1 core, 2GB RAM
- Designed for AI workloads (RAG, embeddings, hybrid search)

Together: bub handles the Agent loop, seekdb stores everything (including the Agent’s own footprints).

What We Learned

Lesson 1: Channels should be zero-code

Built-in channels:

Feishu, DingTalk, WeChat, Discord, Telegram
Web interface (Marimo notebook)

Setup: Configure environment variables for each channel. No additional code required.

Note: Feishu is an enterprise collaboration platform popular in Asia, similar to Slack.

Note: Feishu is an enterprise collaboration platform popular in Asia, similar to Slack.

Lesson 2: Data consumption is a conversation, not a queue

Traditional BI: Deploy system → build reports → train users

bubseek: Tell it what you want → it figures out the rest

Example Workflows

Output formats:

Marimo notebooks (interactive Python dashboards)
GitHub repo cards (SVG/PNG for sharing)
Natural language reports (for chat)

Lesson 3: The Agent is its own best analyst

Traditional observability: External monitoring system → metrics → dashboards

bubseek observability: Agent naturally produces data → analyzes itself

The Tape System

Every Agent execution creates an immutable trace:

User request
Agent thoughts (step-by-step reasoning)
Tool calls (which APIs, which queries)
Results (what was found/generated)
Delivery (where sent, when)

This tape isn’t a log. It’s the data source for meta-analysis.

Example Insights (from early testing)

The loop closes: Agent serves team → produces data → data analyzed → team understands itself better.

Lesson 4: Your data foundation shapes everything

Why seekdb?

Configuration:

BUB_TAPESTORE_SQLALCHEMY_URL=mysql+oceanbase://user:pass@host:port/database

Exit strategy: If seekdb hits limits, seamless upgrade to OceanBase (same protocol, distributed scale).

The Real Innovation: Self-Understanding Agent

Most Agents are stateless workers:

Do task → forget everything
Next task starts from zero
No institutional memory

bubseek is stateful team member:

Remembers all interactions
Learns from failures
Produces insights about itself

Example: bubseek Analyzes Its Own Usage

User: "What questions did people ask most this week?"

bubseek: (queries its own tape in seekdb)
         (clusters by topic)
         (generates report)

Example output (illustrative — your actual numbers will vary):

Top 5 topics:
 1. GitHub trending (23 queries)
 2. AI paper summaries (18 queries)
 3. Team sprint metrics (12 queries)
 4. Competitor analysis (9 queries)
 5. Code review automation (7 queries)

No separate analytics tool needed. The Agent is the analytics.

Getting Started

Prerequisites

seekdb installed (1 core, 2GB RAM minimum) — see seekdb deployment docs (https://docs.seekdb.ai/seekdb/seekdb-overview/) if you need a local server
A model provider account and API credentials compatible with bubseek (see the bubseek README: https://github.com/ob-labs/bubseek)

Configure bubseek

Example values below are placeholders from the README; replace them with your own model, API key, API base URL, and database URL before running uv run bub chat.

git clone https://github.com/ob-labs/bubseek.git
cd bubseek
uv sync
uv run bub --help
export BUB_MODEL=openrouter:qwen/qwen3-coder-next
export BUB_API_KEY=sk-or-v1-your-key
export BUB_API_BASE=https://openrouter.ai/api/v1
export BUB_TAPESTORE_SQLALCHEMY_URL=mysql+oceanbase://user:pass@host:port/database
uv run bub chat

For channel-specific variables, production URLs, and alternative model providers, use the full guides in the repo: Getting started (https://github.com/ob-labs/bubseek/blob/main/docs/getting-started.md), Configuration (https://github.com/ob-labs/bubseek/blob/main/docs/configuration.md).

What’s Next

Under discussion:

Further iterations may include multi-Agent coordination, smarter schema design, and proactive insight recommendations.

(Roadmap still evolving — join the conversation on GitHub.)

The Big Picture

bubseek isn’t a BI tool. It’s a bet on a different future:

We’re not saying bubseek is the answer. We’re saying: the question is worth asking.

What if your Agent knew as much about your team as you do

References

bubseek: https://github.com/ob-labs/bubseek
seekdb: https://github.com/oceanbase/seekdb
bub Framework: https://github.com/bubbuild/bub
Tape Context Model: https://tape.systems

Token, Harness, OpenClaw, RAG, MCP, Agent — What’s the Difference? One Map Makes It Clear

Charles Wu — Mon, 27 Apr 2026 12:33:31 +0000

You know these terms alone. Together? They’re confusing. Here’s the map.

Ever feel like this — people keep saying you need “Agents” for AI apps, connect “MCP”, install “OpenClaw”, and now there’s “Harness” too? Each term makes sense alone, but together it’s overwhelming. Today we’ll sort it out — who comes first, who comes after, who manages whom. By the end, you’ll see clearly.

No fluff. Let’s look at a real case: Your boss asks you to “research the latest competitor dynamics online, combine with our company’s past two years of legacy product data, and produce a new product development PPT with data charts.”

Below is the complete process from start to finish. Once we run through this, those confusing concepts will naturally fall into place.

Step 1: You Receive the Task, Send Instructions to OpenClaw

Your boss’s request is clear, but you can’t personally search for info, query data, draw charts, and write the PPT. To complete this efficiently, you organize the task into a single instruction and send it to something called OpenClaw.

1. OpenClaw (“Lobster” 🦞)

What is OpenClaw? Simply put, it’s the “central dispatch console” for the entire AI assembly line — task decomposition, resource allocation, budget monitoring, and logging.

To understand why OpenClaw is needed, we first need to know what the foundation of the entire system is. No matter how complex the operations later become, everything ultimately rests on two most basic things.

2. Large Language Model (LLM)

ChatGPT, Claude — essentially, they’re just really smart brains. Brilliant, knowledgeable, but they have two fatal flaws:

First, they only “respond passively” — you ask one question, they give one answer, never proactively working.

Second, the default chat experience has no durable thread state — every conversation is a fresh start; close the dialog and the model does not “remember” your last session. Production stacks fix that outside the model with logs, RAG, Memory, and databases (covered below).

3. Token

Many people think Token equals word count — big mistake. Token is the model’s basic text unit — think “atoms of text.” One word can be one token (cat) or split into several (understanding → under + stand + ing). On average, 100 English words ≈ 130 tokens. Every sentence you send and every piece the model generates shows up on the meter. This determines two things:

First, your money — APIs charge by token
Second, its “short-term memory” — whatever fits in the context window for this request

Why does token affect memory? Here’s a counter-intuitive mechanism. LLMs themselves have no memory function. Before answering you, the system packages your prior conversation together with your new question into a huge text block and feeds it to the model to read from scratch. The size of this text block is the “context window,” and the token limit is this window’s maximum capacity. Once conversation history gets too long and exceeds the token limit, the system has to truncate — discarding the earliest content.

So “amnesia” in a bare chat UI isn’t mystical — there is literally a finite window. Token is both fuel and the size of that window. Long-term facts and preferences still live in external stores (RAG, Memory, databases) — not inside the next blank chat.

Alright, foundation is clear. But foundation alone isn’t enough — who orchestrates all those complex parts? This is why OpenClaw exists. Next, it will awaken a team to get to work.

Step 2: OpenClaw Awakens a Multi-Agent Team, Each Playing Their Role

Upon receiving the instruction, OpenClaw awakens a Multi-Agent team.

4. Multi-Agent

Multi-agent is the product of necessary division of labor for complex tasks. One agent can be a great line cook. But don’t ask it to also be the head chef, server, cashier, and dishwasher simultaneously — that’s why kitchens have stations.

In the multi-agent model, you create a group with four core roles:

Search Agent — finding information across the web
Writer Agent — drafting articles and reports
Reviewer Agent — checking for errors and policy violations
Analyst Agent — generating charts and data insights

There are two coordination patterns:

Orchestrator–worker — A coordinator decomposes tasks, assigns work, and collects results (most enterprise setups)
Peer-to-peer — No fixed coordinator; multiple agents message each other in a shared channel and pick up relevant tasks

Enterprise deployments usually prefer orchestrator–worker because it’s easier to control, permission, and audit.

In this PPT task, OpenClaw awakens three of these agents:

“Search Agent” crawls competitor dynamics
“Internal Data Agent” retrieves historical data
“Analyst Agent” generates charts

How do they work? This brings us to the essence of Agent.

Many people think Agent is just “LLM plus some tools,” but this misses the most critical thing. The core difference between Agent and LLM is the locus of control.

To achieve this transformation, you need to wrap a “scheduler” layer outside the LLM. This scheduler does four things:

Decomposition — Break complex tasks into executable sub-steps
Execution — Call tools one by one to complete each step
Observation — Watch execution results of each step; continue if successful, retry or switch plans if failed
Decision — Make its own judgments at forks in the road

So: Agent = Brain (LLM) + Scheduler + Knowledge Base + Skill Library + Tooling (often wired through MCP). The LLM only understands goals and generates instructions; the true “proactiveness” comes from the scheduler layer outside. AI assistants help you brainstorm; agents finish the work for you.

One more common point of confusion: What’s the difference between Agent and OpenClaw?

In one sentence: Agent is the worker getting the job done; OpenClaw is the system managing the workers.

One agent is like a renovation worker — you tell him “paint this wall white,” he finishes. Multi-agent is like a renovation team with masons, electricians, painters, collaborating to renovate a room. OpenClaw is the renovation company’s operations backend. It doesn’t manage how to paint walls specifically; it manages: which worker is available, whether tools are ready, whether there’s permission to enter the site, how much work was done and how much it cost, whether the work process was logged, what to do if a worker runs away.

Why can’t one giant agent replace OpenClaw? Three recurring failure modes:

With the agent concept clear, let’s see how the three agents awakened by OpenClaw actually work. This is where MCP, databases, RAG, Skill, Memory naturally emerge.

5. MCP (Model Context Protocol)

First, the “Search Agent” crawls competitor dynamics across the web via MCP interfaces.

MCP is an open standard for plugging tools into models (think USB-C for capabilities). Before it appeared, to let AI search the web, you needed programmers to write bespoke glue translating “what AI wants to search” into “call search API”. Change the tool, rewrite the code; change the AI model, maybe rewrite again. This is the “M×N Problem”: M models × N tools = M×N development efforts.

MCP changes this pattern to “M+N”: Tool developers ship one MCP surface; any MCP-capable host can call it; hosts implement MCP once and reach many tools. MCP is essentially a translation layer — AI says “I want to search competitors,” MCP translates to browser-understandable instructions; browser returns results, MCP translates back to model-friendly content. With MCP, the model is like plugging into a hub — gaining many connectors without custom glue each time.

6. Vector Database / AI Database

Second, the “Internal Data Agent” triggers RAG, diving into the vector database to retrieve the past two years of historical data.

A vector database (or AI-native DB) is a semantic index over embeddings. Traditional databases (like MySQL) are rigid — you search “happy,” it absolutely won’t find “glad.” Vector databases turn documents and chat into vectors — long arrays of numbers representing directions in embedding space. Texts with similar meaning land near each other in that space. “Happy” and “glad” are close; “happy” and “sad” are far.

When you search “competitor Q3 data,” it doesn’t match keywords — it embeds the query, then returns the nearest neighbors. It’s not matching text; it’s retrieving by semantic distance.

Related projects:

Vector Database OceanBase: https://github.com/oceanbase/oceanbase
Native AI Database seekdb: https://github.com/oceanbase/seekdb

7. RAG (Retrieval-Augmented Generation)

Without RAG, LLMs lean on parametric knowledge — when that’s thin, they hallucinate more often. With RAG, a typical loop has four steps:

Retrieval — Find relevant materials in the vector database
Ranking — Pick the most reliable pieces
Context assembly — Combine materials and question into a single prompt
Generation — The LLM answers conditioned on those materials

RAG reduces — but does not eliminate — fabrication: The model is steered with “answer from the following context” instead of an open-ended prompt. If the context is thin or wrong, it can still go off rails — guardrails and harnesses still matter.

8. Skills (Skill Package)

Third, the “Analyst Agent” calls up the chart generation Skill you predefined earlier, and queries its Memory: “The boss can’t distinguish red from green; charts must not rely on red–green encoding.”

Skills exist to solve a real problem: Prompts don’t stick. A prompt is a one-off command like “rewrite this email to sound more professional” or “summarize this meeting transcript into 3 bullets.” It works today, but when you open a new chat tomorrow, you have to type it again. Writing Prompts daily equals doing AI chores every day.

Skills fix this by making repeatable workflows permanent. Think automated buttons, not verbal instructions. You write the SOP once, the system executes it forever. Prompt is giving orders; Skill is building an assembly line.

9. Memory (Long-Term Memory)

And the Memory just mentioned records “you as a person.” RAG remembers objective materials; Memory remembers subjective preferences. Technically they’re often implemented similarly — both retrieved from stores outside the model (vector DBs, KV, etc.). The difference: RAG stores documents and reports, imported by developers in advance; Memory stores user preferences and identity tags, automatically extracted and stored by the system during conversation. RAG is the company’s shared filing cabinet; Memory is your personal file folder. With Memory, the assistant can reuse stable preferences — e.g., avoiding red–green palettes — without you repeating them every session.

PowerMem (a reference implementation for OpenClaw-style hosts): https://github.com/oceanbase/powermem

Step 3: Encountering Hard Problems, Summon Special Forces

The task involves writing a complex piece of data analysis code — beyond what the standard Analyst Agent can handle. For this, OpenClaw activates a specialist coding agent (in our stack, Claude Code — the coder’s exclusive tool for deep technical work).

10. Claude Code

Don’t confuse Claude Code with the web-chat version of Claude. Web version is a consultant — in the browser you ask one question, it answers one. Claude Code is completely different — it lives directly in your computer terminal, with broad filesystem and shell access — read, write, modify, and delete files where your OS user allows. Workflow: you give the goal, it decomposes and executes with minimal interruption. Built-in tools include reading files, writing files, running commands, searching code.

Its principle is: When Anthropic trained Claude, they specifically strengthened its terminal command and file operation capabilities, then packaged it as a local terminal agent, pre-connecting two MCP tools: file system and command line. Opening Claude Code equals launching an agent specialized in writing code. One sentence — it digs through tens of thousands of lines of codebase itself, fixes bugs itself, submits tests itself.

Claude Code finishes writing and running the data analysis code, results returned to “Analyst Agent,” charts generated smoothly. PPT draft emerges.

Step 4: Finished Product, First Pass Security Check

PPT draft is generated. But do you really dare to send it directly to your boss?

What if the agent used red–green-only charts (the boss can’t distinguish red from green)? What if there’s a number in the data charts the model invented? What if the format completely doesn’t match company templates? Worse: what if a tool-enabled agent had credentials broad enough to damage production data? Keep database credentials, destructive tools, and customer PII out of reach of exploratory agents — scope tools per environment.

This is why the AI assembly line still needs one final layer: Harness Engineering.

11. Harness Engineering

Mitchell Hashimoto (HashiCorp co-founder) wrote persuasively in early 2026 about treating long-running agents like systems that need a harness — constraints, checks, and recovery. See My AI Adoption Journey. “Harness” literally evokes horse tackle — reins, harness, saddle — equipment for guiding strength without fighting it. The metaphor fits: agents are powerful and fast, but they can spook, drift, or act outside intent. Harness engineering is the discipline of making unsafe failure modes rare — with permissions, tests, sandboxes, humans in the loop, and telemetry.

Harness Engineering differs from ad-hoc “debug and hope.” Traditional thinking: agent makes a mistake, you manually intervene, then hope it doesn’t repeat. Harness thinking: each time a failure mode appears, encode a guard — policy, test, sandbox, or auto-rollback — so the same class of harm is much harder to repeat.

Mitchell Hashimoto cited a classic example: Let an AI agent refactor a million-line codebase. The naive path is wide GitHub permissions and “go ahead,” then waiting for disaster — the agent will recklessly modify files, introduce bugs, and delete files it thinks are useless. A harnessed approach might look like this:

Speaking of this, you might be curious: What’s the difference between Harness Engineering and OpenClaw?

OpenClaw manages “assembly line operations” — scheduling, allocation, monitoring, logging. Harness Engineering manages “assembly line safety” — constraining behavior boundaries, validating output quality, building self-healing closed loops. One manages “can run”; the other manages “runs stably.”

Here, let’s pause and think about a question: Why do many enterprises still dare not put AI agents into production environments?

It’s not because agents aren’t smart enough — it’s because of distrust. You don’t know what it’ll do next second, you don’t know if it’ll spend your entire budget, you don’t know if it’ll send a nonsensical email to clients in the middle of the night.

Harness Engineering targets that trust gap. It uses engineered constraints — policy, tests, observability, approvals — to move agents from opaque automation toward auditable, predictable, stoppable systems. Predictability is what lets serious work land on agents.

Back to our task. The system validates PPT format. It checks color encodings against the accessibility rule. After passing, the PPT lands in your Slack drafts.

Tokens are metered end to end; per-step caps catch runaway loops. If spend crosses 80% of budget, route to a cheaper model tier where policy allows. Every tool call hits an audit log so when the boss asks where did this number come from? You can answer in seconds.

In a few minutes, done — and you only clicked Approve once.

Conclusion: Which Layer Are You At?

Once you see how these thirteen building blocks fit together across five layers — from the foundation (LLM + Token) through memory and knowledge
(RAG + Memory + Vector DB + AI DB + Skill + MCP), execution
(Agent + Multi-Agent + Claude Code), orchestration (OpenClaw),
and finally the safety envelope (Harness Engineering) — you stop treating the space as magic jargon.

If this helped, clap and share it with someone who’s still drawing the map on a whiteboard.

Where are you now?

Would you ship Friday’s release from an agent you can’t stop or explain?

Harness Engineering in Practice: Building a 6-Agent System That Runs Itself

Charles Wu — Mon, 27 Apr 2026 12:28:30 +0000

“Six agents” here means one orchestrator (Zoe) plus five specialist agents. Six ACP coding experts run as concurrent implementation workers — not counted in that headline number.

Your Day Has Been Taken Over

Overnight, the trading agent ships the prior US session wrap-up. By morning, the macro analyst has the pre-market brief ready. The butler has pushed weather, schedule, and to-dos. AINews (AI Sentinel) has scanned GitHub Trending, arXiv’s latest papers, and 100+ sources — 18+ curated items ranked by importance. Content (Content Strategist) is tracking trending topics across 50+ platforms.

Here’s what matters most to me — automatic tracking of AI dynamics and tech trends. After discovering valuable projects or papers, the system doesn’t just push news — it evaluates impact on our systems and provides P0/P1/P2 action recommendations. Valuable discoveries enter Zoe’s Tech Radar (Zoe is the CTO Agent), going through evaluation → decision → delegated coding implementation.

60 cron tasks run automatically every day (3 AM backup to 11:45 PM reflection). Agents are evolving on their own — mistakes are remembered, recurrence rates drop significantly. This isn’t rules I wrote — it’s autonomous iteration from .learnings/ to MEMORY.md.

System: 1 orchestrator (Zoe) + 5 specialized agents (AINews, Trading, Macro, Content, Butler) + 6 ACP coding experts + 60 cron tasks + 100+ Skills + ~30 configured model profiles + 23 automatic recoveries in two weeks.

Note: Metrics based on February-March 2026 monitoring. Individual results may vary.

System Architecture

┌─────────────────────────────────────────────┐
│              User (Human)                   │
│    Requirements + Key Node Approval         │
└─────────────────┬───────────────────────────┘
                  │
         ┌────────▼────────┐
         │   Zoe (CTO)     │
         │  3x Daily Check │
         └────────┬────────┘
                  │
    ┌─────────────┼─────────────┐
    │             │             │
┌───▼───┐   ┌────▼────┐   ┌───▼───┐
│AINews │   │ Trading │   │ Macro │
└───┬───┘   └────┬────┘   └───┬───┘
    │            │            │
    └────────────┼────────────┘
                 │
        ┌────────▼────────┐
        │ Content + Butler│
        └────────┬────────┘
                 │
        ┌────────▼────────┐
        │   Event Bus     │
        │ + Shared Context│
        └────────┬────────┘
                 │
        ┌────────▼────────┐
        │ ACP Coding      │
        │ (6 concurrent)  │
        └─────────────────┘

Key Design Decisions:

Agents Evolving Autonomously

Designed protocols — Zoe diagnosed communication issues, designed three-state protocol (request → confirmed → final, with silent as the default "no news is good news" state), solidified into AGENTS.md
Self-developed Skills — Content researched ways to make drafts sound less generically LLM-written (“de-AI” polish), wrote Skills, published to ClawHub (shared repository)
Strategy roundtables — Macro + Trading produce weekly reports with data snapshots, position recommendations, stop-loss discipline
Task Watcher — Zoe designed cron-level Task Callback Event Bus for async monitoring

My role: Set up framework, establish constraints, confirm direction. Requirement discovery, solution research, protocol design, implementation — all done by agents.

Team: 1+5+6 Formation

Zoe (CTO / Chief Orchestrator)

3 daily inspections (10:00/14:00/22:00 PT): cron execution, disk usage, session health, Chrome DevTools Protocol (CDP) leak checks, .learnings/ pending, shared-context/ timestamps.

Weekly: Analyze each agent’s MEMORY.md, execute layered compression.

Key capability: Solution design — three-state protocol, Task Watcher, Communication Guardrail framework, all designed autonomously.

AINews (AI Sentinel) — Intelligence Hub

Collects from 100+ sources daily: GitHub Trending, arXiv, RSS, HackerNews, Reddit. 7 cron tasks: morning brief (08:30), midday paper (12:00), evening trends (20:00).

Critical capability: Proactive tech impact evaluation. Discovered ReMe framework → proposed to Zoe → I confirmed → agents executed.

Toolchain: github_trending.py, rss_aggregator.py, arxiv_papers.py, Tavily, agent-browser. Anti-hallucination: every item MUST have a URL, reachability self-check, and unverifiable items labeled single-source.

Trading (Quantitative Analyst)

21 cron tasks (densest load). 20 quant tools, 15 Skills (68K+ lines), 65/35 scoring (tool/AI). Covers US stocks + commodities + crypto.

Four-step framework: Macro factors → scoring (technical 25% / flow 30% / fundamentals 10% / sentiment 20% / market 15%) → cross-check (sanity-check vs. macro and flow) → target + score + stop-loss + confidence.

Not financial advice — automated research output only; you are responsible for any real-money decisions.

Hard rules (system policy, not investment advice): no entry without a defined stop, never fabricate data, confidence <60% = “wait.”

Macro (Chief Economist)

9 cron tasks: Morning (07:50) → Midday (12:30) → Evening (18:00) → US pre-market (22:00) → morning digest of the prior US session (05:20 PT) — scheduled after the cash close, not at the closing bell. Sunday weekly review → Trading references for market review.

Discipline: Cite sources, distinguish facts vs judgments, mark confidence (high >70% / medium 50–70% / low <50%), propose counter-arguments.

Real case: Iran tension → traditional: “gold rises” → actual: oil +14%, gold -5%. Macro: “inflation logic dominates, not safe haven.” Saved to MEMORY.md.

Content (Content Strategist)

9 cron tasks: Research (09:00, 50+ platforms) → Ideate (10:30, consume AINews) → Write (14:00, score drafts) → Reflect (22:10).

Autonomous evolution: Discovered content too “AI-flavored” → researched humanizing / de-generic copy tools → wrote Skills → published to ClawHub.

Five-Basket Radar: AI/Tech (≤40%), Product/Startup, Solopreneur, Investment/Macro, Social/International. 40% AI cap self-imposed during reflection.

Butler (Life Assistant)

7 cron tasks: Greeting (08:00) → Schedule (08:30) → 5 water reminders (rotating styles) → Health (20:00) → Summary (22:00).

Philosophy: <50 chars per reminder, ≥1.5h interval, 23:00–07:00 emergency only, no pestering if no reply.

ACP Coding Experts

Pi / Claude Code / Codex / OpenCode / Gemini / GPT-4.1-Codex. Max 6 concurrent, 120min TTL — queue or shed load when saturated so you don’t stampede gateways. Analysis agents don’t code — delegated via sessions_spawn.

Design Lesson

Don’t let analysis agents code directly. Early setup: coding + architect + PM roles. Result: almost no output, high overlap with Zoe + ACP, increased complexity. Cut them all. Zoe handles PM + architect.

Complexity grows fast: pairwise coordination explodes (six specialists ≈ fifteen pairwise handoffs if everyone talks to everyone). Each new agent ≈ half a day debugging conflicts, resource competition, and rule compatibility.

Three Core Engineering Problems

Problem 1: Context Is the Agent’s OS

The Problem: Entropy Always Increases

Without constraints, agent systems deterministically collapse. Agents are processes without an OS: no memory management, no garbage collection, no OOM protection.

Three incidents:

P0–8 Hours Paralysis

AINews session: 235K tokens. Gateway compaction → timeout → crash → macOS launchd ThrottleInterval=1 infinite loop. All agents offline.

Fix: Clean session → ThrottleInterval 1→10 → idleMinutes 180→30 → execution policy tightened from permissive to allowlist (smaller blast radius; keep the list maintained). Four defense lines missing.

P1–3500 Chars → 800 Chars

Trading’s flash report had data tables. OpenClaw auto-compacted when exceeded textChunkLimit—"intelligently compressed" away. AI "help" is disaster in data-dense scenarios.

P2 — Rules Ignore After Bloat

Sessions bloat to 10K+ tokens → agents “selectively comply.” Butler doing investment analysis. Trading ignoring validation. Critical info drowned in noise.

Solution: Dual-Layer Control

Layer 1: Context Engineering (information architecture)

SOUL.md (front): Identity + hard constraints + decision framework (40–60 lines)
AGENTS.md (after): Operating norms + collaboration protocols
Skills: Via extraDirs on-demand (Trading: 15 Skills, 68K lines on disk—retrieve or inject only the 1–3 relevant fragments per turn, not the whole tree)
shared-context/: Cross-agent state, read via tools
Obsidian: Cold storage, archives output, no inference

Rule wording targets weakest model (GPT-4.1 → Qwen3.5 → Ollama qwen3:8b):

"Suggest not fabricating" → qwen3:8b ignores
"MUST: do not fabricate" → all comply
"MUST + P0 + NON-NEGOTIABLE" → even weak models comply

Write for weakest link.

Layer 2: Harness (framework lifecycle management)

Without Harness → 235K tokens → crash. Without Context Engineering → all piled → rules drowned.

Representative openclaw.json excerpt (field names drift by release—validate against your OpenClaw version before paste-deploying):

{
  "compaction": {
    "mode": "safeguard",
    "memoryFlush": {
      "enabled": true,
      "softThresholdTokens": 40000,
      "prompt": "Distill to memory/YYYY-MM-DD.md. Focus: decisions, state changes, lessons."
    }
  },
  "contextPruning": { "mode": "cache-ttl", "ttl": "6h", "keepLastAssistants": 3 },
  "session": {
    "reset": { "mode": "daily", "atHour": 5, "idleMinutes": 30 },
    "maintenance": { "pruneAfter": "7d", "maxDiskBytes": 104857600 }
  },
  "hooks": { "bootstrap": ["self-improving-agent"] }
}

Cross-session recovery:

New session → SOUL.md + AGENTS.md + MEMORY.md + .learnings/ → memorySearch → shared-context/
= "Knows who, what done, what team doing"

Problem 2: Let Agents Remember and Grow

The Problem: Repeating Mistakes

Trading got BILLBOARD_BUY_AMT wrong 5 times (wrote BUY_AMT). Session reset → lost memory → repeat. User corrects → agent changes → 3 days later same scenario → same error.

Chatbot vs Agent dividing line: Agents learn from mistakes.

Solution: Five-Layer Memory

Autonomous Memory: 6-Step Cycle

Trigger: Operation failed · User corrected · Better approach found
L4 Recording: Write to .learnings/ERRORS.md or LEARNINGS.md
Daily Reflection (22:00): Review .learnings/, Zoe aggregates cross-agent value
PROMOTE: 3+ verifications → MEMORY.md, single → keep observing
L2 Sedimentation: Weekly compression, ❤000 tokens
L5 Skill: Generalizable → write as Skills → ClawHub

This is the core mechanism. Without it: chatbot. With it: agent.

Chatbot vs Agent

Problem 3: Let Agents Collaborate

The Problem: Multi-Agent Communication

Initial issues:

Status sync failures: A finished, B didn’t know
Resource contention: Multiple agents write same file
Information silos: Macro produced, Trading never saw
Responsibility gaps: “Who’s handling this?” → all silent

Solution: Three-State Protocol + Event Bus

Protocol (three active states + default silent state):

request → confirmed → final → [silent]

request: Explicitly acknowledges, starts the loop
confirmed: In progress, sends intermediate updates
final: Complete, result delivered, loop closes
[silent]: Default state when no active task — “no news is good news” (prevents spam)

Event Bus:

{
  "type": "MARKET_CLOSE",
  "source": "TRADING",
  "timestamp": "2026-03-07T15:00:00-08:00",
  "payload": { "symbol": "SPY", "note": "schema omitted for brevity" },
  "requiresAck": false
}

Shared Context:

tech-radar.json — Read-only except authorized writers
market-status.json — Trading updates, Macro/Content consume

Guardrails:

No ad-hoc cross-agent file writes; mediated writes only (tools, bus, approved writers)
All communication via event bus or shared-context; never park API keys or session tokens in shared JSON — use your platform’s secret store
Zoe has final arbitration

Results: 4 Weeks, 23 Auto-Recoveries

Timeline:

Week 1: Basic setup, single agent, frequent crashes
Week 2: Multi-agent coordination, protocols established
Week 3: Autonomous evolution, agents self-fixing
Week 4: Production-ready, 60 cron tasks smooth

Key Metrics:

What I Learned

1. Agents Need an OS, Not Just Prompts

Context Engineering is OS design. You need:

Memory management (compaction, pruning, reset)
Process isolation (separate workspaces)
IPC mechanisms (event bus, shared context)
Garbage collection (session cleanup, disk limits)

2. Memory = Chatbot vs Agent

Can’t remember yesterday’s mistakes = fancy chatbot. Five-layer memory transforms stateless LLM calls into stateful, learning entities.

3. Constraints Enable Creativity

Clear boundaries = more creative, not less. 40% AI quota, three-state protocol, hard “MUST” rules — these are guardrails for autonomous operation.

4. Multi-Model Fallback Is Production Necessity

GPT-4.1 → Qwen3.5 → Ollama qwen3:8b. Write rules for weakest link.

5. Human: Doer → Designer

My job: design system where code writes itself. I’m architect, not bricklayer.

Looking Ahead

Next steps:

P0: Dead-letter queue for failed events
P1: Manual resend CLI for stuck tasks
P1: Audit log rotation
P2: Visual dashboard for system health

Goal: Amplify human capability. One person + six agents > one person + zero agents. That’s Harness Engineering.

Quick Reference

Agent Roster

Total: 60 cron, ~90 Skills

Daily Schedule (Pacific Time, America/Los_Angeles)

Cron rows are snapshots from my stack — align to your exchange calendar, asset class (equities vs. crypto), and whether you are on PST or PDT.

Critical Files

If you run a similar harness, how do you handle failures when compaction, cron, and multi-agent handoffs all interact — what breaks first in your stack, and what fixed it?

References

OpenClaw: https://github.com/openclaw/openclaw
PowerMem: https://github.com/oceanbase/powermem
ClawHub: https://github.com/openclaw/clawhub
Mitchell Hashimoto: “My AI Adoption Journey” — https://mitchellh.com/writing/my-ai-adoption-journey
Anthropic: “Effective harnesses for long-running agents” — https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents

All times Pacific Time (America/Los_Angeles; PST or PDT depending on season). macOS + OpenClaw. Monitoring: Feb–Mar 2026. Validate config against your OpenClaw release at https://github.com/openclaw/openclaw

Harness Engineering: From AI-Assisted to AI-Driven, What Is Software Engineering Undergoing?

Charles Wu — Mon, 27 Apr 2026 12:22:38 +0000

What happens when a team ships a million lines of code without writing a single line by hand?

Editor’s Note: This article is based on verified engineering blogs from OpenAI, Anthropic, and Mitchell Hashimoto (2025–2026). All references are linked in the end.

In February 2026, OpenAI engineers revealed they had shipped a million-line codebase in five months — with zero manually-written code. All of it was generated by Codex agents.

When I first read about this experiment, my feelings were complicated. Three engineers, five months, one million lines of code — all written by AI. As someone who’s written code for years, I had to ask: If AI can write code by itself, what’s left for us?

It wasn’t until I understood Harness Engineering that I found the answer:

AI is not replacing engineers; it’s forcing us to level up — from “craftsmen” to “system designers.”

What Is Harness Engineering?

“Harness” originally means horse tack — equipment that both constrains a horse and enables it to pull a cart. You can’t let the horse run wild, but you can’t tie up its legs either. You give it direction.

Mitchell Hashimoto (HashiCorp founder) applied this to AI engineering in early 2026:

“I don’t know if there is a broad industry-accepted term for this yet, but I’ve grown to calling this ‘harness engineering.’ It is the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again.”

Traditional debugging: “Something broke, fix it.”
Harness Engineering: “Something broke, build a system to prevent it from happening again.”

For example: If AI keeps calling an API incorrectly, don’t just remind it. Write code that requires API calls to pass type checking — encode human judgment into system constraints.

The core of Harness: Not predicting what mistakes AI will make, but designing an environment where mistakes are hard to occur.

OpenAI’s Experiment: Zero Human-Written Code

In August 2025, a three-person team at OpenAI set a rule: No writing any code — all left to Codex.

The Challenge

Early progress was slower than expected. Not because AI was incapable, but because the environment wasn’t ready. The team spent time not on “using AI,” but on “making AI usable.”

Key insight:

When AI fails, don’t just “let it try again.” Ask: “What capability is missing? How can we make this executable and verifiable?”

Three Core Designs

Progressive Context Management

AI’s context window is limited. OpenAI used structured files like claude-progress.txt to pass state between sessions. Like a relay race baton—each AI reads what the previous "shift colleague" accomplished.

Feature List: Letting AI Know “It’s Not Done”

AI has a bad habit: thinking it’s done after half the work. The Initializer Agent breaks requirements into 200+ small features, each marked “incomplete.” Coding Agents take one at a time, only changing status after completion.

Self-Check Mechanism

They equipped AI with Puppeteer (browser automation), letting it interact with its own application — clicking, screenshotting, verifying functionality. Not checking if code is correct, but if the thing actually works.

Results

After five months:

1,500 PRs, all AI-generated
3.5 PRs per engineer per day
Single AI sessions running 6+ hours (often while humans slept)

By the later stages, AI could complete features end-to-end:

Reproduce bug → Record video → Fix bug → Verify → Open PR → Respond to feedback → Merge

This is autonomous software engineering.

Anthropic’s Deep Exploration: Generator + Evaluator

OpenAI proved feasibility. Anthropic went further with harness design for long-running agents.

The Core Challenge

As Anthropic researcher Justin Young noted:

“Imagine a software project staffed by engineers working in shifts, where each new engineer arrives with no memory of what happened on the previous shift.”

Every time the context window fills and resets, AI gets amnesia. Anthropic’s solution: “structured handoff” — designing documentation so the next AI can quickly take over.

GAN-Inspired Architecture

Prithvi Rajasekaran from Anthropic Labs designed a Generator + Evaluator dual-agent system, inspired by GANs (Generative Adversarial Networks).

Key discovery: If AI evaluates its own work, it’s lenient — clearly mediocre, but says “pretty good.” Split evaluation into an independent agent, and things change.

Frontend design experiment:

Generator: Produces design drafts
Evaluator: Operates the page using Playwright, scoring on design quality, originality, craftsmanship, functionality

One prompt addition made a difference: “The best designs should be museum quality.” The generator started producing surprisingly creative effects — including once restructuring a Dutch art museum’s website into a 3D spatial experience with walkable exhibition halls.

Full-Stack Application

Rajasekaran expanded to a three-agent system:

Key: Contract — before each iteration, Generator and Evaluator negotiate “what counts as done.”

Test: Build a “retro game maker.”

The gap was not small.

The Deeper Logic: Three Paradigm Shifts

1. From “Writing Code” to “Designing Systems”

Traditional growth path: learn to write code → design modules → architect systems.

Harness Engineering reverses this: You must first know how to design systems to use AI for writing code effectively.

This is upgrading, not downgrading. From “craftsman” to “factory designer” — you’re not making less, but what you make has more leverage.

2. “Constraints” Become Creation

Adding constraints to AI doesn’t limit it — clear constraints make AI more creative.

Anthropic’s “museum quality” standard made AI strive in that direction. OpenAI’s architecture constraints let AI write code boldly without breaking things.

Like jazz chord progressions — having the framework lets musicians improvise confidently.

3. Quality Control Paradigm Shift

From the OpenAI team:

“Humans may review pull requests, but aren’t required to. Over time, we’ve pushed almost all review effort towards being handled agent-to-agent.”

AI is reviewing code written by AI. Not because humans got lazy, but because throughput is too high. When AI opens 3.5 PRs per day, humans can’t review them all.

Quality control shifts from “checking every line” to “designing mechanisms for AI self-verification.”

If AI can operate browsers, run tests, and verify functionality — why can’t it review code?

What This Means for Developers

Don’t Panic, But Don’t Wait

Harness Engineering doesn’t mean programmers become unemployed. Those three OpenAI engineers weren’t replaced — they changed their way of working from “people who write code” to “people who design systems and control quality.”

But this transformation won’t wait until you’re ready.

“Boring” Technologies Win

The OpenAI team prefers “boring” technologies — stable APIs, comprehensive documentation, high composability. AI performs better in predictable environments.

Future tech selection: React over Svelte (more documentation), Python over Rust (more training data). Not exciting, but practical.

Soft Skills Become More Valuable

If AI writes code, what’s more valuable?

System Design: Breaking down problems, defining interfaces
Product Sense: Turning vague requirements into clear definitions
Quality Judgment: Knowing “good” versus “just runs”
AI Management: Which tasks suit AI, which need humans

These aren’t new skills, but their importance is changing.

The Future: Orchestrating Agents

Industry trends through 2025–2026 show software engineering shifting from “writing code” to “orchestrating agents.”

Harness Engineering provides a framework: not treating AI as a black box, but as a system component to be designed.

You’re not “conversing” with AI; you’re collaborating — like conducting an orchestra, or managing a team.

Future software engineers may be more like “directors” or “conductors”: not playing every note, but determining the direction and style of the entire piece.

Is this good? I don’t know. But this is what’s happening.

Final Thoughts

If AI can write code by itself, what can programmers do?

We can design systems that let AI write code.

This is not escape — this is evolution.

Harness Engineering doesn’t make engineers lazy; it makes engineers stronger — using system power instead of individual power, design capability instead of coding capability.

Perhaps this is what software engineering was always meant to be.

Your Turn

Where is your AI pipeline breaking first?

Ingestion?
Retrieval?
Evaluation?
Cost control?

Share your experience in the comments. The best harness designs come from real war stories, not textbook theory.

Enjoyed this? Follow for more on AI infrastructure, agentic coding, and the future of software engineering.

References

OpenAI (Feb 2026). “Harness engineering: leveraging Codex in an agent-first world.” https://openai.com/index/harness-engineering/
Hashimoto, Mitchell (2026). “My AI Adoption Journey.” https://mitchellh.com/writing/my-ai-adoption-journey
Fowler, Martin (Feb 2026). “Harness Engineering — first thoughts.” https://martinfowler.com/articles/exploring-gen-ai/harness-engineering-memo.html
Anthropic (Nov 2025). “Effective harnesses for long-running agents.” https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
Anthropic (2026). “Harness design for long-running application development.” https://www.anthropic.com/engineering/harness-design-long-running-apps

AI Products Break on the Data Layer — Not on the Next Model Release

Charles Wu — Mon, 27 Apr 2026 12:17:24 +0000

Harness Engineering, in plain terms: ingestion, retrieval, memory lifecycle, and hybrid search matter more than a bigger context window once real traffic hits.

Your AI can sound fluent and still burn trust after launch. The failure mode is rarely “swap the model.” It is what you retrieve, what you remember, and what you never ingested correctly.

Across deployments and community conversations, we keep seeing the same arc: traction first, then tickets — answers that read authoritative but trace to stale docs, policies updated on Monday still echoed on Friday, and churn that does not look like “model weakness” because the underlying model is still capable.

We treat that pattern as a pipeline problem, not pure hallucination. Here, Harness Engineering means applying data-engineering discipline — schemas, lifecycle, retrieval, and cost/latency budgets — so production behavior is bounded by the data layer, not by prompt cleverness. If you are shipping AI in 2026, this is the layer to harden next; below, we walk through memory, RAG, and the database patterns teams use to get past the demo.

The Hallucination Problem

Looking at the journey from large models to AI products over the past two years, hallucination has remained the core bottleneck. Many optimization solutions have emerged: prompt engineering, context engineering, and the recently highlighted Harness Engineering.

Hallucinations in production often trace to gaps in the data processing pipeline, not only to model limits. Below, we clarify why the underlying data foundation matters.

Why Context Engineering Matters

Context engineering has evolved through several stages: prompt engineering, RAG (Retrieval-Augmented Generation), and the emerging Memory mechanism.

A model’s context window functions like a computer’s RAM — fast but limited. Even with expanded context windows (some can process entire novels), dumping raw data into context rarely produces reliable gains on its own.

The Long Context Trap

Theoretically, more information should mean better understanding. In reality, excessive context length triggers multiple issues:

Performance: More tokens = higher inference latency
Cost: Token usage grows linearly with context length
Accuracy: Context length and model accuracy are negatively correlated — the “Lost in the Middle” effect

This explains why system prompts and user prompts should be placed at the beginning and end of the sequence — avoiding attention weakening toward middle information.

Solving AI “Amnesia” at the Data Level

Many AI products have obvious memory deficits: user interactions from today are forgotten tomorrow; switching sessions causes the system to fail to recognize the user’s identity.

PowerMem, an open-source AI memory component, addresses this at the data layer. In stress testing:

Improved Accuracy: +48.77% (from 52.9% to 78.7%)
Higher Retrieval Efficiency: P95 latency significantly reduced
Reduced Costs: Up to 96.53% token cost savings

How It Works

PowerMem simulates human memory mechanisms through three layers:

Access Layer: Python SDK, MCP Protocol, HTTP API, CLI (pmem), and Dashboard
Core Layer:
- Hierarchical Memory (Working/Short-term/Long-term)
- Shared vs Private Memory isolation
- Intelligent filtering and conflict detection
- Ebbinghaus Forgetting Curve for lifecycle management
Model & Storage Layers: Integration with GPT, Qwen, DeepSeek; optimized for OceanBase and seekdb

For AI hallucination, what’s needed is not just memory storage, but an intelligent memory engine with “thinking” and “forgetting” capabilities.

Real-World Impact: OpenClaw Integration

OpenClaw, a popular AI agent framework, defaults to local Markdown files and SQLite for memory. This works for individuals but fails at enterprise scale:

Uncontrolled token consumption as memory files grow
No centralized, structured management for collaboration

By integrating PowerMem via plugins.slots.memory = memory-powermem:

Accuracy: +49%
Latency: -92%
Token consumption: 18% of original

This transforms memory from a “personal toy” to an “enterprise tool.”

RAG Done Right

Memory alone doesn’t give AI wisdom. The key lies in Retrieval-Augmented Generation (RAG).

The RAG Dilemma

Many teams face “great demos, poor production.” After months, results remain unsatisfactory with frequent hallucinations. Pain points:

Insufficient Document Parsing: Can’t extract structured data from unstructured sources
Poor Retrieval Accuracy: Can’t recall relevant information from massive datasets

PowerRAG enhances both modules:

Enhanced Parsing: SOTA models with title recognition, regex matching, intelligent chunking
Enhanced Retrieval: Hybrid search (full-text + vector + scalar filtering)
Unified Storage: Metadata, documents, vectors in a single database

Application Scenarios

The AI Database Imperative

Beyond memory and RAG, the database directly determines AI application intelligence, performance, and cost.

Hybrid Search Becomes Standard

Consider this query:

“Find coffee shops within 0.3 miles, with average price under $6, rating above 4.0 stars, and minimal wait time.”

This contains:

Spatial: “Within 0.3 miles” → geographic indexing
Scalar: “Under $6,” “above 4.0” → structured filters
Vector: “Minimal wait” → semantic understanding

Traditional architectures need multiple systems. Integrated databases handle this in one SQL query.

Multi-Path Fusion Retrieval

Single retrieval modes (vector-only or full-text-only) can’t meet complex needs. Multi-path fusion significantly improves recall:

One-Stop Document Processing

AI-era databases integrate AI Functions at the kernel level:

Built-in Models: Embedding, Rerank, Document AI deployed inside
Simple Development: One SQL statement processes unstructured documents
Full Automation: document → text → parsing → embedding → retrieval → reranking

All AI processing logic is “pushed down” to the database layer, lowering the development threshold.

Database Selection Guide

For Enterprise Projects

Traditional “patchwork” architecture (Milvus + MySQL + Elasticsearch + Redis) brings:

Complex deployment and monitoring
Version compatibility nightmares
Stacked operational costs

A typical hybrid search requires 2+ database requests and transmits 910 records to present Top 10 results — inefficient and costly.

Integrated architecture manages vector, document, KV, spatial, relational, and time-series uniformly — one database covers all scenarios.

For Startups

Startups need:

Reliability: Data foundation is the lifeline
Cost-Performance: Every penny counts

seekdb — a lightweight AI-native database based on OceanBase — mainly offers:

AI-Native Functions: AI_EMBED, AI_COMPLETE, AI_RERANK built into SQL; DBMS_AI_SERVICE for LLM integration
Hybrid Search: Vector + full-text + scalar in a single query with multi-path recall and advanced reranking (RRF, LLM-based)
Multi-Model Data: Relational tables, vectors, text, JSON, and GIS unified in one engine
Lightweight Deployment: 1C2G specification; embedded mode for prototyping, client/server mode for production
Apache 2.0 Open Source: Fully open-source with smooth migration path to OceanBase for scale-up

The Layered Architecture

A successful AI product design follows four layers:

The Core Logic

AI engineering has evolved:

2022–2023: Prompt Engineering
2025: Context Engineering
2026: Harness Engineering

Breaking through AI bottlenecks still relies on a solid data foundation:

“Use the reliability of data engineering to drive AI products to operate more efficiently and stably from the data level.”

Where to start

If you are building in this problem space, these public entry points lead straight to the code:

PowerMem (open-source memory component): https://github.com/oceanbase/powermem
seekdb (lightweight AI-native database for prototyping and small deployments): https://github.com/oceanbase/seekdb

If you have shipped memory or RAG in production, tell us where the pipeline broke first — ingestion, retrieval, evaluation, or cost. We welcome the discussion in the comments.

References

Context Engineering Research: https://research.trychroma.com/context-rot
Anthropic on Memory: https://www.anthropic.com/research/memory

Nobody Picks Your AI Product Because of Your Spreadsheet

Charles Wu — Mon, 27 Apr 2026 12:08:27 +0000

The adoption curve still runs on copycats, not charts.

ll line up to try it.

They didn’t. Not most of them.

And the more time I spend with real customers — not personas on a slide — the more convinced I am that we’re not living in a “data decides” era for the majority of buyers. We’re living in the same era we always were. The packaging just got shinier.

The setup: a book from 1962 still runs your roadmap

There’s an old book — Diffusion of Innovations, first published in 1962 — that studied how new ideas spread in agriculture and a dozen other “unsexy” domains. The core idea is almost boring in how well it holds:

Don’t spray a new thing on everyone. Seed it with a small group who actually use it, succeed with it, and become visible.

People who look like them notice. Then imitation does the marketing for you.

That’s not a metaphor. It’s the mechanism.

The real issue: “data-driven” is a minority sport

Like a lot of teams, we invested heavily in proof: benchmarks, reproducible scripts, comparison tables, the whole performance page aesthetic. That work matters — for someone.

But here’s the pattern I keep seeing in the field:

Roughly nine in ten people, when they’re choosing something new, aren’t optimizing a spreadsheet first. They’re running a social proof script: Who that’s like me is already on this? Do they like it? If it’s working for them, I’ll try it.
Maybe one in ten is the “try the weird thing because the architecture is interesting” crowd — the people who read the methodology footnotes, who reproduce the benchmark, who file the issue before they’ve paid.

That second group is tiny. They’re also the entire audience for your benchmark PDF.

So we keep optimizing artifacts for 10% of the decision loop — and wondering why the other 90% still asks the same three questions on every sales call: Who uses this? At what scale? Would you use it yourself?

Call it what it is: people learn from people. The rest is commentary.

What actually works (for GTM and internal rollouts)

I’m not arguing against rigor. I’m arguing for allocation.

Treat early adopters like infrastructure, not vanity metrics.
They’re not “nice to have.” They’re the distribution channel. Find them deliberately — communities, power users, the engineers who already filed three feature requests — and over-invest in their success: access, support, fast fixes, public credit.
Make their wins legible to the 90%.
Case studies aren’t marketing fluff if they answer the real question: someone like me got from A to B. Prefer named contexts (role, stack, constraint) over anonymous “10x faster” claims.
Stop expecting the median buyer to behave like a reviewer.
Your benchmark suite is for trust-building with skeptics and internal discipline. Your growth loop is referenceability among peers.
Inside the company, run the same play.
When you introduce an AI tool or an internal “skill,” give the enthusiasts the lion’s share of pilot budget — time, credits, executive air cover — then broadcast what they shipped. Not as a mandate. As a story. The rest of the org will follow the same imitation math external users do.

What I’d do differently next time

I’d still ship the charts. I’d just stop mistaking them for the main character in adoption.

I’d start every launch plan with one blunt question: Who are our first ten visible users, and what does “win” look like for them — not for our narrative?

Takeaways

Diffusion beats diffusion slides: adoption is still a social process dressed up in SaaS metrics.
~90% of selection is peer imitation; ~10% is exploratory — and that 10% is who actually reads your benchmark appendix.
Your scarcest asset isn’t attention — it’s credible early users; resource them like a channel, not a lottery.
Internal AI rollouts follow the same law: over-invest in willing experimenters, celebrate outcomes loudly, let imitation do the rest.

If you’re building in the AI infra space: I’m curious — what’s the one question prospects ask you before they ever open your perf doc? Drop it in the comments.

Your Documentation Has Two Audiences Now (And One Is an AI)

Charles Wu — Mon, 27 Apr 2026 11:59:40 +0000

Technical documentation’s audience has changed. It’s no longer just engineers reading pages — increasingly, humans and AI work together: humans make decisions, AI finds materials, organizes steps, and assists execution. Here’s how to make the same knowledge serve both.

Last month, our team shipped a major documentation update. Two weeks later, I noticed something odd: our AI assistant was giving outdated answers. The docs were right. The AI was wrong.

That’s when I realized — we were writing for humans, but forgetting the AI assistants helping them.

This isn’t just about adding llms.txt to your repo. It's about recognizing a fundamental shift: technical documentation now serves two audiences simultaneously. And if you optimize for only one, you're already behind.

Welcome to the era of Document “Skillification” — a term for making documentation AI-consumable through structured, callable capabilities. Not yet in the dictionary, but you’ll hear it more as AI Agents become mainstream.

Why This Matters Now

The audience for technical documentation has changed. In the past, it was primarily engineers reading pages. Today, more and more scenarios involve humans and AI working together: humans make decisions, while AI is responsible for finding materials, organizing steps, and assisting execution.

If documentation only exists in web page form, AI typically needs to process HTML first, then extract the main content from navigation, styling, and irrelevant information. This step reduces accuracy and slows down response times.

Therefore, what document Skillification solves is not a new buzzword, but a practical problem: how can the same body of knowledge serve both humans and AI?

What Is Document Skillification?

This can be understood in two layers.

The first layer is making documentation AI-consumable. Common entry points are llms.txt, llms-full.txt, and page-level .md exports. The focus is on enabling AI to reliably obtain structured content.

The second layer is the Skill repository. Using SKILL.md to write processes, constraints, and best practices as callable capabilities, answering "what rules to use in what scenarios."

These two layers work in tandem: the former provides content entry points, while the latter constrains usage patterns.

A Practical Implementation Roadmap

Start by adding AI entry points — no need to refactor all documentation at once. Create llms.txt, fill in .md exports for key pages, and provide llms-full.txt as needed. This way, you first ensure content is readable, then gradually improve reading accuracy and usage stability.

Then codify high-frequency actions into Skills. Examples include SQL documentation writing standards, operations troubleshooting flows, and upgrade checklists. This type of content has high reuse rates and is most prone to inconsistencies when communicated orally.

For the retrieval layer, adopt “search first, then read.” Given large and rapidly updating documentation, do not dump the entire text into context at once. You can use MCP or a database query layer. The key is not the integration form, but on-demand retrieval.

Drawing from the oceanbase-doc-skills implementation (https://github.com/amber-moe/oceanbase-doc-skills), this path is already viable: skills, rules, examples tables store structured knowledge, and QueryService retrieves results by skill name, category, or keywords, then passes them to the upper layer for invocation.

How Existing Projects Approach This

Nuxt’s approach is to standardize entry points first. Official support for llms.txt capabilities is provided, and Nuxt Content offers an LLM integration module. Instead of manually maintaining two sets of documentation, this adds an AI consumption export on top of the existing content system.

Docus leans toward “in-site capabilities.” It integrates AI Assistant and MCP into the documentation site. AI doesn’t need to preload the entire site but retrieves on demand. This reduces context pressure and improves hit controllability.

Vite’s path is straightforward: documentation pages and Markdown pages have a one-to-one correspondence — guide corresponds to guide.md. Combined with llms.txt as a directory entry point, this forms a "locate first, then fetch by page" flow. Engineering refactoring costs are relatively low.

Cloudflare’s approach is more comprehensive. Documentation entry points, Skills, and retrieval capabilities are connected together, basically forming a closed loop of content, rules, and invocation.

Anthropic’s focus is on standardization itself. Through Agent Skills specifications and example repositories, it standardizes Skill metadata, trigger descriptions, and content organization methods, facilitating cross-tool reuse.

Direct Value This Direction Brings

Reduced maintenance costs. One knowledge source can simultaneously serve web reading and AI invocation, reducing duplicate maintenance.
Reduced team memory burden. Operations statements, SQL specifications, and troubleshooting flows change from “relying on human memory” to “on-demand invocation.”
Better usability in offline scenarios. In intranet or isolated environments, llms-full.txt and local Skills can support local retrieval and assisted execution.
More consistent output. Processes and formats are front-loaded into Skills, reducing variance between different people and different models.

Problems to Address Upfront

This is not a one-time engineering effort. Specifications change, tools change, models change — Skills require continuous maintenance.

If documentation volume is large, avoid doing everything at once. A safer approach is to pilot in high-value domains first, then gradually expand.

Additionally, human-readable versions and AI consumption entry points need a synchronization mechanism. Without synchronization, you’ll eventually end up with two diverging documentation sets.

Finally, Skill instructions must be executable and verifiable. Rules written too abstractly will spiral out of control during implementation.

Conclusion

Document Skillification is not about changing how documentation is written — it’s about refactoring the knowledge delivery path: enabling the same content to support reading, retrieval, and execution simultaneously. For technical teams, this ultimately translates to lower communication costs, more stable delivery quality, and faster issue resolution cycles.

What’s Next?

→ Try it yourself: Start with llms.txt on your next documentation update.

→ Building agent skills? Check out the Anthropic Skills specification (https://github.com/anthropics/skills) for best practices.

→ Got questions? Drop a comment below — I read every one.

→ Want more? Follow for deeper dives into AI-native documentation patterns.

Is your documentation AI-ready? Share your approach in the comments.