In questa pagina
Considera un compito illustrativo nel browser composto da cento passaggi. Supponi che ciascuno riesca nel 99% dei casi, indipendentemente dagli altri. La probabilità che riescano tutti è 0.99^100, circa il 36,6%.
Il novantanove per cento sembra eccellente. Il trentasei per cento molto meno.
La discussione originale sul lavoro transazionale nel browser usa questo calcolo per un punto preciso: il cliente ottiene valore quando il compito è finito, mentre costi e rischi di errore si accumulano a ogni passaggio. È aritmetica basata su un’ipotesi, non il tasso di successo pubblicato di un agente browser o di una sincronizzazione Tajo. Gli errori reali possono dipendere gli uni dagli altri. Un accesso scaduto, per esempio, può compromettere varie azioni successive.
La domanda utile, quindi, non è «Quanto era accurato l’ultimo clic del modello?». È «Lo stato richiesto dall’utente è comparso?».
L’unità che conta è la transazione
Immagina un agente che apre un portale assicurativo, trova un documento, lo scarica e verifica che appartenga all’account giusto. Può attraversare correttamente 99 schermate e scaricare il file sbagliato alla centesima. Un registro pieno di clic riusciti non ripara il risultato.
La stessa distinzione vale per un’integrazione. Un agente può trovare un’API, proporre una mappatura dei campi e salvare una bozza. Nessuna di queste azioni significa che un contatto nella destinazione abbia ora lo stato di consenso previsto. Il lavoro è concluso soltanto quando l’operazione approvata è stata eseguita e la condizione finale pertinente è stata controllata.
È la differenza tra attività e completamento. L’attività è facile da contare. Il completamento richiede una definizione.
Per un download, la prova potrebbe essere un file il cui identificativo dell’account corrisponde alla richiesta. Per la sincronizzazione di un contatto, potrebbe essere un record di destinazione con identificativo, campi e stato dei permessi di comunicazione corretti. Il controllo deve esaminare ciò che interessava all’utente. Una risposta positiva dalla chiamata precedente prova che quella chiamata ha risposto. Può non provare che la destinazione sia cambiata come previsto.
La guida Tajo a collegare gli strumenti aziendali parte dal flusso e dalla fonte autorevole per ciascun oggetto dati. Queste scelte danno significato al controllo finale. Se due sistemi rivendicano entrambi la proprietà di un campo, persino una scrittura eseguita perfettamente può produrre uno stato sbagliato nel tempo.
Il costo di un’altra decisione
Con la stessa ipotesi del 99%, dieci decisioni indipendenti danno circa il 90,4% di successo per l’intera sequenza. Cinquanta danno circa il 60,5%. Cento circa il 36,6%.
Probabilità di successo dell’intera sequenza (%)
Numero di passaggi indipendenti
- Successo ipotizzato del 99% per passaggio
Leggi i valori calcolati
| Passaggi | Successo dell’intera sequenza (%) |
|---|---|
| 0 | 100,0 |
| 10 | 90,4 |
| 25 | 77,8 |
| 50 | 60,5 |
| 75 | 47,1 |
| 100 | 36,6 |
La curva scende rapidamente perché le probabilità si moltiplicano, anche quando la media sembra buona. Ogni decisione aggiuntiva deve giustificare il proprio posto.
Questo non significa fondere tutte le chiamate API in un’operazione gigantesca. Alcune chiamate sono deterministiche: recuperare una pagina con un cursore noto, confrontare un identificativo o scrivere un campo secondo una mappatura approvata. Il modello non deve decidere di nuovo per ogni record. Altre richiedono un vero giudizio: un nuovo campo del fornitore, un messaggio d’errore cambiato o una richiesta la cui responsabilità è incerta.
La divisione pratica è lasciare che il giudizio progetti o ripari una regola, e che il codice ordinario la applichi quando è stabile. Il reverse ETL è un esempio di movimento ripetuto dei dati: dovrebbe essere la pipeline, non una conversazione, a eseguire le operazioni ordinarie su ogni riga. Un agente può comunque aiutare a decidere che cosa debba fare la pipeline.
È un confine, non uno slogan. Se il fornitore cambia il significato di un campo, una regola deterministica può ripetere perfettamente l’azione sbagliata. Il sistema deve riconoscere quando le sue ipotesi non valgono più e riportare il caso in revisione.
Perché un unico grande strumento non basta
Un’obiezione ragionevole è: «Se le sequenze lunghe falliscono, mettiamo tutto dietro un’unica chiamata». Funziona quando lo strumento rappresenta una transazione ben definita con un risultato controllabile. Fallisce quando nasconde soltanto un processo lungo e incerto.
Supponi che syncCustomer() restituisca success: true dopo aver inviato un aggiornamento. Se la destinazione elabora gli aggiornamenti in seguito, la chiamata non può ancora provare lo stato finale del contatto. Lo strumento ha ridotto i passaggi visibili, ma non l’incertezza.
Un’interfaccia migliore espone lo stato rilevante: accettato, applicato, verificato o fallito. Ogni parola dovrebbe corrispondere a una prova. Una scrittura accettata può bastare per un’anteprima a basso impatto. Prima di definire completata una modifica a un pubblico di campagna o al consenso, serve un controllo nella destinazione.
In questa vista Tajo proposta, una richiesta accettata e un aggiornamento applicato restano separati da uno stato della destinazione verificato. Il controllo finale è ancora in sospeso. La distinzione dà uno scopo al passo successivo: esaminare ciò che la destinazione ha salvato. Contare un’altra chiamata riuscita lascerebbe senza risposta la domanda iniziale.
Una scrittura completata richiede ancora prove
La sincronizzazione del cliente è terminata?
Scrittura applicata. Verifica in sospeso.
Lo stato nella destinazione non è ancora stato verificato.
Attività di sincronizzazione
- Richiesta accettata
- Aggiornamento applicato
- Verifica della destinazione in sospeso
Esecuzione di esempio · 14:32 UTC
Cosa sappiamo
- Risposta del fornitore
- Accettata
- Risultato della scrittura
- Applicato
- Rilettura dalla destinazione
- In sospeso
Una chiamata riuscita non prova lo stato finale.
Schema proposto ispirato al registro delle attività di Tajo. Questa illustrazione aggiunge uno stato di verifica; non afferma che la rilettura dalla destinazione sia già implementata.
Cambia anche la misurazione. Registra i tentativi se aiutano a capire i costi, e gli errori intermedi se rivelano un passaggio rotto. Ma valuta il flusso dalle transazioni completate e verificate, specificando accanto al numero come sono state verificate. Un team che riferisce «il 99% delle chiamate è riuscito» non ha ancora risposto alla domanda se i clienti abbiano ottenuto il risultato.
La spiegazione dei server MCP mostra come gli strumenti consentano a un assistente di chiamare un altro sistema. L’accesso allo strumento è soltanto l’inizio. Il contratto è lo stato che rimane dopo.
Cento buoni clic possono ancora non lasciare nulla. Conta il risultato.
Domande frequenti
Perché un flusso lungo fallisce se i singoli passaggi di solito riescono?
Se ogni passaggio riesce indipendentemente con probabilità p, una sequenza di n passaggi riesce con probabilità p elevato alla n. Assumendo il 99% per passaggio, cento passaggi si completano circa nel 36,6% dei casi. Gli errori reali possono essere correlati: il calcolo è un esempio, non una percentuale misurata per gli agenti.
Ridurre il numero di chiamate agli strumenti garantisce maggiore affidabilità?
No. Meno chiamate aiutano solo se l’operazione combinata mantiene i controlli e i punti di recupero giusti. Una sola chiamata opaca può nascondere una scrittura fallita tanto facilmente quanto una lunga sequenza può perdere il filo.
Che cosa dovrebbe misurare un team per un flusso con agenti?
Misura il completamento verificato della transazione richiesta dall’utente, non solo le chiamate al modello riuscite. Definisci l’artefatto o lo stato della destinazione che prova la conclusione del lavoro, poi registra quanto spesso compare al termine dell’intero flusso.