Adaptieve procesorkestratie

Wat is adaptieve procesorkestratie?

Adaptieve procesorkestratie draait één bedrijfsproces waarin de meeste stappen vaste regels volgen en een paar stappen door een model of een agent beslist worden. De flow houdt de volgorde, de processtaat en de controles in handen. Op de plaats waar geen enkele regel het dossier kan afhandelen, roept ze een model op, geeft ze een korte lijst toegelaten uitkomsten mee en stuurt ze het dossier verder op wat er terugkomt.

Het woord adaptief slaat op één ding. Het proces kan nu een geval afwerken dat niemand op het schema getekend heeft, zonder dat een collega het moet oppikken. De rest blijft staan. De volgorde van de stappen, de goedkeuring boven een bedrag, de retry na een time-out en het spoor van wat er gebeurd is liggen nog altijd vast, en zijn voor elk dossier hetzelfde.

Camunda zet de taakverdeling in zijn architectuurgids in één zin. Het model beslist welke tool wordt opgeroepen, in welke volgorde en met welke parameters. Camunda voert de gekozen BPMN-elementen uit, bewaart de processtaat, doet de retries en de incidentafhandeling, en coördineert de menselijke taken en de rest van de vaste proceslogica.

Een vaste flow en een vrije agent falen elk op hun eigen manier

Een deterministische flow heeft één eigenschap die hem de moeite waard maakt. Microsoft beschrijft een agent flow in Copilot Studio (documentatie van juni 2026) precies zo: hij is deterministisch, volgt een pad van regels, en dezelfde input geeft altijd dezelfde output. Daarom tekent een boekhouder ervoor. Draai hetzelfde dossier twee keer en je krijgt dezelfde stappen, dezelfde bedragen en hetzelfde spoor.

Diezelfde eigenschap is meteen de grens. Elke aftakking op het schema is getekend door iemand die het geval op voorhand bedacht heeft. De leverancier die het nummer van de creditnota in het onderwerp zet in plaats van in de mail zelf, de klant die één artikel uit een bestelling van drie terugstuurt en er een paragraaf uitleg bij schrijft: die belanden in een uitzonderingswachtrij, en een medewerker werkt die wachtrij af.

Een agent krijgt zo'n geval wel afgehandeld. Wat je inlevert, is herhaalbaarheid. Het artikel over non-determinisme in LLM-output legt uit waar die variatie vandaan komt, en kort gezegd samplet het model zijn output in plaats van hem op te zoeken, zodat hetzelfde dossier morgen een andere volgorde van tool calls kan opleveren, een andere formulering en soms een ander antwoord.

De vaste ruggengraat en de beoordelingsstap

De opstelling die het in productie uithoudt, houdt de ruggengraat van het proces deterministisch en zet het oordeel in afgebakende stappen.

Wat de flow zelf blijft doen

De flow bepaalt welke stap volgt en bewaart de staat van het dossier: het dossiernummer, de variabelen, de actieve stap en hoelang die al bezig is. Ze voert de controles uit, dus de goedkeuring boven een bedrag, de functiescheiding tussen wie aanvraagt en wie goedkeurt, en de deadline die escaleert zitten in het procesmodel en niet in een prompt. Ze is ook eigenaar van elke schrijfactie naar een bronsysteem en van het herstel: de retry na een time-out, de timer die drie dagen op een antwoord wacht, de compensatiestap als er later iets misgaat.

Wat een afgebakende beoordelingsstap moet vastleggen

Een beoordelingsstap is meer dan een vakje met "roep hier het model op". Het is een stap met een contract, en dat contract heeft vier delen.

1. Een afgebakende input. Benoem de velden die het model krijgt: de bestellijn, de retourreden, de leverdatum, de eerdere retours van deze klant. Het volledige dossierobject doorgeven maakt de stap onmogelijk om te testen en zet gegevens in de prompt die daar niets te zoeken hebben.

2. Een gesloten lijst uitkomsten. De stap geeft één waarde terug uit een korte lijst, bijvoorbeeld aanvaarden, weigeren of doorgeven aan een mens, met een geschreven motivering erbij. In UiPath Maestro staat een agent in het proces als een service task waarvan de uitvoerparameters op procesvariabelen gezet worden, en de volgende gateway stuurt daarop. Een antwoord buiten de lijst is een fout die de flow afhandelt, geen vierde uitkomst.

3. Een weigeringspad. Het model moet kunnen zeggen dat het dit geval niet kan beslissen, en dat antwoord heeft een eigen route nodig. De ontwerpgids van Camunda is daar duidelijk over: geef een agent altijd een escalatiepad naar een mens, en laat een betrouwbaarheidsscore niet alleen bepalen wanneer dat pad genomen wordt.

