AI-agenten nemen SaaS-werkzaamheden over, en weinig teams zijn er klaar voor

De meeste SaaS-uitgaven kopen je niet langer software. Ze kopen je een plek om knoppen aan te klikken die een agent sneller kan indrukken, om drie uur 's nachts, zonder dat er om een loginupgrade wordt gevraagd.

Dat klinkt vluchtig. Het wordt ook steeds vaker waar.

Multi-agent deployments groeiden 327% in de vier maanden tot Q1 2026, volgens gegevens van Andreessen Horowitz in hun State of AI-rapport. Bedrijven wachten niet af tot hun SaaS-leveranciers AI-features uitbrengen. Ze halen specifieke workflows volledig uit die platforms en herbouwen ze als custom apps met modellen in het hart. Niet omdat SaaS doodgaat. Omdat voor een aanzienlijk deel van het werk de interfacelaag het knelpunt is geworden.

Dat deel is ongeveer 20 tot 30% van het dagelijkse operationele werk, gebaseerd op workflow-audits die we hebben uitgevoerd bij klanten in logistiek, fintech en media. Het is niet al het werk. Maar het is genoeg om uit te maken op basis van kosten en snelheid. En het is het soort werk waarbij een zes maanden durende SaaS-implementatie gewoon het verkeerde gereedschap lijkt.

De workflows die het waard zijn te automatiseren zijn de saaie

Hier komt het contra-argument. De beste kandidaten voor agent-vervanging zijn niet je meest complexe processen. Ze zijn je meest gestandaardiseerde. De dingen die zo routineus zijn dat je team er nauwelijks over nadenkt, maar toch uren per week opslokken.

Factuurafstemming. Statusupdateemails. Data van het ene dashboard naar het andere knippen. Vervolgafspraken plannen op basis van CRM-status. Deze workflows bestaan in SaaS-platforms omdat SaaS-platforms plaatsen zijn waar data leeft. Maar de cognitieve inspanning die nodig is om ze uit te voeren is bijna nul. Dat is precies wat ze agent-terrein maakt.

De valkuil. Gestandaardiseerd betekent niet eenvoudig te automatiseren. Een workflow die eruit ziet als twee stappen heeft vaak zeven edge cases die niemand heeft gedocumenteerd omdat degene die het deed het gewoon wist. Voordat je iets aan een agent overdraagt, heb je een beslisboom nodig die een nieuwe werknemer kan volgen. Als dat document niet bestaat, schrijf het eerst. Het agent-werk komt daarna.

Begin met wat je team saai vindt. Niet wat indrukwekkend klinkt in een boardupdate.

Kopen, bouwen of laten lopen

Zodra je de kandidaten in kaart hebt gebracht, is de echte keuze niet technisch. Het is architecturaal. Voor elke workflow kies je voor een van drie paden.

Kopen. Je SaaS-leverancier brengt een agent-feature uit die het geval dekt. Je configureert het, betaalt de meerprijs en gaat verder. Dit is vaker het juiste antwoord dan builders graag willen toegeven. Als HubSpot of Linear een workfloaagent uitbrengt die 80% van wat je nodig hebt doet, moet de custom build zijn waarde bewijzen tegen de lopende onderhoudskosten.

Bouwen. De workflow is specifiek genoeg voor je bedrijf dat geen kant-en-klare agent zonder flink aanpassen zal passen. Of de data leeft over systemen verspreid op een manier die geen leverancier verbindt. Dit is waar custom apps gebouwd bovenop modellen als Claude je een voordeel geven. Niet omdat custom altijd beter is, maar omdat sommige workflows echt van jou zijn.

Laten lopen. Sommige workflows die er uit zien als agent-kandidaten zijn eigenlijk oordelen in vermomming van routine. Een mens maakt telkens een klein maar echt besluit, en het automatiseren ervan heft verantwoordelijkheid op zonder complexiteit weg te nemen. Dit zijn de workflows om nu voor nu alleen te laten. Niet voor altijd. Maar totdat de beslissingslogica expliciet genoeg is om te controleren.

De valkuil bij het bouwen. de meeste teams onderschatten het onderhoudsoppervlak. Een agent die in januari werkt kan in april afdrijven als upstream datasysteemschema's veranderen. Begroting daarvoor in. Of werk met een team dat het van dag één in de architectuur inbouwt.

Toezicht is de vaardigheid, niet bediening

Hier gaat het meeste transformatieplannen mis.

