AI Workers offre le cycle de vie complet d'une main-d'œuvre synthétique. Les administrateurs définissent des identités de workers, chacune dotée d'un persona d'affichage, d'un rôle, d'un system prompt qui façonne le ton et l'expertise, et de paramètres de génération tels que le budget de tokens et la température. Chaque worker porte une file de travail, un fil de conversation durable et un ensemble d'assistants connectés par lesquels il peut être joint ou par lesquels il prend contact. Les workers interrogent les données opérationnelles en direct, exécutent des écritures et des changements d'état, exécutent des tâches planifiées sans surveillance, guettent les exceptions, extraient de l'information structurée à partir de documents, et agissent comme réviseurs et approbateurs au sein des processus métier.

Deux voies de réponse se tiennent derrière chaque worker et sont choisies automatiquement. Lorsqu'un assistant externe est connecté et joignable, la plateforme lui transmet la requête et reçoit la réponse via un callback signé et authentifié. Lorsqu'aucun assistant externe n'est disponible, un modèle intégré s'exécute directement sur le même ensemble d'outils gouvernés : un worker n'est donc jamais muet et ne répond jamais à partir d'un contexte périmé. Les deux voies s'appuient sur un même registre partagé d'outils d'entreprise, garantissant qu'un worker se comporte de manière identique que ce soit un assistant externe ou le modèle intégré qui assure le raisonnement. La conversation, la gestion de la file, la configuration des workers, les paramètres du fournisseur de modèles et l'enregistrement des assistants connectés sont tous pilotés depuis une unique surface de gestion de l'IA.

Au centre se trouve l'AI Worker : une identité persistante dotée d'un nom, d'un rôle et de la mémoire de tout ce qui lui a été demandé. Un worker se définit moins par son code que par trois éléments qui l'entourent. Le premier est un rôle, qui porte les permissions du worker et constitue l'unique autorité sur ce qu'il peut voir et faire ; un worker ne peut jamais dépasser la frontière décrite par son rôle, et modifier ce rôle modifie immédiatement sa portée. Le deuxième est la file de travail, un arriéré ordonné de tâches dont le worker est propriétaire, chacune avec une priorité, un calendrier optionnel, un cycle de vie de la mise en file à l'exécution jusqu'à un résultat abouti, et un résultat consigné. Le troisième est la conversation, un enregistrement en ajout seul des tours d'utilisateur, de worker et de système qui confère à chaque échange une continuité et une piste d'audit complète.

Autour de ces éléments gravitent deux concepts de soutien. Un fournisseur de modèles décrit quel moteur de raisonnement anime un worker, résolu au moment de l'utilisation afin qu'un worker particulier puisse remplacer le choix par défaut de l'organisation sans aucune modification du worker lui-même. Les assistants connectés décrivent les outils externes vers lesquels un worker peut être acheminé, chacun avec son propre point d'accès, ses identifiants et son état de santé. Les relations sont volontairement simples : un rôle façonne de nombreux workers, un worker possède une file et une conversation et peut détenir plusieurs assistants connectés, et un fournisseur peut animer de nombreux workers. Rien ici n'appartient à un client ou à un grand livre ; il s'agit de configuration et de persona, conservés dans le cœur de la plateforme afin que l'identité et la permission soient gouvernées en un seul endroit.

L'interaction quotidienne est conversationnelle. Un utilisateur ouvre le panneau des workers, sélectionne un worker par son nom et son rôle, et saisit une demande. Le message est consigné et confirmé instantanément, puis transmis sans bloquer l'interface. Si un assistant connecté répond, sa réponse arrive via le callback et remplace l'indicateur d'attente ; si aucun ne répond, le modèle intégré compose directement la réponse, en appelant les outils gouvernés requis par la demande et en renvoyant une prose ancrée et étayée par les données. Le panneau se maintient à jour grâce à un polling adaptatif qui s'accélère lors des échanges actifs et se détend lorsque le fil est calme.

Le deuxième flux est autonome. Un utilisateur planifie un travail, et l'élément rejoint la file du worker avec une priorité et, lorsqu'elle est définie, une heure d'exécution future. Le planificateur récupère les éléments en file, les exécute via le modèle sur l'ensemble d'outils en direct avec un nombre borné d'étapes de raisonnement, et consigne le résultat. Une tâche qui s'achève sans accroc est marquée comme telle ; une tâche où chaque action a réussi mais où certaines ont été refusées ou en erreur est présentée honnêtement comme un résultat partiel accompagné d'un avis clair pour revue humaine ; une tâche qui échoue purement et simplement est consignée comme échouée. Le troisième flux est entrant : les assistants externes se connectent au propre point d'accès de protocole de la plateforme et exploitent les mêmes outils gouvernés sous application des portées, de sorte que les capacités d'un worker sont disponibles au sein même des outils que les gens utilisent déjà ailleurs.

