Google's Open Knowledge Format: een eerste blik vanuit de praktijk

Google's Open Knowledge Format: een eerste blik vanuit de praktijk op OKF

Ik had het bijna genegeerd. Weer een specificatie, weer een afkorting, weer een "leveranciersonafhankelijke standaard" persbericht dat op vrijdag in mijn feed verscheen. Google Cloud publiceerde het Open Knowledge Format — OKF v0.1 — op 12 juni 2026, en mijn eerlijke eerste reactie was een schouderophalen. We hebben al tientallen "dit verandert alles"-formaten zien verschijnen en stilletjes zien verdwijnen.

Toen opende ik de specificatie. En ik realiseerde me dat het hele ding gewoon markdown-bestanden zijn met een paar regels YAML bovenaan, gegroepeerd in een map. Geen SDK. Geen runtime. Geen compressieschema. Geen API om aan te roepen. Een "kennisbundel" in het Open Knowledge Format is, bijna beledigend, gewoon bestanden die je in een teksteditor zou kunnen schrijven.

Dat was het deel dat me deed stoppen met scrollen en een testmap liet aanmaken. Want ik heb het afgelopen jaar agent-workflows gebouwd, en het enige waar ik steeds tegenaan loop is dezelfde muur: mijn agents zijn briljant in redeneren en waardeloos in onthouden. Ze scrapen, vatten samen en leiden dezelfde context elke sessie opnieuw af. Als een formaat dat zo dom-simpel is een agent een schone, gestructureerde plek zou kunnen geven om kennis uit te lezen — in plaats van het elke keer opnieuw af te leiden uit ruwe HTML — dan is dat een middag waard.

Dus besteedde ik die middag eraan. Ik bouwde een kleine bundel met de hand vanuit de gepubliceerde specificatie, liet mijn eigen site door een community-generator lopen, en opende het resultaat in Obsidian om te zien of de claim "mensvriendelijk" de confrontatie met de werkelijkheid overleeft. Dit is wat ik vond — wat OKF werkelijk is, de delen die de aankondigingen goed hebben, en de veel grotere stapel dingen die toekomstgerichte beloften zijn in plaats van geleverde realiteit. Ik zal duidelijk zijn over wat wat is, want het gat daartussen is waar het meeste van de hype leeft.

Wat is het Open Knowledge Format eigenlijk?

Het Open Knowledge Format is een open, leveranciersonafhankelijke specificatie van Google Cloud voor het opslaan van kennis als een directory van markdown-bestanden, elk met YAML front matter, ontworpen om gelezen te worden door zowel mensen als AI-agents. Dat is het hele verhaal. Eén zin dekt het.

Laat de aankondigingstaal weg en OKF maakt precies drie structurele keuzes:

• Kennis is een map met markdown-bestanden. Google noemt een map een kennisbundel. Het is een directory — mogelijk met subdirectories — vol .md-bestanden.
• Elk bestand is één concept. Geen webpagina. Geen heel document. Eén afzonderlijke eenheid van kennis: een playbook, een metriekdefinitie, een runbook, een API-beschrijving, een enkele entiteit. Karpathy's intuïtie dat kennis geatomiseerd zou moeten worden in conceptpagina's in plaats van gedumpt als lange documenten zit recht in het formaat ingebakken.
• Elk concept declareert een type. De specificatie vereist precies één front-matter-veld in elk bestand: type. Al het andere — title, description, resource, tags, timestamp — is aanbevolen maar optioneel.

Hier is een conceptbestand dat ik met de hand schreef om het formaat te testen, gemodelleerd naar een van mijn eigen interne playbooks:

---
type: playbook
title: Client Onboarding Sequence
description: The exact steps I run when a new AI automation client signs.
tags: [onboarding, process, clients]
resource: https://mejba.me/onboarding
timestamp: 2026-06-18
---

# Client Onboarding Sequence

