Two open-source projects have recently surfaced the right question at the right time: what should an AI agent remember, and how should it remember it?

GBrain (garrytan/gbrain, ~3.7K stars) gives every AI agent a "personal brain" -- a directory of markdown files organized into MECE categories, backed by PGLite/pgvector for hybrid search. Rowboat (rowboatlabs/rowboat) takes a similar approach with an Obsidian-compatible vault where [[Entity]] wiki-links form the knowledge graph and background agents maintain it.

Both projects correctly identify the core problem: persistent agent knowledge beats cold-start RAG. A pre-computed knowledge base, where synthesis happens at write time rather than query time, will always outperform a system that re-derives understanding from raw documents on every request. GBrain's "compiled truth" pattern -- current state above the line, append-only timeline below -- is genuinely elegant. And Rowboat's decision to make the vault Obsidian-compatible means humans can browse what the agent knows using tools they already use.

But both projects encode their knowledge in markdown. And that is where the architecture starts to crack.

What markdown gives you

To be fair about what works: markdown knowledge bases are fast to set up, readable by humans and LLMs alike, and trivially version-controlled with git. GBrain's MECE resolver pattern -- every directory has a README.md that answers "what goes here" and "what does NOT go here" -- is a clever way to impose structure without a schema language. The agent reads the resolver before creating any page, walks a decision tree, and files the entity in exactly one directory. No duplicates, no ambiguity.

GBrain's two-layer page structure (compiled truth + timeline) solves a real problem that most RAG systems ignore: temporal ordering of facts. When you separate "what is currently true" from "what happened and when," you get a knowledge base that agents can actually reason over without re-deriving state from raw source documents.

Rowboat's [[wiki-link]] syntax is familiar to anyone who has used Obsidian or Notion. It creates a navigable graph of entities. Background agents can traverse links, update pages, and maintain cross-references.

These are real strengths. For a single agent managing a single person's knowledge at personal scale -- a few thousand entities, one writer, no regulatory requirements -- text-first knowledge graphs work surprisingly well.

The question is what happens when they don't.

The seven things markdown can't express

1. Typed relationships

When GBrain writes See Also: [[Acme Corp]], [[Jane Doe]] at the bottom of a deal page, what is the relationship between the deal and Acme Corp? Is Acme the buyer? The seller? A competitor? A subsidiary of the actual counterparty?

A markdown backlink says "these two things are related." It doesn't say how. In an RDF knowledge graph, that relationship is a typed predicate: deal:AcmeSeries-B logos:hasCounterparty company:AcmeCorp. The predicate carries semantic meaning that survives aggregation, inference, and multi-hop traversal.

This matters the moment you need to answer a question like "show me all deals where the counterparty has raised more than $50M." With typed predicates, that's a single SPARQL query. With markdown backlinks, it's a full-text search across every deal page, hoping the agent wrote "counterparty" in a consistent format near the company name.

2. Write-time validation

GBrain's MECE resolvers enforce directory structure, but they can't enforce data quality within a page. If the agent writes a person's title as "CEO" on one page and "Chief Executive" on another, nothing catches the inconsistency. If it links to a company that doesn't exist yet, the backlink silently points to nothing.

SHACL (Shapes Constraint Language) and ShEx (Shape Expressions) solve this at the graph level. A shape contract declares: every Person node must have exactly one schema:jobTitle, and that title must come from a controlled vocabulary. Every logos:hasCounterparty link must point to an existing Company node. Violations are caught at write time, not discovered months later when a query returns garbage.

The difference is the same as the difference between a dynamically typed language and a statically typed one. Both work. One catches errors earlier.

3. Epistemic routing

GBrain organizes knowledge by topic: people/, companies/, deals/, concepts/. This is intuitive but creates a fundamental problem when the same entity participates in multiple epistemic domains.

Jane Doe might be a person (biographical facts), a patent inventor (IP claims with evidence chains), a product lead (go-to-market intelligence), and a build contributor (implementation decisions). In a directory-based system, Jane's page lives in people/ and everything else is cross-referenced via backlinks. The directory tells you the topic. It doesn't tell you the function of the knowledge.

Named graphs solve this by routing knowledge by epistemic function, not subject. The same Jane Doe node appears in the default graph (what we know and believe), the NOUS graph (her patent claims and prior art), the VENUS graph (her product positioning), and the TECHNE graph (her build decisions). Each graph has its own validation rules, access controls, and lifecycle. A patent claim has different evidentiary requirements than a biographical fact. Named graphs make that distinction structural, not procedural.

4. Subsumption and hierarchy

Markdown backlinks are flat. [[Fintech]] and [[Banking]] are just two links. There's no way to express that fintech subsumes banking, that banking is a specialization of financial services, or that a regulatory requirement that applies to financial services transitively applies to every fintech company in the graph.

