Holo4 : alimenter des agents généralistes d’utilisation d’ordinateurs, mais l’écart des benchmarks reste important

Holo4 est arrivé le 28 septembre avec deux modèles, quatre modes d’interaction et un défi direct aux systèmes spécialisés d’utilisation d’ordinateurs. H Company décrit Holo4 : alimenter des agents généralistes d’utilisation d’ordinateurs comme une famille de modèles capable de naviguer sur des écrans, d’exécuter du code et d’appeler des outils logiciels.

Cette sortie est importante parce que l’automatisation informatique reste rarement confinée à une seule interface. Un processus métier peut commencer dans un navigateur, se poursuivre via une API et s’achever dans un logiciel de bureau dépourvu d’intégrations modernes. La plupart des systèmes agentiques gèrent cette transition en combinant différents modèles, outils et boucles de contrôle.

Holo4 propose une voie plus simple. Le même modèle peut choisir entre des interfaces graphiques, du code, des outils Model Context Protocol et des API. MCP est une norme qui permet aux systèmes d’IA d’accéder à des outils et à des données externes via des connexions structurées.

Cette promesse place Holo4 face à une architecture spécialisée, et non simplement face à un autre fournisseur de modèles. L’approche spécialisée attribue différents modèles ou politiques à la navigation visuelle, au codage et à l’appel d’outils. H Company soutient qu’un seul généraliste entraîné peut coordonner ces surfaces plus efficacement.

L’entreprise a également mis à disposition des milliers de trajectoires de benchmark à des fins d’inspection. Cette transparence offre aux développeurs davantage d’éléments qu’un simple score au classement. Elle ne répond pas pour autant aux questions de fiabilité, de sécurité ou de performances au sein d’organisations réelles.

Holo4 : alimenter des agents généralistes d’utilisation d’ordinateurs à travers quatre interfaces

Le changement central est architectural : Holo4 traite l’interface comme un choix au sein de la tâche, plutôt que comme une frontière fixe autour de l’agent.

Selon la sortie de Holo4, la famille comprend un modèle dense de 27 milliards de paramètres et un modèle mixture-of-experts de 35 milliards de paramètres. Ce dernier active environ trois milliards de paramètres à chaque étape d’inférence.

Un modèle mixture-of-experts achemine les entrées vers des composants internes sélectionnés au lieu d’activer chaque paramètre. Cette conception peut réduire les besoins de calcul, bien que la vitesse réelle dépende du matériel, des logiciels et des choix de déploiement.

Les deux modèles Holo4 peuvent interagir avec des interfaces graphiques, écrire et exécuter du code, ainsi qu’appeler des outils MCP ou API. H Company affirme que le même modèle peut opérer sur des ordinateurs de bureau, des sites web, des appareils Android, des environnements de codage isolés et des systèmes métier.

Cela diffère d’un agent qui ne prédit que des clics de souris à partir de captures d’écran. Cela diffère également d’un modèle d’appel d’outils qui devient inefficace lorsqu’une application ne dispose pas d’API. Holo4 est conçu pour changer de méthode à mesure qu’un flux de travail évolue.

Prenons une opération financière courante. Un agent pourrait extraire des champs d’un document, les normaliser avec du code, les soumettre via une API et vérifier le résultat à l’écran. Un ancien logiciel d’entreprise pourrait imposer une nouvelle transition vers le contrôle par souris et clavier.

Un modèle généraliste pourrait conserver un même processus de décision tout au long de ces étapes. Une pile spécialisée orienterait généralement chaque étape vers un modèle, une politique ou un service distinct. Ce routage peut améliorer le contrôle, mais il introduit aussi davantage de transferts et de points de défaillance.

H Company indique avoir entraîné Holo4 par apprentissage supervisé et apprentissage par renforcement dans des environnements interactifs générés. Son usine de tâches interne aurait créé environ 10 000 tâches couvrant des applications web, des ordinateurs de bureau, des serveurs MCP et des environnements hybrides.

Ces tâches générées sont importantes parce que des exemples statiques ne peuvent pas reproduire les conséquences des actions d’un agent. Un environnement interactif peut vérifier si un clic a modifié l’état, si le code s’est exécuté ou si un appel API a produit l’enregistrement attendu.

Cette approche permet également à H Company de générer des tâches à partir de documentation et de captures d’écran. Elle pourrait élargir la couverture de l’entraînement sans concevoir manuellement chaque flux de travail. Toutefois, les environnements générés peuvent toujours différer des systèmes de production désordonnés, avec leurs autorisations, délais et états imprévus.