Wanneer je een agent implementeert om een workflow uit te voeren, wordt de taak van je team niet kleiner. Het verschuift. Ze voeren het proces niet langer uit. Ze controleren een systeem dat het proces uitvoert, wat een volledig ander inzicht vereist.

Een tool bedienen betekent de logica volgen. Een agent controleren betekent weten wanneer de logica op het punt staat een verkeerd antwoord te geven, het tegenhouden voordat het verspreidt, en dat signaal teruggeven aan het systeem zodat het niet weer gebeurt. Dat is meer kwaliteitscontrole in een productiecontext dan software-training.

De concrete implicatie. train je team niet op hoe je de agent-interface gebruikt. Train ze op hoe tegenslag eruitziet. Welke outputs een beoordeling moeten triggeren. Welke edge cases de agent nog niet is tegengekomen. Geef ze een kort checklist en een duidelijk escalatiepad. Volg dan het checklist. De items die blijven opduiken zijn je volgende ronde verbeteringen.

Even terzijde. De teams die het hardst worstelen met agent-adoptie zijn niet de teams die automatisering weerstaan. Het zijn degenen die het de eerste twee weken volledig vertrouwen en stoppen met checken. Stel een verplichte reviewcyclus in en houd die minstens drie maanden aan.

Waarom een boutique hier sneller is dan een platform

Een SaaS-implementatie van dit soort workflow duurt meestal vijf tot zeven maanden van scoping tot go-live. Die tijdlijn bestaat om goede redenen: veranderingsmanagement, integratietests, trainingsuitrol, leverancierscoördinatie. Het is geen verspilling. Het is overhead die schaalt met organisatorische complexiteit.

Het probleem is dat de meeste workflows die het waard zijn om te automatiseren in H2 2026 organisatorisch niet complex zijn. Ze zijn technisch specifiek. De juiste aanpak is een klein, gericht project dat de systemen die je al hebt verbindt, de modellogica inpakt die je nodig hebt, en iets gebruiksklaar oplevert in weken in plaats van maanden.

Studio Hyra bouwt deze als Track B custom apps, met Claude Code als primaire engine. De architectuur is van nature lean, niet als compromis. Een klein team betekent minder handoffs. Minder handoffs betekent dat degene die het probleem scopte dezelfde persoon is die het debugt in week drie. Die continuïteit is geen luxe. Zo vermijd je de situatie waar het afgeleverde product technisch werkt maar niemand aan de kant van de klant snapt waarom.

We hebben dit proces uitgevoerd voor klanten die na een mislukte enterprise-rollout naar ons kwamen. Het verhaal is meestal hetzelfde: te veel stakeholders, te veel requirementsdocumenten, te weinig contact tussen de bouwers en de eigenlijke workflow. De oplossing is geen beter methodologie. Het is een korter pad tussen het probleem en de mensen die het oplossen.

Wat je kunt doen voor Q3

Als je een founder of operationeel leider bent die hierover nadenkt voor de tweede helft van 2026, is dit de praktische volgorde.

Eerst je meest gestandaardiseerde workflows in kaart brengen. Niet de spannende. De saaie die je team in drie zinnen kan beschrijven. Rangschik ze naar uren per week en aantal betrokken personen. Het begin van die lijst is je startpunt.

Twee, pas de kopen-bouwen-laten test op elk toe. Wees eerlijk over wat je leveranciers in de komende zes maanden gaan uitbrengen. Een roadmap-belofte is geen implementatie. Als de leveranciersfunctie vandaag niet in productie staat, behandel het als niet bestaand voor planningsdoeleinden.

Derde, voordat wat voor bouw dan ook begint, schrijf de beslissingslogica op. Elke vertakking. Elke uitzondering die iemand ooit intuïtief heeft afgehandeld. Dit document zal langer duren dan je verwacht. Het zal je ook meer tijd besparen dan welke andere enkele investering in het project ook.

Vierde, ontwerp de controlelaag voordat je de agent ontwerpt. Wie controleert de outputs? Hoe vaak? Hoe ziet een vlag eruit? Wat gebeurt er als er een afgaat? Als je die vragen niet kunt beantwoorden, ben je niet klaar om in te zetten.

Het venster om dit voor te doen voordat het de standaard wordt is niet oneindig. Het sluit morgen ook niet. Je hebt genoeg tijd om het goed te doen. Niet genoeg tijd om het twee keer te doen.