Veel enterpriseorganisaties investeren momenteel zwaar in de ontwikkeling van AI-agents om bedrijfsprocessen te automatiseren, een trend die de softwaremarkt domineert. De verschuiving van statische AI-workflows naar dynamische, procesgestuurde architectuur dwingt ontwikkelaars tot een kritische blik. Grote techbedrijven beloven software die zelfstandig taken uitvoert en systemen aan elkaar knoopt. In de praktijk lopen operationele teams echter tegen een fundamentele grens aan.
De werkvloer hanteert flexibele principes. De ingerichte AI-workflows blijken daarentegen verrassend star. Er ontstaat een pijnlijke mismatch tussen de wendbaarheid van de mens en de rigiditeit van de software. De huidige agents zijn in de kern proactief in potentie, maar passief in de praktijk. De term pro-passieve automatisering dekt waarschijnlijk het beste de lading.
Een pro-passieve agent beschikt over de technische capaciteit om autonoom beslissingen te nemen via APIs (softwarekoppelingen die systemen laten communiceren). Hij voert acties uit via het Model Context Protocol (een open standaard voor data-uitwisseling). De inrichting blijft echter deterministisch. De agent volgt een vooraf vastgesteld traject. Hij wacht passief op de juiste input of een menselijke trigger binnen dat specifieke straatje. Dit model is in feite een simpele evolutie van Robotic Process Automation (software die repetitieve computertaken automatiseert). Het is voorzien van een Large Language Model (een taalmodel getraind op tekstuele patronen) als interface. Het automatiseert de bestaande status quo. Het optimaliseert het proces zelf niet. Daarin gelooft inmiddels niemand meer.
De frictie in de praktijk
Wanneer een agile team een proces aanpast om de efficiëntie te verhogen, breekt de AI-workflow direct. De logica van de agent beweegt niet automatisch mee met de dynamiek van het team. Dit zorgt voor specifieke fricties in de IT-infrastructuur. Ontwikkelaars zijn relatief veel tijd kwijt aan het herprogrammeren en finetunen van agents wanneer bedrijfsprocessen veranderen, met een hoge onderhoudslast tot gevolg. Starre agents voeren opdrachten lineair uit. Ze vertonen een opvallende kostenblindheid. Ze maken geen afweging of een taak efficiënter of goedkoper opgelost kan worden via een kleiner, lokaal open-sourcemodel (vrij toegankelijke software waarvan de broncode openbaar is). Veel systemen leunen op externe cloudmonopolies en commerciële APIs. De organisatie verliest hierdoor de regie over de datastroom en de operationele kosten, met een sterke afhankelijkheid van derden als resultaat. Als puntje bij paaltje komt, gaat de organisatie hiermee de biedenbrug op.
Om deze starheid te doorbreken, verschuift de research and development binnen de IT-industrie van traditionele taalmodellen naar Large Process Models. Waar een taalmodel is getraind op textuele patronen en semantiek, is een LPM specifiek getraind op procesontologieën, workflowdata, business rules en event logs (digitale logboeken van systeemgebeurtenissen) afkomstig uit systemen zoals ERP en CRM. Een LPM begrijpt niet alleen de tekst van een opdracht. Het model begrijpt de architectuur en de doelstelling van een bedrijfsproces. Logisch ook.
De werking van Large Process Models (LPM)
De executiemethode verandert fundamenteel. Een traditionele agent volgt een vast stappenplan. De nextgen-agent, gedreven door Large Process Models (LPM), bepaalt de route dynamisch op basis van de context. Het model begrijpt procesafhankelijkheden, bottlenecks en bedrijfslogica, in plaats van statische definities te volgen. Een traditionele agent loopt vast als een stap afwijkt of als een parameter verandert. Het vindingrijke LPM herrouteert de taak autonoom of kiest een alternatieve tool. Waar de oude software die taken telkens op exact dezelfde manier uitvoert, analyseert het LPM de kosten en de runtime om de workflow continu te optimaliseren. Onder de streep levert dit een wezenlijk voordeel op.
Large Process Model (LPM)
Een LPM-gestuurde agent werkt met doelfuncties en een Cognitive Loop (een cyclus van observeren, oriënteren, beslissen en handelen). Het model draait continu op de achtergrond binnen een afgeschermde private infrastructuur. In plaats van te wachten op een trigger monitort het model de datastromen en event logs. Het signaleert wanneer een team de werkwijze aanpast, bijvoorbeeld door het gebruik van een nieuw CRM-veld voor compliancechecks. Wanneer de agent een taak moet uitvoeren, genereert het LPM ter plekke de meest efficiënte route. Als een externe SaaS-tool (software die als onlinedienst wordt aangeboden) of een koppeling offline is of te duur blijkt voor de omvang van de deeltaak, zoekt het LPM een alternatief pad. Het model kan indien nodig zelf een tijdelijk microscript genereren en in een afgeschermde omgeving uitvoeren om de data te verwerken. Gek genoeg werkt dit verrassend soepel.
Tegelijkertijd is er sprake van een sterk FinOps-bewustzijn (het beheersen van operationele kosten binnen de cloud). Het LPM berekent de computationele en financiële kosten van de operatie. Voor een eenvoudige datatransformatie zal het model een lokaal, lichtgewicht open-source model aanroepen. Het bewaart de zwaardere, duurdere redenering voor complexe compliancevraagstukken. Het bouwen van starre, pro-passieve agents lost op de lange termijn geen efficiëntievraagstukken op. Het ontwerpen van flexibele, soevereine architectuur is noodzakelijk om legacysoftware te voorkomen. Is uw organisatie al klaar om de hardgecodeerde scripts los te laten voor een adaptieve procespartner?
Bronnen