Vault-LD: how agent memory joins the web's knowledge graph

The plumbing moved this week

On 8 July 2026 the W3C's JSON-LD Working Group published a fresh Working Draft of YAML-LD 1.0 (W3C, 2026). It made no headlines. It is plumbing: conventions for serialising linked data as YAML, and a registered media type, application/ld+yaml.

Plumbing is invisible. Plumbing also decides what you can build on top.

Here is what this particular pipe makes possible.

The web already solved "shared meaning, no centre"

JSON-LD runs on 54.4% of all websites (W3Techs, July 2026). More than half the web.

Nobody was made to do that. There was no platform to join, no consortium policing it, no central registry keeping score. A site owner adds a block of structured data to a page they were publishing anyway, and from that moment the page serves two audiences at once: prose for the person reading it, facts for the AI assistant parsing it.

Repeat that a few million times and the interesting part shows up. Those blocks all point at the same vocabulary, schema.org, so they stop being isolated. Two pages that have never heard of each other can name the same company, and anything reading both knows it is one company, not two.

Distributed meaning is not a proposal. It is load-bearing structure on the web you are using right now.

The web did not scale by pouring everything into one enormous database. It scaled by letting independent documents carry shared meaning at the edges. No centre. No bottleneck. Nothing every fact has to pass through.

Agent memory is standing at the same fork

The pattern Andrej Karpathy popularised as the LLM wiki is disarmingly simple: give an AI agent a folder of markdown files it reads and writes, and let its knowledge compound instead of being re-retrieved from scratch every time (Karpathy, 2026).

And then someone says it. Nice toy. It won't scale.

They have half a point. A folder of notes is a private world. Readable, honest, entirely provincial. Your notes mean what you decided they mean, and no other AI agent has any way of finding that out.

Look at what is actually in one of those files, though. Above the prose sits a block of YAML: type, status, tags, dates, owners, links. The structured part is already written, and you wrote it. You recorded the data. You just never said what any of it meant.

Google's Open Knowledge Format proves the pattern

Open Knowledge Format (OKF) is a vendor-neutral specification, published by Google Cloud in June 2026, for representing knowledge as a directory of markdown files with YAML frontmatter - so AI agents get curated, structured context instead of a slab of unstructured text. This is not a fringe idea any more. Google's own diagnosis of the problem is blunt: company knowledge today is "locked behind whichever surface created it" (Google Cloud, 2026).

OKF is deliberately minimal. It requires exactly one field of every concept, type, and defines no shared vocabulary at all - producers add whatever else they like, consumers must tolerate what they don't recognise. Two filenames carry the rest of the structure: index.md and log.md are reserved at any level of the hierarchy for navigation and change history, not for concepts, and they carry no frontmatter of their own. That minimalism is deliberate, and it is why OKF will spread: nothing to agree on means nothing to argue about.

It also leaves one question open. Without a shared vocabulary, your type: Customer and your supplier's type: Customer are two strings that happen to match. The files interoperate. The meaning still has to be negotiated.

That question is the one the web already answered.

What Vault-LD actually does

One answer is Vault-LD, an open spec published under Apache-2.0 by Tony Seale and The Knowledge Graph Guys. It is not a standard, and it is not ours - an early proposal from a small team, worth your attention for the move it makes, not the authority behind it.

The move is deliberately unambitious about your files and ambitious about their meaning: keep the notes, keep the folder, keep git. Just make the frontmatter linked data.

In simple terms: most AI agents today keep their memory as plain notes - useful to read, but a dead end to anyone else's software. Vault-LD adds one small thing on top: a shared dictionary of what each note's fields mean, kept in a separate file. Nothing moves into a database, and nothing is handed to a vendor. The notes just stop being only yours to understand.

In practice a note looks like a note:

---
type: "[[Client]]"
accountManager: "[[Priya Shah]]"
renewalDate: 2027-03-01
contractValueGBP: 48000
---
# Northwind Foods
Renewed in March. Wants the retainer extended to their EU sites.

Three things are happening quietly here. The [[wiki links]] your team already writes for navigation double as real identifiers, so [[Priya Shah]] is a thing, not a string. The plain values stay plain. And the prose underneath stays prose - the spec is explicit that the body never becomes data, which is what keeps the note worth reading.

The vocabulary itself lives outside the note, in a shared @context. That file is the whole trick, and it is smaller than you would expect:

{
  "@context": {
    "schema": "https://schema.org/",
    "xsd": "http://www.w3.org/2001/XMLSchema#",
    "acme": "https://acme.example/context.jsonld#",

    "id": "@id",
    "type": "@type",
    "Client": "schema:Organization",

    "accountManager":   { "@id": "acme:accountManager", "@type": "@id" },
    "renewalDate":      { "@id": "acme:renewalDate", "@type": "xsd:date" },
    "contractValueGBP": "acme:contractValueGBP"
  }
}

Read it against the note and three things click into place.

"Client": "schema:Organization" is your word answering to a global one. Your [[Client]] and your supplier's [[Customer]] stop being two strings that have to be reconciled by a human, because both resolve to the same class.

{ "@type": "@id" } on accountManager is the line doing the real work. It says the value is an identifier, not text - which is precisely what promotes [[Priya Shah]] from a phrase in a file to a thing you can join on.

And where schema.org has no term for what you mean, you mint your own under your own prefix. acme:contractValueGBP is still a global identifier. Nobody else's vault will collide with it, and anyone who cares can go and look it up.

Write that once. Every note in the vault is now linked data, and not one of them had to change. The notes stay terse and diffable, the meaning is agreed in a single place, and nothing central is holding your knowledge.