When a new client signs, I run these steps in order. Each one has a
trigger and a definition of done — agents reading this should treat the
"done" condition as the success check.

## 1. Access provisioning
Grant repo + cloud read access within 24h of signature...

## 2. Context capture call
A 45-minute recorded call. The recording becomes its own concept file...

Dat is een volledig, spec-geldig OKF-concept. Geen tooling heeft het geproduceerd. Ik typte het. En hier is het stilletjes belangrijke deel: het rendert netjes in elke markdown-app waar ik het in gooide — GitHub gaf een preview, Obsidian indexeerde de front matter als eigenschappen, en het zou zonder problemen in Notion passen. Het formaat vraagt je niet om iets nieuws te adopteren. Het beschrijft wat je waarschijnlijk al doet, alleen met één afgesproken vorm.

Maar een enkel bestand is niet de interessante eenheid. De bundel is dat wel. Dus laat me je laten zien hoe een bundel daadwerkelijk aan elkaar zit — want dit is waar OKF stopt met "een markdown-bestand" zijn en begint een systeem te worden.

Hoe een kennisbundel is gestructureerd

Een kennisbundel is een directory van concepten, en de specificatie geeft het twee optionele-maar-krachtige organiserende bestanden die een platte map veranderen in iets waar een agent intelligent doorheen kan navigeren.

De structuur ziet er zo uit:

my-knowledge-bundle/
├── index.md          # overzicht + directorylijst (optioneel)
├── log.md            # chronologische wijzigingsgeschiedenis (optioneel)
├── onboarding.md     # een concept in de bundel-root
├── pricing.md        # nog een concept
└── playbooks/        # een subdirectory groepeert gerelateerde concepten
    ├── index.md      # subdirectories kunnen hun eigen index hebben
    ├── refunds.md
    └── escalation.md

De twee speciale bestanden zijn waar het ontwerp slim wordt.

index.md is de kaart van de bundel. Het somt op wat er in de directory zit zodat een agent de bundel kan overzien voordat hij iets leest. Dit is progressieve onthulling — exact hetzelfde patroon dat goed ontworpen agent-skills efficiënt maakt. Een agent leest de index, besluit welke drie van de veertig conceptbestanden hij daadwerkelijk nodig heeft, en laadt alleen die. Hij giet niet de hele map in de context. Als je hebt gevochten met de token-bloat die komt van alles in het contextvenster dumpen, herken je waarom dit belangrijk is — het is hetzelfde principe waar ik over schreef in mijn analyse van waarom contextmanagement configuratie verslaat voor AI-agents. De index is de schijnwerper; de concepten zijn waar hij op wijst.

log.md is het geheugen van de bundel over zijn eigen wijzigingen. Een chronologische geschiedenis van updates. Waarom heeft een kennisformaat een changelog nodig? Omdat OKF ervan uitgaat dat de kennis leeft — dat het herzien, tegengesproken en gecorrigeerd wordt in de loop van de tijd. De log is hoe een agent (of een mens) begrijpt niet alleen wat de kennis vandaag zegt, maar hoe het hier gekomen is.

Toen ik mijn testbundel bouwde, was het indexbestand wat me overtuigde. Ik schreef vijf conceptbestanden, schreef toen een index.md die elk opsomde met een beschrijving van één regel. Toen wees ik Claude naar de map en stelde een vraag die alleen één concept kon beantwoorden. Het las eerst de index, opende precies één bestand en antwoordde. Het raakte de andere vier nooit aan. Dat is het verschil tussen een agent een bibliotheekkaartcatalogus geven versus elk boek op zijn bureau dumpen.

Nu — voordat dit te gepolijst klinkt — laat me eerlijk zijn over waar de eenvoud een beperking wordt. Er is geen handhaving. Niets houdt je tegen om veertig conceptbestanden te schrijven zonder index, met inconsistente type-waarden, en een log.md die een leugen is. Het formaat is een conventie, geen garantie. Wat me brengt bij de vergelijking die iedereen blijft maken, en enigszins fout krijgt.

