Cominciamo col togliere un'ambiguità di vocabolario, perché è all'origine di molti malintesi in questo mercato. In UNYX, l'orchestrazione indica la macchina che esegue. L'orchestratore indica la persona qualificata che pilota quella macchina da voi. Le due parole si assomigliano, non indicano la stessa cosa, e la seconda è un mestiere.
I componenti, nell'ordine in cui una richiesta li attraversa
- Una porta d'ingresso unica. Modulo, e-mail, messaggistica, chiamata da un altro software: tutto arriva da un punto di passaggio che autentica, convalida il formato e registra.
- Una base dati che fa autorità. Ogni richiesta vi diventa una riga, con il suo stato. Gli agenti non lavorano mai su una copia che sta da un'altra parte.
- Una coda di attesa. Tutto ciò che è lungo, costoso o soggetto a errore passa da lì, con nuovo tentativo e abbandono motivato.
- Agenti specializzati. Un agente, una missione, un perimetro di strumenti. Non un agente unico che saprebbe fare tutto.
- Uno strato di regole deterministiche. Posto fra gli agenti e il mondo esterno, rifiuta le azioni vietate prima che partano.
- Un registro. Ogni azione porta il suo autore, il suo motivo, il suo costo, il suo esito.
Dove sono archiviati i dati
In una base relazionale ospitata nell'Unione europea, con regole di accesso applicate riga per riga: un utente può leggere solo ciò che il suo ruolo autorizza, e quella verifica avviene lato server, mai nel browser. I documenti e gli allegati vivono in un archivio privato accessibile unicamente tramite collegamenti firmati e temporanei.
Le chiamate ai modelli trasportano soltanto ciò di cui il compito ha bisogno. Questo punto merita di essere posto a qualsiasi fornitore: inviare un'intera base a un modello per rispondere a una domanda semplice è insieme costoso e inutilmente rischioso.
Come comunicano gli agenti
Non conversando fra loro in linguaggio naturale, cosa spettacolare in una dimostrazione e ingestibile in produzione. Comunicano attraverso lo stato della richiesta nella base: un agente legge uno stato, produce un risultato strutturato, scrive il nuovo stato. Il successivo prende il testimone.
Il vantaggio è decisivo al momento della diagnosi: si può aprire qualsiasi richiesta e leggere esattamente chi ha fatto che cosa, in quale ordine e con quale esito. Una conversazione fra agenti non lascia quella traccia.
Un sistema che non si può rileggere dopo non è un sistema. È una scatola nera con delle fatture.
I permessi
Tre livelli, tutti necessari. Il livello utente, con ruoli e abilitazioni verificate a ogni richiesta. Il livello agente, in cui ogni agente riceve il minimo indispensabile di strumenti e accessi necessari alla sua missione. E il livello azione, in cui le operazioni con effetto esterno passano dallo strato di regole, qualunque sia la loro origine.
Quest'ultimo livello è il più importante e il più spesso assente: la stessa verifica deve applicarsi all'azione avviata da un agente e a quella avviata da un umano dall'interfaccia. Altrimenti la sicurezza dipende dal percorso seguito, il che equivale a non averla.
Gli errori
Nuovo tentativo con attesa progressiva sui guasti passeggeri, abbandono motivato e avviso oltre quel punto, ripiego documentato quando un modello non è disponibile, soglia di fiducia che rimanda a un umano e annullamento reale delle azioni reversibili. Descriviamo questo dispositivo, e la lezione che l'ha generato, in l'articolo sugli errori.
Come verificare
Chiedete una dimostrazione in tre schermate, non una presentazione: il registro di una richiesta reale dall'inizio alla fine, la schermata in cui un umano convalida un'azione e il comportamento del sistema quando si provoca un errore. Un fornitore che ha costruito tutto questo può mostrarlo subito. La nostra pagina Orchestratore IA spiega il resto: chi pilota, con quale impegno e su quali accessi si esegue l'IA.
