Agentic data engineering en zelfherstellende pijplijnen

Wat is agentic data engineering?

Agentic data engineering betekent dat je een AI-agent inzet op het werk dat je pipelines draaiende houdt: een mislukte run lezen, uitzoeken waar het misliep en een fix schrijven die iemand daarna goedkeurt. Zelfherstellende pijplijnen is de term die leveranciers gebruiken voor de oudere helft van diezelfde belofte: een pipeline die zichzelf uit de problemen haalt zonder dat er iemand wakker moet worden.

De twee staan in bijna elke productaankondiging in dezelfde zin, en het zijn andere dingen. Automatisch herstel vangt een fout op waarvan jij het antwoord op voorhand vastlegde: probeer het drie keer opnieuw, aanvaard de nieuwe kolom, gooi de rijen weg die deze regel breken. Een agent vangt een fout op waarvoor niemand een regel schreef, door de foutmelding, de recente wijzigingen en de code te lezen en iets voor te stellen dat er voordien niet was.

Wat er in de praktijk stukgaat aan een pipeline

Zes oorzaken dekken zowat alles wat er misloopt bij een nachtelijke load.

1. Een schemawijziging bij de bron. Een veld hernoemd, gesplitst, verwijderd of met een ander type.

2. Een vervallen credential. Een afgelopen token, een geroteerd wachtwoord, een serviceaccount dat een recht kwijt is.

3. Een late of ontbrekende levering. Om middernacht stond er niets klaar.

4. Een wijziging aan de bron-API. Een versie die verdwijnt, een endpoint dat verhuist, een strengere rate limit.

5. Een schending van je kwaliteitsregels. Dubbele sleutels, lege waarden waar het model er een nodig heeft, een bedrag dat nergens op slaat.

6. Een echte fout in je eigen logica. De join vermenigvuldigt rijen, de filter gooit een categorie weg, de omrekening naar euro gebeurt twee keer.

De eerste vier zijn samen het grootste deel, en ze hebben iets gemeen: het antwoord is mechanisch. Er is niets veranderd aan de business.

Die rangschikking lees je af van de tools zelf. Elk platform van enige omvang heeft een retry-instelling, een beleid voor schemawijzigingen en een knop om opnieuw te authenticeren. Geen enkel platform heeft een knop voor een verkeerde margeberekening.

De laatste twee gedragen zich anders. Een kwaliteitsschending detecteer je mechanisch, maar oplossen is een oordeel, want de vraag is of de data fout zit of de regel. Een logicafout is net het soort fout dat een agent op eigen houtje het minst goed opspoort, omdat er niets faalde.

Wat een leverancier bedoelt met zelfherstellend

Staat er zelfherstellend op een productpagina, dan gaat het bijna altijd over een van drie mechanismen, elk netjes gedocumenteerd.

Retry. Het eenvoudigste en het nuttigste. In Apache Airflow gaat een taak die faalt terwijl er nog pogingen over zijn naar de toestand up_for_retry, en wordt ze opnieuw ingepland in plaats van als mislukt gemarkeerd. Dat vangt de netwerkhapering op en de API die even niet lekker was.

Automatisch meebewegen met het schema. Azure Data Factory noemt dit allow schema drift. Zet je het aan op de bron, dan wordt elk binnenkomend veld gelezen en doorgegeven tot in de sink, ook kolommen die niet in je projectie staan. Microsoft schrijft de prijs in datzelfde document: drifted columns komen binnen als string tenzij je ook infer drifted column types aanvinkt, en de flow wordt late binding, waardoor die kolomnamen ontbreken in de schemaweergaves terwijl je bouwt. Databricks Auto Loader staat standaard op addNewColumns: bij een nieuwe kolom werkt de stream het schema bij en stopt ze dan met een UnknownFieldException, en na een herstart draait ze verder met het bijgewerkte schema.

Quarantaine. De run levend houden en de slechte rijen apart zetten. In Lakeflow declarative pipelines krijgt elke expectation een van drie acties: warn, waarbij ongeldige records toch naar het doel geschreven worden, ON VIOLATION DROP ROW, waarbij ze voor het wegschrijven verwijderd worden, en ON VIOLATION FAIL UPDATE, waarbij ongeldige records de update doen mislukken en er eerst iemand handmatig moet ingrijpen.

Alle drie zijn het vormen van automatisch herstel. Alle drie voeren ze een beslissing uit die jij nam voor de fout gebeurde, en alle drie bestaan ze langer dan de huidige golf van agents. Twee van de drie herstellen zelfs niets: de Auto Loader-stream stopt en wacht op een herstart, en een gefaalde expectation vraagt om een mens. Degelijke techniek met een te grote naam.

