Thesis

Core Claim Agent memory can scale the same way the human web scaled — not by centralizing it into a database or a platform, but by making the structured data already sitting in markdown format into Linked Data, the way JSON-LD did for HTML.
1
The objection: "the LLM wiki doesn't scale"
Andrej Karpathy's LLM-wiki pattern — a folder of markdown files an agent reads and writes — is dismissed as "cute" but non-scalable, because plain markdown is local and not part of any shared semantic fabric.
2
The overlooked asset: frontmatter is already half-structured
Most notes in an LLM wiki already carry YAML frontmatter (status, tags, dates, links, types). It just isn't anchored to a shared vocabulary yet — the "semantic island" already exists, unlabeled.
3
The precedent: JSON-LD already proved the pattern at web scale
JSON-LD sits inside 54% of websites (W3Techs) with no central platform, database, or vendor owning it — millions of independent "islands" that connect because they share a context, not because they share infrastructure.
4
The move: YAML-LD and Vault-LD apply the same mechanism
YAML-LD (a fresh W3C working draft) does for YAML what JSON-LD did for JSON. Vault-LD applies that specifically to agent memory: keep the notes and files, just make the frontmatter Linked Data.
5
The principle: "scaleless" — no centre, no bottleneck
The web did not scale through one giant database; it scaled through independent documents carrying shared meaning at the edges. Vault-LD asks agent memory to scale the same way, not through a new proprietary platform.
6
The implication: the Agentic Web is continuous with the human web
If human meaning went web-scale as islands of JSON-LD scattered across pages, agent meaning can go the same way — islands of Vault-LD scattered across notes, memories, and workflows.
Read the full post, verbatim

This week YAML-LD advanced down the W3C standards track - a fresh working draft, published on Wednesday.

YAML-LD turns plain YAML into Linked Data. Useful, technical, invisible. Plumbing. But plumbing decides what you can build on top.

Take agent memory - the problem we open-sourced Vault-LD for last week.

The pattern Andrej Karpathy called the LLM wiki is simple: give an agent a folder of markdown files it reads and writes. The objection is instant: "Cute. But it doesn't scale."

In one sense, fair. Plain markdown is local - readable and human, but not part of any shared semantic fabric.

But those notes are rarely just markdown. At the top sits YAML frontmatter: status, tags, dates, links, types. The wiki is already half-structured. The semantic island is already there. It just isn't semantic yet.

Turn that YAML into YAML-LD and the block does what JSON-LD already does across the web: point to a shared context, identify things, say what they mean, connect local notes to other documents, agents and systems - with no central platform holding them all.

Look at JSON-LD. W3Techs puts it on 54% of websites. More than half the web.

JSON-LD is not an app, database or platform. It is a little island of structured data inside ordinary HTML. Nobody mandated it. No database contains it. No vendor owns it. Millions of sites adopted the same move: one page, two readers. Humans read the prose; machines read the island. And because the islands share a context, they don't just coexist - they connect.

That is not a theory of distributed meaning. It is the actual current state of the web.

Vault-LD is the same move, aimed at agent memory. Not "swap your wiki for a database". Not "move your memory into our platform". Keep the notes, keep the files - just make the frontmatter linked data.

JSON-LD put linked data inside HTML. VAULT-LD puts Linked Data inside markdown.

Same @context. Same Open Standards. Same scalability!

So when someone says the LLM wiki cannot scale, the answer isn't to turn it into someone else's platform. It is to give it the pattern the web already used.

The web did not scale through one giant database. It scaled through independent documents carrying shared meaning at the edges. That is what web-scale means: no centre, no bottleneck, no single place all meaning must pass through.

Scaleless.

Human meaning went web-scale as islands of JSON-LD scattered across pages. Agent meaning can go the same way - islands of Vault-LD scattered across notes, memories and workflows.

The Agentic Web will be part of the human web not separate from it.

⚡ JSON-LD made the web a knowledge graph. Vault-LD is how agents can join it ⚡

View original post on LinkedIn ↗

The Move: JSON-LD → YAML-LD → Vault-LD

Same pattern, new substrate

JSON-LD put Linked Data inside HTML — an island of structured data on 54% of websites, with no central platform, database, or vendor owning it.

YAML-LD (now a fresh W3C working draft) does the same thing for YAML: it turns the frontmatter block already sitting atop most markdown notes into Linked Data.