4. Een budget en een vaste terugvaloptie. De stap krijgt een plafond op hoeveel werk ze mag doen en een vastgelegde route wanneer ze dat plafond raakt. Het AI-agentsubproces van Camunda begrenst het aantal modelaanroepen, zet die limiet standaard op 10 als je zelf niets invult, en gooit de foutcode MAXIMUM_NUMBER_OF_MODEL_CALLS_REACHED zodra de agent erover gaat. Die vang je op met een error boundary event en stuur je langs hetzelfde pad als een weigering.

Schrijf het contract op voor je de prompt schrijft. Die prompt verandert in een jaar tien keer. Het contract is waar de rest van het proces tegen gebouwd is.

Een retouraanvraag met drie vaste stappen en één beoordelingsstap

Een webshop verwerkt ongeveer 900 retouraanvragen per maand. Het retourbeleid loopt 30 dagen. Zo'n 130 aanvragen komen na dag 30 binnen met een geschreven reden erbij, en tot nu las een medewerker van de klantendienst ze stuk voor stuk na.

1. Vast: toets de aanvraag aan de bestelling. Zoek de bestellijn, de leverdatum en het bedrag op. Binnen 30 dagen en ongeopend aanvaardt de flow de retour zonder dat er ook maar één model aan te pas komt. Boven 250 euro gaat het dossier naar een mens, wat er verder ook in staat.

2. Beoordelingsstap: beslis over de late aanvraag. Het model krijgt zes velden: het artikel, het bedrag, het aantal dagen sinds levering, de geschreven reden van de klant, het aantal retours van deze klant in twaalf maanden, en of het artikel op de uitsluitingslijst staat. Het geeft aanvaarden, weigeren of doorgeven terug met één paragraaf motivering, en het heeft geen toegang tot het ERP. Een paar schoenen dat op dag 38 terugkomt omdat de rits stuk ging, van een klant zonder eerdere retours, komt terug als aanvaarden met die reden in het dossier.

3. Vast: maak de creditnota. Bij aanvaarden boekt de flow een creditnota tegen de oorspronkelijke bestellijn. Eén artikel van 89 euro geeft 89 euro, want het bedrag komt uit de bestelling en nooit uit het model.

4. Vast: antwoord de klant. De flow stuurt de beslissing door en boekt bij aanvaarden het retourlabel.

De terugvaloptie telt zwaarder dan het vlotte scenario. Geeft het model iets terug buiten de drie uitkomsten, loopt het in een time-out of gaat het over zijn aanroepbudget, dan zet het error boundary event op de stap het dossier in dezelfde wachtrij van de klantendienst waar het vroeger ook belandde, met de dossiergegevens en de halve motivering erbij. Er gaat niets verloren en er wordt niets per ongeluk aanvaard. Een stap die faalt mag je de automatisering kosten, nooit het dossier.

Wat je achteraf kan aantonen

Een flow met een beoordelingsstap tegenover een agent die het hele proces stuurt

Beide opstellingen kunnen tot een juiste uitkomst komen. Ze verschillen in wat je een maand later kan tonen, wanneer de financiële dienst vraagt hoe één bepaald dossier behandeld is.

• Welke stappen liepen, en in welke volgorde. Met een beoordelingsstap is dat voor elk dossier dezelfde getekende volgorde. Met een agent die het proces stuurt wordt het pad tijdens de run gekozen en verschilt het per dossier.

• Waar de beslissing viel. Met een beoordelingsstap zit ze in één benoemde stap, met de input en de uitkomst ernaast. Met een agent kan ze overal in de run zitten, tussen de tool calls door.

• Wat er liep voor het geld bewoog. Met een beoordelingsstap is dat een getekende controle die de proceseigenaar kan aanwijzen. Met een agent is het wat de agent die keer beslist heeft na te kijken.

Het eerste antwoord van elk paar komt uit een procesmodel dat al bestond voor het dossier bestond. Het tweede komt uit een transcript dat pas achteraf bestaat, en daarom blijft alles wat met geld te maken heeft, een betaling of een creditnota, aan de deterministische kant staan. Een proces dat een agent stuurt heeft na een crash ook geen vastgelegde stappenlijst om op te hervatten, en dat is net wat durable execution oplost door elke afgewerkte stap in een log te schrijven.

Wat er in het dossier moet staan

Een beoordelingsstap moet meer opschrijven dan "goedgekeurd". Per aanroep hou je vier dingen bij.

