Il software aziendale ha un utente in mente, ed è sempre stato lo stesso: una persona con occhi per leggere uno schermo e mani per compilarlo. Ogni modulo, scheda, wizard e dashboard è una concessione alla memoria di lavoro e all'attenzione di quella persona. Il modello di dati sottostante è solitamente solido. L'interfaccia è una rappresentazione di esso per un tipo di lettore.
È arrivato un secondo tipo di lettore. Un agente AI non guarda uno schermo; legge un elenco di strumenti con nomi, descrizioni e schemi, e li chiama. Il software che vuole essere utilizzato da quell'utente deve esporre le sue azioni come strumenti, applicare permessi a ogni chiamata, chiedere per design e mantenere il record come sottoprodotto. Questo è ciò che significa software agent-native, ed è un cambiamento più grande rispetto all'aggiunta di una finestra di chat ai vecchi schermi.
Ogni schermo è un'ipotesi su chi sta guardando.
Considera cosa è un ERP dal punto di vista del suo utente. Dietro il marchio c'è un insieme di tabelle e regole: clienti, articoli, ordini, fatture, movimenti di magazzino e le restrizioni che li mantengono coerenti. Davanti a questo c'è la parte su cui è stata spesa la maggior parte del denaro: diverse migliaia di schermi che presentano quelle tabelle a una persona pochi campi alla volta, in un ordine che una persona può seguire, con etichette che una persona può leggere e pulsanti che una persona può trovare.
Ognuno di quegli schermi codifica un'ipotesi su chi si trova dall'altra parte. L'ipotesi è una persona con una memoria di lavoro limitata, quindi il modulo è suddiviso in schede. Una persona che legge da sinistra a destra, quindi il campo importante va in alto a sinistra. Una persona che può tenere in mente circa sette cose, quindi il dashboard ha sei riquadri. Una persona che commetterà errori di battitura, quindi c'è validazione al momento dell'invio. Una persona che si stanca, quindi il percorso comune ha meno clic. Tutto questo è un buon design per l'utente che il designer aveva, e per quattro decenni quell'utente è stato l'unico esistente.
La conseguenza è che l'interfaccia è una rappresentazione approssimativa del modello di dati per un tipo di lettore. Il modello sa che una fattura ha righe, un cliente, una data di scadenza e uno stato; lo schermo mostra le righe su una scheda, il cliente su un'altra e lo stato come un colore. Un lavoro che tocca cinque record significa cinque schermi, e la persona porta il filo tra di essi nella propria testa. Quel filo è la maggior parte di ciò per cui un'azienda paga il proprio personale amministrativo.
Il nuovo utente ha strumenti, non mani
Un agente AI che opera in un sistema aziendale non riceve nulla di tutto ciò. Ciò che riceve, quando si connette tramite il Model Context Protocol, è il risultato di una richiesta per elencare gli strumenti: per ciascuno, un nome, una descrizione scritta per un modello da leggere, uno schema per i suoi input e, facoltativamente, un'annotazione che indica se lo strumento legge solo, se può distruggere qualcosa e se chiamarlo due volte è sicuro. L'agente sceglie uno strumento, lo chiama con argomenti digitati, legge il risultato e sceglie di nuovo. Il riassunto del protocollo stesso è che è un modo standardizzato per connettere applicazioni AI a sistemi esterni, come un porto comune collega i dispositivi, e i principali clienti ora lo parlano: Claude, ChatGPT, Cursor e VS Code tra di essi.
Guarda cosa non ha bisogno questo utente. Non ha bisogno che la fattura sia suddivisa in schede, perché può tenere l'intero record contemporaneamente. Non ha bisogno che il campo importante sia in alto a sinistra, perché non c'è un sinistro. Non ha bisogno di sei riquadri, perché può chiedere il numero che desidera. Non si stanca, e non ci sono clic. Ogni concessione che ha reso lo schermo buono per una persona è, per questo utente, irrilevante o un ostacolo.
E guarda a cosa ha bisogno invece, che lo schermo non ha mai fornito. Ha bisogno che la descrizione di ogni azione sia precisa, perché la descrizione è l'intero della sua comprensione. Ha bisogno che lo schema sia completo, perché non può vedere un esempio. Ha bisogno di sapere quali azioni sono sicure da ripetere. Ha bisogno che il risultato dica cosa è successo e cosa può fare dopo. Per questo utente, la documentazione è l'interfaccia, e la denominazione è design: uno strumento ampio con una descrizione di due righe è un prodotto peggiore rispetto alla stessa capacità come tre strumenti con nomi semplici e descrizioni oneste, qualunque sia l'aspetto degli schermi sopra di essi.
La deviazione attraverso lo schermo non durerà
La prima risposta a un nuovo utente è sempre di vestirlo come il vecchio. L'automazione dei processi robotici ha fatto questo per un decennio: un bot accede con un account di servizio e guida gli schermi come se avesse mani, trovando il pulsante tramite il suo selettore o le sue coordinate. La versione attuale fornisce a un modello linguistico uno screenshot e un cursore. L'uso del computer di Anthropic fa esattamente questo, e la sua documentazione è attenta a dire dove appartiene: esiste per i casi in cui non è disponibile un'interfaccia più stretta, ti indirizza a uno strumento del browser quando il lavoro rimane all'interno di una pagina e chiede a una persona di confermare qualsiasi cosa con conseguenze reali significative, comprese le transazioni finanziarie.
Il costume è costoso da indossare. Uno schermo non fa promesse a una macchina, quindi ogni modifica apportata per la persona rompe l'automazione che finge di essere tale. Ogni strato tra l'agente e l'azione, lo screenshot, il tentativo di indovinare quale pixel sia il pulsante, il testo digitato che potrebbe o meno essere finito nel campo giusto, è un luogo in cui si può sbagliare, e un modello è già un luogo in cui si può sbagliare. La guida tramite schermo è il ponte che costruisci mentre il sistema sottostante non ha nulla di meglio, e i fornitori dei bot lo dicono loro stessi: ora descrivono il robot come uno strato di esecuzione che un agente chiama per i sistemi che ne hanno ancora bisogno.
Ciò che il software deve diventare
Se l'argomento finora è valido, la forma del software agent-native ne deriva, ed è più di un'API a parte. Cinque proprietà devono essere vere contemporaneamente.
- Ogni azione è uno strumento. Non una dozzina che il fornitore pensava fosse sicura, ma l'intera superficie che una persona può raggiungere attraverso gli schermi: creare, leggere, spostare, approvare, inviare, riconciliare. Qualsiasi cosa in meno, e l'agente deve tornare allo schermo per il resto.
- Ogni chiamata porta un'identità. L'agente agisce come una persona specifica, attraverso un accesso normale, e gli strumenti che gli vengono offerti sono filtrati in base al ruolo di quella persona prima che li veda e controllati di nuovo quando vengono eseguiti. Un agente con accesso completo al sistema è un fallimento di design, non una funzionalità.
- Chiede per design. Alcune azioni vengono eseguite; alcune sono in attesa di una persona; alcune vengono rifiutate outright. Il protocollo stesso afferma che ci deve sempre essere un umano nel loop in grado di negare una chiamata a uno strumento, e i principali clienti chiedono prima di una scrittura per impostazione predefinita. Il software deve rendere esplicite le categorie piuttosto che sperare che il modello sia educato.
- La spesa ha un limite. Dove il ragionamento del sistema costa denaro, o dove uno strumento impegna denaro, c'è un limite per connessione che il sistema applica e il modello non può superare con le parole.
- Il registro è il prodotto. Ogni chiamata, i suoi input e il suo risultato, sotto l'identità che l'ha generata, sono esaminabili nello stesso modo in cui si esaminano le azioni di una persona. Per un agente, la traccia di audit è come si costruisce la fiducia, una settimana alla volta.
Una sesta proprietà è meno un requisito che una conseguenza. Quando il lavoro viene svolto tramite strumenti, il registro è mantenuto come un sottoprodotto: l'agente che fattura, insegue e riconcilia lascia esattamente la fattura, l'inseguitore e la riconciliazione che una persona avrebbe digitato, senza la digitazione. Gli schermi sopravvivono, per guardare, rivedere e decidere. Smettono di essere l'unico luogo in cui può avvenire il lavoro.
L'obiezione da prendere sul serio
La più forte obiezione ammette che gli agenti possono svolgere il lavoro e sottolinea che a volte lo fanno in modo errato, con sicurezza, in una scrittura. Questo è vero, e la documentazione onesta lo afferma: ChatGPT tratta qualsiasi strumento senza un'annotazione di sola lettura come una scrittura e richiede conferma per impostazione predefinita; Claude chiede approvazione prima di invocare uno strumento da un connettore personalizzato e avverte che un server malevolo potrebbe contenere istruzioni nascoste. I clienti hanno ragione a essere cauti, e anche un'azienda dovrebbe esserlo.
Ma nota dove deve risiedere la cautela. Non può risiedere nel modello, che è la parte che potrebbe sbagliarsi. Deve risiedere nel software, che è esattamente dove il buon software l'ha già messa per gli utenti umani. Validazione, permessi, soglie di approvazione, annulla, audit: ognuno di questi esiste perché l'utente precedente ha commesso errori, con sicurezza, in una scrittura. Il software nativo per agenti prende sul serio quella vecchia disciplina ad ogni azione piuttosto che nei pochi che il designer dello schermo ha ricordato, e la applica a un utente che chiamerà cento strumenti prima di pranzo.
Una seconda obiezione è il determinismo. Alcuni lavori devono produrre lo stesso output per lo stesso input, provabilmente, ogni volta. Quel lavoro dovrebbe rimanere un flusso di lavoro fisso, e l'agente dovrebbe chiamare il flusso di lavoro come uno strumento piuttosto che improvvisarlo. Il giudizio non sostituisce le regole qui; il sistema ha bisogno di entrambi, esposti a un utente che può distinguerli.
Chi lo costruisce e per chi
L'ultima conseguenza è quella che l'imprenditore dovrebbe notare. Se l'utente del software può essere un agente, anche il costruttore può esserlo. Un sviluppatore descrive l'app che desidera a un agente che già ha, l'agente la costruisce utilizzando un insieme di strumenti di costruzione, lo sviluppatore la valida localmente e la pubblica, e dal primo giorno ogni strumento che l'app distribuisce è disponibile a ogni altro agente sulla piattaforma. L'azienda che la installa non impara i suoi schermi; il suo personale porta l'agente che già utilizza e descrive il risultato. Questo è l'accordo attorno al quale è costruito Sois, offerto qui come una implementazione dell'argomento piuttosto che come la sua conclusione.
La conclusione è più semplice. Per quarant'anni la domanda che un designer di software si è posto è stata cosa ha bisogno di vedere la persona dall'altra parte. Il prossimo utente non vede. Legge un contratto e chiama ciò che è autorizzato a chiamare, e lo farà per conto delle stesse persone per cui sono stati costruiti gli schermi. Il software che tratta quell'utente come un cittadino di prima classe sarà operato fluentemente. Il software che mantiene lo schermo come la sua unica porta sarà ancora operato, attraverso un buco della serratura, da un agente che indossa un costume, fino a quando i suoi proprietari si stancheranno del costume e si muoveranno.
- Protocollo di Contesto del Modello: introduzione cosa è il protocollo, l'analogia della porta e i clienti che lo supportano.
- specifica del Protocollo di Contesto del Modello: sicurezza e fiducia consenso e controllo dell'utente, sicurezza degli strumenti e principio dell'uomo nel ciclo
- Anthropic: strumento per l'uso del computer controllo dello schermo per Claude, dove appartiene, e le indicazioni per confermare azioni consequenziali
- Sois: cos'è Sois la piattaforma descritta nell'ultima sezione, come una implementazione
Questo articolo viene revisionato quando i prodotti che descrive cambiano. Prossima revisione programmata: 4 dicembre 2026.