RDF's rdfs:subClassOf and skos:broader/skos:narrower predicates give you this for free. A SPARQL query that asks "find all entities in financial services" automatically includes banking and fintech without the query author knowing those subcategories exist. Taxonomy traversal is built into the query language, not bolted on as a text search heuristic.

5. Temporal logic

GBrain's timeline layer (the append-only section below the line) records what happened and when. But it's unstructured text. You can't query "what was true about this company in Q3 2025?" without reading every timeline entry and reconstructing state.

Bitemporal provenance -- tracking both when a fact became true in the world (validFrom) and when it was recorded in the system (discoveredAt) -- makes temporal queries first-class operations. "Show me every claim about this company that we believed was true in October 2025 but have since revised" is a single query, not an archaeology expedition through markdown files.

6. Confidence scoring

Every fact in a markdown knowledge base is implicitly asserted as true. There's no way to express "we're 70% confident this company is raising a Series B" or "this claim is supported by two independent sources but contradicted by one."

Quantified confidence -- ISR (Information Source Reliability) and EDFL (Evaluated Data Fidelity Level) scoring -- turns binary true/false assertions into a spectrum. When an agent writes a claim, it attaches a confidence score and a provenance chain. When a second source confirms or contradicts the claim, the score updates. Downstream consumers can filter by confidence threshold: show me only claims above 0.8 reliability for the board presentation, but include everything above 0.4 for the research brief.

7. Multi-agent coherence

This is the gap that will matter most as agent systems scale.

GBrain is designed for a single agent maintaining a single person's brain. The MECE resolver, the compiled truth pattern, the enrichment pipeline -- all assume one writer. The moment a second agent starts writing to the same knowledge base, you need conflict resolution, merge semantics, and a way to determine whose assertion takes priority when two agents disagree.

Rowboat's background agents share a vault, but wiki-links provide no mechanism for coordinating concurrent writes. Two agents can create contradictory [[Entity]] pages simultaneously, and the conflict surfaces only when a human notices.

A schema-first system with typed predicates, named graphs, and provenance tracking can support multi-agent fleets because every write carries metadata: who wrote it, when, with what confidence, under what authority. PARALLAX trust tiers, where agents at different trust levels have different write permissions and their assertions carry different default confidence scores, make multi-agent coordination a graph property rather than an application-level hack.

The complexity tradeoff

Schema-first knowledge graphs are harder to set up. That's not a minor point.

GBrain goes from zero to a working brain in 30 minutes. An RDF knowledge graph with SHACL validation, named graphs, SPARQL endpoints, and multi-agent coordination takes days to weeks. The learning curve is steeper. The tooling is less polished. "Just write markdown" is a powerful pitch because it's true -- you can start immediately, with tools you already know, producing artifacts you can read without specialized software.

GBrain's "thin harness, fat skills" philosophy -- keep the infrastructure minimal, put the intelligence in markdown skill files that the model already knows how to read -- is a legitimate architectural position. When Garry Tan argues that "markdown is actually code" and that a skill file is "a more perfect encapsulation of capability than rigid source code," he's making a real point about where the bottleneck is in current agent systems. It's not model intelligence. It's context delivery.

But the bottleneck shifts as scale increases. At 500 entities and one agent, context delivery is the constraint and markdown wins. At 50,000 entities across 12 epistemic domains with five concurrent agent writers and regulatory audit requirements, structural integrity is the constraint and schema wins.

When to use which

Use text-first (GBrain, Rowboat) when:

Use schema-first (RDF/SPARQL with SHACL) when:

The convergence thesis

Here's what I think actually happens: text-first systems will gradually add schema. GBrain's MECE resolvers are already proto-schemas -- they define what goes where and enforce it procedurally. The compiled truth pattern is a proto-shape constraint -- it mandates page structure, even if the enforcement is an LLM reading instructions rather than a validator checking triples.

The question is whether you want to add schema incrementally (starting with markdown and bolting on validation as you hit scale problems) or start with schema and relax it where simplicity matters more than rigor.

Both paths converge on the same destination: knowledge that is structured enough for machines to reason over and flexible enough for humans to maintain. The text-first path gets you started faster. The schema-first path gets you to production without a rewrite.

GBrain and Rowboat are proving that agents need persistent, pre-computed knowledge. That insight is correct and important. The architectural question isn't whether to build a knowledge graph -- it's whether your graph should be validated at write time or discovered at read time.

For personal-scale agent memory, discovery at read time is fine. For production-scale multi-agent systems, you want the graph to tell you when something is wrong before a downstream consumer discovers it the hard way.

The markdown is the interface. The schema is the infrastructure. Build both, but know which one is load-bearing.