• Welk model geantwoord heeft. De OpenTelemetry-conventies voor AI-aanroepen houden het model dat je vroeg, gen_ai.request.model, apart van het model dat antwoordde, gen_ai.response.model, en die twee zijn niet altijd hetzelfde zodra een provider verkeer verlegt of een versie uitfaseert.

• Wat het meekreeg en wat het teruggaf: de invoervelden, de uitkomst, de geschreven motivering, de tools die het opriep, en gen_ai.response.finish_reasons, dat zegt of het model zelf gestopt is of afgekapt werd.

• Welke versie van de stap zelf actief was: de prompt, de lijst tools en de lijst toegelaten uitkomsten die op dat moment golden. Een wijziging aan één daarvan is een release, en het dossier moet zeggen welke release beslist heeft.

• Wie de uitkomst mocht overrulen, en of iemand dat gedaan heeft.

De inhoud van prompts en tool-argumenten wordt in de OpenTelemetry-conventies standaard niet bijgehouden, precies omdat er klantgegevens in kunnen zitten. Ze toch loggen is dus een bewuste keuze met een bewaartermijn eraan vast.

Testen en opvolgen als één stap niet herhaalbaar is

Een regressietest legt één juist antwoord vast. Dat werkt voor de vaste stappen en valt uit elkaar bij de beoordelingsstap, want een run van morgen kan langs een andere weg bij een verdedigbare uitkomst raken. Wat je in de plaats vastlegt, is een eigenschap die moet kloppen wat het model ook zegt.

Property-based testing doet dat al jaren buiten AI. De documentatie van Hypothesis, de Python-bibliotheek daarvoor, geeft het voorbeeld dat elke financiële medewerker herkent: een reeks transacties in een financieel systeem klopt altijd, er gaat nooit geld verloren. Je controleert niet dat één transactie één bepaalde lijn opleverde. Je controleert de boeken.

Voor het retourproces zien die invarianten er zo uit.

• Elk dossier bereikt een eindtoestand, en geen enkel dossier blijft langer dan een dag in de beoordelingsstap hangen.

• Het totaal van de creditnota is gelijk aan het totaal van de aanvaarde bestellijn. Het model verschuift nooit een bedrag.

• Geen enkele bestellijn wordt twee keer gecrediteerd, hoe vaak de stap er ook op gedraaid heeft.

• Geen enkel dossier boven 250 euro sluit zonder een menselijke taak in zijn geschiedenis.

• Elke geregistreerde uitkomst is één van de drie toegelaten waarden.

Draai die eerst op historische dossiers die je opnieuw door het proces stuurt, en daarna op live verkeer. Een invariant die breekt is een bug waar je iets mee kan doen, wat het model op dat moment ook aan het redeneren was.

Het oordeel zelf heeft een tweede mechanisme nodig, want geen enkele invariant zegt je of aanvaarden de juiste beslissing was. Neem er een steekproef van. Trek elke week een vast aantal beslissingen uit de stap, laat de proceseigenaar elk geval juist of fout aanduiden, en volg dat percentage over de tijd. Kijk er de verdeling naast: het aandeel aanvaarden, weigeren en doorgeven per week, en hoe vaak de terugvaloptie afging. Beweegt die verdeling terwijl het proces niet veranderde, dan is er iets anders veranderd. Meestal is dat een nieuwe modelversie bij de provider, of een andere manier waarop klanten hun aanvraag schrijven.

Die twee cijfers horen op dezelfde pagina als de doorlooptijd en de kost per dossier. Een beoordelingsstap die goedkoper wordt door meer dossiers verkeerd te beslissen is geen vooruitgang, en alleen de steekproef vertelt je welke van de twee je hebt.

Waar moet je op letten bij adaptieve procesorkestratie

Je flow moet niet vervangen worden. De bruikbare versie hiervan voor een kleiner bedrijf is smal. Zoek de stap of twee waar een collega vandaag iets leest en beslist, en zet daar een beoordelingsstap. De twintig andere stappen blijven exact zoals ze zijn. De stap die je best ombouwt, is die met de langste wachtrij ervoor en een beslissing die een collega in twee zinnen kan uitleggen.

Laat de betrouwbaarheidsscore niet bepalen wie een menselijke taak krijgt. Het bedrag, de klant en de juridische blootstelling bepalen dat, in het procesmodel waar de eigenaar de drempels ziet staan en ze kan aanpassen. Een zelfzeker model op een dossier van 50.000 euro blijft een dossier van 50.000 euro.

Hou het model uit het bronsysteem. Het leest, het beslist, het schrijft een motivering. De flow doet de boeking. Zodra een model zelf in het ERP schrijft, verlies je waar de hele opstelling voor diende: één vast antwoord op de vraag wat er met het geld gebeurd is.