OKF vs llms.txt vs schema.org: waar past het?

Dit is de vraag die ik had binnen tien minuten na het lezen van de specificatie, en het is de vraag die de aankondigingen het minst duidelijk beantwoorden. We hebben al llms.txt. We hebben al schema.org. Hebben we een derde ding nodig? Het korte antwoord: ze zitten op verschillende lagen, en OKF is de diepste.

Zo zou ik de stack voor AI-zichtbaarheid in 2026 in kaart brengen:

Denk eraan als een restaurant. llms.txt is het menu dat de agent vertelt wat er beschikbaar is. Schema.org is de allergenen- en ingrediëntenetikettering die dubbelzinnigheid over elk gerecht wegneemt. OKF is het werkelijke eten, opgemaakt en klaar om te eten — de kennis zelf, overhandigd als een schoon markdown-concept in plaats van de agent te dwingen het te reverse-engineeren uit gescrapete HTML.

Die framing is belangrijk vanwege een vergelijking die de specificatie impliciet maakt en die ik expliciet zal maken: OKF is waar je naar grijpt als schema.org geen ruimte meer heeft. Schema.org is briljant voor de dingen waarvoor het types heeft — producten, recepten, evenementen, organisaties. Maar het moment dat je kennis een genuanceerd playbook is, een eigendomsproces, een zuurverdiende metriekdefinitie, of een strategie die niet past bij enig @type in het vocabulaire, heeft schema.org niets voor je. OKF beperkt je niet tot een voorgedefinieerd vocabulaire. Je type kan playbook, runbook, case-study, pricing-logic zijn — wat je domein ook nodig heeft. Dat is de afweging: schema.org geeft je machinaal gevalideerde strengheid binnen een vast vocabulaire; OKF geeft je open flexibiliteit met bijna geen validatie.

En het waarschijnlijke bindweefsel tussen deze lagen is weer llms.txt. De toekomstgerichte verwachting — en ik wil dit duidelijk markeren als verwacht, niet geleverd — is dat sites het bestaan van een OKF-bundel zullen signaleren via een llms.txt-achtige verwijzing, op dezelfde manier waarop XML-sitemaps en gestructureerde data na robots.txt arriveerden. Vanaf v0.1 is er geen geformaliseerd ontdekkingsprotocol ingebakken in OKF zelf. Dat is een gat, en het is het soort gat dat een v0.1 hoort te hebben.

Als je contentsystemen bouwt en deze laag liever geautomatiseerd hebt dan handmatig onderhouden, dan is dit precies het soort pipeline dat ik bouw — het omzetten van de kennis van een site naar agent-leesbare structuur wordt een eigen discipline, en je kunt zien hoe ik dit aanpak in mijn werk over het automatiseren van SEO-contentworkflows met Claude Code. Maar je hebt mij niet nodig om te beginnen. Je kunt vandaag je eerste bundel bouwen, en dat zou je ook moeten doen, want het lezen van een specificatie leert je bijna niets vergeleken met het schrijven van één slechte bundel.

Hoe ik mijn eerste OKF-bundel bouwde (en wat er misging)

Ik koos bewust twee paden: één bundel met de hand bouwen om het formaat te begrijpen, en een bestaande site door een generator laten lopen om te zien wat automatisering produceert. Het contrast leerde me meer dan elk apart.

Pad één: met de hand. Ik maakte een map aan, schreef vijf conceptbestanden op basis van echte interne documenten — mijn onboardingsequentie, mijn prijslogica, twee playbooks, en een woordenlijst van termen die ik gebruik met klanten. De front matter was de enige wrijving. Bepalen wat het type voor elk concept moest zijn duurde langer dan het schrijven van de inhoud, omdat de specificatie je bewust niet vertelt welke types je moet gebruiken. Is mijn prijsdocument een pricing? Een policy? Een reference? De vrijheid is echt, en de keuzestress ook. Mijn conclusie: kies je type-vocabulaire eerst, schrijf het op als een eigen concept, en houd je eraan. Inconsistente types zijn de snelste manier om een bundel te maken waar een agent slecht doorheen navigeert.