Ce qui rend le module digne de confiance, c'est que la capacité et l'autorité ne sont jamais dissociées. Les permissions sont appliquées au moment où un outil s'exécute, et non simplement lorsqu'une tâche est mise en file, de sorte qu'un changement de rôle ou une suspension de worker prend effet dès l'action suivante. Chaque outil déclare une portée, et cette portée correspond à une paire de permissions concrète qui est vérifiée face au rôle du worker avant que l'outil n'entreprenne quoi que ce soit ; un worker qui ne dispose pas du droit renvoie un résultat net de permission refusée plutôt que d'agir. Si les permissions d'un worker ne peuvent être chargées pour quelque raison que ce soit, le système se résout à tout refuser, échouant en sécurité par construction.

La posture de sécurité est stratifiée en conséquence. L'accès interactif s'exécute sous des sessions authentifiées avec des contrôles de capacité sur chaque route. L'émission sortante vers les assistants externes est signée au moyen d'un code d'authentification de message à clé, afin que les destinataires puissent vérifier l'origine, et chaque émission transporte le contexte du worker, une tranche bornée de l'historique de conversation et une adresse de callback à usage unique. Les callbacks entrants s'authentifient à l'aide d'un jeton porteur vérifié face à un hachage stocké, sont soumis à une limitation de débit par worker, sont bornés en taille et sont idempotents, de sorte qu'une livraison retentée ne duplique jamais une réponse. Les échanges périmés expirent sur minuterie, les assistants injoignables font l'objet d'une surveillance de santé et sont mis hors service automatiquement, et chaque création de message est journalisée pour audit avec l'identité agissante et l'adresse d'origine. Le résultat est une autonomie assortie d'une traçabilité : les workers agissent vite, mais toujours à l'intérieur d'une frontière qui peut être inspectée après coup.

AI Workers est le tissu conjonctif de Nashua 360 plutôt qu'un îlot. Via le registre d'outils partagé, un worker accède directement à Business Relations pour lire et tenir à jour les entreprises, contacts et sites ; à Accounting and Control pour interroger les factures débiteurs et créanciers et l'ensemble du tableau financier ; à Catalog Management pour effectuer des recherches dans le catalogue en couches de produits et services ; et à Test Management ainsi qu'au module System central pour les métadonnées et diagnostics de plateforme. Chacun de ces accès est encadré par le même mappage rôle-vers-portée, de sorte qu'un worker conçu pour la finance voit le grand livre mais pas le catalogue, sauf si son rôle en décide autrement.

Parce que le module réside dans le cœur de la plateforme, aux côtés des rôles et de l'enregistrement des modules, il hérite en bloc du modèle d'identité et d'autorisation de la suite plutôt que de le réinventer. Le rôle d'un worker s'exprime dans la même grammaire de permissions que celle d'un utilisateur humain, ce qui signifie que la gouvernance, la revue et la conception au moindre privilège forment une discipline unique, commune aux personnes comme aux workers synthétiques. Toute nouvelle capacité ajoutée à un module quelconque devient disponible pour les workers dès l'enregistrement de son outil, si bien que la surface conversationnelle et autonome grandit au même rythme que le reste de Nashua 360, sans travail d'intégration sur mesure.

À l'intérieur du module, les workers sont les acteurs, et leur registre est vaste. Ils répondent aux questions en interrogeant les données de module en direct et en renvoyant des synthèses ancrées : un utilisateur peut ainsi demander un solde créancier en cours ou l'activité récente d'un client et recevoir une réponse tirée de l'état actuel du grand livre et des enregistrements de relation, plutôt que d'un rapport stocké. Ils exécutent des actions sur demande ou selon un calendrier, créant et mettant à jour des enregistrements, générant des éléments de travail et pilotant des processus en plusieurs étapes au moyen d'une boucle de raisonnement bornée. Ils guettent les anomalies et les exceptions, et lorsqu'une tâche planifiée s'achève avec des actions refusées ou échouées, ils émettent une notification d'avertissement et un message système clair plutôt que de laisser passer silencieusement un résultat partiel.

Ils traitent les documents et les saisies non structurées, extrayant des champs structurés pour une utilisation en aval, et ils appuient les décisions en assemblant et en expliquant les données qui sous-tendent un choix. Point crucial, un worker peut tenir lieu de nœud d'approbation ou de revue au sein d'un workflow : une demande lui étant acheminée sous sa propre identité habilitée, il évalue l'élément face à son rôle et à ses instructions, consigne sa détermination dans la piste de conversation et, soit fait avancer le processus, soit le renvoie à l'attention humaine. Parce que tout ce qu'un worker fait passe par les mêmes outils gouvernés, les mêmes contrôles de permission et la même journalisation d'audit que n'importe quel autre acteur de la suite, un AI Worker est un véritable collègue dans le processus, responsable et borné, et non une automatisation opaque tournant à côté de celui-ci.