Belangrijkste Takeaways

• Verschuiving van Vraag naar Executie: Echte agentic automation gaat verder dan het beantwoorden van vragen; het voert multi-step operationele taken uit binnen complexe enterprise software-ecosystemen.
• Single-Responsibility Architecture: Robuuste multi-agent systemen vereisen het chainen van specifieke, single-purpose agents met gestructureerde schema-handoffs, in plaats van te vertrouwen op monolithische LLM-prompts.
• Human-in-the-Loop Waarborgen: Niet-onderhandelbare architectonische grenzen garanderen menselijke verantwoordelijkheid voor elke actie met externe of financiële gevolgen.
• Gestandaardiseerde Protocol-integratie: Het benutten van open standaarden zoals het Model Context Protocol (MCP) maakt snelle integratie met CRM's, VoIP-systemen en ERP's mogelijk, zonder de bottlenecks van custom code.
• Native Compliance Engineering: Enterprise AI-operations in Nederland vereisen dat GDPR, scoped access control en gedetailleerde per-step audit logging vanaf dag één zijn ingebed in de pipeline-architectuur.

Ik schreef al eerder over hoe AI deel werd van onze business via compliance, en niet via een AI-mandaat. Dit is het vervolg daarop: wat er gebeurde toen we agents multi-step acties lieten uitvoeren binnen onze eigen systemen, in plaats van ze er alleen vragen over te laten beantwoorden.

Er is een wezenlijk verschil tussen die twee. Een agent die een scoping-vraag beantwoordt op basis van documentatie, informeert een beslissing die een mens uiteindelijk nog steeds neemt. Een agent die data uit het ene systeem haalt, deze kruislings controleert aan de hand van regels en een gestructureerde set aanbevelingen oplevert waar een mens mee aan de slag kan, doet iets wat veel dichter bij echt werk ligt. Die tweede categorie is wat ik bedoel met agentic workflow automation, en dat is waar we het meeste van hebben geleerd – te beginnen bij onze eigen operations.

Waar we daadwerkelijk zijn begonnen: ons eigen delivery-proces

Voordat we aan een klantgerichte workflow kwamen, veranderden we de manier waarop we intern delivery aansturen. We stapten over op een meer gestructureerde, agent-gestuurde manier van software bouwen. Dat was een flinke aanpassing, niet een knop die we zomaar omzetten. Maar het gaf ons wel het vertrouwen én het interne bewijs om dit aan klanten aan te bieden, in plaats van het puur vanuit de theorie te pitchen.

Het duidelijkste voorbeeld van hoe dat er in de praktijk uitziet, was allesbehalve glamoureus. Het was onze eigen CRM.

De Pipedrive-audit: een echte multi-step agentic workflow, toegepast op onze eigen chaos

We hadden onze Pipedrive-pipeline jarenlang op zijn beloop gelaten: 423 openstaande deals, 87 procent van de waarde geparkeerd in een fase zonder duidelijke exit-criteria, en kansen ingeschat op basis van onderbuikgevoel. Dit handmatig opschonen zou betekenen dat iemand dagenlang bezig zou zijn met het handmatig controleren van deal-leeftijd, activiteitslogs, fase en waarschijnlijkheid, deal voor deal.

In plaats daarvan trok een agent de volledige export leeg, paste een consistente set regels toe op elke deal en leverde een gestructureerd rapport op: 360 van de 423 deals werden als 'stale' gemarkeerd, 43 deals hadden een te optimistische waarschijnlijkheid in verhouding tot hun werkelijke fase en activiteit, en 50 deals voldeden aan een duidelijke "dead"-drempel – goed voor zo'n €1,68 miljoen aan pipeline-waarde die realistisch gezien geen kans van slagen meer had. Het kostte een fractie van de tijd van een handmatige audit, en er werd niets over het hoofd gezien dat bij een handmatige controle wel opgevallen zou zijn.

De agent deed het multi-step, cross-referencing werk door gebruik te maken van business process automation. Een mens besliste nog steeds wat er met elke geflagde deal moest gebeuren. Niets werd automatisch als Lost gemarkeerd.

