Webagent veut standardiser les agents d’entreprise sans recoder l’orchestration

Agent-net a publié Webagent, un harness open source en Go destiné à déployer des agents d’entreprise accessibles depuis le web, Slack ou WhatsApp. L’outil repose sur une spécification JSON déclarative qui remplace une bonne partie du code d’orchestration, avec neuf emplacements à remplir par des fournisseurs compatibles. Le projet est utilisable dès maintenant pour certains usages, mais il reste en version v0 et plusieurs briques sont encore absentes, dont l’identité AgentNet et la facturation. C’est le genre de projet qui promet de faire gagner du temps aux équipes, tout en rappelant que la production n’aime jamais les raccourcis trop élégants.

Un agent, neuf emplacements, une seule recette

Webagent, présenté par Agent-net, fonctionne comme une couche de déploiement pour agents publics d’entreprise. Une équipe renseigne un fichier JSON, choisit un fournisseur pour chacun des neuf slots, puis lance webagent serve. La mécanique couvre la récupération, la mémoire, les garde-fous, les canaux, les secrets, la présentation, le modèle, les actions et l’observabilité.

Selon la documentation décrite dans la source, les fournisseurs intégrés incluent par exemple live, session, basic, a2a, env, text, echo, none et plusieurs variantes pour les canaux, les modèles et les actions. Le cœur du projet vise trois profils à la fois : les entreprises qui configurent, celles qui étendent avec un fournisseur personnalisé et les partenaires qui livrent des adaptateurs. Personne n’a donc intérêt à forker le noyau. Voilà au moins une façon élégante d’éviter le syndrome du “on va juste modifier deux lignes”.

La sécurité est imposée par l’architecture, pas par le prompt

Le point le plus sensible du projet se nomme action.Guard. Chaque outil passe à travers cette couche de protection avant exécution, qu’il provienne d’un fournisseur d’actions ou qu’il soit injecté par l’hôte. Le modèle ne peut pas la contourner, ce qui place la sécurité au niveau du code plutôt qu’au niveau des instructions données au modèle.

La source relie ce choix à une recherche citée dans le DESIGN.md, avec une différence de succès de tâche annoncée de 85 % contre 50 % pour les mêmes modèles selon l’architecture employée [à vérifier]. Le message est clair : la performance d’un agent ne dépend pas seulement du LLM, mais de la manière dont on encadre ses actions. Pour les entreprises, cela compte autant que le choix du modèle lui-même, car un agent qui voit tout mais ne sait rien exécuter proprement reste un joli PowerPoint.

Ce qui marche déjà, et ce qui manque encore

La version actuelle du dépôt est annoncée comme fonctionnelle sur plusieurs briques. Le cerveau par défaut echo ne requiert aucune clé, ce qui permet de valider et de lancer les exemples zomato.json et bakery.json immédiatement. Pour utiliser un vrai modèle, l’outil prend en charge OpenRouter ou gateway, deux clients compatibles OpenAI avec boucle de tool calling.

Les intégrations existantes couvrent aussi des agents Slack, WhatsApp et HTTP, ainsi qu’un provider d’actions mcp. L’outil peut se connecter à un serveur MCP via Streamable HTTP, avec authentification par bearer ou clé API, puis récupérer les outils à exécuter derrière le garde-fou. Côté messagerie, les connecteurs valident les signatures des webhooks, répondent immédiatement, ignorent leurs propres messages et dédupliquent les envois répétés. Côté secrets, toute clé finissant par Secret est résolue au build via un coffre choisi ; si la résolution échoue, le démarrage est bloqué.

Une base utile, mais pas encore un produit fini

Webagent peut déjà servir de socle à des démonstrateurs sérieux, notamment quand un entreprise dispose d’un serveur MCP et veut l’exposer comme agent. La logique de certification des fournisseurs, via une suite de conformité par slot, donne aussi une direction claire aux partenaires qui veulent livrer des modules compatibles.

Mais les limites sont explicites : le projet n’intègre pas encore les actions navigateur, l’authentification OAuth pour MCP, l’export OTel ni la couche d’identité et de facturation AgentNet. Pour les équipes produit ou infra, cela signifie qu’il faut lire la liste des éléments différés avant d’envisager un déploiement en production. Le dossier est prometteur, mais la dernière marche reste à construire. Et, comme souvent avec les agents, la vraie difficulté commence au moment où quelqu’un demande : “qui paie, qui trace et qui contrôle ?”