Toen schreef ik de index.md met de hand en begreep onmiddellijk waarom het optioneel is in de specificatie maar verplicht in de praktijk. Zonder is een bundel een stapel. Mét is het een graaf.

Pad twee: een generator. De community bewoog snel. Suganthan Mohanadasan — een SEO die, opvallend genoeg, zijn eigen site al een markdown-conceptformaat liet spreken vóór Google OKF uitbracht — bouwde een gratis OKF Bundle Generator die een URL of sitemap neemt en een downloadbare bundel plus een kaart van je content produceert. Ik liet een sectie van mijn eigen site erdoorheen lopen.

Het resultaat was oprecht nuttig en oprecht beperkt tegelijk, en de beperking is de hele les. De generator deed het voor de hand liggende goed: elke pagina werd een schoon markdown-bestand met verstandige front matter, kruisgelinkt, geen HTML-rommel. Maar het produceerde één concept per pagina — en dat is niet echt waarvoor OKF bedoeld is. De eenheid van OKF is het concept, niet de pagina. Een enkele lange blogpost van mij zou vier verschillende concepten kunnen bevatten die, in een goede bundel, vier aparte bestanden zouden moeten zijn waarnaar een agent onafhankelijk kan verwijzen. De generator vertaalde trouw mijn paginastructuur; het kon niet de moeilijkere handeling uitvoeren van conceptextractie — een pagina lezen en beslissen dat het eigenlijk drie ideeën bevat die hun eigen bestanden verdienen.

Dat gat is de echte kans, en ik zeg het ronduit: de waardevolle OKF-tooling is nog niet gebouwd. Pagina-naar-markdown-converters zijn een opgelost, gecommoditiseerd probleem. De tools die ertoe zullen doen zijn degene die je rommelige, overlappende content lezen en het ontleden in schone, ontdubbelde concepten die je daadwerkelijke bedrijfsstructuur weerspiegelen. Suganthans term voor wat OKF mogelijk maakt — "semantisch ontbakken," samengebakken kennis terugbreken in gestructureerde, interoperabele elementen — is precies het deel dat automatisering nog niet gekraakt heeft. Een taalmodel is daar goed geschikt voor, maar er naïef een op richten met "maak van deze site concepten" produceert nog steeds conceptbestanden die overlappen en elkaar tegenspreken. Het goed doen is onopgelost.

Als je liever iemand hebt die deze conceptextractie-pipeline voor je bedrijf bouwt dan er zelf mee te worstelen, dan is dat een project dat ik aanneem — je kunt het soort systemen dat ik bouw zien op fiverr.com/s/EgxYmWD. Maar bouw oprecht eerst een bundel van vijf bestanden met de hand. Het kost twintig minuten en het leert je wat geen tool kan.

De Karpathy-connectie: kennis die zichzelf onderhoudt

OKF komt niet uit het niets. Het is de formalisering van een idee dat Andrej Karpathy opperde — wat hij het LLM Wiki-patroon noemde — en het begrijpen van die oorsprong vertelt je waar dit werkelijk naartoe gaat.

Karpathy's argument ging in tegen hoe we tegenwoordig retrieval doen. Het dominante patroon, RAG, werkt door ongestructureerde documenten op te delen in chunks, te embedden, en de best passende chunks op te halen bij het stellen van een vraag. Het is krachtig, maar het is fundamenteel een zoekopdracht over een statische stapel. De stapel leert niet. Hij verzoent niet. Als twee documenten elkaar tegenspreken, haalt RAG vrolijk beide op en laat het model het uitzoeken.