Automatisch herstel tegenover diagnose door een agent

Zet ze naast elkaar op één dimensie: is er iets uitgezocht?

De derde rij draagt de rest van de tabel. Een retry weet niet waarom de call mislukte en hoeft dat ook niet te weten. Een schema-instelling die een nieuwe kolom overneemt, weet niet wat die kolom betekent, alleen dat jij ja zei tegen nieuwe kolommen.

Een agent die de stacktrace leest, ziet dat de connector veertig minuten voor de fout een schemawijziging logde, het model opent dat naar de verdwenen kolom verwijst en met een mapping terugkomt, heeft een hypothese gevormd over de oorzaak. Dat is een uur van iemands ochtend waard, en het is exact het stuk dat overtuigend fout kan zijn. Automatisch herstel koopt je de run. Diagnose koopt je het uur dat iemand zou besteden aan het zoeken naar de oorzaak, en dat uur hou je enkel over als er nog altijd iemand het antwoord leest.

Een schemawijziging die de nachtelijke load breekt

Een installatiebedrijf met veertig technici verwerkt zijn werkorders in een field service-app. Een connector haalt de werkorderlijnen elke nacht om twee uur binnen in het datawarehouse, een transformatie maakt er een urenmodel van, en dat model voedt twee Power BI-rapporten en de wekelijkse facturatie-export.

Om 02:12 loopt de transformatie vast. Ze selecteert duration_minutes en die kolom bestaat niet meer. De leverancier van de app rolde 's nachts een nieuwe versie uit: duration_minutes is weg en er staan twee velden in de plaats, duration en duration_unit, waarbij de eenheid minuten of uren is.

Een agent met toegang tot de logs, de schemahistoriek en de lineage heeft dit klaar voor er iemand wakker is.

• De fout, benoemd: het model leest een kolom die de bron niet meer stuurt.

• Het verband: de connector logde de schemawijziging om 01:47, vijfentwintig minuten voor de fout, en aan jouw kant ging die dag niets in productie.

• De impact via de lineage: het werkordermodel voedt het urenmodel, dat op zijn beurt twee rapporten en de facturatie-export voedt.

• Een blik op de nieuwe data: de bron geeft de laatste negentig dagen nu in de nieuwe vorm terug, en van die 9.800 lijnen staan er 260 op uren en de rest op minuten.

• Een voorstel, uitgevoerd op een kopie van de data in plaats van op productie: neem duration waar de eenheid minuten is, vermenigvuldig met zestig waar ze uren is, plus een test die het totaal aantal uren per maand voor afgesloten periodes naast de vorige run legt.

Nu het stuk dat telt, namelijk de fix die de agent bijna schreef in de plaats. De kortste weg om de foutmelding te laten verdwijnen, is duration rechtstreeks op duration_minutes mappen. Elke run kleurt groen. Die 260 lijnen staan gemiddeld op zo'n drie uur, dus 780 uren komen binnen als 13. Het totaal aan factureerbare uren over negentig dagen leest dan ongeveer 18.733 in plaats van 19.500, bijna vier procent te weinig.

Aan dat cijfer is niets te zien: het staat niet op nul, het is niet verdubbeld, het beweegt week na week de goede kant op. Het rapport ververst, de maandagvergadering gebruikt het, de facturatie-export gaat vier procent te licht de deur uit, en wie het uiteindelijk vindt is een technicus die een maand later over een factuur discussieert. Daarin verschilt een pipeline van gewone software. Een slechte wijziging in een applicatie gooit meestal een fout, of de pagina breekt en de telefoon rinkelt. Een slechte wijziging in een pipeline levert plausibele cijfers op, en die worden gebruikt.

Drie dingen in deze fix zijn niet aan de agent.

• De betekenis. De facturatie rondt af naar het kwartier. Draagt het nieuwe veld dezelfde afronding als het oude, of staat er ruwe tijd in? Die vraag ligt bij wie eigenaar is van het model, of bij de release notes van de leverancier.

• De historiek. Negentig dagen aan rijen zijn op het oude veld gebouwd. Herverwerk je die, of laat je ze staan en noteer je waar de breuk zit? Beide antwoorden zijn verdedigbaar en maar één ervan is wat je boekhouder verwacht.

• Het gevolg. De facturatie-export verlaat het bedrijf en wordt geld. Daar hoort een handtekening bij, en op een handtekening staat een naam.

