Un agente non può automatizzare ciò che non riesce a vedere

Entrate in una qualsiasi organizzazione e contate i sistemi. Un CRM. Un ERP. Una piattaforma di fatturazione. Uno strumento di pianificazione adottato da un team nel 2019. Un sistema di gestione dell'edificio con un'interfaccia web del 2014. Tre fogli di calcolo da cui dipende tutto. Una rete di telecamere. Uno spazio di messaggistica dove si prendono le decisioni vere.

Nessuno di questi è stato progettato per incontrarsi. Ognuno custodisce una versione parziale, e sicura di sé, dello stesso cliente, dello stesso sito, dello stesso bene. L'organizzazione non ha un mondo: ne ha undici, e mandare avanti l'attività significa riconciliarli a mano.

È questo l'ambiente in cui l'automazione deve davvero sopravvivere, ed è la ragione per cui così spesso delude.

In breve, ciò che segue: un agente può attraversare quelle giunture solo se l'ambiente sotto di lui sa già quattro cose — che cosa esiste, come è in relazione, che cosa l'agente può fare e che cosa è successo. Identità, contesto, autorità, prove. Il resto di questo saggio spiega perché ciascuna appartiene all'ambiente e non all'agente.

Che cosa vuol dire "vedere"

Il titolo usa una parola sola per parecchi lavori. Per agire su un cliente, un agente deve scoprire che il cliente esiste; capire che l'account nel CRM, il pagante nella fatturazione e il sito nel sistema dell'edificio sono lo stesso cliente; raggiungere i dati; sapere che cosa significa un campo e se questa copia è quella che conta; sapere quali azioni gli sono permesse; e osservare che cosa ha prodotto la sua azione. Un agente può avere le credenziali di tre record cliente e non sapere che sono un cliente solo. L'accesso è la parte facile.

Visibilità, in questo saggio, significa quindi la capacità di scoprire le entità rilevanti, le loro relazioni, il loro stato, i permessi che le riguardano e la loro storia, dentro un unico contesto operativo. La maggior parte di tutto questo non è una proprietà dell'intelligenza dell'agente. È una proprietà del terreno su cui l'agente sta in piedi.

Le giunture sono il punto in cui l'automazione muore

Un'automazione che vive dentro un solo sistema è facile, e di solito esiste già. Quelle che contano attraversano: arriva una richiesta, si cerca il cliente, si verifica il contratto, si riserva la risorsa, si avvisa il sito, si registra l'accaduto. Cinque sistemi, cinque credenziali, cinque modelli di dati, cinque idee diverse di che cosa sia un "cliente".

Costruita nel modo consueto, quell'automazione è uno script con cinque integrazioni e nessuna posizione riconosciuta. Tiene un insieme di chiavi ampio quanto è stato comodo emetterle. Si rompe quando uno dei cinque cambia un campo. Nessuno può dire che cosa le sia permesso fare senza leggerne il codice. E quando sbaglia, la traccia di ciò che è accaduto è sparsa su cinque registri che non condividono un identificatore.

Così la si avvolge di processo. Un calendario di patch per le sue dipendenze. Una revisione prima di ogni cambio di permessi. Un esercizio trimestrale per capire a che cosa abbia ancora accesso. L'automazione ha fatto risparmiare un'ora a settimana ed è costata un obbligo permanente — e l'obbligo cresce nel tempo, il risparmio no.

Perché gli agenti cambiano l'equazione

La frammentazione è stata tollerabile finché l'automazione è rimasta stretta. Uno script costruito attorno a un solo flusso è deterministico: quando il mondo si sposta, si ferma, e qualcuno se ne accorge. La sua autorità è piccola perché è piccola la sua ambizione.

Il valore di un agente viene dal contrario: operare tra più sistemi, adattarsi all'eccezione, decidere che cosa fare dopo. Più è capace, più attraversamento può fare — e più diventa pericoloso affidargli quell'attraversamento tramite credenziali sparse e presupposti propri di ciascuna applicazione. Un agente capace con cinque chiavi ampie non è un guadagno di produttività. È un nuovo soggetto nell'organizzazione senza la descrizione di un ruolo, i cui limiti sono ciò che per caso non ha ancora provato a fare.

Entrambi i costi della frammentazione crescono dunque con la capacità: le persone che fanno da livello di integrazione, e l'autorità che nessuno osa dare al software. La via d'uscita non sono agenti meno capaci. Gli agenti non hanno bisogno di un'autonomia illimitata: hanno bisogno di confini leggibili — un compito con un perimetro definito, e un ambiente che quel perimetro lo fa rispettare. Chiamiamola autonomia delimitata. Il resto di questo saggio riguarda che cosa deve essere vero, sotto, perché esista.

Perché i livelli che abbiamo già non fanno un confine

L'obiezione ovvia è che tutto questo esiste già. Ci sono le API, la gestione di identità e accessi, le piattaforme di integrazione, i bus di eventi, i data warehouse, le service mesh e, da poco, i gateway che si mettono davanti agli agenti. Ognuno è reale, e ognuno fornisce una proprietà a un livello.