Karpathy's LLM Wiki draait het model om: in plaats van een statische stapel waar je doorheen zoekt, onderhoud je een levende wiki die het model zelf bouwt en herziet. Nieuwe informatie wordt niet gewoon toegevoegd — het wordt geïntegreerd. Het model werkt de relevante entiteitspagina bij, herziet een samenvatting, en wanneer nieuwe data een oude bewering tegenspreekt, verzoent het de tegenstrijdigheid in plaats van beide op te slaan. De kennisbasis is een dynamisch, evoluerend iets, en het model doet het meeste onderhoud. Dat laatste is de doorbraak: de reden dat wiki's meestal niet schalen is dat mensen ze moeten onderhouden. Een agent die zijn eigen wiki onderhoudt verwijdert het knelpunt.

Je kunt OKF's log.md en concept-per-bestand-ontwerp zien als het on-disk-formaat voor precies deze visie. Een conceptbestand is een entiteitspagina. De log is de herzieningsgeschiedenis. De structuur is bewust simpel genoeg dat een agent het niet alleen kan lezen maar ook kan schrijven — een concept openen, een bewering herzien, aan de log toevoegen, opslaan. Dat is een levende kennisgrafiek die een machine werkelijk actueel kan houden.

Ik jaag al een tijdje een zelfgebouwde versie hiervan na met Obsidian als opslag en Claude als onderhouder — ik schreef dat hele experiment op in mijn Obsidian + Claude Code persistent memory setup en een gerelateerde deep-dive over het bouwen van een Karpathy-stijl RAG-kennisbasis in Obsidian. OKF's bijdrage is niet een nieuw idee daarbovenop. Het is een gedeelde vorm. De reden dat een standaard hier belangrijk is, is interoperabiliteit: als mijn agent en jouw agent beiden OKF spreken, kan mijn onboardingbundel door jouw agent gelezen worden zonder vertaling. Wat leidt tot het deel dat ofwel het meest opwindend ofwel het meest overbeloofd is, afhankelijk van je scepsis.

Agentische zoekoptimalisatie en verkoopbare kennis

Hier worden de aankondigingen luidruchtig, dus hier zal ik voorzichtig worden. Twee grote claims reizen mee met OKF, en het zijn beiden plausibele richtingen in plaats van huidige realiteiten. Ik zal het mechanisme van de marketing scheiden.

Claim één: OKF herformuleert SEO tot "agentische zoekoptimalisatie." De logica: naarmate AI-agents steeds meer bemiddelen tussen mensen en informatie, verschuift het doel van vindbaar zijn voor een zoekcrawler naar bruikbaar zijn voor een agent. In plaats van een pagina te optimaliseren zodat een mens erop klikt, publiceer je kennis zodat een agent het direct kan lezen, citeren en ernaar kan handelen. Wanneer Google zelf je content gaat beschrijven als "context die aan agents geserveerd moet worden," is het serveren ervan in de vorm die Google beschrijft een rationele afdekking.

Ik denk dat de richting echt is. De uitvoering is onbewezen. Er is, medio 2026, geen bevestigd mechanisme waardoor het publiceren van een OKF-bundel je zichtbaarheid verbetert in Googles agent-gemedieerde oppervlakken. Google heeft een formaat uitgebracht; het heeft geen rangschikkingsvoordeel geleverd — of beloofd — voor het gebruik ervan. Behandel iedereen die "OKF voor rankings" verkoopt met dezelfde argwaan als iemand die je probeerde te overtuigen van een meta keyword tag. De eerlijke zet is: OKF maakt je kennis schoner en bruikbaarder voor elke agent die het leest, en dat is een verdedigbare inzet op eigen merites, ongeacht of Google het ooit beloont.

Claim twee: mensen zullen OKF-kennisbundels verpakken en verkopen. Een advocaat verkoopt een bundel van samengestelde juridische playbooks. Een accountant verkoopt belastingstrategieconcepten. Een SEO verkoopt een bundel van rangschikkingsheuristieken. Een bedrijf koopt deze en monteert ze in de context van zijn eigen agents. Omdat een bundel gewoon een tarball van markdown is, is het triviaal verzendbaar, hostbaar op elke git-repo, en licentieerbaar als elk digitaal product.