La sortie inclut un modèle Holotron4 Nano mis à jour aux côtés des deux principales variantes Holo4. Elle propose également les poids des modèles dans plusieurs formats, notamment BF16, FP8, NVFP4 et GGUF quatre bits.

La disponibilité dans ces formats offre aux développeurs plusieurs options de déploiement. Toutefois, l’affirmation la plus déterminante reste qu’un seul modèle peut coordonner plusieurs interfaces sans couche externe de sélection de modèles.

Cela fait de Holo4 : alimenter des agents généralistes d’utilisation d’ordinateurs un test visant à déterminer si la généralité des interfaces peut réduire la complexité du système sans sacrifier la précision offerte par les agents spécialisés.

Pourquoi les flux de travail longs mettent les piles d’agents spécialisées sous pression

Holo4 met les piles spécialisées sous pression parce que les flux de travail longs multiplient le coût de chaque décision de routage, transfert de contexte et étape de récupération.

Une courte tâche dans un navigateur peut masquer des faiblesses architecturales. Un agent peut ouvrir une page, saisir une valeur et soumettre un formulaire. Même un système fragile réussit parfois cette séquence.

Le travail professionnel est différent. Il implique plusieurs applications, un état persistant, des instructions ambiguës et des informations qui apparaissent pendant l’exécution. Un agent doit se souvenir des contraintes antérieures tout en s’adaptant aux événements ultérieurs.

OSWorld 2.0 a été conçu autour de ce cadre plus exigeant. Ses chercheurs ont assemblé 108 flux de travail de longue durée couvrant des tâches quotidiennes et professionnelles. Un humain compétent met environ 1,6 heure, en médiane, à accomplir chaque tâche.

Le benchmark indique que les principaux agents peuvent atteindre en moyenne plus de 300 étapes par flux de travail. Les tâches d’OSWorld 1.0 nécessitaient environ 30 étapes, ce qui fait du benchmark plus récent un test bien plus strict de la gestion du contexte.

Les échecs ne se limitent pas non plus à des clics imprécis. Les chercheurs ont observé des agents perdre des contraintes, manquer des informations entrantes, deviner alors qu’une clarification était nécessaire et omettre la vérification. Ces faiblesses peuvent s’aggraver au fil d’un processus long.

H Company affirme avoir reconstruit le harnais agentique de Holo4 en réponse à ces problèmes. Un harnais est la boucle d’exécution qui fournit les observations, gère le contexte, exécute les actions et renvoie les résultats au modèle.

Ses deux ajouts les plus notables sont une mémoire persistante sur des centaines d’étapes et un shell exécuté sur la machine de bureau. Le shell offre à l’agent une voie fondée sur le code lorsque l’interaction directe avec l’interface graphique devient inefficace.

C’est ici que la conception généraliste devient plus qu’une liste de fonctionnalités. Le modèle peut décider qu’analyser un fichier local avec du code est préférable à une lecture visuelle. Il peut ensuite revenir à l’interface pour les actions nécessitant une confirmation visuelle.

Une pile spécialisée peut exécuter la même séquence. Elle doit toutefois décider quand transférer le contrôle et quelle quantité de contexte accompagne chaque transfert. Un mauvais choix de routage peut gaspiller des étapes ou perdre des informations.

Holo4 cherche à intégrer cette décision dans le modèle entraîné. Si l’approche fonctionne de manière cohérente, les développeurs pourraient réduire la logique nécessaire à la coordination du contrôle des navigateurs, des ordinateurs de bureau, de l’exécution de code et des outils structurés.

Cela n’élimine pas l’orchestration. Les systèmes de production ont toujours besoin de gestion des identifiants, de sandboxing, de nouvelles tentatives, de journalisation et de contrôles d’approbation. Ils ont également besoin d’un moyen fiable d’arrêter un agent avant qu’une action incertaine ne provoque des dommages.

Le changement est plus limité, mais reste significatif. Les développeurs pourraient consacrer moins d’efforts à décider quel modèle doit gérer chaque interface. Ils pourraient davantage se concentrer sur la définition des autorisations, la validation des résultats et la mesure de flux de travail complets.

Cette distinction compte pour les équipes qui construisent une base de connaissances consultable. Leurs flux de travail traversent souvent des documents locaux, la recherche interne, des outils de navigateur et des systèmes d’entreprise structurés.