Vault-LD applies that move to agent memory: keep the notes, keep the files, keep the "LLM wiki" pattern Andrej Karpathy popularized — just make the frontmatter linked data. Same @context, same open standards, same scalability the web already proved.

YAML-LD in Practice

Reproduced from the W3C YAML-LD 1.0 Working Draft — Example 1 and Example 2, the spec's own introductory example — not an invented illustration. Every identifier resolves to a real, dereferenceable HTTP IRI on DBpedia or Schema.org via the compact-IRI prefixes in @context.

YAML-LD (spec Example 1)
"@context":
  - https://json-ld.org/contexts/dollar-convenience.jsonld
  - schema: https://schema.org/
    dbo: http://dbpedia.org/ontology/
    dbp: http://dbpedia.org/property/
    dbr: http://dbpedia.org/resource/
    xsd: http://www.w3.org/2001/XMLSchema#
    dbp:discovered:
      "@type": xsd:date
    dbp:star:
      "@type": "@id"

$id: dbr:Proxima_Centauri_b
$type: dbo:Planet
schema:description: >-
  The closest known exoplanet to Earth,
  orbiting in Proxima Centauri's habitable zone.
dbp:discovered: 2016-08-24
dbp:star: dbr:Proxima_Centauri
JSON-LD equivalent (spec Example 2)
{
  "@context": [
    "https://json-ld.org/contexts/dollar-convenience.jsonld",
    {
      "schema": "https://schema.org/",
      "dbo": "http://dbpedia.org/ontology/",
      "dbp": "http://dbpedia.org/property/",
      "dbr": "http://dbpedia.org/resource/",
      "xsd": "http://www.w3.org/2001/XMLSchema#",
      "dbp:discovered": {
        "@type": "xsd:date"
      },
      "dbp:star": {
        "@type": "@id"
      }
    }
  ],
  "$id": "dbr:Proxima_Centauri_b",
  "$type": "dbo:Planet",
  "schema:description": "The closest known exoplanet to Earth, orbiting in Proxima Centauri's habitable zone.",
  "dbp:discovered": "2016-08-24",
  "dbp:star": "dbr:Proxima_Centauri"
}

The entity (dbr:Proxima_Centauri_b), its type (dbo:Planet), and its properties (dbp:discovered, dbp:star) all expand — via the @context prefix map — to real, resolvable DBpedia HTTP IRIs, not placeholder identifiers. This is the exact JSON-LD-proven mechanism the post argues Vault-LD should apply to agent-memory frontmatter.

Comments (24 of 30 captured)

2 replies — continued by Kingsley Uyi Idehen
Also commented
1 reply — continued by Kingsley Uyi Idehen
1 reply from George Burch
GB
George Burch 2h ago (edited)

Tony Seale Linkapedia.net has semantically indexed billions of URL at sentence level (UID W3C RDF triple). 10m KG nodes. How does that database fit into this schema.

SK
Szymon Klarman 👍 4 10h ago

100%! YAML-LD seems like a tailored fit for Open Knowledge Format and similar markdown-based llm-wiki proposals. I wonder if we shouldn't define also a dedicated schema.org property to map the remaining body of the markdown to, so that we can just consume all such content as RDF and get over the whole markdown intermediate representation altogether ;)

3 replies — from Tony Seale and Kingsley Uyi Idehen
TS
Tony Seale 👍 1 10h ago

Szymon Klarman, Yeah I think that makes really good sense. Dan Brickley - what do you think about that?

FP
Dr. Florian Patzer 👍 1 9h ago

Tony Seale I haven't quite figured out yet why Vault-LD scales better than LLMWiki. After all, semantic isn't the factor that limits scaling on LLMWiki.

1 reply from Tony Seale

Dr. Florian Patzer, great question - it's the crux, so thanks for pushing on it.

You're right: semantics doesn't limit a single markdown wiki. On one machine, for one agent, a folder of markdown scales fine.

But there are two kinds of scale. Scaling up is a bigger pile in one place - markdown handles that. Scaling out is many independent wikis, across many machines and agents, becoming one queryable whole. That's what the Agentic Web runs on, and where a plain wiki hits the wall.

The reason is locality. A markdown link is a private string - it means something to you, nothing to another wiki. Two can't merge without a human deciding "does your customer mean mine?" The wiki works locally because its meaning is implicit - and that's exactly what blocks integration.

That's what semantics fixes: a shared @context gives fields common meaning, URIs give entities global identity (your decentralised identifiers), and RDF merges any two graphs by default - same URI, same node, no central database.