Deze vind ik overtuigender, omdat het mechanisme klopt — een bundel is oprecht een draagbare, op zichzelf staande eenheid van expertise, en er is echte vraag naar samengestelde context die agents kunnen consumeren. Maar het is een markt die nog niet bestaat, niet iets dat vandaag op schaal gebeurt. Dezelfde wrijving die goede bundels moeilijk te genereren maakt (conceptextractie, consistentie, de log eerlijk houden) maakt goede verkoopbare bundels nog moeilijker, omdat kwaliteit nu een productfeature is. Ik durf te wedden dat deze markt ontstaat. Ik zou niet wedden op de tijdlijn, en ik zou sceptisch zijn over de eerste golf van "expertisebundels" op dezelfde manier als ik sceptisch ben over elke eerste golf.

Dus waar laat dat een bouwer nu? Met één duidelijke, laag-risico stap en veel geduld voor de rest.

Wat ik vandaag werkelijk met OKF zou doen

Laat me dit concreet maken, want "experimenteer ermee" is het soort advies dat goed klinkt en niets verandert. Hier is de specifieke reeks die ik zou doorlopen, en wat je van elke stap kunt verwachten.

1. Lees de werkelijke specificatie, niet de samenvattingen. De OKF SPEC.md op GitHub is kort en leesbaar in vijftien minuten. Elke tweedehands samenvatting (inclusief deze) verliest getrouwheid. De bron is de bron.

2. Bouw een bundel van vijf bestanden met de hand. Kies een echt stuk van je eigen kennis — je processen, je productdocumentatie, je zuurverdiende heuristieken. Schrijf vijf conceptbestanden, één index.md, en één log.md. Gebruik geen tool. De wrijving is het onderwijs. Je leert meer over je eigen kennisstructuur in twintig minuten dan een generator je ooit zal vertellen.

3. Open het in de tools die je al gebruikt. Drop de map in Obsidian, push het naar een GitHub-repo, plak een bestand in Notion. Bevestig voor jezelf dat "mensvriendelijk" standhoudt. Dit is de eigenschap die OKF veilig maakt om te adopteren: in het slechtste geval heb je wat goed georganiseerde markdown geschreven, wat waarde heeft met of zonder enige agent.

4. Wijs een agent naar de bundel en stel een vraag. Geef Claude of Gemini de map en stel iets wat alleen één concept kan beantwoorden. Kijk of het de index gebruikt om te navigeren. Dit is het moment dat OKF stopt abstract te zijn — wanneer je ziet dat een agent de kaart overziet en precies het juiste bestand opent, klikt het ontwerp.

5. Schrijf je type-vocabulaire op als een eigen concept. Dit is de enige gewoonte met de hoogste hefboomwerking. De vrijheid van de specificatie op het gebied van types is een tweesnijdend zwaard; de bundels die goed verouderen zijn die met een bewust, gedocumenteerd typesysteem. Neem die beslissing één keer, met opzet, en verwijs ernaar.

Wat ik vandaag niet zou doen: mijn hele contentoperatie herinrichten rond OKF, betalen voor "OKF SEO"-diensten, of v0.1 behandelen als een afgewerkte standaard. Google noemde v0.1 zelf een startpunt, geen afgewerkte specificatie. Erop bouwen is slim; je bedrijf erop inzetten in zijn huidige vorm is dat niet.

Veelgestelde vragen

Wat is het Open Knowledge Format (OKF)?

Het Open Knowledge Format is een open, leveranciersonafhankelijke specificatie van Google Cloud, gepubliceerd als v0.1 op 12 juni 2026, voor het opslaan van kennis als een directory van markdown-bestanden met YAML front matter — leesbaar door zowel mensen als AI-agents. Elk bestand vertegenwoordigt één concept en moet een type-veld declareren. Voor de volledige structuuruitleg, zie de bundelsectie hierboven.

