Hone veut remplacer les tâches par des objectifs business mesurables

Hone Engines remplace le prompt par une métrique de résultat économique. Ce que ce pilotage par le P&L change pour la gouvernance des agents en entreprise.

Hone présente Engines, une nouvelle catégorie d’agents d’entreprise qui ne reçoivent plus simplement des tâches à exécuter, mais des résultats business à atteindre. L’entreprise résume son positionnement ainsi : les chatbots répondent, les agents accomplissent des tâches, les Engines doivent prendre la responsabilité d’un objectif et être évalués sur la valeur économique réellement créée.

Un Engine peut ainsi recevoir une consigne comme « améliorer la rétention client » ou « augmenter le pipeline qualifié », puis déterminer lui-même les étapes nécessaires, les personnes à solliciter, les outils à utiliser et les agents spécialisés à créer. Hone présente cette architecture comme un système persistant qui continue à poursuivre son objectif lorsque les conversations s’arrêtent ou que les conditions changent.

Le lancement s’accompagne d’une levée seed de 60 millions de dollars, menée par Benchmark et Index Ventures avec Elad Gil, Hanabi, Definition, Diffusion, Lux, SV Angel et Align. Index décrit Hone comme une couche située entre les modèles frontier et l’entreprise, capable de transformer leurs capacités en processus opérationnels continus. L’objectif remplace le prompt

La différence revendiquée par Hone tient d’abord au niveau auquel intervient l’utilisateur.

Avec un assistant classique, il faut formuler une question. Avec un agent, l’utilisateur délègue généralement une tâche ou un workflow déjà identifié. Un Engine reçoit plutôt une métrique de résultat, ainsi que les limites dans lesquelles il peut agir.

Hone donne l’exemple de la rétention client. L’organisation définit le résultat attendu, puis le système commence par comprendre l’entreprise avant de déterminer son plan d’action. Il peut analyser les outils utilisés, les processus, l’historique, les contraintes, les personnes décisionnaires et les pratiques existantes.

L’entreprise affirme que l’Engine peut ensuite identifier de lui-même de nouvelles responsabilités ou stratégies susceptibles d’améliorer son KPI.

Ce fonctionnement rapproche davantage le système d’un rôle organisationnel que d’une automatisation ponctuelle. Un onboarding automatique avant d’agir

Avant son déploiement, un Engine construit une représentation de l’environnement dans lequel il doit travailler.

Il ingère les systèmes, l’historique et les connaissances nécessaires à son rôle, identifie la manière dont les décisions sont prises et apprend ce qui constitue un bon résultat pour l’organisation.

Sur le site de Hone, cette phase prend également la forme d’un entraînement sur l’historique réel de l’entreprise.

L’Engine peut rejouer d’anciens tickets, opportunités commerciales, décisions ou situations pour montrer ce qu’il aurait fait. Les équipes humaines corrigent ensuite les comportements incorrects avant d’autoriser le système à intervenir sur des opérations réelles.

Cette logique de simulation constitue l’une des briques techniques les plus intéressantes de Hone. Tester ses propres changements avant la production

Hone détaille ce mécanisme dans un travail de recherche publié parallèlement au lancement.

Lorsqu’un Engine modifie ses propres instructions, sa mémoire ou certaines routines, ces changements sont d’abord testés dans un environnement de replay qui reproduit l’état historique de l’entreprise. Le système peut ainsi vérifier l’impact d’une modification avant de la promouvoir en production.

Hone compare ce principe au cycle classique d’amélioration d’un système logiciel : observer un problème, modifier le système, tester, puis déployer.

La différence est que l’Engine reçoit lui-même une partie des outils permettant d’effectuer cette boucle.

Dans une expérimentation menée par Hone sur 125 scénarios, l’utilisation de ces replays aurait fait passer le taux de régression de 33 % à 5 %. Sans simulation, les agents étaient notamment incapables de prévoir correctement quelles capacités existantes allaient être cassées par leurs propres modifications.

Ces résultats sont internes à Hone, mais ils montrent le type de problème que l’entreprise cherche à résoudre : permettre à un système persistant de s’améliorer sans détériorer silencieusement ce qu’il savait déjà faire. Les Engines écrivent leurs propres routines

Cette amélioration passe également par un Engine repository.

Selon Hone, chaque Engine peut écrire les routines nécessaires à son travail puis les conserver dans un repository versionné. Lorsqu’une tâche devient répétitive, le système peut donc transformer une procédure jusque-là improvisée en code ou en workflow réutilisable.

Ce mécanisme se combine avec une mémoire organisationnelle.

Les Engines conservent des préférences utilisateurs, des pratiques internes et des apprentissages accumulés entre plusieurs personnes et plusieurs exécutions. Lorsqu’un membre de l’équipe apporte une correction, celle-ci peut améliorer le comportement du système pour l’ensemble de l’organisation.

Hone insiste particulièrement sur ce point : la connaissance acquise au fil du temps ne doit pas disparaître à la fermeture d’une conversation ni rester enfermée dans les poids d’un modèle accessible à tous. Elle doit devenir une forme de capital opérationnel propre à l’entreprise. Une flotte d’agents sous un même objectif

Un Engine n’est pas nécessairement un agent unique.

Hone utilise une couche d’agent orchestration capable de créer ou coordonner plusieurs agents spécialisés pour traiter les différentes parties d’un objectif. Ceux-ci peuvent être distribués sur plusieurs tâches puis collaborer avec les humains concernés.

Cette architecture rappelle la distinction qui apparaît progressivement entre le modèle, l’agent et le harness qui l’entoure.

Chez Hone, l’Engine représente la couche persistante qui possède le résultat attendu. Les agents deviennent des unités d’exécution temporaires ou spécialisées utilisées pour atteindre ce résultat.

Le véritable produit se situe donc dans l’orchestration, la mémoire, les évaluations et les mécanismes de gouvernance qui persistent au-dessus des modèles. Les humains