Holo4 ne prouve pas que les généralistes remplaceront chaque spécialiste. Il fait du routage spécialisé un choix de conception que les développeurs doivent justifier, plutôt qu’un fondement inévitable.

Un modèle d’agent est plus simple, mais les spécialistes fixent toujours la barre de la fiabilité

La confrontation principale oppose un modèle généraliste à une pile coordonnée de spécialistes, la fiabilité déterminant quelle architecture l’emporte.

Les spécialistes offrent un avantage intuitif. Un modèle entraîné étroitement pour l’ancrage visuel peut se concentrer sur la localisation des contrôles. Un modèle de codage peut se concentrer sur la syntaxe, l’exécution et le débogage sans interpréter chaque capture d’écran.

Les modèles d’appel d’outils bénéficient également de schémas structurés. Une API expose des actions autorisées et des champs prévisibles. Une interface graphique offre davantage de flexibilité, mais ses boutons, mises en page et états transitoires créent de l’ambiguïté.

L’approche spécialisée permet aux ingénieurs de sélectionner le meilleur modèle pour chaque surface. Elle peut aussi isoler les capacités risquées. Un agent visuel peut recevoir l’accès à l’écran sans obtenir la possibilité d’exécuter arbitrairement des commandes shell.

Cependant, la spécialisation déplace la complexité vers le système environnant. Un routeur doit classifier chaque étape, choisir un composant et préserver l’intention de l’utilisateur à travers les transferts. La pile doit réconcilier différents formats de contexte et signaux de défaillance.

L’approche généraliste de Holo4 intègre une partie de cette coordination au modèle. L’agent peut regarder un écran, reconnaître que la manipulation directe est inefficace, puis utiliser du code ou un outil structuré à la place.

H Company illustre cette approche par des tâches dans des logiciels professionnels. Dans un exemple, Holo4 27B aurait utilisé 68 appels et 2,4 millions de tokens pour créer un jeu autonome dans Godot. Sa base Qwen a utilisé 197 appels et 11,4 millions de tokens avec le même prompt et le même harnais.

Ces chiffres proviennent de l’évaluation propre à H Company, et non d’un laboratoire indépendant. Ils décrivent une tâche plutôt qu’une performance moyenne en production. Ils montrent néanmoins le type d’efficacité que l’entreprise veut que Holo4 apporte.

D’autres exemples portent sur la construction d’objets détaillés dans FreeCAD. Ces flux de travail combinent interprétation spatiale, contrôle logiciel et génération de code. Ils sont plus exigeants que le remplissage d’un simple formulaire web.

Les exemples révèlent aussi une limite. La tâche de la tour Eiffel de Holo4 aurait nécessité 84 appels et 1,3 million de tokens. Les longues sessions d’utilisation d’ordinateurs peuvent rester coûteuses en calcul, même lorsque le résultat final est réussi.

Les spécialistes conservent un autre avantage lorsque le flux de travail est prévisible. Un script déterministe ou une intégration API étroite peut être plus rapide et plus facile à auditer qu’un agent choisissant parmi plusieurs actions possibles.

L’argument généraliste devient plus convaincant lorsque les flux de travail varient, que les interfaces changent ou que les systèmes hérités manquent d’intégrations. L’argument spécialisé reste plus fort lorsque les organisations ont besoin de reproductibilité et peuvent définir précisément le processus.

Cela signifie que Holo4 ne devrait pas effacer l’automatisation conventionnelle. Il se positionne plutôt sur le terrain intermédiaire incertain, où les scripts fixes échouent mais où les agents de pointe sans restriction restent trop coûteux ou difficiles à gouverner.

Les développeurs devraient donc évaluer des tâches complètes, et non des clics isolés. La question pertinente est de savoir si Holo4 réduit les échecs et la charge d’ingénierie sur des flux de travail réels.

Un modèle qui atteint l’état final correct avec moins de transferts peut justifier une précision brute inférieure dans une compétence étroite. Un généraliste qui change de méthode de manière imprévisible peut créer une charge de débogage plus importante.

Le résultat dépendra de la qualité des trajectoires, de la reproductibilité et du comportement de récupération. Ces facteurs comptent davantage que l’apparente simplicité d’une architecture dans un diagramme.

Les résultats de benchmark de Holo4 ont besoin de leurs harnais et de leurs notes de bas de page

Les résultats de Holo4 sont notables, mais la publication elle-même explique pourquoi plusieurs comparaisons phares ne sont pas directement équivalentes.

