In het eerste artikel van deze reeks, Datakwaliteit in AI Agents, stelden we dat in het tijdperk van AI agents geldt: garbage in equals garbage out, ongeacht hoe geavanceerd het model of de orchestration stack ook is. Nu organisaties overstappen van eenvoudige chatbots naar multi-step agents die informatie ophalen, redeneren en actie ondernemen in complexe systemen, is schone ruwe data niet langer voldoende.
Wat robuuste agents in toenemende mate onderscheidt van fragiele varianten, is de kwaliteit en rijkheid van de metadata rondom die data. In de moderne Retrieval-Augmented Generation (RAG) en agentic architecturen is metadata stilletjes de belangrijkste brandstof geworden voor context, controle en compliance.
DataNorth AI werkt samen met Hyperplane, opgericht door Cube Digital (een vooraanstaande specialist in digitale transformatie), om te onderzoeken hoe uitdagingen op het gebied van datakwaliteit de aanpak van AI agents bepalen. Samen brengen we decennia aan gecombineerde expertise in AI-implementatie en digitale strategie samen om een van de meest dringende uitdagingen voor hedendaagse organisaties aan te pakken: het waarborgen van data-integriteit in een door AI gedreven wereld.
Waar het eerste artikel zich richtte op de kern van datakwaliteit, onderzoekt dit tweede artikel metadata als de primaire beperkende factor voor de prestaties van agents. We analyseren hoe standaarden zoals PROV-AGENT en OpenLineagede nodige audit trails bieden, hoe GraphRAG hallucinaties voorkomt via gestructureerde kennis, en hoe protocollen zoals MCP en OASF het agentic ecosysteem standaardiseren.
Metadata als brandstof voor context bij agents
Een autonome agent verschilt van een rekenmachine door de noodzaak om de kloof te overbruggen tussen doelen op hoog niveau en uitvoering op laag niveau. Wanneer aan een mens wordt gevraagd om “een financiële review voor te bereiden”, vertrouwt deze op impliciete kennis: valuta normen, belangrijke stakeholders en de betrouwbaarheid van bronnen. Een AI agent, die deze intuïtie mist, werkt strikt binnen de kaders van expliciet beschikbare informatie.
Metadata overbrugt het gat tussen ruwe opslag en actief redeneren, door institutionele kennis te coderen in machineleesbare formaten. Zonder een robuuste metadata land is een agent in een modern data lake functioneel blind.
De cognitieve architectuur van metadata
Large Language Models (LLMs), de cognitieve kernen van agents, worden beperkt door eindige “context windows”. Bovendien verslechtert het redeneervermogen wanneer het werkgeheugen van een agent wordt gevuld met irrelevante ruis. Metadata fungeert als een compressie-algoritme voor context, waardoor agents informatie kunnen filteren via headers en tags voordat de computationele kosten van volledige inname worden gemaakt.
Srinivas Tallapragada, President en Chief Engineering Officer bij Salesforce, biedt een treffende analogie voor deze relatie door data te vergelijken met ruwe bouwmaterialen en metadata met de architecturale instructies. Zonder de blauwdruk kunnen materialen geen functionele structuur vormen. Op dezelfde manier heeft een AI-systeem zonder metadata weliswaar toegang tot “feiten”, maar ontbreekt het raamwerk om deze samen te voegen tot de “waarheid”.
De vier pijlers van agentic metadata
We categoriseren agentic metadata in vier functionele pijlers, die elk een specifiek cognitief tekort aanpakken.
| Pijler | Functie | Antwoord op vraag | Gevolg van falen |
|---|---|---|---|
| Descriptief | Identificatie & Definitie | “Wat is deze data?” | Berekeningsfouten, valuta-mismatches. |
| Structureel | Hiërarchie & Relatie | “Hoe verhoudt dit zich tot X?” | Hallucinaties, haperende workflows. |
| Administratief | Governance & Rechten | “Mag ik dit gebruiken?” | PII-lekken, schending van regelgeving. |
| Gedragsmatig | Historie & Observability | “Hoe is dit eerder gebruikt?” | Herhaling van eerdere fouten. |
Descriptieve metadata biedt de definities die nodig zijn voor basisbegrip. In een traditionele database heeft een kolom misschien de naam amt. Voor een menselijke analist is dit dubbelzinnig; voor een agent is het betekenisloos. Descriptieve metadata verrijkt dit veld met semantische tags: type: currency, currency_code: EUR, precision: 2, source_system: SAP_General_Ledger. Hiermee kan de agent onderscheid maken tussen een financieel bedrag, een voorraadhoeveelheid of een tijdsduur. Zoals opgemerkt door XenonStack, is deze praktijk van opschonen, classificeren en organiseren de fundering van data bruikbaarheid. Zonder dit zou een agent die probeert “sales” te aggregeren, per ongeluk omzetcijfers kunnen optellen bij aantallen eenheden, wat een wiskundig valide maar operationeel onzinnig resultaat oplevert.
Structurele metadata definieert de geometrie van het datalandschap. Het brengt de verbindingen tussen discrete objecten in kaart: het koppelen van een support ticket aan een klantprofiel, een klantprofiel aan een aankoophistorie, en een aankoophistorie aan een productcatalogus. Voor een agent zijn deze koppelingen traversale paden. Wanneer een agent de taak krijgt om “alle klanten te mailen die de defecte widget hebben gekocht”, vertrouwt deze volledig op structurele metadata om de graph te doorkruisen van het “Product”-object naar het “Order”-object en uiteindelijk naar het “Klant”-object. Een breuk in deze metadata keten resulteert in een gestrande agent die de workflow niet kan voltooien.
Administratieve metadata omvat permissies, auteursrecht status, bewaartermijnen en access control lists (ACL’s). Het fungeert als een semantische firewall. Wanneer een agent een document repository doorzoekt, moet deze eerst de administratieve metadata raadplegen om te bepalen of de aanvragende gebruiker (of de agent zelf) over de juiste autorisatie beschikt. Dit is cruciaal voor compliance met regelgeving zoals de AVG (GDPR) en HIPAA. Zoals Box opmerkt, stelt het vooraf definiëren van toegangsrechten agents in staat om noodzakelijke context op te halen terwijl ze strikt voldoen aan industriestandaarden. Dit voorkomt het “jailbreak”-scenario waarbij een agent, geautoriseerd om algemene vragen te beantwoorden, onbedoeld een vertrouwelijk HR-document ophaalt en samenvat, simpelweg omdat het semantisch relevant was voor de vraag.
Gedragsmatige metadata volgt het gebruik van data door agents. Het legt vast welke datasets zijn opgehaald voor welke taken, hoe nuttig de agent ze vond (vaak gemeten via gebruikersfeedback op de uiteindelijke output) en welke fouten er tijdens de verwerking zijn opgetreden. Dit creëert een feedbackloop. Als meerdere agents een specifieke dataset markeren als “ruizig” of “inconsistent”, kan deze gedragsmatige metadata een datakwaliteit waarschuwing triggeren. Omgekeerd, als een specifiek document vaak wordt geciteerd in hoog gewaardeerde antwoorden, stijgt de “relevantiescore” in de metadata laag, wat toekomstige agents naar hoogwaardige context leidt.
De fysica van data: Latency en progressive disclosure
De prestaties van agents worden bepaald door de “fysica van data”. James Cullum stelt dat een agent zonder data is als een Formule 1-auto met een beslagen voorruit. Snelheid is cruciaal; als het ophalen van data langer duurt dan 120ms, ervaren agents “cognitieve vertraging”, wat leidt tot timeouts in omgevingen met hoge frequentie, zoals aandelenhandel.
Om dit te beheersen, gebruiken engineers Progressive Disclosure. In plaats van alle data in het context window te dumpen, navigeren agents door bestaande hiërarchieën met behulp van metadata signalen (mapnamen, tijdstempels) om de relevantie te bepalen. Anthropic definieert dit als een verschuiving van Prompt Engineering naar “context engineering”: het configureren van de informatie status om het redeneren te optimaliseren.
Provenance, lineage en semantische verrijking
Om een agent verantwoordelijk te kunnen houden, moeten we niet alleen de vraag “Wat heeft hij gedaan?” kunnen beantwoorden, maar ook “Op basis waarvan?”. Dit vereist robuuste provenance (oorsprong) en lineage (stroom), samen met semantische verrijking om een correcte interpretatie te waarborgen.
Provenance vs. lineage
Hoewel ze vaak door elkaar worden gebruikt, hebben provenance en lineage verschillende rollen in de agentic stack. IBM maakt een duidelijk onderscheid: Data Lineage volgt de beweging en transformatie van data door verschillende systemen (de “stroom”), terwijl Data Provenance het verslag is van de oorsprong van de data, de historische context en de authenticiteit.
- Lineage: Volgt welke downstream agents een rapport hebben gebruikt, wat impactanalyse mogelijk maakt als er fouten worden ontdekt.
- Provenance: Valideert of een rapport afkomstig is van een gecertificeerde SAP-export of een concept-e-mail.
De PROV-AGENT standaard
Terwijl W3C PROV statische workflows afhandelt, hebben autonome agents een model nodig dat doelgerichte besluitvorming vastlegt. PROV-AGENT is een opkomend framework dat hiervoor op maat is gemaakt. In een omgeving met hoge belangen is een hallucinatie niet alleen een irritatie, maar een fysiek risico.
In een case study bij Oak Ridge National Laboratory neemt een agent die een metalen 3D-printer bestuurt in een fractie van een seconde beslissingen op basis van sensorsystemen. PROV-AGENT fungeert als een “flight recorder” die de input (sensoren), de trigger (prompt), de context (fysische modellen) en de output (printcommando) vastlegt. Dit stelt engineers in staat om te debuggen of een defect werd veroorzaakt door een sensorfout of door gebrekkig redeneren van het LLM.
OpenLineage voor observability
Voor macroscopische zichtbaarheid biedt OpenLineage een standaard framework om Jobs (processen) en Runs(uitvoeringen) te definiëren. Door OpenLineage te integreren, kunnen data governance-teams de “impact radius” van een data kwaliteitsprobleem opvragen en direct elke uitvoering van een agent identificeren die toegang heeft gehad tot een beschadigd document.
Semantische verrijking: GraphRAG
Ruwe tekst is dubbelzinnig. “Apple” kan een vrucht zijn of een bedrijf. Agents lossen dit op via Semantische Verrijking, voornamelijk door gebruik te maken van Knowledge Graphs en GraphRAG.
Traditionele “Naive RAG” maakt gebruik van vector-overeenkomst, wat vaak faalt bij het verbinden van ongelijksoortige feiten. GraphRAG structureert informatie als nodes (entiteiten) en edges (relaties). Ontwikkelaars van Neo4j leggen uit dat dit multi-hop reasoning mogelijk maakt.
Als een agent wordt gevraagd: “Wie behandelt facturatie-bugs?”, vindt Naive RAG misschien algemene facturatie-documenten. GraphRAG doorkruist de graph: Billing Integration -> HAS_ISSUE -> Bug #402 -> ASSIGNED_TO -> Sarah. De agent kan dan een precies antwoord geven.
Entity linking met Schema.org
Een lichtere maar zeer effectieve methode van semantische verrijking is Entity Linking met behulp van de Schema.org vocabulaire. Dit is bijzonder waardevol voor webcontent en publieke documentatie. Door de eigenschap sameAs in JSON-LD markup te gebruiken, kunnen we dubbelzinnige termen expliciet verankeren aan gezaghebbende definities.
Ter voorbeeld gebruiken we een pagina over “Jaguar”. Om te voorkomen dat een agent het automerk verwart met het dier, voegen we de volgende metadata toe:
JSON
{
"@context": "https://schema.org",
"@type": "Brand",
"name": "Jaguar",
"sameAs": [
"https://en.wikipedia.org/wiki/Jaguar_Cars",
"https://www.wikidata.org/wiki/Q30055",
"https://g.co/kg/m/012x34"
]
}
Deze metadata vertelt de agent expliciet: “Dit is het automerk, niet het dier.” Deze praktijk is essentieel voor interoperabiliteit, omdat het garandeert dat elke consumerende agent de entiteit correct interpreteert zonder uit de context te hoeven raden.
Standaarden om data agent-ready te maken
Naarmate organisaties opschalen van individuele agents naar zwermen (swarms), wordt interoperabiliteit van cruciaal belang. De industrie verenigt zich rond twee belangrijke protocollen: MCP en OASF.
Het Model Context Protocol (MCP)
MCP is de “USB-C voor AI” en standaardiseert hoe modellen verbinding maken met data. Het elimineert de noodzaak voor op maat gemaakte API-wrappers voor elke database.
MCP-architectuur:
- Host: De AI-applicatie (bijv. Claude Desktop).
- Cliënt: De connector die de sessie beheert.
- Server: De brug naar de databron, die Resources (passieve data), Tools (uitvoerbare functies) en Prompts ontsluit.
MCP dwingt “Schema-on-Read” af. Een op Python gebaseerde MCP-server definieert expliciet het datacontract:
Python
from mcp.server.fastmcp import FastMCP
# Maak een MCP-server instantie aan
mcp = FastMCP("Sales Data Server")
# Definieer een Resource: Gevalideerde datatoegang
@mcp.resource("sales://{region}")
def get_sales_data(region: str) -> str:
"""
Retourneer gevalideerde verkoopgegevens voor een specifieke regio.
METADATA: Deze data betreft 'bevestigde' omzet, niet 'geprojecteerd'.
Valuta is genormaliseerd naar USD.
"""
return fetch_clean_data(region)
# Definieer een Tool: Uitvoerbare logica
@mcp.tool()
def calculate_growth(current: int, previous: int) -> float:
"""
Bereken het groeipercentage jaar-op-jaar.
"""
if previous == 0:
return 0.0
return ((current - previous) / previous) * 100
De doc string is niet zomaar een comment; het is het context-protocol. Het voorkomt dat agents “voorspelde” en “werkelijke” cijfers met elkaar verwarren.
Het Open Agentic Schema Framework (OASF)
Waar MCP de verbinding afhandelt, verzorgt OASF de definitie. Naarmate multi-agent systemen groeien, worden we geconfronteerd met een “discovery”-probleem. Een orchestration agent (een “Manager Agent”) moet weten welke sub-agents beschikbaar zijn en wat ze kunnen doen. “Heb ik een agent die in staat is Franse juridische contracten te analyseren?”
OASF biedt een gestandaardiseerd, op JSON gebaseerd schema voor het definiëren van de “Agent Badge” of “Record”. Het is het cv en de ID-kaart van de agent. Het biedt een gestandaardiseerde Agent Badge, een Verifiable Credential (VC) die fungeert als het cv van een agent.
De badge definieert Skills (bijv. skill:code-generation), Inputs/Outputs (strict typing) en de Issuer. Dit stelt een orchestration agent in staat om te verifiëren dat een “Finance Agent” daadwerkelijk is uitgegeven door de financiële afdeling voordat een gevoelige taak wordt gedelegeerd.
Strategische roadmap
De transitie naar agentic AI is een revolutie in de data infrastructuur. Wij adviseren de volgende stappen:
- Metadata-first governance: Keur geen pipelines goed zonder gedefinieerde lineage- en tagging-strategieën.
- Small graph approach: Begin met domein specifieke Knowledge Graphs (bijv. Compliance) in plaats van direct de hele onderneming in kaart te brengen.
- Standaardiseer op MCP: Wikkel interne API’s in MCP-servers om verbindingen toekomstbestendig te maken.
- Audit op machine leesbaarheid: Valideer of documentatie- en data-interfaces machineleesbaar en entiteit-gekoppeld zijn. Behandel je data als code; het moet worden gecompileerd en gevalideerd voor consumptie door agents.
Conclusie
Metadata is de nieuwe data, want context is de valuta van intelligentie. We bewegen ons voorbij “Garbage In, Garbage Out” naar “Metadata In, Intelligence Out.” Door te investeren in provenance (PROV-AGENT), semantische verrijking (GraphRAG) en open standaarden (MCP, OASF), transformeren organisaties ruwe data in geraffineerde brandstof voor autonome systemen. Degenen die metadata beheersen, zullen agents beheersen; degenen die het negeren, zullen achterblijven met het managen van de chaos van hallucinaties.
Veelgestelde vragen (FAQ)
Wat is het verschil tussen Agentic Metadata en Data Lineage?
Data Lineage vertelt je het pad (waar kwam het vandaan).
Agentic metadata vertelt je de intentie (waarom koos de agent deze informatie).
Waar moeten we beginnen met de implementatie van OASF en MCP?
Begin klein. Implementeer MCP voor je meest kritieke databron, zoals je CRM. Dit maakt je belangrijkste data direct “agent-ready”.
Vervangt GraphRAG vector-databases?
Nee, ze werken het beste samen. Gebruik vector search voor de breedte en Knowledge Graphs voor de diepte en gestructureerd redeneren.
Hoe voorkomt metadata hallucinaties?
Hallucinaties ontstaan vaak door creatief gokken bij gebrek aan kennis. Metadata biedt de agent een expliciete blauwdruk, waardoor hij kan vertrouwen op feiten in plaats van waarschijnlijkheid.
Zijn er kosten aan de prestaties verbonden aan deze metadata-laag?
Er zijn enkele kleine prestatiekosten aan verbonden tijdens het indexeren, maar het verbetert de runtime-prestaties aanzienlijk door ruis te verminderen. Dit leidt tot snellere en goedkopere antwoorden van de LLM.