Same JSON-LD move: the web scaled not through bigger pages, but through pages sharing enough meaning to federate. Scaleless = no ceiling, because no centre. Semantics doesn't make one wiki bigger - it lets a billion behave as one.

FS
Franz-Josef Siegemund 👍 2 3h ago (edited)

Just waiting for the Obsidian integration.

1 reply from Tony Seale
TS
Tony Seale 👍 1 3h ago

watch this space :-)

KG
Kyle Gilbride 👍 1 2h ago

Tony Seale great stuff - thanks for such clear explanations on the "plumbing." This is the important but not urgent work that companies ignore until it's usually too late to fix.

1 reply — continued by Kyle Gilbride

Tony Seale I agree but for the buyers and decision makers (CEO, CFO, CRO) - do they get this? I was chatting with Daniel Remedios about this and I don't think most understand the need.

DS
Dmitri Safine 👍 2 2h ago

It sounds like something very similar to LinkML.

1 reply from Tony Seale
TS
Tony Seale 👍 1 2h ago

yes same backbone - the semantic web

Interesting approach. But scaling concepts for shared semantic frameworks like YAML-LD might face resistance without clear immediate benefits for adopters. We'll see if this can seamlessly integrate into existing systems without causing chaos. Keeping it decentralized is key though!

The frontmatter already being half-structured is the detail most people miss on first read. The gap to linked data is smaller than it looks.

JP
Joseph Pellegrini 💜 1 1h ago

AWESOME!

1 reply from Tony Seale

Thank you 😊

JK
Joon Nyip Koh 👍 1 50m ago

I Use LLM wiki. Is good organise to obsidian.

SeeAlso — Reference Links (Kingsley Uyi Idehen)

1
The Next Influencers Won't Sell Attention. They'll Sell Better Answers
Economic value of files (documents) in an Agentic Web.
2
The Missing Layer in Enterprise AI
The Semantic Web Project Has Been Building It for Two Decades.
3
kg-generator
Linked Data Generator that works with a broad variety of document types.
4
rdf-infographic-skill
Linked Data Generator and visualizer for a broad range of document types.
5
agent-rdf-memory
Linked Data based Context Layer for AI Agents.

Source

LinkedIn Post
linkedin.com/posts/tonyseale_this-week-yaml-ld-advanced-down-the-w3c-standards-share-7481067252428046336-CPSL ↗
🔗 Lookup post entity

Explore & Reference

Frequently asked questions, glossary terms, the HowTo walkthrough, and live SPARQL queries against the companion knowledge graph — grouped here for quick browsing.

YAML-LD is a W3C working-draft specification (a fresh draft was published the Wednesday before this post) that turns plain YAML into Linked Data — the same underlying mechanism JSON-LD uses, applied to YAML instead of JSON, so YAML frontmatter can identify things, say what they mean, and connect documents, agents, and systems without a central platform.
The pattern Andrej Karpathy called the LLM wiki — a folder of markdown files an agent reads and writes — is local, readable, and human. But plain markdown is not part of any shared semantic fabric; the objection "Cute, but it doesn't scale" targets that missing shared context, not the folder-of-notes approach itself.
Vault-LD is the pattern open-sourced by Tony Seale for agent memory: it does not ask you to swap the wiki for a database or move memory into a platform. It makes the YAML frontmatter of existing notes Linked Data, so agent memory can scale the same way the web scaled — through independent documents carrying shared meaning at the edges, not through one giant central database.
W3Techs puts JSON-LD on 54% of websites — more than half the web — without any single vendor owning it, any database containing it, or any platform mandating it. That decentralized, standards-based adoption pattern is the proof-of-concept the post cites for why the same @context-driven approach (via YAML-LD/Vault-LD) can scale agent memory.
Per Kingsley Uyi Idehen's comment, AWWW and "the Web" are easily conflated, inadvertently or cynically — mentioning "the Web" leads many to presume public Internet-scale access is required. In reality, the underlying architecture is simply about using hyperlinks — pointers surfaced in user space, not just developer space — to break down the technical debt compounding inside silos, whether or not the result is publicly accessible.
By reusing the same @context mechanism and open standards that JSON-LD already proved at web scale, Vault-LD agent memory avoids becoming a new proprietary lock-in. Meaning encoded in the frontmatter can be resolved, extended, and joined by any compliant system — not just the one that wrote it.
Most markdown notes used in LLM-wiki-style agent memory already carry YAML frontmatter with status, tags, dates, links, and types. This is structured data — it just isn't yet semantic, because nothing anchors those keys and values to a shared, dereferenceable vocabulary. YAML-LD is the missing step that makes it semantic.
The post's closing line frames it directly: JSON-LD made the web a knowledge graph for human-facing content; Vault-LD is how agents can join that same knowledge graph via their own memory. The Agentic Web, in this framing, is part of the human web, not a separate system.
YAML-LD