Dat laatste punt is belangrijker dan de snelheid. Op het moment dat een agent multi-step acties uitvoert binnen je systemen, is de vraag niet alleen "levert dit tijdwinst op?", maar vooral "wie is er verantwoordelijk voor wat er verandert?". Het scheiden van de aanbeveling en de uiteindelijke beslissing is geen beperking waar we omheen werken. Het is de kern van het design.

Het grotere geheel: één operationeel overzicht, geen vier losstaande tools

De Pipedrive-audit was slechts de eerste stap, niet het hele plaatje. We koppelden Xero, Harvest en ClickUp aan hetzelfde overzicht, zodat financiële data, urenregistratie, delivery-status en pipeline-gezondheid niet langer verspreid waren over vier afzonderlijke tools die niemand handmatig met elkaar vergeleek.

Het duidelijkste bewijs dat dit echt iets veranderde: onze MT-meetings beginnen er nu mee, in plaats van dat iemand de status van het bedrijf uit het hoofd en met vier open tabbladen moet reconstrueren. Cashpositie, gelogde uren op actieve delivery, deal-bewegingen en account-gezondheid, allemaal in één overzicht, nog voordat het gesprek begint. Beslissingen die voorheen moesten wachten tot iemand de cijfers had verzameld, worden nu direct in de meeting genomen, omdat de cijfers er al staan.

Het brengt ook zaken sneller aan het licht die voorheen pas laat opvielen: een project dat over zijn gelogde uren heen gaat nog voordat de factuur dat laat zien, een deal die als "closing soon" staat gemarkeerd maar al maanden niet is bewogen, of vastgelegd geld tegenover crediteuren dat nog door niemand was opgemerkt.

Geen van deze punten is op zichzelf spectaculair. Maar door ze consistent op te vangen, weken eerder dan ze anders aan het licht zouden zijn gekomen, tellen ze op tot een bedrijf dat stuurt op wat er daadwerkelijk gebeurt, in plaats van op wat iemand zich herinnert.

Dit naar onze klanten brengen

De reden dat dit in een blogpost thuishoort en niet in een interne memo, is dat we ditzelfde type systemen nu ook voor klanten bouwen, en niet alleen voor onszelf. We breiden dit werk uit naar ons portfolio van klantprojecten.

Voor een langdurige klant gevestigd in Rotterdam hebben we een agentic workflow ontworpen die direct in hun callcenter is ingebouwd. Het koppelt met hun VoIP-software, haalt de gegevens van de beller op zodra het nummer wordt herkend, en luistert live mee met het gesprek. Hierdoor blijft de relevante account- en casushistorie gedurende het hele gesprek op het scherm staan, in plaats van dat de agent hier tijdens het gesprek naar moet zoeken.

Het helpt bij het in real-time opstellen van reacties, stelt de juiste SOP voor op basis van de eigen templates van het bedrijf en de casushistorie van de beller, en logt de volledige interactie automatisch zodra het gesprek eindigt. Werk dat voorheen afhing van iemands geheugen voor het juiste template en een zoektocht door oude tickets, staat nu direct voor hun neus nog voordat ze erom hoeven te vragen. Dit toont de impact aan van AI-integratie in softwaresystemen.

Voor een andere klant in Rotterdam, waar de implementatie nog volop bezig is, hebben we lead generation gebouwd als een chain van agents in plaats van één enkele tool. De eerste agent haalt prospectdata uit meerdere bronnen. Een tweede verrijkt en verifieert deze data. Een derde doet onderzoek naar recent nieuws over elke lead, zodat de outreach gebaseerd is op actuele gebeurtenissen in plaats van een generiek template. Een sequencer stelt vervolgens het outreach-bericht voor (via InMail of e-mail), leest de binnenkomende reacties, beoordeelt wat voor type reactie het is en stelt op basis daarvan het volgende bericht voor.

Wat voorheen betekende dat een medewerker verschillende losse zoekopdrachten moest doen voordat hij één bericht kon schrijven, is nu een chain van agents die het zoekwerk doet, waarbij een mens nog steeds goedkeurt wat er daadwerkelijk wordt verzonden.

Beide zijn live trajecten, nog geen case studies met een strak voor-en-na-verhaal. Ik beschrijf ze liever eerlijk als work in progress, dan dat ik er cijfers aan hang voordat we echte resultaten kunnen rapporteren.

Hoe deze agents daadwerkelijk zijn opgebouwd