La gestione delle identità risponde a chi può chiamare quale servizio. Non risponde a che cosa questo agente può fare a questo cliente attraverso cinque sistemi, perché il cliente non è una cosa di cui sappia nulla. Una piattaforma di integrazione sposta record tra modelli di dati, e ogni mappatura che contiene è un posto in più dove la domanda "è lo stesso cliente?" viene decisa, in modo diverso, da chi ha scritto la mappatura. Un warehouse sa che cosa è successo ieri e non può rifiutare una scrittura oggi. Un bus di eventi trasporta fatti senza autorità. Un gateway può misurare e registrare le chiamate di un agente, ma vede chiamate, non entità: può dire che l'agente ha letto qualcosa, non che cosa.

Questi pezzi si possono assemblare in visibilità, e le organizzazioni li assemblano davvero, un'automazione alla volta. Il punto è proprio questo: l'assemblaggio torna a essere un compito dell'automazione. Ogni nuovo agente ricava di nuovo l'identità, codifica di nuovo i permessi, ricollega da sé la propria traccia, e il confine che ottiene vale quanto l'ultimo pezzo di colla che lo tiene insieme. La tesi qui non è che la visibilità non si possa costruire in altro modo. È più stretta, e più difficile da liquidare: visibilità e autorità sono enormemente più robuste come primitive di un ambiente di esecuzione condiviso che come responsabilità ricreate in modo indipendente da ogni automazione — perché un confine ricostruito per ogni automazione è un confine che nessuno può leggere dall'esterno.

Quattro primitive

Messo sotto le applicazioni, dove ognuna di esse lo condivide, l'ambiente deve sapere quattro cose. Identità: che cosa esiste. Contesto: come entità e sistemi sono in relazione. Autorità: che cosa può fare questo agente. Evidenza: che cosa è successo. L'agente diventa lo strato sottile in cima, che decide come portare a termine un compito dentro quei quattro, invece dello strato spesso che deve stabilirli.

Quando un cliente è un'entità sola invece di cinque record, un'automazione non deve riconciliare nulla: le basta farvi riferimento. I cinque record non spariscono — la riconciliazione non scompare, si sposta. Si sposta sotto l'automazione, in un'infrastruttura il cui compito è mantenere un'identità operativa unica attraverso i sistemi: quale record è autorevole per quale attributo, come si risolve un conflitto, che aspetto aveva l'entità in un dato momento. È difficile, ed è difficile una volta sola, in un posto che ne risponde, invece che difficile di nuovo dentro ogni agente, in modo diverso.

Quando il permesso è un'autorizzazione su quell'entità invece di una chiave in un file di configurazione, la domanda "che cosa può fare" ha una risposta che si legge, si cambia e si revoca senza aprire il codice. Quando ogni azione finisce in un unico registro riferito allo stesso mondo, "che cosa è successo" è una query e non un'indagine.

Ecco che aspetto ha un rifiuto quando è l'ambiente a possedere il confine:

10:02:11  agente  lettura    ordini/cust-2481    3 righe · ok
10:02:14  agente  scrittura  fattura/inv-1094    1 riga  · ok
10:02:19  agente  lettura    payroll/*           rifiutato — nessuna autorizzazione

Per produrre quella terza riga non è stata applicata nessuna patch. Nessuna integrazione è stata irrobustita. L'agente ha chiesto e l'ambiente ha risposto, perché il confine non è mai stato qualcosa che spettava all'agente far rispettare.

Che cosa cambia nelle operazioni

Di solito l'argomento dell'efficienza viene presentato come tempo risparmiato su ogni attività. Quello più grande è un altro: un lavoro che prima era impossibile delegare diventa delegabile, perché è possibile delimitarlo.

Un'organizzazione non affida un'attività che attraversa più sistemi a un software che non riesce a vincolare. La affida a una persona — e la persona diventa il livello di integrazione: porta il contesto tra sistemi che non si parlano, assorbe le discrepanze ed è l'unica traccia duratura che il lavoro sia stato fatto bene. È lì che si annida il costo operativo reale, ed è invisibile in ogni dashboard perché somiglia a qualcuno che fa il proprio lavoro.

L'autonomia delimitata sposta quel lavoro. Non perché il software sia diventato più intelligente, ma perché per la prima volta gli si può affidare un compito con un perimetro definito: queste entità, queste azioni, questa finestra temporale — e il perimetro lo fa rispettare il terreno su cui poggia, non la cura di chi lo ha scritto.

I sistemi resteranno frammentati. Non è una fase che le organizzazioni attraversano: è l'aspetto che ha un patrimonio software reale dopo vent'anni di decisioni ognuna delle quali era corretta sul momento. Ciò che può cambiare è che cosa c'è sotto. La domanda non è se gli agenti possano operare attraverso software frammentato. Possono. La domanda è se l'ambiente dia loro un mondo che riescono a vedere, un'autorità entro cui possono essere delimitati, e un registro di ciò che hanno fatto.