Gli AI Worker mettono a disposizione l'intero ciclo di vita di una forza lavoro sintetica. Gli amministratori definiscono le identità dei worker, ciascuna con una persona visibile, un ruolo, un system prompt che ne modella tono e competenze e parametri di generazione come il budget di token e la temperatura. Ogni worker dispone di una coda di lavoro, di un thread di conversazione persistente e di un insieme di assistenti collegati attraverso i quali può essere raggiunto o tramite i quali prende l'iniziativa. I worker interrogano i dati operativi in tempo reale, eseguono scritture e cambi di stato, avviano attività pianificate in modo automatico, sorvegliano le eccezioni, estraggono informazioni strutturate dai documenti e agiscono come revisori e approvatori all'interno dei processi aziendali.

Dietro ogni worker esistono due percorsi di risposta, selezionati automaticamente. Quando un assistente esterno è collegato e raggiungibile, la piattaforma gli inoltra la richiesta e ne riceve la risposta tramite un callback firmato e autenticato. Quando non è disponibile alcun assistente esterno, un modello integrato viene eseguito direttamente sullo stesso insieme di strumenti governati, cosicché un worker non resta mai muto e non risponde mai partendo da un contesto obsoleto. Entrambi i percorsi attingono a un unico registro condiviso di strumenti aziendali, garantendo che un worker si comporti in modo identico sia che a ragionare sia un assistente esterno sia il modello integrato. La conversazione, la gestione della coda, la configurazione dei worker, le impostazioni dei provider di modelli e la registrazione degli assistenti collegati sono gestite tutte da un'unica superficie di gestione AI.

Al centro si colloca l'AI Worker: un'identità persistente con un nome, un ruolo e la memoria di tutto ciò che gli è stato chiesto. Un worker è definito meno dal codice che da tre elementi che lo circondano. Il primo è un ruolo, che porta con sé le autorizzazioni del worker ed è l'unica autorità su ciò che può vedere e fare; un worker non può mai superare il perimetro descritto dal proprio ruolo e la modifica di tale ruolo cambia immediatamente il suo raggio d'azione. Il secondo è la coda di lavoro, un arretrato ordinato di attività di cui il worker è titolare, ciascuna con una priorità, una pianificazione facoltativa, un ciclo di vita che va dallo stato in coda, passando per in corso, fino a un esito definito, e un risultato registrato. Il terzo è la conversazione, un registro in sola aggiunta dei turni di utente, worker e sistema che conferisce continuità a ogni scambio e un audit trail completo.

Attorno a questi elementi ne gravitano due di supporto. Un provider di modelli descrive quale motore di ragionamento alimenta un worker, risolto nel momento dell'uso, così che un singolo worker possa sovrascrivere l'impostazione predefinita dell'organizzazione senza alcuna modifica al worker stesso. Gli assistenti collegati descrivono gli strumenti esterni verso cui un worker può essere instradato, ciascuno con il proprio endpoint, le proprie credenziali e il proprio stato di salute. Le relazioni sono volutamente semplici: un ruolo modella molti worker, un worker possiede una sola coda e una sola conversazione e può disporre di diversi assistenti collegati, e un provider può alimentare molti worker. Nulla di tutto ciò appartiene a un cliente o a un libro mastro; si tratta di configurazione e persona, custodite nel nucleo della piattaforma affinché identità e autorizzazioni siano governate in un unico luogo.

L'interazione quotidiana è conversazionale. Un utente apre il pannello dei worker, seleziona un worker per nome e ruolo e digita una richiesta. Il messaggio viene registrato e confermato istantaneamente, quindi inoltrato senza bloccare l'interfaccia. Se risponde un assistente collegato, la sua risposta arriva tramite il callback e sostituisce l'indicatore di attesa; se nessuno risponde, il modello integrato compone direttamente la risposta, invocando gli strumenti governati richiesti dalla richiesta e restituendo un testo fondato e supportato dai dati. Il pannello si mantiene aggiornato tramite un polling adattivo che si intensifica durante gli scambi attivi e si allenta quando il thread è inattivo.

Il secondo flusso è autonomo. Un utente pianifica un'attività e l'elemento entra nella coda del worker con una priorità e, ove impostato, un orario di esecuzione futuro. Lo scheduler preleva gli elementi in coda, li esegue attraverso il modello sull'insieme di strumenti in tempo reale con un numero limitato di passi di ragionamento e registra l'esito. Un'attività che si conclude senza errori viene contrassegnata come tale; una in cui ogni azione è riuscita ma alcune sono state rifiutate o hanno prodotto errori viene presentata onestamente come risultato parziale, con un avviso chiaro per la revisione umana; una che fallisce del tutto viene registrata come fallita. Il terzo flusso è in entrata: gli assistenti esterni si collegano all'endpoint del protocollo proprio della piattaforma e operano gli stessi strumenti governati sotto l'applicazione degli ambiti, così che le capacità di un worker siano disponibili all'interno degli strumenti che le persone già utilizzano altrove.

