Wat een workflow hier werkelijk is
De meeste «workflow»-tools in het AI-veld zijn promptketens met een dun laagje eroverheen. De bouwer van ToRun is een gerichte acyclische graaf (DAG) van getypeerde stappen: je verbindt modelaanroepen, gereedschapsaanroepen, voorwaardelijke vertakkingen, lussen en subworkflows tot een graaf, en de motor voert ze uit in volgorde van afhankelijkheid, parallel waar de graaf dat toelaat.
Elke stap is een volwaardige entiteit met een eigen configuratie: het staptype (LLM-aanroep, webzoekopdracht, code-uitvoering, beeldgeneratie, ophaling, transformatie, enzovoort), het invoerschema, het foutbeleid (snel falen, opnieuw proberen met wachttijd, terugvallen op een alternatief), een uitvoeringsbudgetplafond per stap en een tijdslimiet.
De modelroutering binnen elke LLM-stap loopt via dezelfde capaciteitenpijplijn als al het andere in ToRun. Je verklaart wat je nodig hebt — gestructureerde uitvoer, zicht, gereedschapsgebruik, redeneren, een contextvenster van minstens N tokens — en de uitvoerder bepaalt het best passende model onder de op dat moment beschikbare aanbieders. Geeft je voorkeursaanbieder een 5xx, dan neemt de terugvalketen automatisch over.
Uitvoerders met kwaliteit eerst en wat dat in de praktijk betekent
Wanneer je een workflow draait, kiest de uitvoerder bewust modellen van kwaliteitsniveau in plaats van de goedkoopste optie. Twee redenen: automatiseringen leveren artefacten op (rapporten, gegenereerde inhoud, code) die niemand meteen nakijkt, dus kwaliteitsfouten stapelen zich stilletjes op; en bij gematigd volume is het kostenverschil kleiner dan de prijs van slechte uitvoer die een nieuwe run of handmatige correctie afdwingt.
In de praktijk betekent dit dat een workflow «onderzoek samenvatten en een rapport schrijven» een degelijk redeneermodel voor de samenvatting en een tekstmodel van hoge kwaliteit voor het schrijven zal verkiezen, in plaats van naar de prijsbodem te rennen. Je kunt dit per stap overrulen als je weet dat daar een licht model volstaat.
De facturering volgt de rest van ToRun: elke modelaanroep binnen een workflow schrijft precies één regel met een bevroren tariefmomentopname. Een run die drie verschillende modellen over vijf stappen aanroept, levert vijf regels op. Je kunt de exacte kosten van elke run achteraf controleren, uitgesplitst per stap — zelfs maanden later, wanneer de tarieven van aanbieders al zijn verschoven.
Een run onderzoeken
Elke workflowrun levert een gestructureerd spoor op. Het spoor toont de DAG met elk knooppunt geannoteerd: starttijd, eindtijd, bepaald model, aantal invoer- en uitvoertokens, uitgevoerde gereedschapsaanroepen en de eventuele fout. Bij LLM-stappen kun je de exacte verzonden prompt en het ruwe ontvangen antwoord uitklappen.
Faalt een stap, dan vertelt het spoor je of de fout van de modelaanroep kwam (aanbiedersfout, contextoverschrijding, weigering op inhoudsbeleid), van een gereedschap verderop (netwerktijdslimiet, mislukte schemavalidatie) of van je eigen voorwaardelijke logica. Je hoeft geen logregels toe te voegen: het wordt op infrastructuurniveau bij elke run vastgelegd.
Elke run kan met dezelfde invoer worden herhaald, wat het reproduceren van een storing rechttoe rechtaan maakt.
Een klein voorbeeld: wekelijkse workflow voor concurrentie-informatie
Stel je een workflow voor die je elke maandagochtend start:
- Webzoekstap — zoekt recente berichtgeving over een set concurrentiezoekwoorden en levert een lijst met adressen en fragmenten.
- Ophaalstap — haalt de laatste vier rapporten uit een kennisbank om de uitgangscontext vast te leggen.
- Samenvattingsstap (LLM) — destilleert de zoekresultaten tot gestructureerde bevindingen: nieuwe functies, prijswijzigingen, opvallende aankondigingen.
- Schrijfstap (LLM) — schrijft een beknopte interne notitie in een consistente huisstijl, verankerd in de samengevatte bevindingen.
- Afleverstap — publiceert de notitie naar een geconfigureerd webhook-eindpunt.
De graaf heeft een natuurlijke afhankelijkheid: stap 3 hangt af van 1 en 2 (die parallel kunnen draaien), stap 4 van 3, stap 5 van 4. De uitvoerder doet dit zonder enige expliciete parallellisme-instelling: hij leest de randen.