Il vocabolario sbagliato ti costa due contratti agent invece di uno

La settimana scorsa Hugging Face ha pubblicato in silenzio un glossario sulla terminologia degli agent AI. È più utile come filtro per gli acquisti che come tutorial. Se il tuo team non riesce a concordare su quale layer vende davvero un vendor, finirai per comprare infrastrutture sovrapposte — e probabilmente lo hai già fatto. Il gap di vocabolario tra "harness", "scaffold" e "runtime" è esattamente dove si nasconde la spesa duplicata.

Come è cambiata la definizione di infrastruttura agent nel settore

Il glossario agent di Hugging Face traccia distinzioni nette tra termini che il settore usava in modo intercambiabile. Un harness è un wrapper per testing e valutazione — esegue il tuo agent in scenari controllati e misura il comportamento. Uno scaffold è il layer strutturale che sequenzia i passi dell'agent, gestisce le chiamate agli strumenti e controlla il flusso di esecuzione. Un runtime è l'ambiente di esecuzione: gestione della memoria, concorrenza, persistenza dello stato. Sono tre problemi diversi, tre categorie di vendor diverse, tre decisioni build-vs-buy separate.

La confusione non è casuale. La maggior parte dei vendor che vendono "piattaforme agent" raggruppa due o tre di questi layer senza etichettarli separatamente. Un vendor che propone una "piattaforma di orchestrazione agent" potrebbe starti vendendo uno scaffold, un runtime o entrambi — e il suo deck commerciale non farà mai questa distinzione spontaneamente. La stessa sovrapposizione esiste nei progetti open-source: framework come LangGraph, AutoGen e CrewAI enfatizzano layer diversi, ed è per questo che i team che ne adottano due scoprono un'overlap significativa solo quando l'integrazione è già in corso.

Il glossario chiarisce anche due termini adiacenti: tool use (il meccanismo con cui un agent chiama API o funzioni esterne) e agent memory (contesto a breve termine vs. recupero a lungo termine). Sono capacità, non layer — vivono dentro lo scaffold o il runtime a seconda dell'implementazione. Trattarle come layer genera una terza categoria di acquisti ridondanti: comprare una "soluzione per la memoria" da un vendor quando il tuo scaffold ne include già una.

Perché questo cambia i conti sulla proprietà degli agent per un team da 50 a 500 FTE

Alla tua dimensione aziendale non stai costruendo tutto da zero, ma non stai nemmeno comprando una suite enterprise monolitica. Stai assemblando. Questo significa che la linea build-vs-buy non è una sola decisione — sono tre decisioni prese a tre layer diversi, ognuna con un profilo di rischio diverso.

Il layer harness è quasi sempre una decisione di acquisto o di open-source. I framework di valutazione sono infrastruttura commodity; costruirne uno su misura è raramente giustificato, a meno che il tuo dominio abbia requisiti di compliance che gli strumenti off-the-shelf non riescono a soddisfare. Il layer runtime è ad alto rischio: i problemi di gestione dello stato, persistenza e concorrenza emergono in produzione, non nelle demo. È qui che la maggior parte dei team sottostima il costo di build. Lo scaffold, al contrario, è dove vive la tua logica di business — la sequenza di passi che riflette come funzionano davvero i tuoi processi. Quella logica vale spesso la pena di tenerla in casa, anche quando il runtime sottostante non lo vale.

La conseguenza pratica: quando un vendor propone di "gestire la tua infrastruttura agent", la domanda giusta non è "quanto costa" ma "quale dei tre layer copre questo, e cosa dice il contratto sugli altri?" I team che saltano questa domanda comprano uno scaffold dal vendor A, scoprono di aver ancora bisogno di un runtime, lo comprano dal vendor B, e sei mesi dopo trovano che lo scaffold del vendor A ha un runtime opinionated integrato che ora crea conflitti. Abbiamo visto questo scenario ripetersi in più engagement con clienti. Il vocabolario è la due diligence.

Parla con Domani AI di come costruirlo →

Cosa fare questa settimana come CTO per smettere di comprare infrastruttura due volte

Fai un audit interno di 90 minuti prima della prossima chiamata con un vendor. L'obiettivo è una mappa dei layer su una pagina: cosa possiedi o gestisci attualmente a livello di harness, scaffold e runtime? La maggior parte dei team scopre di avere copertura parziale su due layer e niente sul terzo. Quel gap è esattamente ciò che la tua prossima chiamata con un vendor dovrebbe affrontare — in modo specifico e solo quello.

Poi applica questo albero decisionale a qualsiasi proposta di vendor nella tua pipeline:

• Il vendor indica chiaramente quale layer (o quali layer) copre il suo prodotto? Se no, richiedilo per iscritto prima della prossima chiamata.
• Hai già una copertura parziale su qualsiasi layer che stanno vendendo? Se sì, chiedi un contratto circoscritto che escluda ciò che già possiedi.
• Lo scaffold del vendor è opinionated sul runtime? Se sì, è un rischio di lock-in. Ottieni le condizioni di disaccoppiamento nel contratto o includi il costo di migrazione nel calcolo.
• La tua logica di business core è incorporata nello scaffold? Se sì, tieni in casa quel layer. Contrattualizza harness e runtime.
• Il bisogno è principalmente di testing e valutazione? Allora ti serve un harness, non una piattaforma — e probabilmente puoi soddisfarlo con uno strumento open-source in meno di 2 settimane.

Se sei a metà valutazione con un vendor agent e non hai ancora mappato il suo prodotto su questi tre layer, metti in pausa la conversazione commerciale e fai prima la mappatura. Un'ora di allineamento interno risparmia 6 mesi di re-architettura.

Quanto costa — e quanto si risparmia

L'esercizio di mappatura richiede circa 4 ore di un senior engineer e 90 minuti tuoi. Se coinvolgi un revisore esterno di architettura, aspettati mezza giornata di tempo fatturabile. Questo è il costo totale se lo fai prima di firmare. Se lo fai dopo, il costo è il contratto duplicato, il lavoro di integrazione per riconciliare due runtime e il tempo di engineering perso in una migrazione che avresti potuto evitare — tipicamente da 3 a 8 settimane di capacità di un piccolo team, sulla base di quanto vediamo nei post-mortem con i clienti.

Il risparmio non è solo economico. È flessibilità. I team che possiedono il loro layer scaffold e contrattualizzano tutto il resto mantengono la capacità di cambiare vendor di runtime quando i prezzi cambiano o quando arriva un'opzione migliore. I team che comprano una piattaforma bundled senza capire i layer tendono a scoprire di non possedere nulla di separabile — e rinegoziamo da una posizione debole. In un mercato dove i prezzi dell'infrastruttura agent sono ancora volatili e il consolidamento dei vendor è in corso, quella flessibilità ha un valore che si accumula nel tempo.