Now the part that makes this more than a filing tidy-up. Add three lines to the same context file:

"Service":     "schema:Service",
"provider":    { "@id": "schema:provider", "@type": "@id" },
"serviceType": "schema:serviceType"

and it describes a note that is not in your vault at all. It describes a page on your website:

---
id: /core
type: "[[Service]]"
provider: "[[Agentu]]"
serviceType: AI visibility audit
---
# CORE
Make your business legible to the AI assistants your customers now ask first.

One vocabulary, two notes. The first never leaves your firewall. The second is served to every AI agent that asks for it. They resolve through the same @context, so [[Agentu]] means the identical thing to the AI agent reading your private client history and to the AI assistant deciding, out on the open web, whether to name you.

Most companies run two knowledge stores that have never been introduced: what they know, and what they say. This is the move that makes them one graph.

JSON-LD put linked data inside HTML. Vault-LD puts linked data inside markdown. Same @context. Same open standards.

"But a folder of notes doesn't scale"

It depends which kind of scale you mean, and the distinction is the whole argument.

Scaling up is a bigger pile in one place. Plain markdown handles that fine. One agent, one machine, ten thousand notes - no problem, and this is what most people picture when they dismiss the idea.

Scaling out is many independent vaults, across many teams and agents, behaving as one queryable whole. That is where a plain wiki hits the wall, and the reason is locality. A markdown link is a private string. [[Client]] in your vault means something to you and nothing to anyone else's, so two vaults cannot merge until a human sits down and rules on whether your customer means the same thing as theirs. The wiki works precisely because its meaning is implicit - and that is exactly what blocks it from joining anything.

Shared meaning removes the human from that step. A common @context gives fields the same definition everywhere, identifiers give things global identity, and two graphs that use the same identifier merge on contact - no negotiation, no central database.

Semantics doesn't make one vault bigger. It lets a billion behave as one.

That is the same move the web made. It did not scale by growing bigger pages. It scaled by pages sharing just enough meaning to federate.

To be clear: shared meaning is not public data

One thing this emphatically does not mean is publishing your notes.

"Joining the web's knowledge graph" sounds like putting contractValueGBP on the open internet. It is not that. Linked data is about shared meaning, not shared access - the vocabulary is public, your data stays exactly where you put it. The example above lives behind your firewall, in your git repo, readable by your agents and nobody else's.

What you gain is that when you choose to connect two things - your vault and your CRM, your team's notes and a supplier's, your internal knowledge and your own public website - they already speak the same language. Being legible is not the same as being visible.

What a company actually gains

Be honest about where this sits on a board agenda: it is important, not urgent. Nobody's quarter is ruined this week because their agent memory is a pile of private strings. That is exactly why it gets skipped - and why it is usually expensive by the time anyone notices, because the cost arrives as a migration, not a bill.

Four things, in the order a technical director would care about them.

• Your memory stops belonging to your tools. Today the knowledge your AI agents accumulate is trapped in whichever product wrote it, in an embedding store you cannot read. Frontmatter you own, in a format anyone can parse, is the difference between an asset and a subscription.
• Your internal knowledge and your public website finally speak one language. That is the two-notes trick above, at company scale: the Organization, Service and Person in your site's schema.org markup are the same vocabulary your private vault already uses. One story, inside and out - which is precisely the consistency answer engines reward when they decide whether to name you.
• Governance comes free. A vector database cannot tell you why an AI agent believed something. A folder of markdown notes in git can: who wrote it, when, what changed, and what it was based on. That is an audit trail you can hand to a regulator.
• It is additive and reversible. Nothing migrates. Vault-LD round-trips - notes to RDF and back - so the experiment costs you a context file, not a replatforming. If it fails, you still have your notes.

Set that against the failure rate. Gartner expects over 40% of agentic AI projects to be cancelled by the end of 2027, on escalating costs, unclear business value and weak controls (Gartner, 2025). Meanwhile 40% of enterprise applications are forecast to carry task-specific AI agents by the end of this year, up from under 5% (Gartner, 2025). A great many AI agents are about to be handed a great deal of company knowledge. The ones that survive contact with an auditor will be the ones whose memory can be read.

What we would not claim

We would rather be useful than breathless, so: YAML-LD is a Working Draft, not a Recommendation, and Working Drafts change. Nothing reads any of this for you yet either - no agent framework treats frontmatter as linked data out of the box, so the graph only exists if you run the extraction yourself. This is a direction, not a product you can buy on Monday.

So do not bet the company on the spec. Bet on the discipline.

Naming your types once, reusing schema.org where it fits, and giving the things you care about stable identifiers will make your notes more useful to every AI agent you ever run, even if every specification named on this page disappears. It is the same bet that wins you citations in AI answers: be the clearest, most consistent, easiest correct thing to understand. Standards come and go. Clarity compounds.

Where to start

1. Read your own frontmatter. You almost certainly have some. Whatever is at the top of your notes, your docs and your CLAUDE.md files is a vocabulary you have already invented by accident.
2. Name your types once. Agree a short, controlled list, and reuse schema.org terms wherever one already exists. This is the whole cost.
3. Then the @context is a small step, not a migration.

We have done all three to our own site - every page of agentu.co.uk now serves a linked-data note an AI agent can fetch. Read the build log, including what broke.

The agentic web will not be a separate web. It will be this one, read differently. The companies that get quoted in it will be the ones whose meaning was legible before it was asked for - on their website, and now in their memory too.

Want to know how legible yours is today? Run the free agent-readiness diagnostic - it reads your site the way an AI assistant does, in about ten seconds. If you would rather talk it through, talk to Agentu.

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