Automatiseringen breken vaak niet omdat hun eigen code verandert, maar omdat een externe applicatie plots een veld hernoemt, een interface aanpast of een API anders laat reageren. Een recente demo met GPT-6 Astra laat zien hoe een AI-agent zulke fouten automatisch kan detecteren, classificeren, onderzoeken, repareren en testen. De interessantste les is niet dat automatiseringen nooit meer stukgaan, maar dat ze steeds minder lang onopgemerkt kapot hoeven te blijven. Tenminste zolang verificatie, auditlogs en menselijke goedkeuring rond risicovolle acties goed zijn ingebouwd.
Voor de voorbereidingen van de inhoud en creatie van de visuals wordt (uiteraard) gebruikgemaakt van generatieve AI.
De workflow die zichzelf herstelt
Automatiseringen zien er tijdens een demo vaak indrukwekkend uit. Een workflow opent een browser, kopieert informatie tussen applicaties, vult formulieren in en bespaart uren handmatig werk. Tot iemand anders de software wijzigt.
Een veld dat gisteren `account number` heette, heet vandaag `account ID`. De automatisering zelf is niet veranderd, maar kan het element niet meer vinden en stopt.
Dat was het uitgangspunt van een recent experiment waarin met GPT-6 Astra een zogenaamde immortal automation bouwde: geen workflow die letterlijk nooit stukgaat, maar een systeem dat zelf merkt wanneer iets mislukt, onderzoekt waarom dat gebeurt, een reparatie opstelt en controleert of die reparatie werkt.
Een fout oplossen is meer dan code schrijven
De interessantste stap is dat zo’n herstelproces niet puur een programmeerprobleem is. Een agent moet achtereenvolgens:
1. de foutlog lezen
2. begrijpen waar de automatisering stopte
3. de betrokken applicatie openen
4. bepalen wat sinds de laatste succesvolle uitvoering veranderd is
5. de code of configuratie aanpassen
6. de wijziging testen
7. controleren of het gewenste bedrijfsresultaat daadwerkelijk werd bereikt.
Dat soort werk past goed bij modellen die coding, computer use en langere agentische workflows combineren.
OpenAI positioneert GPT-6 Astra precies op dat snijvlak. Het bedrijf zegt dat Astra sterke prestaties levert op computergebruik, software-engineering en cybersecurity. Tegelijk is het het eerste OpenAI-model dat binnen het Preparedness Framework het niveau Critical voor cybersecuritycapaciteiten bereikt.
Niet iedere fout mag automatisch worden gerepareerd
De demo laat ook zien waarom simpelweg iedere foutmelding naar een AI-agent sturen een slecht ontwerp zou zijn. Een workflow kan om heel verschillende redenen mislukken:
- Transient: tijdelijke netwerkfout, timeout of storing.
- Credential: verlopen sessie, ongeldige API-key of vereiste 2FA.
- Data: ontbrekende of foutieve invoer.
- Surface change: gewijzigd veld, DOM-element, interface of workflow.
- Unknown: onvoldoende informatie om de oorzaak veilig vast te stellen.
Alleen bij sommige categorieën is een automatische reparatie logisch.
Een netwerkfout vraagt meestal om een beperkte retry. Een authenticatieprobleem moet naar een mens worden geëscaleerd. Verkeerde data moeten worden geïsoleerd. Een gewijzigde interface kan wel geschikt zijn voor automatische diagnose en een voorgestelde codewijziging.
Dat onderscheid voorkomt dat een agent bij iedere storing onmiddellijk productiecode begint te herschrijven.
Van foutmelding naar gecontroleerde reparatie
In het experiment evolueert de architectuur uiteindelijk naar een keten:
Monitor → Triage → Diagnose → Reparatievoorstel → Semantische verificatie → Risicoclassificatie → Menselijke goedkeuring → Deployment → Controle na deployment → Auditlog
Dat is belangrijk, omdat een technisch geslaagde uitvoering nog niet betekent dat het resultaat correct is.
Een workflow kan perfect groen eindigen en toch het verkeerde klantrecord aanpassen, tweemaal een betaling uitvoeren of een bericht naar de verkeerde persoon sturen. Daarom moet verificatie niet alleen vragen:
> Is de workflow zonder foutmelding afgerond? Maar vooral:
> Is exact het bedoelde bedrijfsresultaat bereikt?
In de demo betekent dat bijvoorbeeld controleren of precies één record werd aangemaakt, of het juiste bedrag werd verwerkt en of niets anders onverwacht veranderde.
De mens verdwijnt niet, maar verhuist
Dat leidt tot misschien wel het belangrijkste ontwerpprincipe: plaats menselijke controle rond consequenties, niet rond complexiteit.
Een AI-agent kan gerust tientallen logs onderzoeken, vijf bestanden openen, softwareversies vergelijken, code aanpassen en twintig tests uitvoeren. Maar zodra een reparatie geld verplaatst, berichten verstuurt, gegevens verwijdert, productieconfiguraties wijzigt of andere onomkeerbare gevolgen heeft, hoort een mens de wijziging eerst te zien.
De menselijke rol verschuift daarmee van:
‘zoek gedurende 40 minuten uit waarom deze workflow stuk is’ naar:
’dit ging mis, dit is de oorzaak, dit is de voorgestelde patch, dit hebben de tests aangetoond- goedkeuren of weigeren?’
‘Immortal’ betekent vooral: nooit stilletjes dood
De term immortal automation klinkt spectaculair, maar de praktische betekenis is nuchterder. Alles wat afhankelijk is van software die je niet zelf controleert, zal uiteindelijk veranderen. Interfaces worden aangepast, API’s evolueren, authenticatieregels veranderen en gegevensstructuren verschuiven.
De echte vooruitgang zit daarom niet in automatiseringen die **nooit breken**. Het doel is een automatisering die nooit lang gebroken blijft zonder dat iemand het weet, zelf het probleem kan onderzoeken en een gecontroleerd herstelproces kan starten.
GPT-6 Astra maakt zulke architecturen realistischer doordat computergebruik, coding en redeneren steeds meer binnen één agentische loop samenkomen. Tegelijk maakt precies die grotere autonomie monitoring en duidelijke grenzen belangrijker.
Daarmee verandert de volgende generatie automatisering fundamenteel. Niet alleen werk automatiseren**, maar ook het **onderhoud van die automatisering automatiseren.
En dat kan uiteindelijk belangrijker worden dan nog een extra workflow bouwen.