Wat zijn agent-first data-architecturen en zijn ze beter dan tool calls?

Een agent-first data-architectuur zet de databronnen van een bedrijf achter één querylaag voor AI-agents, in plaats van de agent per bron een aparte tool te geven. Een voorbeeld is Dinobase, een open-sourceproject dat op 7 april 2026 op Hacker News werd gepresenteerd: het synchroniseert bronnen zoals Stripe en HubSpot naar Parquet-bestanden en bevraagt ze met DuckDB, zodat één SQL-query een vraag over meerdere systemen kan beantwoorden. In de eigen benchmark van Dinobase beantwoordden 11 modellen zo 91% van de vragen goed, tegen 35% met een tool per bron.

Wat gaat er mis met één tool per bron?

De gangbare opzet geeft een agent één tool per databron, vaak een MCP-server per SaaS-product. De README van Dinobase noemt drie gaten in die aanpak: agents kunnen geen JOIN over API's heen doen, ze missen context om veldwaarden te interpreteren, en ze krijgen JSON in pagina's terug die hun contextvenster vult.

De voorbeeldvraag uit de README: "Welke klanten haakten vorig kwartaal af, met dalend gebruik én open supporttickets?" Met één tool per bron moet de agent door de factuurdata bladeren, gebruik en open tickets uit twee andere systemen ophalen, en de drie lijsten dan in zijn eigen context aan elkaar koppelen, bijvoorbeeld op e-mailadres. Volgens de toelichting bij de benchmark kost het lezen van 1.000 records via zo'n tool 10 rondes en zo'n 60.000 tokens, waar SQL één aggregatiequery nodig heeft.

De ontwikkelaar achter Dinobase verwoordde het op Hacker News zo: tool calls, MCP's en ruwe API's dwingen de agent om informatie in zijn context samen te voegen, terwijl SQL dat van zichzelf doet. Vóór Dinobase bouwde hij PostHog AI, de analyse-agent van het analysebedrijf PostHog, waar het team directe SQL-toegang vergeleek met tools. Zijn oordeel: "SQL wint."

Hoe werkt Dinobase?

Het idee lijkt op een datawarehouse: eerst de data bij elkaar brengen, dan met SQL bevragen. Volgens de README van 9 april 2026:

• Bronnen: 101 connectors voor SaaS-API's, databases en bestandsopslag. API-data wordt gesynchroniseerd naar Parquet-bestanden op de lokale schijf of in je eigen S3-, GCS- of Azure-bucket; Parquet- en CSV-bestanden worden pas bij de query gelezen.
• Query-engine: DuckDB. Elke bron wordt een schema, en joins tussen bronnen lopen via gedeelde kolommen zoals e-mail.
• Interface: een commandlinetool voor agents die shellcommando's uitvoeren, zoals Claude Code, Cursor en Codex, of een MCP-server voor andere clients.
• Semantische laag: optioneel. Na elke synchronisatie schrijft een Claude-agent, met je eigen Anthropic-API-sleutel, tabelbeschrijvingen, kolomdocumentatie, markeringen voor persoonsgegevens (PII) en relaties tussen tabellen.
• Terugschrijven: agents kunnen brondata via SQL wijzigen, maar elke wijziging geeft eerst een voorbeeld en wordt pas na bevestiging uitgevoerd.

Wat laat de benchmark zien?

Dinobase testte 11 modellen, van Kimi K2.5 tot Claude Opus 4.6, met 15 vragen over revenue operations op synthetische HubSpot- en Stripe-data: zo'n 1.400 rijen in 7 tabellen. Elk model kreeg in beide opstellingen dezelfde data en vragen, met hooguit 15 beurten en temperature 0, en beantwoordde elke vraag één keer. Het rapport geeft deze totalen:

• Nauwkeurigheid: 91% (150 van 165 antwoorden) met SQL, 35% (57 van 165) met een tool per bron
• Gemiddelde tijd per vraag: 34 seconden tegen 106 seconden
• Kosten per goed antwoord: $0,027 tegen $0,445, ongeveer 16 keer minder

SQL scoorde bij elk model hoger, van 80% (Kimi K2.5) tot 100% (Claude Opus 4.6 en Sonnet 4.6). Met een tool per bron scoorden de modellen tussen 20% en 53%. De snelheid liep meer uiteen: bij drie modellen, waaronder GPT-5.4, waren de tools per bron ongeveer even snel.

Het verschil was bij eenvoudige vragen over één bron ongeveer even groot als bij vragen die een join vereisten: SQL haalde 91% op elk van de drie soorten vragen, de tools per bron 38% op de eenvoudige, 29% op de vragen die domeinkennis vroegen en 36% op de vragen over meerdere bronnen. Van de fouten met tools per bron was 62% een verkeerd antwoord of een verkeerde interpretatie, 12% een join die de agent niet kon maken, 9% een bedrag dat in centen bleef staan in plaats van dollars, 9% een fout in een tool of API en 7% het gevolg van alleen de eerste 100 records zien.

Hoeveel zegt die benchmark?

Dinobase bouwde en draaide de benchmark zelf. De ontwikkelaar noemde hem "een experimentele benchmark" en schreef dat de uitkomsten "bijna te mooi" leken. Vier dingen beperken hem:

• De vergelijking is een eigen simulatie van Dinobase: één lijsttool per tabel die hooguit 100 records per pagina teruggeeft, met alleen een limit en een offset als parameters. Tools die kunnen filteren of aggregeren zijn niet getest. Volgens de ontwikkelaar is 80% van de vragen in de benchmarkset een aggregatie, en daar levert het overslaan van pagina's het meeste op.
• Elk model beantwoordde 15 vragen één keer, dus één antwoord verschuift de score met bijna 7 procentpunt.
• De antwoorden op ongeveer 40% van de vragen werden beoordeeld door een ander model (Claude Haiku 4.5); de rest werd automatisch gecontroleerd.
• De README noemt 75 vragen en "16 tot 22 keer goedkoper". Het gepubliceerde rapport gaat over de 15 vragen over revenue operations en een factor 16.

Wat zijn de afwegingen?

Gesynchroniseerde API-data is zo actueel als de laatste synchronisatie. In april 2026 leverde een kolomwijziging bij een SaaS-leverancier een nieuwe kolom op terwijl de oude bleef staan, en beschreef de semantische laag de huidige stand inclusief die verouderde kolommen, aldus de ontwikkelaar. Hij was van plan automatische schemamigraties toe te voegen. De optionele semantische laag laat Claude over je data lopen met je eigen API-sleutel. Het grootste deel van de code van Dinobase valt onder de MIT-licentie, en de code, vragen en resultaten van de benchmark staan in de map benchmarks van de repository.