Vercel présente agent-browser, un accès léger au navigateur pour les agents IA, sans MCP

Vercel a lancé agent-browser, un outil qui donne aux agents IA un accès au navigateur sans les lourdes couches de MCP. L'idée est simple : montrer au modèle non pas tout le DOM de la page, mais une courte liste d'éléments interactifs avec lesquels il peut travailler immédiatement.

Pourquoi MCP cale

Playwright et Puppeteer ne disparaissent pas : ce sont des outils solides pour les tests e2e, le CI/CD et le scraping prévisible. Les problèmes commencent dès qu'on tente de confier le navigateur à un LLM via MCP.

Pour savoir où cliquer, le modèle doit voir la page. En général, on envoie dans le contexte soit du HTML brut, soit un arbre d'accessibilité. Sur les SPA modernes, cela se traduit vite par des milliers de tokens superflus à chaque étape et engloutit la mémoire de l'agent avant même qu'il atteigne son but.

Selon les données citées par l'auteur de l'analyse, un seul clic et un snapshot d'une page complexe peuvent coûter de 15 à 200 mille tokens par étape. C'est non seulement cher, mais aussi instable : le modèle dépense son contexte à lire l'arbre de la page, s'embrouille dans les sélecteurs CSS et rate plus souvent les bons boutons. Pour des scénarios déterministes, cette approche reste tolérable, mais pour un agent autonome qui doit s'orienter vite sur le web, elle est trop lourde.

Ce qu'a fait Vercel

Le besoin de Vercel était pratique : si un agent écrit lui-même une interface, il doit pouvoir ouvrir une page, vérifier un composant et exécuter des actions de base dans le navigateur. Pour cela, l'équipe a simplifié agent-browser et supprimé l'ancienne dépendance à un démon Node.

La version actuelle est un CLI léger en Rust, qui dialogue directement avec le Chrome DevTools Protocol. Résultat : l'outil est plus simple à lancer en local, plus commode à placer dans des conteneurs et n'oblige pas à embarquer une infrastructure Node supplémentaire.

• un binaire unique en Rust
• communication directe avec CDP, sans couches inutiles
• zéro dépendance pour Docker et les environnements locaux
• références courtes à la place du DOM complet

L'idée clé est le snapshot des éléments interactifs. Au lieu d'un arbre gigantesque, l'agent reçoit une liste compacte comme button "Sign In" [ref=e1] ou textbox "Email" [ref=e2], puis travaille avec de courtes commandes : ouvrir la page, cliquer sur @e1, remplir le champ @e2. Ce format pèse des centaines de tokens, et non des dizaines de milliers. Pour le LLM, la charge diminue nettement, tout comme le risque qu'une action échoue à cause d'un sélecteur fragile.

Une nouvelle interface pour les agents

La différence ressort bien dans un scénario simple : ouvrir un site et cliquer sur le premier article. Dans le schéma MCP classique, l'agent reçoit d'abord un énorme arbre d'accessibilité, y cherche le bon titre, puis tente de construire un sélecteur CSS exact. Le moindre changement de mise en page, une fenêtre modale de cookies ou un conteneur en plus fragilisent ce clic.

Avec agent-browser, le trajet est plus court : open, puis snapshot, puis click sur une courte ref. Le modèle ne s'appuie pas sur des suppositions quant à la structure du DOM, mais sur une carte déjà préparée des éléments interactifs.

« N'utilisez pas MCP pour le navigateur : économisez vos fenêtres de

contexte et votre argent d'API. »

Fait notable, Microsoft défend déjà une idée proche avec @playwright/cli. Là aussi, l'agent travaille avec de courtes commandes et l'état du navigateur est conservé hors du contexte du modèle. C'est un tournant important pour toute la catégorie des outils agentiques : le marché s'éloigne de l'idée de déverser les entrailles du navigateur directement dans le LLM et adopte un schéma où un outil local garde l'état et ne transmet au modèle que la couche de contrôle minimale. La différence entre les solutions tient désormais plutôt à l'écosystème : Playwright reste plus lourd, l'approche Rust de Vercel plus minimaliste.

Ce que cela signifie

L'automatisation du navigateur pour les agents IA commence à se scinder en deux classes. Playwright et Puppeteer classiques restent la base pour les tests complexes et le scraping, mais pour le codage agentique et la validation rapide d'interfaces, la demande pour des surcouches CLI légères se fait de plus en plus sentir.

La conclusion principale est simple : pour un LLM, mieux vaut fournir non pas le navigateur entier, mais une couche compacte de commandes et de références aux éléments. C'est moins cher, plus stable et plus pratique en conditions réelles.