AI-zijbalken, agentgestuurde browsers, cloudgeïsoleerde browsers en browsers met omgevingsbeheer lossen heel verschillende problemen op. Bepaal vóór je kiest of je vooral begrip, uitvoering of schaalbare orkestratie nodig hebt.
De term AI-browser wordt tegenwoordig erg breed gebruikt. Een browser met een chatvenster kan een AI-browser worden genoemd, maar ook een browseromgeving die door software als planbare resource wordt aangestuurd.
De naam is hetzelfde, maar de problemen die worden opgelost verschillen sterk. In plaats van producten één voor één te bekijken, is het duidelijker om vier vormen te onderscheiden en per vorm te bekijken wat die kan en waar de grens ligt.
Zijbalkassistent: begrijpt de pagina, maar bedient de pagina niet
Deze vorm voegt een vaste zijbalk of een vast paneel toe naast een gewone browser. De assistent kan lange artikelen, wetenschappelijke papers en zelfs PDF’s van honderden pagina’s samenvatten; vragen beantwoorden op basis van de pagina die je bekijkt; e-mails en weekrapporten schrijven; vertalen en herschrijven; en toon en lengte aanpassen. Sommige tools kunnen ook afbeeldingen analyseren na een upload of rechtstreeks via spraak communiceren.
In wezen wordt de AI-assistent naast de pagina geplaatst, zodat kopiëren en plakken naar een aparte chat niet meer nodig is. Voor het ordenen van materiaal, onderzoek naar onderwerpen en schrijfhulp is dit vaak al voldoende.
De beperking is net zo duidelijk: de assistent begrijpt de inhoud, maar bestuurt de website niet. Hij kan een grote hoeveelheid materiaal voor je ordenen, maar niet namens jou klikken, velden invullen en verzenden. Dit is een lees- en verwerkingslaag, geen uitvoeringslaag.
Agentgestuurd: kan zelf handelen, maar is het meest geschikt voor één taak tegelijk
Dit type gaat een stap verder. Je geeft in natuurlijke taal een opdracht en de agent voert zelf meerdere stappen uit: scrollen, op knoppen klikken, formulieren invullen en informatie vergelijken tussen meerdere geopende tabbladen. Het belangrijkste is begrip van de pagina. De agent moet zelf herkennen wat een invoerveld is en welke knop verzendt, in plaats van te vertrouwen op vooraf geschreven selectors. Als de paginastructuur verandert en een selector niet meer werkt, kan de agent dus nog steeds proberen door te gaan.
Er zijn drie belangrijke beperkingen. Handelingen rond betalingen, bankzaken of privacy worden doorgaans gepauzeerd en vereisen handmatige bevestiging; dat is een bewuste veiligheidsgrens, geen fout. Op complexe sites met veel aangepaste componenten kan de agent nog steeds fouten maken. Daarnaast wordt vaak vergeten dat dit type voor interactie met één gebruiker is ontworpen, niet voor hoge gelijktijdigheid. Eén taak tegelijk is het normale werkritme.
Dit past bij personen die complexe maar weinig voorkomende webtaken uitvoeren.
Cloudisolatie: de browser draait op afstand, maar voelt lokaal aan
Bij dit type draait het browserproces niet op je eigen machine; het lokale apparaat verzorgt vooral de interactie. Daardoor kun je dezelfde omgeving vanaf verschillende apparaten openen, terwijl sessies en aanmeldstatus in de cloud blijven staan en niet op elke machine opnieuw hoeven te worden ingesteld. Je kunt snapshots maken en terugrollen, een problematische omgeving herstellen naar de laatste werkende toestand en voorkomen dat gegevens lokaal achterblijven. Dat is praktisch voor teams die niet met vaste apparaten werken of bedrijfsgegevens niet over meerdere endpoints willen verspreiden.
De nadelen komen eveneens uit de cloud. Netwerkverkeer heen en terug veroorzaakt vertraging, waardoor de interactie minder direct aanvoelt dan lokaal. Naarmate het aantal omgevingen groeit, stijgen de kosten voor cloudresources mee. Toegang tot lokale bestanden, lokale hardware en interne netwerksystemen is beperkter dan bij een lokale browser. Bovendien verplaatst de cloud alleen de machine: de verdeling van netwerkuitgangen en de beheersing van gelijktijdigheid tussen meerdere omgevingen moeten nog steeds worden gepland.
Browser met omgevingsbeheer: de laag voor software-orkestratie
Dit type is niet in de eerste plaats een browser voor mensen, maar een omgevingsresource die door software kan worden ingepland en aangestuurd.
Het kan in batches onafhankelijke omgevingen maken, elk met een eigen fingerprint, cookies en lokale opslag; via interfaces omgevingen aanmaken, opvragen, starten, stoppen en recyclen; per omgeving een afzonderlijke netwerkuitgang koppelen; en integreren met gangbare automatiseringsframeworks voor programmatische besturing. Het doel is van browseromgevingen planbare, geïsoleerde en beheerbare infrastructuur te maken.
Daarmee wordt een heel ander probleem opgelost. Wanneer een workload van 1 naar 100 taken groeit, kunnen de eerdere benaderingen tegelijk tekortschieten: één gebruiker, één venster en één taak tegelijk ondersteunen geen batchwerk; omgevingen beïnvloeden elkaar; taken zitten elkaar in de weg; en accounts kunnen als één groep worden gezien. Op dit niveau biedt PurpleMark isolatie en centraal beheer van browseromgevingen, zodat elke taak in zijn eigen omgeving draait.
De beperking is dat het geen beslissingen voor je neemt en geen regels van platforms verandert. Of een taak aan de regels voldoet, wordt nog steeds door de taak zelf bepaald.
Hoe kies je?
De volgorde is eenvoudig: redeneer terug vanuit je werkelijke behoefte.
- Heb je AI alleen nodig om webpagina’s beter te begrijpen, dan is het eerste type voldoende; betaal niet extra voor uitvoeringsmogelijkheden die je niet nodig hebt.
- Moet AI eenmalig een complexe handeling voor je uitvoeren, dan past het tweede type.
- Wil je gegevens niet lokaal bewaren en op meerdere apparaten kunnen doorgaan, dan sluit het derde type beter aan.
- Moeten geautomatiseerde taken stabiel, in batches en zonder onderlinge verstoring draaien, dan heb je ongeacht de gebruikte AI-capaciteit uit de eerdere typen ook de vierde laag nodig.
Dat laatste punt verdient extra aandacht. AI bepaalt wat er moet gebeuren; de browseromgeving bepaalt onder welke identiteit dat gebeurt. Als die identiteitslaag instabiel is, lijken fouten willekeurig terwijl de oorzaak in de omgeving ligt. Veel teams worden eerst aangetrokken door het idee van een AI-browser en kopen een tool die vooral op begrip is gericht, om later te ontdekken dat hun echte behoefte batchuitvoering was. Als de richting verkeerd is gekozen, kan zelfs een goede tool dat verschil niet opvangen.
Bepaal dus eerst of je een assistent of uitvoering nodig hebt en kijk daarna naar schaal. Bouw vóór opschaling de omgevingslaag op en test het proces met een klein aantal taken. Daarna uitbreiden is veel eenvoudiger dan achteraf een reeks onderling verbonden accounts opruimen.