H Company indique que Holo4 27B a obtenu 61,7 % sur OSWorld 2.0. Son modèle 35B-A3B a atteint 30,9 %. L’entreprise compare ces résultats aux 81,8 % d’Opus 5.5.

L’écart de 20,1 points entre Holo4 27B et Opus 5.5 est considérable. Holo4 ne devance pas le meilleur modèle fermé selon cette mesure rapportée. Son argument repose sur la taille du modèle, la flexibilité de déploiement et le coût estimé des tâches.

H Company cite également des scores de 70,2 % pour Opus 5 et de 66,2 % pour GPT-5.6 Sol. Ces références utilisent des récompenses partielles avec effort maximal sur un ensemble OSWorld 2.0 hors ligne daté du 8 août 2026.

La publication avertit que les versions de modèles, les harnesses et les sous-ensembles de tâches varient. Cet avertissement devrait accompagner chaque comparaison. Les performances des agents dépendent de bien plus que du checkpoint du modèle.

Le harness contrôle la mémoire, l’accès aux outils, le formatage des observations, le comportement de reprise et le nombre maximal d’étapes. Modifier l’une de ces variables peut changer le résultat, même si le modèle sous-jacent reste inchangé.

Les graphiques de coûts exigent une prudence similaire. H Company a estimé les dépenses à partir des tokens d’entrée et de sortie utilisés lors de chaque exécution. Elle a appliqué ses propres tarifs d’API à Holo4 et des prix catalogue externes aux autres modèles.

De telles estimations peuvent soutenir la planification interne, mais ne constituent pas des mesures économiques contrôlées. Les hypothèses de mise en cache, l’infrastructure d’inférence, les reprises et les remises sur volume peuvent modifier les coûts réels de déploiement.

AutomationBench introduit un autre problème de comparabilité. H Company a évalué Holo4 et ses références Qwen avec la version 1.0.6 dans son harness interne. Les scores des autres modèles provenaient de l’ensemble public du benchmark.

Les chiffres de coût cités pour les autres modèles provenaient d’un classement utilisant un ensemble privé. H Company indique qu’elle prévoit de communiquer les résultats de Holo4 sur cette évaluation privée après les tests.

D’ici là, les lecteurs ne devraient pas considérer tous les points AutomationBench comme les résultats d’une seule expérience contrôlée. Ils représentent des mesures apparentées produites dans des conditions différentes.

Même les définitions des benchmarks peuvent façonner un récit. OSWorld 2.0 prend en charge la réussite binaire et la notation par crédit partiel. Un modèle peut recevoir un crédit partiel significatif tout en échouant à fournir un workflow finalisé.

Cela ne rend pas la notation partielle inutile. Elle peut identifier des progrès sur des tâches longues, là où une réussite binaire masquerait des améliorations. Pourtant, les acheteurs se préoccupent de savoir si l’enregistrement, le fichier ou la transaction finale est correct.

L’efficacité nécessite également plus que le comptage des tokens. Des recherches sur l’efficacité des agents ont montré que les principaux agents d’utilisation d’ordinateur effectuaient entre 1,4 et 2,7 fois plus d’étapes que nécessaire dans leur évaluation.

Ces mêmes recherches ont montré que les étapes tardives peuvent prendre bien plus de temps que les premières. Les appels de planification et de réflexion représentaient une grande part de la latence. Une longue trace d’agent peut donc amplifier les délais au-delà de son nombre visible d’actions.

Ces conclusions renforcent l’accent mis par H Company sur la mémoire et l’accès au shell. Elles montrent aussi pourquoi un bon score de benchmark ne produit pas automatiquement une expérience utilisateur acceptable.

L’interprétation équitable n’est ni le rejet ni l’acceptation. Holo4 affiche un résultat compétitif communiqué par l’entreprise pour un modèle relativement compact, tout en restant derrière le principal système fermé.

Le test pratique consiste à déterminer si ces résultats perdurent dans des harnesses indépendants, des évaluations privées et des workflows contenant des autorisations et des données propres à l’organisation.

Les trajectoires ouvertes améliorent la vérification, pas la sécurité

Le geste de crédibilité le plus fort de H Company est la publication des traces derrière ses scores, même si un comportement inspectable n’est pas automatiquement un comportement sûr.

Le jeu de données de trajectoires contient 7 366 exécutions de Holo4 27B et Holo4 35B-A3B. Chaque trace peut inclure la tâche, le raisonnement, les actions, les résultats des outils, les captures d’écran, la durée, les étapes et le score final.

