Di Andrew Tan
Abbastanza fresco per un agente AI? Il budget di freschezza dei dati che nessuno definisce
La maggior parte dei team parla del contesto AI come un problema di archiviazione. La domanda più difficile è se i dati siano abbastanza freschi per l'azione che l'agente sta per intraprendere.
Molte conversazioni sull'infrastruttura AI sono ancora rivolte al collo di bottiglia sbagliato.
I team discutono di database vettoriali, cache dei prompt, memoria a lungo termine, server MCP e quale modello dovrebbe stare dietro l'agente. Tutto questo è importante. Nessuno di questi risponde alla domanda che effettivamente determina se un agente è sicuro da usare in produzione.
Quanto sono freschi i dati quando l'agente decide di fare qualcosa?
Questa domanda sembra noiosa. Non è noiosa quando l'agente invia il rimborso sbagliato, approva l'ordine sbagliato, intensifica l'incidente sbagliato o chiama lo strumento sbagliato perché sta guardando un record cliente di venti minuti fa.
La maggior parte dei team di dati comprende già qualità, lineage e schema drift. La freschezza viene trattata come un optional fino a quando gli agenti entrano in gioco. Poi la freschezza smette di essere una preferenza del dashboard e diventa un confine operativo.
Il contesto non è lo stesso del permesso
Questa è la parte che molti team saltano.
Un agente può avere molto contesto e avere comunque il contesto sbagliato per l'azione che vuoi che intraprenda. Dieci milioni di righe in un magazzino non aiutano se il campo che conta è cambiato tre minuti fa e la tua sincronizzazione avviene ogni ora.
Questa è la differenza tra dati informativi e dati azionabili.
I dati informativi aiutano un agente a spiegare cosa è successo la settimana scorsa. I dati azionabili gli permettono di decidere cosa dovrebbe succedere adesso.
Questi non sono lo stesso carico di lavoro.
Un copilota di supporto che riassume gli ultimi cinque ticket può tollerare un certo ritardo. Un agente che decide se un rimborso è già avvenuto non può.
Un assistente alle vendite che redige un resoconto del conto può lavorare con sincronizzazioni CRM notturne. Un agente che instrada un lead attivo basato sull'uso attuale del prodotto probabilmente ha bisogno di dati che siano vecchi di pochi minuti al massimo.
Un bot finanziario che prepara un riepilogo delle variazioni mensili può rimanere batch. Un agente che blocca un pagamento sospetto non può.
L'errore è trattare tutto il contesto AI come una categoria chiamata "dati AI-ready."
Non è una categoria. È una pila di decisioni con diversi requisiti di freschezza.
Il budget di freschezza
Il modo più semplice per pensare a questo è un budget di freschezza.
Ogni compito dell'agente ha un ritardo massimo accettabile tra ciò che è accaduto nel sistema sorgente e ciò che l'agente vede quando agisce.
Quel budget di ritardo dipende dalla conseguenza di essere sbagliati.
Ecco una versione semplice:
| Compito dell'agente | Budget di freschezza tipico | Cosa succede se lo manchi |
|---|---|---|
| Riepilogo settimanale del conto | 24 ore | Narrazione leggermente stantia |
| Q&A KPI interno | 1 a 4 ore | Risposte confuse, bassa fiducia |
| Instradamento dei lead di vendita | 5 a 15 minuti | Cattiva prioritizzazione, follow-up più lento |
| Decisione di rimborso del supporto clienti | Meno di 5 minuti | Rimborsi duplicati, errori di politica |
| Intervento di frode o rischio | Secondi a 1 minuto | Perdita di denaro reale |
Questa non è una tabella universale. È una funzione forzante.
La maggior parte dei team non definisce mai questi numeri. Dicono solo che vogliono "AI in tempo reale" o "pipeline AI-ready" e sperano che lo stack si sistemi da solo in seguito.
Non lo farà.
Se non definisci un budget di freschezza, il budget predefinito diventa "qualsiasi cosa faccia già la pipeline." Di solito è un incidente, non una scelta di design.
Il batch va ancora bene per molti lavori AI
Non penso che la risposta sia spingere ogni carico di lavoro nello streaming.
È costoso. Crea anche una nuova classe di problemi operativi se il team non ne ha bisogno.
Alcuni casi d'uso AI sono perfettamente felici in batch:
- Scrivere riepiloghi interni
- Preparare resoconti di ricerca
- Etichettare conversazioni di supporto per l'analisi delle tendenze
- Redigere note di preparazione al rinnovo
- Arricchire documenti di pianificazione
- Creare riepiloghi settimanali per dirigenti
Questi compiti beneficiano della completezza più che dell'immediatezza.
Di solito vuoi il record completo, non l'evento più recente di quindici secondi fa.
Questo è importante perché molti messaggi AI attualmente inquadrano il futuro come un unico grande sistema in tempo reale. È un buon modo per spendere troppo.
La domanda migliore è più ristretta: dove i dati a bassa latenza cambiano effettivamente la qualità dell'azione?
Se la risposta è da nessuna parte, mantienilo batch.
Se la risposta è interfacce specifiche, sposta prima quelle interfacce.
Il pericoloso mezzo
Il vero problema non è chiaramente batch e non veramente in tempo reale.
È il mezzo pastoso dove i team hanno pipeline che si aggiornano ogni ora, o ogni trenta minuti, o ogni volta che un connettore si sente di recuperare, e poi consegnano quei dati a un agente con il permesso di agire.
È lì che gli errori diventano costosi.
La freschezza oraria sembra decente finché non la mappi al workflow.
Se un cliente esegue un upgrade alle 10:02 e l'agente vede il vecchio piano fino alle 11:00, hai quasi un'ora in cui può negare un diritto che il cliente ha già pagato.
Se un ordine viene annullato alle 2:11 e il tuo assistente di inventario non lo apprende fino alle 3:00, può riordinare stock di cui non hai più bisogno.
Se una bandiera di chargeback arriva in un sistema prima di un altro, il tuo agente di rischio può vedere un account sano e approvare la transazione successiva con piena fiducia.
Niente è ovviamente rotto in quegli esempi. I lavori sono stati eseguiti. Le tabelle aggiornate. Il dashboard probabilmente sembra a posto.
Il problema è che la finestra d'azione è più stretta della finestra dei dati.
Quel divario è dove vivono i fallimenti degli agenti.
I cancelli di approvazione sono anche una strategia di freschezza
C'è un altro punto che si perde nella corsa all'automazione.
A volte la risposta giusta non è dati più veloci. A volte la risposta giusta è un cancello di approvazione.
Se un agente lavora su un contesto stantio o ambiguo, non sempre è necessario bloccare il caso d'uso per sempre. Potrebbe essere necessario solo cambiare l'ultimo passaggio.
Lascia che l'agente raccolga dati. Lascia che rediga la risposta. Lascia che raccomandi l'azione. Poi richiedi un'approvazione umana se il budget di freschezza non è rispettato o se la decisione tocca denaro, conformità, accesso o rischio rivolto al cliente.
Questo non è un fallimento dell'automazione. È parte del design.
I buoni sistemi AI non pensano solo alla qualità del modello. Pensano a quando non agire da soli.
Questo è particolarmente vero quando i dati sottostanti arrivano attraverso un mix di sincronizzazioni batch, pipeline CDC, flussi di eventi e API esterne che si muovono tutte a velocità diverse.
Hai bisogno di freschezza per interfaccia, non per slogan di piattaforma
Molto del posizionamento dei fornitori sfuma questo di proposito.
La promessa suona di solito qualcosa del genere: collega tutti i tuoi dati, alimenta i tuoi agenti, sblocca decisioni in tempo reale.
Va bene. Ma quali decisioni?
Non hai bisogno di un unico grande obiettivo di freschezza per tutta l'azienda. Hai bisogno di obiettivi di freschezza per interfaccia.
Inizia con i luoghi in cui un agente passa dal consiglio all'azione:
- approvare o negare qualcosa
- inviare una comunicazione al cliente
- cambiare accesso o diritti
- muovere denaro
- aprire o chiudere incidenti
- attivare sistemi a valle automaticamente
Queste interfacce meritano limiti di ritardo espliciti, monitoraggio, comportamento di fallback e proprietà.
Se la pipeline manca il budget, cosa dovrebbe succedere?
Forse l'azione si ferma.
Forse l'agente può ancora redigere ma non inviare.
Forse può operare su un sottoinsieme sicuro di strumenti.
Forse ha bisogno di un umano nel loop.
Il punto è definire questo prima che il primo incidente te lo insegni.
Cosa significa questo per lo stack dei dati
Una volta definiti i budget di freschezza, la conversazione sullo stack diventa più facile.
Puoi smettere di discutere di batch contro streaming come ideologia.
Alcune interfacce hanno bisogno di elaborazione basata su eventi. Alcune hanno bisogno di CDC con SLA stretti. Alcune vanno bene con sincronizzazioni programmate. Alcune hanno bisogno di un percorso ibrido dove lo stesso workflow gestisce sia i riempimenti storici che gli aggiornamenti a bassa latenza.
Quella ultima categoria è quella che diventa dolorosa rapidamente se la tua architettura divide batch e streaming in sistemi separati.
Ora stai mantenendo due versioni della stessa logica di business. Una risponde a domande storiche. Una alimenta azioni live. Si allontanano. Il tuo agente ottiene uno stato incoerente a seconda di quale percorso ha toccato.
Ecco perché penso che il miglior design a lungo termine non sia "tempo reale ovunque." È un runtime che può gestire sia batch che streaming, oltre all'orchestrazione intorno a loro, senza costringere il team a ricostruire il workflow ogni volta che un requisito di freschezza cambia.
È anche dove layline.io si inserisce. Il punto non è trasformare ogni pipeline in un flusso. Il punto è permettere ai team di stringere la freschezza dove l'azione lo richiede, mantenere il batch dove è sufficiente e gestire entrambi in un unico modello operativo.
Il test pratico
Se il tuo team sta implementando agenti AI in questo momento, fai una domanda per ogni azione dell'agente:
Qual è l'età massima dei dati che possiamo tollerare prima che questa azione diventi insicura, sbagliata o imbarazzante?
Scrivi il numero.
Se nessuno può rispondere, non hai ancora un problema AI. Hai un problema di requisiti.
E se la risposta è "dipende," va bene. Scomponilo per interfaccia finché non smette di dipendere.
I team che fanno bene questo non saranno quelli con lo stack AI più rumoroso. Saranno quelli che sanno quali decisioni richiedono secondi, quali minuti, quali possono aspettare fino a domani e dove un umano appartiene ancora nel loop.
Questo sembra meno eccitante delle solite demo degli agenti.
È anche la differenza tra un sistema utile e uno che crea un nuovo tipo di rotazione di reperibilità.
Andrew Tan è un imprenditore seriale e fondatore di layline.io, costruendo infrastrutture di elaborazione dati aziendali che gestiscono carichi di lavoro sia batch che in tempo reale su larga scala.
