Live browserbediening is een runtime-mogelijkheid en is nog niet op iedere Hands-omgeving beschikbaar. Als jouw Hand deze mogelijkheid heeft, kan de browser een extra route zijn voor werk dat niet via een gestructureerde App-koppeling beschikbaar is.
Een goede koppeling is meestal de beste plek om te beginnen. Een Plug-in kan je Hand een vooraf ingerichte providerverbinding geven. Een Connector kan een set MCP-tools aanbieden. Een API kan voorspelbare acties en gestructureerde data beschikbaar maken. Deze routes zijn snel, duidelijk en beter te overzien dan rondklikken op een website.
Maar een koppeling kan alleen aanbieden waarvoor hij gebouwd is. De website erachter kan nog een extra instelling, formulier, workflow of beheerscherm hebben dat niet via de gekoppelde tools beschikbaar is.
Waarom Apps nog steeds eerst komen
De browser is geen vervanging voor Apps. Hij is de nuttige tweede route als de gestructureerde route zijn grens bereikt.
Gestructureerde tools zijn meestal de schoonste route om data te lezen of een ondersteunde actie uit te voeren.
Een Hand met browserbediening kan met dezelfde interface werken als een mens, in plaats van te doen alsof een ontbrekende API-actie wel bestaat.
Daardoor verandert een belangrijke vraag. In plaats van “heeft deze dienst voor werkelijk alles een API?” kun je vragen: “wat is voor deze stap de beste route?” Soms is dat de Connector. Soms de Plug-in. En soms gewoon de website zelf.
Waar de browser helpt
Als live browserbediening is ingeschakeld, kan de statuskaart de browser van de Hand tonen terwijl hij werkt. Je kunt de voorgrondpagina volgen en de Hand kan als onderdeel van de opdracht pagina’s openen, op knoppen klikken en gewone velden invullen.
Dat maakt de browser vooral nuttig voor het lange staartje aan werkzaamheden: die ene instelling diep in een dashboard, een configuratiescherm zonder passende API-actie, een providerflow die sneller verandert dan een integratie, of een taak die door meerdere pagina’s van een webapplicatie loopt.
“Controleer of deze instelling in het providerdashboard bestaat. Als de Connector hem niet kan wijzigen, open dan de website en ga daar verder. Vraag mij alleen om over te nemen als je bij een login of een andere stap komt die ik zelf moet uitvoeren.”
Hoe de login-handoff werkt
Bij inloggen moet browserautomatisering een samenwerking worden in plaats van een oefening in wachtwoorden delen. Als de pagina jouw credentials nodig heeft, kan de Hand een Take control-handoff starten. Jij krijgt de browser, logt rechtstreeks op de website in en gebruikt daarna Give back wanneer je klaar bent.
Jij geeft hem terugDe Hand kan verder vanuit de ingelogde browserstatus.Tijdens een credential-handoff mag de Hand de browser niet bedienen, uitlezen of screenshots maken. Je hoeft dus nooit een wachtwoord in het gesprek te plakken alleen om het werk door te laten gaan.
Een praktisch voorbeeld
Stel dat je een instelling bij een SaaS-provider wilt wijzigen. De Connector laat je Hand het account uitlezen en een aantal veelgebruikte objecten beheren, maar deze specifieke instelling bestaat alleen in het webdashboard.
- Eerst controleert de Hand de gestructureerde route. Bestaat de juiste tool, dan gebruikt hij die.
- Ontbreekt de tool, dan kan hij naar de website. De taak hoeft niet te stoppen omdat het API-oppervlak kleiner is dan de productinterface.
- Vraagt de website om inloggen, dan neem jij over. Jij authenticeert rechtstreeks bij de provider.
- Daarna geef je de browser terug. De Hand kan de ingelogde pagina weer bekijken en de gevraagde workflow vervolgen.
Het interessante is niet alleen dat “AI op knoppen kan klikken”. Het interessante is continuïteit: het werk kan bewegen tussen gestructureerde tools, een menselijk authenticatiemoment en de grafische interface zonder dat jij de hele opdracht opnieuw hoeft te starten.
Wat de browser niet verandert
Een browser is geen manier om rechten te omzeilen. De Hand kan alleen werken met wat het ingelogde account en de website zelf toestaan. Providerregels, accountrechten, bevestigingen en beveiligingscontroles blijven gewoon gelden.
Het is ook niet altijd de beste route. Als er een veilige, gestructureerde App-actie bestaat, heeft die meestal de voorkeur. Browserinterfaces kunnen veranderen en sommige ingrijpende acties horen nog steeds te pauzeren voor jouw beoordeling in plaats van als routineklik te worden behandeld.
En omdat browserbediening van de runtime afhangt, moet je er vandaag niet vanuit gaan dat iedere Hand deze mogelijkheid heeft. De interface hoort zichtbaar te maken wanneer live browserbediening beschikbaar is.
Apps geven je Hand gestructureerde tools. De browser geeft hem een route naar de delen van een website die die tools niet aanbieden. De login-handoff houdt de mens in controle over credentials. Samen zorgen die routes ervoor dat de grens van een API veel minder snel de grens van de opdracht wordt.
Begin met de schoonste route en ga daarna gewoon verder.
Gebruik Plug-ins en Connectors voor het werk dat ze goed aanbieden. Heeft je Hand live browserbediening en leeft de ontbrekende stap alleen in de website, laat de taak daar dan verdergaan — terwijl jij alleen overneemt voor de momenten die echt van jou moeten blijven.