La collection comprend plus de 2 100 exécutions OSWorld pour les deux modèles. Elle contient également 212 exécutions OSWorld 2.0 et près de 3 200 exécutions AutomationBench.

Des traces supplémentaires couvrent AndroidWorld, PinchBench et Agents’ Last Exam. H Company permet aux utilisateurs de télécharger le jeu de données ou de rejouer les traces via un visualiseur dédié.

Cette divulgation donne aux chercheurs plusieurs moyens de remettre en question les conclusions de l’entreprise. Ils peuvent examiner si une exécution réussie a suivi un chemin raisonnable, répété des actions inutiles ou bénéficié de raccourcis propres à la tâche.

Ils peuvent également étudier les schémas d’échec. Un score agrégé ne peut pas montrer si l’agent a mal compris l’instruction, cliqué sur la mauvaise cible, perdu le contexte ou arrêté son travail avant vérification.

Les trajectoires ouvertes peuvent révéler si les améliorations de performance proviennent d’un meilleur raisonnement ou d’un harness plus indulgent. Elles peuvent aussi aider les équipes à estimer la fréquence à laquelle une intervention humaine pourrait être nécessaire.

Toutefois, la transparence après l’exécution diffère du contrôle avant l’exécution. Une trace aide les enquêteurs à comprendre ce qui s’est passé. Elle n’empêche pas un agent d’envoyer des données, de supprimer des fichiers ou de suivre des instructions malveillantes.

Les agents d’utilisation d’ordinateur sont confrontés à des risques que les systèmes conversationnels classiques évitent. Ils opèrent dans des environnements contenant du contenu non fiable et des identifiants précieux. Une page web peut placer du texte adversarial directement dans l’observation du modèle.

Le benchmark OS-Harm teste les usages abusifs délibérés, l’injection de prompt et les comportements involontaires des modèles sur 150 tâches. Ses chercheurs ont constaté des comportements dangereux significatifs dans plusieurs systèmes de pointe.

Cette étude n’a pas évalué Holo4 ; ses résultats ne peuvent donc pas établir la sûreté de Holo4. Elle démontre que le contrôle compétent d’un ordinateur et le contrôle sûr d’un ordinateur constituent des problèmes d’évaluation distincts.

Le risque devient plus aigu lorsqu’un modèle dispose d’un large accès aux interfaces. Un généraliste peut passer de la lecture d’une page web à l’exécution de code ou à l’appel d’une API. Cette flexibilité accroît l’utilité, mais aussi l’impact potentiel d’une erreur.

Les entreprises auront besoin de contrôles en couches, quels que soient les scores de benchmark. Ces contrôles comprennent des identifiants à portée limitée, une exécution isolée, un accès réseau restreint, des actions réversibles et une approbation humaine pour les étapes à conséquences importantes.

Elles auront également besoin de journaux reliant chaque action à l’instruction de l’utilisateur et à l’état observé à ce moment-là. Le format de trajectoire de Holo4 offre un modèle utile pour de tels enregistrements d’audit.

Les licences méritent aussi une attention particulière. Des poids ouverts ne garantissent pas des droits commerciaux identiques pour chaque checkpoint ou composant. Les équipes devraient examiner chaque fiche modèle et chaque dépendance avant le déploiement.

Il en va de même pour la gouvernance des données. Les captures d’écran et les traces d’agents peuvent enregistrer des informations personnelles, des dossiers clients ou des documents confidentiels. Tout journaliser peut améliorer le débogage tout en créant un autre jeu de données sensible.

H Company indique que les identifiants, hôtes internes et données personnelles ont été masqués dans sa publication publique de trajectoires. Les opérateurs de production doivent mettre en place des contrôles de suppression d’informations sensibles et de rétention équivalents pour leurs propres traces.

Le jeu de données ouvert relève le niveau d’exigence pour les futurs lancements. Les fournisseurs revendiquant des performances supérieures en utilisation d’ordinateur disposent désormais d’un exemple plus clair de ce à quoi peuvent ressembler des preuves reproductibles.

Néanmoins, les travaux externes les plus précieux impliqueront des relectures adversariales, une notation indépendante et des tests hors du harness de H Company. La transparence ouvre ce processus ; elle ne l’achève pas.

Trois signaux montreront si le pari généraliste de Holo4 tient

La prochaine phase devrait être jugée à travers des reproductions indépendantes, des résultats de benchmarks privés et des preuves issues de workflows de production.

