In questa pagina
Una sincronizzazione proposta ha venti caselle. La settima copia uno stato in un foglio di calcolo. L’ottava riformatta il foglio per una piattaforma email. La nona invia un’email a un responsabile per approvare l’importazione. Il piano chiede quale agente debba eseguire le caselle dalla settima alla nona.
La prima domanda è perché esistano. L’esempio è illustrativo, non la verifica di un team reale.
Una discussione sulla progettazione dei flussi propone quattro categorie per il lavoro: eliminare il passaggio, usare codice normale, usare un agente o lasciare una decisione umana. La mossa utile precede la scelta del modello. Cancellare un passaggio può eliminare il bisogno di tutti gli strumenti che lo circondano.
Parti dal risultato visibile al cliente
Nomina il risultato che il flusso deve produrre. Per un collegamento tra negozio e piattaforma email, potrebbe essere «un cliente che ha acquistato non riceve più il promemoria per il carrello». Ciò richiede uno stato, tempi e una regola di esclusione. Non richiede necessariamente un foglio di calcolo, un’esportazione completa ogni notte o la casella di posta di un responsabile.
L’illustrazione Tajo qui sotto concentra la revisione sulla mappatura proposta e sul confine prima dell’attivazione. Non implementa la soppressione dei promemoria del carrello. Per ottenere quel risultato bisogna prima definire il segnale di acquisto e la regola di soppressione. Aggiungere un altro campo mappato non sostituisce nessuna delle due decisioni.
Controlla una sincronizzazione prima dell'avvio
Sincronizza gli aggiornamenti dei clienti con la mia piattaforma email.
Sincronizzazione clienti
| Campo di origine | Campo di destinazione | Regola |
|---|---|---|
email | EMAIL | Diretta |
first_name | FIRSTNAME | Diretta |
last_name | LASTNAME | Diretta |
Anteprima sintetica superata
3 campi mappati · Nessuna scrittura nella destinazione
Schema illustrativo basato sugli strumenti di mappatura di Tajo. Un'anteprima sintetica e una bozza salvata non attivano la sincronizzazione.
Ripercorri il percorso esistente a ritroso dal risultato. Per ogni passaggio, chiedi che cosa fallirebbe se sparisse. Un vero controllo ha una risposta: si perderebbe il consenso, si ignorerebbe una contestazione di pagamento o potrebbe partire un invio non autorizzato. Un passaggio di consegne abituale può avere solo una risposta storica: il vecchio sistema richiedeva un file.
La categoria «elimina» non autorizza a cancellare le protezioni. Capisci lo scopo di ogni passaggio prima di classificarlo.
- Risultato richiestoeffetto sul clientetorna indietro
- Esamina i passaggiscopo e controlloelimina passaggi inutili
- Lavoro mantenutoresponsabile e verificabile
La verifica individua il risultato da consegnare e le dipendenze che lo proteggono davvero. Se un foglio contiene un giudizio commerciale assente altrove, il giudizio va conservato anche se il file scompare.
| Tipo di passaggio | Domanda | Esempio in un flusso illustrativo per carrelli |
|---|---|---|
| Elimina | Protegge o produce il risultato richiesto? | Un’esportazione duplicata che nessuno legge |
| Codice normale | La regola è esatta e stabile? | Bloccare un promemoria quando esiste un acquisto verificato |
| Giudizio del modello | Serve un’interpretazione delimitata? | Classificare una richiesta testuale per il team giusto |
| Persona o regola approvata | La scelta concede autorità o ha conseguenze importanti? | Approvare l’accesso ai dati dei clienti |
La tabella è uno strumento progettuale. Non riferisce come siano stati classificati i passaggi reali di un’azienda.
Metti le regole esatte nel codice
Una chiamata API, la convalida di un campo, il confronto tra date o il controllo di un permesso non migliora perché un modello lo improvvisa. Il codice può esprimere una regola invariabile, eseguirla due volte allo stesso modo e produrre un errore ispezionabile. Usalo quando la regola si può dichiarare.
Nell’esempio del carrello, un evento d’acquisto può arrivare tardi o due volte. Il programma deve identificare l’ordine, confrontare lo stato attuale e rifiutare il promemoria quando l’acquisto è noto. Se non può stabilire se sia avvenuto, serve uno stato d’incertezza. Un modello non può autorizzarsi a indovinare che il cliente non abbia comprato.
Alcuni compiti resistono alle regole esatte. Una richiesta al supporto potrebbe dire: «Ho comprato ieri ma la ricevuta mostra il mio vecchio indirizzo». Instradarla può richiedere un giudizio semantico delimitato. L’output dovrebbe essere un team noto oppure «incerto», non un’istruzione generica a modificare l’ordine. Tieni separata la decisione del modello dal codice che controlla accessi e scritture.
Perché un agente unico può nascondere i passaggi
«Un agente potrebbe leggere il flusso e fare tutto». In una demo può sembrare più semplice. In produzione qualcuno deve ancora spiegare perché può vedere un record, quali azioni può compiere e come annullare un’azione sbagliata. Un agente troppo ampio spesso nasconde gli stessi passaggi dentro un prompt, togliendo le etichette che li rendevano verificabili.
Un’altra obiezione è che classificare il flusso costa tempo. Vero: fallo in breve. Scegli un risultato per il cliente, elenca i passaggi necessari e chiedi che cosa apporta ciascuno. L’esercizio vale se riduce il lavoro o chiarisce le responsabilità. Un’analisi enorme di ogni sistema vicino diventerebbe un’altra casella.
Prova la classificazione con un caso normale e uno di errore. Se un passaggio rimosso era in segreto un controllo, il test dovrebbe rivelarlo. Se un giudizio del modello non può essere valutato con esempi, restringilo o restituisci la decisione a una persona. Se il codice va cambiato per ogni eccezione del cliente, separa le meccaniche stabili dalla regola commerciale locale.
Anche la verifica ha bisogno di una condizione di arresto. Un team può scomporre ogni compito finché la classificazione costa più del lavoro risparmiato. Fermati quando ogni passaggio mantenuto ha un responsabile, un evento di avvio e una ragione verificabile per esistere. Registra l’unica incertezza che cambierebbe il progetto, poi provala nella più piccola parte reale. Per una sync potrebbe essere se l’evento d’acquisto arriva abbastanza presto da fermare un promemoria in coda. La guida alle integrazioni offre il percorso generale; i quattro gruppi impediscono di conservare passaggi inutili. Rivedili quando cambiano il flusso o i permessi.
Il passaggio più economico è quello che il risultato non ha mai richiesto.
Domande frequenti
Che cosa va eliminato prima di automatizzare?
Un passaggio che esiste solo per compensare un passaggio di consegne eliminabile, un record duplicato o un rapporto inutilizzato è candidato. Controlla chi usa il risultato e quali protezioni offre prima di cancellarlo.
Quando un passaggio richiede un modello?
Usa un modello per un giudizio semantico mirato che non si può esprimere come regola esatta e stabile, con input osservabili, output tipizzati e un percorso per l’incertezza.
Quali decisioni dovrebbero restare a una persona?
Tieni presso una persona responsabile o una regola esplicitamente approvata le scelte che richiedono consenso, concedono permessi o hanno conseguenze oltre l’ambito autorizzato del sistema.