Alles hierboven beschrijft wat deze systemen doen. Voor degene aan jouw kant die akkoord moet geven op het 'hoe', is het de moeite waard om specifiek te zijn over de architectuur. Want "we hebben AI toegevoegd" en "we hebben een agentic workflow gebouwd" zijn absoluut niet dezelfde beweringen.

Eén agent per taak, niet één agent die alles doet.

De lead generation pipeline bestaat uit vier afzonderlijke agents, niet uit één grote prompt die in één keer probeert te sourcen, verifiëren, onderzoeken en outreach te schrijven. Sourcing, verrijking, nieuwsonderzoek en het opstellen van berichten draaien elk als een aparte agent met een specifieke, helder gedefinieerde taak en eigen toegang tot tools.

Een enkele agent die al deze vier taken moet uitvoeren, heeft de neiging om steken te laten vallen, stappen stilletjes over te slaan of ze in elkaar te laten overlopen. Een chain van specifieke agents, die elk een gestructureerd resultaat doorgeven aan de volgende, is per stap misschien iets langzamer, maar over de hele linie aanzienlijk betrouwbaarder. Bovendien is het veel makkelijker te debuggen als één schakel een slecht resultaat oplevert.

Gestructureerde handoffs, geen platte tekst tussen stappen.

Elke agent in de chain levert data op basis van een gedefinieerd schema, niet als een paragraaf die de volgende agent moet interpreteren. De verrijkingsagent ontvangt van de sourcing-agent niet zoiets als "hier is wat info over deze lead", maar een vaste set velden die hij direct kan valideren.

Dit is precies wat een multi-agent pipeline onderscheidt van het aan elkaar knopen van een paar chatbot-prompts: elke handoff is een contract, en een foutieve handoff faalt direct en luidruchtig, in plaats van dat het geruisloos de volgende stap verpest.

Integratie via een standaardprotocol, geen maatwerkcode per tool.

De callcenter-workflow moet verbinding maken met het VoIP-systeem, de CRM en de documentopslag van de klant. We koppelen agents hieraan via MCP-servers in plaats van voor elk systeem op elk project een eenmalige integratie te schrijven, gebruikmakend van een schaalbare API- en microservices-architectuur.

Dit betekent dat hetzelfde connector-patroon dat vandaag een casushistorie leest, bij een volgende klant een andere CRM kan uitlezen zonder dat we alles opnieuw moeten bouwen. Dat is een belangrijke reden waarom we dit in weken in plaats van maanden kunnen realiseren.

Een gedefinieerd punt waar de agent stopt en een mens begint.

Dit is een architectonische keuze, geen simpele UI-checkbox. In de callcenter-workflow toont de agent de context en stelt een concept-reactie op; een mens verstuurt deze. In de lead generation pipeline leest en classificeert de agent een reactie en stelt vervolgens het volgende bericht voor; een mens keurt het goed voordat het via InMail of e-mail wordt verzonden.

De pipeline is zo gebouwd dat elke actie met een extern gevolg – een verzonden bericht, een gewijzigd record, een deal die als Lost wordt gemarkeerd – een tussenliggende menselijke stap vereist. Autonomie tot dat punt, een harde stop daarna, volledig in lijn met de moderne principes van enterprise AI governance.

Elke stap gelogd, niet alleen het resultaat.

De input van elke agent, de aangeroepen tools en de geproduceerde output worden afzonderlijk vastgelegd, niet alleen het eindresultaat. Dat is wat een pipeline debugbaar maakt wanneer er drie stappen dieper iets misgaat. Het is bovendien dezelfde discipline die ervoor zorgt dat dit verdedigbaar is tegenover het compliance- of security-team van een klant wanneer zij vragen wat het systeem daadwerkelijk heeft gedaan en waarom.

Compliance is geen apart gesprek, maar onderdeel van het agent-design

Elk voorbeeld in dit artikel raakt ergens aan persoonsgegevens: de stem en accounthistorie van een beller, de naam en inbox van een lead, of het activiteitslogboek van een medewerker. Dit is niet iets waar je achteraf pas over nadenkt. Het moet worden ontworpen voordat de eerste agent actief wordt, niet pas achteraf worden getoetst. Zo bedden we security en ISO-compliance vanaf dag één in.