Le premier signal est la reproduction indépendante des performances de Holo4 sur OSWorld 2.0. Les chercheurs doivent exécuter les poids publiés avec une infrastructure, des prompts, des limites d’étapes et des règles de notation documentés.

Reproduire les 61,7 % rapportés renforcerait l’affirmation de H Company selon laquelle le modèle lui-même porte cette capacité. De grands écarts suggéreraient que le harness de l’entreprise contribue davantage que ne le laisse entendre le titre.

La reproduction devrait également comparer la réussite binaire, le crédit partiel, les étapes, la latence et les taux d’intervention. Un seul score ne peut pas indiquer si un agent atteint un résultat utilisable dans des limites pratiques.

Les trajectoires publiées rendent ce travail plus accessible. Les chercheurs peuvent partir d’exécutions connues, examiner les frontières de l’échec et comparer des harnesses alternatifs sur les mêmes tâches.

Le deuxième signal est le résultat de Holo4 sur AutomationBench privé. La publication reconnaît que ses scores actuels proviennent d’une exécution interne sur l’ensemble public, tandis que les coûts de comparaison font référence à un classement sur ensemble privé.

Une évaluation privée créerait une comparaison plus nette et réduirait les préoccupations liées à l’optimisation sur des tâches visibles. Elle testerait également si Holo4 se généralise à des workflows d’API inconnus.

Le résultat devrait inclure davantage qu’un taux de réussite. Les développeurs ont besoin des coûts, de l’utilisation des tokens, des reprises, de la latence et des catégories d’échec dans une configuration d’évaluation unique et documentée.

Le troisième signal consiste en des preuves de production crédibles issues de workflows à interfaces mixtes. Les meilleurs cas concerneraient des tâches exigeant réellement des GUI, du code et des outils structurés dans une même session.

Des rapports utiles montreraient une réalisation sans correction humaine, une récupération après des changements d’interface et des performances sous des autorisations restreintes. Ils devraient également compter les erreurs irréversibles, et pas seulement les exécutions réussies.

Un workflow de traitement des dépenses offre un test représentatif. L’agent doit lire des documents, valider des champs, interagir avec des logiciels métier et confirmer que les enregistrements ont atteint l’état prévu.

Un autre test solide concernerait des opérations d’ingénierie couvrant des fichiers locaux, des outils de suivi des problèmes, des consoles de navigateur et des outils en ligne de commande. Ces workflows révèlent si le contexte partagé est un avantage ou une source de comportement incontrôlé.

Les mises à jour du modèle fourniront un signal connexe. H Company indique que des checkpoints de rédacteur optimisés sont prévus afin d’accélérer l’inférence. Des réductions mesurées de latence renforceraient l’argument économique en faveur de l’architecture généraliste.

Les réponses des concurrents comptent aussi, mais restent des preuves complémentaires. Les fournisseurs de modèles fermés peuvent améliorer l’utilisation d’ordinateur, tandis que les développeurs de modèles ouverts peuvent ajouter un entraînement aux outils plus large à leurs propres publications.

La question centrale n’est pas de savoir si Holo4 reste devant chaque alternative. Il s’agit de savoir si un modèle généraliste unique offre un meilleur rapport entre fiabilité et complexité qu’une pile de spécialistes.

Pour les développeurs, l’opportunité immédiate est l’évaluation contrôlée. Utilisez des tâches représentatives, des identifiants restreints et des environnements réversibles. Mesurez les résultats achevés plutôt que les actions isolées du modèle.

Pour les acheteurs en entreprise, la question de l’approvisionnement devrait inclure le harness. Demandez quel composant gère la mémoire, les approbations, les reprises, les secrets, les journaux d’audit et la récupération après une exécution partielle.

Pour les travailleurs du savoir, cette publication suggère que les agents franchiront davantage de frontières entre applications. Cette commodité rend aussi la conception des autorisations et la confirmation visible plus importantes.

Holo4: powering generalist computer-use agents est donc moins une déclaration de victoire qu’un défi architectural concret. H Company a fourni des modèles, des affirmations et des traces inhabituellement détaillées.

Le prochain mouvement appartient aux évaluateurs indépendants et aux équipes de déploiement. Holo4 peut-il reproduire ses résultats rapportés, résister à des tâches inconnues et accomplir un travail réel sans accroître le risque opérationnel ?

Ces trois tests détermineront si les agents généralistes d’utilisation d’ordinateur simplifient l’automatisation ou déplacent simplement ses problèmes les plus difficiles.