A W3C working-draft specification (advanced this week per Tony Seale's post) that turns plain YAML into Linked Data by adding an @context block, letting YAML frontmatter identify entities, express meaning, and connect to other documents, agents, and systems.

JSON-LD

A W3C Linked Data serialization embedded inside ordinary HTML pages — present on 54% of websites per W3Techs. An "island" of structured data that machines read while humans read the surrounding prose.

Vault-LD

An open-sourced pattern (referenced in the post as launched "last week") that applies the YAML-LD move to agent memory: keep the markdown notes and files, but make the YAML frontmatter Linked Data — so agent memory scales the way the web scaled, without a central platform.

LLM Wiki

The agent-memory pattern popularized by Andrej Karpathy: give an agent a folder of markdown files it reads and writes. Criticized as not scaling — a critique the post's author addresses via Vault-LD.

YAML Frontmatter

The structured block (status, tags, dates, links, types) at the top of a markdown file. Already half-structured; YAML-LD is what makes it semantic by anchoring it to a shared @context.

Architecture of the World Wide Web (AWWW)

The W3C architectural principles underlying the Web — distinct from "the Web" itself as a public, Internet-scale network. Kingsley Uyi Idehen's comment stresses that AWWW and the Web are often conflated: using hyperlinks to break down silo technical debt does not require public Internet-scale access.

Linked Data

A method of publishing structured data using dereferenceable URIs and shared vocabularies (@context) so that data items can be interlinked and become more useful through association with related data — the underlying pattern of both JSON-LD and YAML-LD/Vault-LD.

@context

The JSON-LD / YAML-LD keyword that maps local terms to shared, dereferenceable vocabulary IRIs, letting independent documents carry compatible meaning without a central schema authority.

Agentic Web

The post's closing claim: the Agentic Web will be part of the human web, not separate from it — agent memory scaling via islands of Vault-LD the same way human meaning scaled via islands of JSON-LD.

W3C Working Draft

A publication stage on the W3C standards track for a technical specification, indicating community review is underway but the spec is not yet finalized. YAML-LD advanced to a fresh working draft, published the Wednesday before this post.

A practical path from a plain markdown LLM wiki to a scalable, standards-based agent memory layer — following the YAML-LD / Vault-LD pattern set out by Tony Seale and the hyperlink-first principles reinforced by Kingsley Uyi Idehen's comment.

1
Audit your existing markdown format
Inventory the YAML frontmatter already present at the top of your agent's markdown notes: status, tags, dates, links, types. This half-structured data is the semantic island waiting to be made semantic.
2
Point frontmatter at a shared @context
Add an @context block to the YAML frontmatter, mapping local keys to shared, dereferenceable vocabulary terms — the same move JSON-LD makes inside HTML.
3
Convert YAML to YAML-LD
Use the YAML-LD working draft to turn plain YAML into Linked Data: identify things, say what they mean, and connect local notes to other documents, agents, and systems — with no central platform holding it all.
4
Apply Vault-LD to agent memory
Keep the notes, keep the files — just make the frontmatter Linked Data. Vault-LD applies the JSON-LD-in-HTML pattern to markdown-in-agent-memory: same @context, same open standards, same scalability.
5
Name entities and relationships using hyperlinks
Per Kingsley Uyi Idehen's comment: use hyperlinks — pointers surfaced in user, not just developer, space — as stable, standardised identifiers for entities and relationships, breaking down the compounding technical debt native to silos.
6
Describe everything as subject–predicate–object statements
Express notes as compact entity–relationship–entity structured statements. Rinse and repeat, manually or automatically, and new data, information, and knowledge emerge through the accumulation and connection of these statements.
7
Let agent memory scale the way the web scaled
Do not centralize agent memory into one giant database or platform. Scale it the way the human web scaled: independent documents (or notes) carrying shared meaning at the edges — no centre, no bottleneck, no single place all meaning must pass through.

Queries target the companion knowledge graph. Load the companion TTL file into a SPARQL endpoint (e.g. URIBurner) then click ▶ Run to execute. SELECT queries render as text/x-html+tr; DESCRIBE/CONSTRUCT queries render as text/x-html-nice-turtle.

PREFIX schema: <http://schema.org/>
SELECT ?position ?author ?text
FROM <https://linkeddata.uriburner.com/DAV/demos/daas/tony-seale-yaml-ld-vault-ld-claude_sonnet_5-1.ttl>
WHERE {
  ?comment a schema:Comment ;
           schema:position ?position ;
           schema:author   ?person ;
           schema:text     ?text .
  ?person schema:name ?author .
}
ORDER BY ASC(?position)
▶ Run

Returns all 17 captured comments in sequence with author name and text.

PREFIX schema: <http://schema.org/>
SELECT ?position ?name ?url ?description
FROM <https://linkeddata.uriburner.com/DAV/demos/daas/tony-seale-yaml-ld-vault-ld-claude_sonnet_5-1.ttl>
WHERE {
  ?ref schema:position ?position ;
       schema:name ?name ;
       schema:url ?url ;
       schema:description ?description .
  ?list schema:itemListElement ?ref .
}
ORDER BY ASC(?position)
▶ Run

Lists the 5 reference links Kingsley Uyi Idehen posted in-thread, in order.

PREFIX schema: <http://schema.org/>
SELECT ?name ?profileIRI
FROM <https://linkeddata.uriburner.com/DAV/demos/daas/tony-seale-yaml-ld-vault-ld-claude_sonnet_5-1.ttl>
WHERE {
  ?person a schema:Person ;
          schema:name ?name ;
          schema:url  ?profileIRI .
}
ORDER BY ASC(?name)
▶ Run

Lists every contributor (author + all commenters + mentioned people) with their LinkedIn profile URL.

PREFIX schema: <http://schema.org/>
SELECT ?title ?author ?url ?interactionType ?count
FROM <https://linkeddata.uriburner.com/DAV/demos/daas/tony-seale-yaml-ld-vault-ld-claude_sonnet_5-1.ttl>
WHERE {
  ?post a schema:SocialMediaPosting ;
        schema:name  ?title ;
        schema:author ?p ;
        schema:url    ?url ;
        schema:interactionStatistic ?ctr .
  ?p    schema:name  ?author .
  ?ctr  schema:interactionType       ?interactionType ;
        schema:userInteractionCount  ?count .
}
▶ Run

Returns post title, author, URL, and all interaction counts (reactions, comments).

PREFIX schema: <http://schema.org/>
SELECT ?position ?author ?excerpt
FROM <https://linkeddata.uriburner.com/DAV/demos/daas/tony-seale-yaml-ld-vault-ld-claude_sonnet_5-1.ttl>
WHERE {
  ?comment a schema:Comment ;
           schema:position ?position ;
           schema:text     ?excerpt ;
           schema:author   ?p .
  ?p schema:name ?author .
  FILTER (CONTAINS(LCASE(STR(?excerpt)), "scal"))
}
ORDER BY ASC(?position)
▶ Run

Filters to comments that explicitly discuss scaling — the post's central objection and rebuttal.

PREFIX schema: <http://schema.org/>
DESCRIBE ?post
FROM <https://linkeddata.uriburner.com/DAV/demos/daas/tony-seale-yaml-ld-vault-ld-claude_sonnet_5-1.ttl>
WHERE {
  ?post a schema:SocialMediaPosting .
}
▶ Run (Turtle)

Returns a full DESCRIBE of the post node in nice Turtle format — useful for verifying the KG structure.

🔍 Explore Knowledge Graph
SPARQL Query
PREFIX rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

SELECT
    ?type
    (SAMPLE(?s) AS ?sampleEntity)
    (SAMPLE(?label) AS ?sampleLabel)
    (COUNT(?s) AS ?entityCount)
WHERE {
    GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/tony-seale-yaml-ld-vault-ld-claude_sonnet_5-1.ttl> {
        ?s rdf:type ?type .

        OPTIONAL {
            ?s rdfs:label ?label
        }
    }
}
GROUP BY ?type
ORDER BY DESC(?entityCount)
▶ Run Query — Explore Knowledge Graph

Entity-type summary across all nodes — grouped by RDF type, with sample IRI and label, ordered by count.