Ciò che rende affidabile il modulo è che capacità e autorità non sono mai separate. Le autorizzazioni vengono applicate nel momento in cui uno strumento viene eseguito, non semplicemente quando un'attività viene messa in coda, cosicché una modifica di ruolo o la sospensione di un worker abbia effetto già dall'azione successiva. Ogni strumento dichiara un ambito, e tale ambito è mappato su una coppia concreta di autorizzazioni che viene verificata rispetto al ruolo del worker prima che lo strumento compia qualsiasi operazione; un worker privo del diritto restituisce un risultato pulito di autorizzazione negata invece di agire. Se per qualsiasi motivo le autorizzazioni di un worker non possono essere caricate, il sistema si risolve nel negare tutto, andando in sicurezza per costruzione.

La postura di sicurezza è stratificata in modo coerente. L'accesso interattivo avviene sotto sessioni autenticate, con controlli di capacità su ogni route. L'inoltro in uscita verso gli assistenti esterni è firmato con un codice di autenticazione del messaggio basato su chiave, così che i destinatari possano verificarne l'origine, e ogni inoltro trasporta il contesto del worker, una porzione limitata dello storico di conversazione e un indirizzo di callback monouso. I callback in entrata si autenticano con un bearer token verificato rispetto a un hash memorizzato, sono soggetti a rate limiting per worker, hanno dimensioni limitate e sono idempotenti, così che una consegna ritentata non duplichi mai una risposta. Gli scambi obsoleti scadono su un timer, gli assistenti irraggiungibili sono monitorati nello stato di salute e disattivati automaticamente, e ogni creazione di messaggio è registrata nell'audit con l'identità che agisce e l'indirizzo di origine. Il risultato è un'autonomia con tracciabilità documentale: i worker agiscono con rapidità, ma sempre entro un perimetro ispezionabile a posteriori.

Gli AI Worker sono il tessuto connettivo di Nashua 360, non un'isola. Attraverso il registro condiviso degli strumenti un worker raggiunge direttamente Business Relations per leggere e mantenere aziende, contatti e sedi; Accounting and Control per interrogare le fatture di debitori e creditori e il quadro finanziario più ampio; Catalog Management per cercare nel catalogo stratificato di prodotti e servizi; e Test Management e il modulo centrale System per i metadati e le diagnostiche della piattaforma. Ognuno di questi accessi è filtrato dalla stessa mappatura ruolo-ambito, cosicché un worker costruito per la finanza veda il libro mastro ma non il catalogo, a meno che il suo ruolo non stabilisca diversamente.

Poiché il modulo risiede nel nucleo della piattaforma, accanto ai ruoli e alla registrazione dei moduli, eredita integralmente il modello di identità e autorizzazione della suite invece di reinventarlo. Il ruolo di un worker è espresso nella stessa grammatica di autorizzazioni di quello di un utente umano, il che significa che governance, revisione e progettazione secondo il privilegio minimo costituiscono un'unica disciplina, valida sia per le persone sia per i worker sintetici. Ogni nuova capacità aggiunta a qualunque modulo diventa disponibile ai worker nel momento stesso in cui il suo strumento viene registrato, cosicché la superficie conversazionale e autonoma cresca di pari passo con il resto di Nashua 360 senza interventi di integrazione su misura.

All'interno del modulo i worker sono gli attori, e la loro portata è ampia. Rispondono alle domande interrogando i dati dei moduli in tempo reale e restituendo sintesi fondate, così che un utente possa chiedere un saldo creditore in essere o l'attività recente di un cliente e ricevere una risposta tratta dallo stato attuale del libro mastro e dai record delle relazioni, anziché da un report memorizzato. Eseguono azioni su richiesta o su pianificazione, creando e aggiornando record, generando elementi di lavoro e conducendo processi a più passaggi attraverso un ciclo di ragionamento limitato. Sorvegliano anomalie ed eccezioni e, quando un'attività pianificata si conclude con azioni rifiutate o fallite, generano una notifica di avviso e un messaggio di sistema chiaro, invece di lasciar passare in silenzio un risultato parziale.

Elaborano documenti e input non strutturati, estraendo campi strutturati per l'uso a valle, e supportano le decisioni raccogliendo e spiegando i dati alla base di una scelta. Aspetto cruciale: un worker può fungere da nodo di approvazione o revisione all'interno di un workflow: instradata una richiesta sotto la propria identità dotata di autorizzazioni, valuta l'elemento rispetto al proprio ruolo e alle proprie istruzioni, registra la propria determinazione nel tracciato della conversazione e fa avanzare il processo oppure lo rimanda all'attenzione umana. Poiché tutto ciò che un worker fa passa attraverso gli stessi strumenti governati, gli stessi controlli di autorizzazione e lo stesso audit logging di qualsiasi altro attore della suite, un AI Worker è un vero collega nel processo, responsabile e circoscritto, non un'automazione opaca che opera in disparte.