De fix gaat dus buiten zoals elke andere wijziging: een branch, een review, een deploy. Wat de agent wegnam, is het uur logs lezen om zeven uur 's ochtends en het gissen naar welke wijziging stroomopwaarts het gedaan heeft. Wat ze niet wegnam, is de beslissing.

Diagnose vrij, naar productie langs dezelfde deur

De leveranciers die het meest te winnen hebben bij het verkopen van autonomie, hebben de goedkeuringsstap zelf in hun productbeschrijving gezet. Databricks beschrijft Genie Code, in een tekst van april 2026, zo: als een pipeline of job faalt, analyseert het de fouten, stelt het aanpassingen voor in de betrokken bestanden en toont het je de diffs voor er iets toegepast wordt, en in agent mode vraagt het je goedkeuring voor het code uitvoert of een pipeline aanpast.

Genie ZeroOps, aangekondigd in juni 2026 en eerst uitgerold als private preview, is het autonomere product en houdt dezelfde poort. Het monitort op de achtergrond en gebruikt de lineage uit Unity Catalog om een fout terug te brengen tot een bug in de code, een schemawijziging drie tabellen stroomopwaarts of slechte data uit een andere pipeline, en test zijn fix daarna in een sandbox met zero-copy clones van je data. Databricks zet de grens in één zin: er gaat niets naar productie zonder jouw goedkeuring.

Daarmee heb je een verdeling die je elke leverancier kan voorleggen.

• Lezen mag alles. Logs, runhistoriek, schemaversies, lineage, steekproeven uit de data, onder dezelfde toegangsregels als een medewerker in dat team.

• Voorstellen mag alles. Een diff, een test, een plan voor een herverwerking, of een bericht dat het er niet uit raakt. Een voorstel is goedkoop en een fout voorstel kost je een leesbeurt.

• Naar productie schrijven mag enkel langs de deur die een mens gebruikt. Dezelfde branch, dezelfde review, dezelfde deploy. Geen tweede weg met minder controles omdat de auteur een machine is.

De reden is niet voorzichtigheid om de voorzichtigheid. Een pipeline die haar eigen transformatie herschrijft en verder draait, breekt net de eigenschap waar je op steunt zodra een cijfer betwist wordt: kunnen zeggen waar het vandaan komt en wanneer het veranderde. Is het eerlijke antwoord dat de agent op 9 maart om 02:14 een mapping bijstelde en dat niemand het nakeek, dan zit er in je data lineage een stap die niemand kan verantwoorden. Dat is een gebrek in je lineage, geen functionaliteit met een governancevraagje eraan.

Diezelfde verdeling zegt je ook bij welke pipelines een agent iets kan betekenen. Er zijn tests nodig, zodat een voorgestelde fix aantoonbaar juist is in plaats van beweerd; de generieke tests van dbt zijn select-statements die naar falende records zoeken, en nul rijen terug betekent dat de bewering klopt. Er zijn afspraken nodig in een data contract, zodat een gewijzigde bron een voor en een na heeft in plaats van iemands geheugen. Er is lineage nodig, zodat de agent ziet wat een wijziging raakt. En er is een herhaalbare run nodig die twee keer hetzelfde antwoord geeft, zodat een fix op een kopie getest kan worden. Dat is exact het lijstje dat een pipeline ook onderhoudbaar maakt voor een mens die ze niet gebouwd heeft.

Waar moet je op letten bij agentic data engineering

Wie een kleiner bedrijf runt, gaat geen vloot agents op zijn dataplatform loslaten. Je komt dit tegen als een functie in een tool waar je al voor betaalt, aangezet via een release note. Dat maakt de vraag smal genoeg om ze echt te stellen: wat verandert het op eigen houtje, en waar staat dat genoteerd?

Vraag de lijst met automatische acties op. Opnieuw proberen, een kolom toevoegen, rijen weggooien, een mapping aanpassen, een herverwerking starten. Vraag per actie of ze zonder mens gebeurt, waar ze gelogd wordt en wie er bericht van krijgt. Een leverancier die antwoordt met het woord intelligent, heeft er niet over nagedacht.

Koop het eerst voor de triage. Wat vandaag werkt, is de gefaalde run, de wijziging die hem veroorzaakte en een kandidaat-fix die om zeven uur 's ochtends klaarligt in plaats van om negen uur. De eerste versie klopt vaak en moet altijd nagelezen worden. Koop je het als een manier om niet meer naar je pipelines te moeten kijken, dan valt het tegen, en die tegenvaller is vier procent te licht in plaats van luid.