Een aantal zaken die daadwerkelijk veranderen zodra je dit serieus neemt:

Toegang is scoped per agent, niet per project.

Omdat elke agent in een pipeline één specifieke taak heeft, heeft hij alleen de data nodig die voor die taak vereist is. De verrijkingsagent in de lead generation pipeline heeft geen toegang nodig tot de accountgegevens van het callcenter, en de callcenter-agent heeft geen toegang nodig tot de financiële velden van de CRM.

Specifieke, gerichte agents maken dit het natuurlijke resultaat van de architectuur, in plaats van een beleid dat iemand er achteraf handmatig bovenop moet afdwingen.

De juridische grondslag wordt bepaald voordat de agent wordt gebouwd, niet pas besproken na een klacht.

Een callcenter-agent die live meeluistert met een gesprek verwerkt in real-time persoonsgegevens. In Nederland betekent dit dat de beller hier consistent over geïnformeerd moet worden voordat het gesprek begint. Een lead-generation-agent die de contactgegevens van een prospect verrijkt, vertrouwt op een gerechtvaardigd belang (legitimate interest) voor B2B-outreach, wat zo zijn eigen grenzen heeft qua rechtvaardiging.

Dit pas beslissen als de pipeline al live is, is de reden dat agencies achteraf consent-flows moeten inbouwen in een systeem dat daar nooit voor ontworpen is.

De audit log uit de architectuur is direct het compliance-bewijs.

De hierboven beschreven per-step logging – welke data een agent heeft geraakt, welke tool is aangeroepen en wat het resultaat was – is exact het overzicht waar de DPO (Data Protection Officer) of een auditor van een klant om vraagt wanneer ze willen weten wat er met een specifiek persoonsgegeven is gebeurd. We onderhouden geen twee aparte systemen voor engineering en compliance.

Het is één discipline die beide doelen dient.

Het menselijke checkpoint is ook de grens van de verantwoordelijkheid.

GDPR heeft geen pasklaar antwoord op "de agent heeft dit besloten". Een persoon die het uitgaande bericht goedkeurt, of het record dat wordt gewijzigd, is ook de persoon die kan worden aangewezen als degene die de beslissing heeft genomen. En dat is cruciaal op het moment dat er wordt gevraagd wie er verantwoordelijk is voor een specifieke actie.

We hebben al eerder geschreven over hoe ISO 27001 and GDPR ons servicemodel hebben gevormd. Wat specifiek bij agentic systemen anders is, is dat compliance geen laag is die je achteraf om het systeem heen legt. Het moet een intrinsieke eigenschap zijn van hoe de pipeline is opgebouwd, agent voor agent, vanaf het allereerste begin.

Wat "het stroomlijnen van enterprise operations" echt betekent

Het betekent niet dat je de mens uit de loop haalt. In elk voorbeeld hier, zowel bij ons als bij onze klanten, neemt een mens nog steeds de beslissing waar de output van de agent naartoe leidt. Wat er verandert, is hoeveel voorbereidend werk een mens moet doen om die beslissing goed te kunnen nemen. Dat is hetzelfde argument dat ik in de vorige post maakte over capaciteit, maar nu toegepast op operations in plaats van documentatie: hetzelfde team dat meer aankan, in plaats van een kleiner team dat evenveel doet.

Voor een bedrijf in Nederland dat zich afvraagt waar te beginnen, is mijn eerlijke advies hetzelfde als bij compliance: begin met de operationele chaos die je nu al hebt, niet met de meest flitsende use case die je kunt bedenken. Wij zijn begonnen met onze eigen CRM omdat dat het dichtst bij ons lag en overduidelijk niet goed werkte. Dat is meestal waar de echte winst te behalen valt.

Stroomlijn Je Enterprise Operations

Transformeer operationele chaos in gestructureerde, compliant multi-agent workflows die specifiek zijn gebouwd voor jouw enterprise stack. Of je nu je gefragmenteerde software-ecosysteem wilt koppelen of grootschalige bedrijfsactiviteiten wilt automatiseren met human-in-the-loop verantwoordelijkheid: ons engineering-team ontwerpt oplossingen op maat die voldoen aan de Nederlandse compliance- en Europese data governance-standaarden.