Hoe verschilt OKF van llms.txt?

OKF en llms.txt opereren op verschillende lagen: llms.txt is een ontdekkingsbestand dat agents naar je belangrijke bronnen wijst, terwijl OKF de samengestelde kennis zelf overhandigt als concept-niveau markdown-documenten. llms.txt is het menu; OKF is het eten. Ze zijn complementair, en OKF-bundels zullen waarschijnlijk in de toekomst gesignaleerd worden via een llms.txt-achtige verwijzing.

Is OKF een SEO-rangschikkingsfactor?

Nee — medio 2026 heeft Google geen rangschikkingsvoordeel aangekondigd voor het publiceren van OKF-bundels. OKF maakt je kennis schoner en bruikbaarder voor AI-agents die het lezen, wat een verdedigbare reden is om het te adopteren, maar behandel elke claim dat OKF direct rankings verbetert met scepsis. Zie de sectie over agentische zoekopdrachten hierboven voor het volledige voorbehoud.

Welke tools kan ik gebruiken om OKF-bundels te maken?

Je kunt OKF-bundels met de hand schrijven in elke teksteditor, omdat het gewoon markdown plus YAML is. Community-generators zoals Suganthans OKF Bundle Generator kunnen een site converteren naar een basisbundel, maar ze produceren momenteel één concept per pagina in plaats van echte conceptextractie — de meer waardevolle tooling voor het ontleden van content in schone concepten is nog niet gebouwd.

Wat is Karpathy's LLM Wiki en hoe verhoudt het zich tot OKF?

De LLM Wiki is Andrej Karpathy's concept van een levende kennisbasis die een AI-model zelf bouwt en onderhoudt — nieuwe informatie integreren, beweringen herzien en tegenstrijdigheden verzoenen, in plaats van een statische stapel doorzoeken zoals traditionele RAG. OKF is in wezen het on-disk bestandsformaat voor die visie, met conceptbestanden als entiteitspagina's en een logbestand als herzieningsgeschiedenis.

De echte reden waarom ik blij ben dat ik het niet heb genegeerd

Ik ging erin met de verwachting dat het weer een specificatie zou zijn om te archiveren onder "interessant, nooit gebruikt." Ik kwam eruit met een veranderde manier van hoe ik mijn eigen kennis opsla — niet omdat OKF af is, maar omdat het naar iets waars wees.

Het ding dat het goed doet is bescheiden: kennis voor agents moet samengesteld, geatomiseerd en overhandigd worden, niet gescraped, opgedeeld in chunks en reverse-engineered. Dat klopt ongeacht of het specifieke formaat van Google wint. De bundel die ik met de hand bouwde zal elke gok over OKF's adoptie overleven, omdat het gewoon goed gestructureerde markdown is die ik nu beter begrijp dan vanmorgen.

Dus hier is het enige dat ik je echt zou vragen om te doen voordat deze week voorbij is: open een map, schrijf vijf conceptbestanden over iets waar je alles van weet, voeg een index toe, en wijs een agent ernaar. Twintig minuten. Maak dan je eigen oordeel over of de toekomst een map is. De mijne is dat het formaat vrijwel zeker voorbij v0.1 zal evolueren — maar de vorm die het beschrijft, kennis als concepten die een agent kan lezen en onderhouden, is de richting waar alles al naartoe beweegt. Beter om de vorm nu te leren dan er je later naartoe te scrapen.

Laten we samenwerken

Op zoek naar het bouwen van AI-systemen, het automatiseren van workflows, of het opschalen van je tech-infrastructuur? Ik help graag.

• Fiverr (maatwerkbouw & integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise-oplossingen): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (beveiligingsdiensten): xcybersecurity.io