Il divario tra risultati modesti e sostanziali dagli strumenti AI dipende dall'architettura che avvolge il modello. Steve Yegge ha osservato all'inizio del 2026 che gli sviluppatori che usano agenti AI per la scrittura di codice riportano guadagni di produttività significativi per compiti appropriati; le cifre variano ampiamente in base alla metodologia e al tipo di attività. Stessi modelli. Stessa intelligenza di fondo. La variabile è la struttura.
In una sola settimana nell'aprile 2026, cinque builder indipendenti hanno pubblicato framework per l'architettura degli agenti AI. Garry Tan (Y Combinator), Andrej Karpathy, Viv Trivedy, Daniel Miessler e un repository della community che ha raggiunto 19.700 stelle su GitHub sono convergiti sulla stessa tesi centrale: mettere l'intelligenza in file markdown portabili, mantenere l'infrastruttura di orchestrazione il più snella possibile, lasciare che il modello faccia il ragionamento. Questo articolo analizza su cosa sono d'accordo, dove divergono e cosa significa per chi costruisce con l'AI.
Punti chiave
- L'intelligenza appartiene ai file skill in markdown, non al codice del framework. Le skill sono portabili, versionabili e migliorano automaticamente quando il modello migliora.
- L'harness deve fare quattro cose e nient'altro. Eseguire il modello in un loop, leggere e scrivere file, gestire il contesto, applicare i controlli di sicurezza. Ogni funzione aggiunta oltre queste consuma contesto e rallenta il ragionamento.
- Cinque builder hanno pubblicato indipendentemente la stessa tesi in tre giorni (12-15 aprile 2026). Garry Tan, Andrej Karpathy, Viv Trivedy, Daniel Miessler e un repo della community con 19.700 stelle. La convergenza di più fonti indipendenti è uno dei segnali che un pattern architetturale è solido.
- LangChain non è d'accordo e ha benchmark per dimostrarlo. Harrison Chase sostiene che l'harness È il prodotto. La risposta potrebbe dipendere dal fatto che si stia costruendo strumenti consumer o pipeline enterprise.
- Le istruzioni prescrittive scadono. Il contesto no. Ogni procedura passo-passo scritta per un'AI degrada con la prossima versione del modello. Il contesto su chi si è e cosa si vuole si accumula nel tempo.
L'architettura è compatta
Le discussioni pubbliche sugli harness per agenti in produzione si sono concentrate sempre più su un'architettura compatta: un loop con il modello, strumenti, gestione del contesto e controlli di sicurezza. Garry Tan ha descritto quel pattern come un fattore di produttività che insegnava a Y Combinator da mesi: il divario di produttività viene da ciò che avvolge il modello.
Tan ha distillato l'architettura in tre livelli:
| Livello | Contenuto | Proprietà chiave |
|---|---|---|
| Fat skills | Procedure markdown che codificano giudizio, processo e conoscenza di dominio | Portabili. Sono tuoi. |
| Thin CLI harness | ~200 righe: JSON in entrata, testo in uscita, gestione del contesto, sicurezza | Minimale. Lo fornisce il vendor. |
| La tua applicazione | QueryDB, ReadDoc, Search, Timeline. Operazioni deterministiche. | Affidabile. Stesso input, stesso output. |
Il principio è direzionale. Spingi l'intelligenza verso l'alto nelle skill. Spingi l'esecuzione verso il basso negli strumenti deterministici. Mantieni l'harness snello. Il 90% del valore vive nel livello delle skill. L'harness è un conduttore che legge file, non li possiede.
L'esperienza personale di Tan è illuminante. Il suo CLAUDE.md personale era partito da 20.000 righe. Ogni quirk, ogni convenzione, ogni lezione mai incontrata. Il risultato: l'attenzione di Claude Code degradava. Il modello gli ha detto letteralmente di ridurlo. La soluzione: 200 righe di puntatori a documenti caricati su richiesta. Le 20.000 righe di conoscenza esistono ancora, ma si caricano solo quando sono rilevanti, invece di inquinare la finestra di contesto ad ogni turno.
Per chi sta costruendo strumenti o workflow basati su AI per la propria azienda, impostare correttamente l'architettura fin dall'inizio determina se il risultato sarà una demo che impressiona o un sistema che va davvero in produzione.
Cinque definizioni che distinguono i build AI ad alto rendimento
L'architettura si basa su cinque concetti. Tralasciarne anche uno solo fa sottoperformare il sistema.
1. File skill
Una skill è un documento markdown riutilizzabile che insegna al modello il processo per una categoria di compiti. L'utente fornisce il compito; la skill fornisce la procedura. Funziona come una chiamata a metodo: stessa procedura, argomenti diversi, output radicalmente diversi.
L'esempio di Tan: una skill chiamata /investigate ha sette passaggi (definire il dataset, costruire una timeline, diarizzare ogni documento, sintetizzare, argomentare entrambi i lati, citare le fonti). Puntata su uno scienziato della sicurezza e 2,1 milioni di email di discovery, produce un analista di ricerca medica. Puntata su una shell company e i documenti FEC, produce un investigatore forense. Stessi sette passaggi. È l'invocazione a fornire il contesto al mondo.
2. Resolver
Un resolver è una tabella di routing per il contesto. Quando appare il tipo di task X, carica prima il documento Y. Senza un resolver, uno sviluppatore modifica un prompt e lo pubblica. Con un resolver, il modello legge prima la documentazione della suite di valutazione, esegue i benchmark e torna indietro se l'accuratezza scende di più del 2%. Lo sviluppatore non sapeva che la suite esistesse: il resolver ha caricato il contesto giusto al momento giusto.
3. Latente vs. deterministico
Ogni passaggio in un sistema è l'uno o l'altro. Confonderli è l'errore più comune nel design degli agenti. Un LLM può disporre 8 persone attorno a un tavolo tenendo conto delle personalità. Chiedigli di disporne 800 e allucinerà una disposizione che sembra plausibile ma è completamente sbagliata. Questo è un problema deterministico forzato nello spazio latente. I migliori sistemi sono spietati nel tracciare questa distinzione.
4. Diarizzazione
Il modello legge tutto su un soggetto e scrive un profilo strutturato. Nessuna query SQL produce questo. Nessuna pipeline RAG produce questo. Il modello deve leggere, tenere le contraddizioni in mente, notare cosa è cambiato e quando, e sintetizzare intelligence strutturata.
Il team di Tan ha costruito un sistema per YC Startup School che gestisce 6.000 profili di fondatori in questo modo. L'output della diarizzazione cattura ciò che nessuna ricerca per parole chiave potrebbe trovare: una fondatrice che dice "Datadog per agenti AI" ma i cui commit su GitHub sono all'80% codice di billing. Sta costruendo uno strumento FinOps mascherato da observability. Quel divario tra "dice" e "sta costruendo davvero" richiede di leggere simultaneamente la cronologia dei commit, la candidatura e la trascrizione dell'advisor. Nessuna ricerca per similarità di embedding lo trova.
5. Aggiornamenti permanenti
L'istruzione di Tan alla sua AI: "Se mi chiedi di fare qualcosa ed è il tipo di cosa che dovrà accadere di nuovo, codificala in un file skill. Se deve girare automaticamente, mettila in un cron. Se devo chiederti qualcosa due volte, hai fallito." Ogni skill scritta è un aggiornamento permanente. Non degrada mai. Quando esce il prossimo modello, ogni skill migliora istantaneamente. Il sistema si accumula.
Cinque framework pubblicati in una settimana dicono tutti la stessa cosa
La convergenza è il segnale più forte. Questi cinque corpus di lavoro sono emersi indipendentemente tra il 12 e il 15 aprile 2026. Nessuno di questi builder sta collaborando. Sono arrivati alla stessa architettura da punti di partenza diversi.
| Framework | Dove vive l'intelligenza | Cosa rimane snello |
|---|---|---|
| Tan (fat skills) | File skill markdown, SOUL.md | L'harness: conduttore, non cervello |
| Karpathy (CLAUDE.md) | File di istruzioni comportamentali | Nessun framework necessario. Un solo file .md |
| Trivedy (frammenti di contesto) | Memoria esternalizzata, livello di recupero | L'harness gestisce il contesto, non possiede la conoscenza |
| Miessler (bitter lesson) | Contesto su identità, obiettivi, gusto | Istruzioni su come eseguire |
| Community (repo con 19.700 stelle) | Skill, slash command, regole CLAUDE.md | I subagenti sostituiscono la compattazione. Grep sostituisce RAG |
Tan è arrivato qui dopo aver pubblicato un alto volume di codice di produzione in due mesi: il conteggio delle righe è una metrica di throughput, e quel throughput è insolito con gstack (23.000+ stelle su GitHub nella prima settimana; il numero di stelle misura la visibilità, non l'idoneità alla produzione). Karpathy è arrivato dal debug delle tre modalità di fallimento persistenti degli assistenti AI per la scrittura di codice. Trivedy è arrivato dall'iterazione sul design dell'harness attraverso oltre 30 versioni. Miessler è arrivato applicando la bitter lesson di Richard Sutton agli strumenti AI.
La convergenza di più fonti indipendenti è uno dei segnali che un pattern architetturale è solido.
LangChain non è d'accordo e ha benchmark per dimostrarlo
Harrison Chase (CEO di LangChain) ha pubblicato Deep Agents la stessa settimana sostenendo l'opposto: l'harness È il prodotto. Pianificazione dei task integrata, spawning di sub-agenti, middleware, hook, infrastruttura di orchestrazione completa. La sua evidenza: cambiare solo l'harness ha portato DeepAgent di LangChain dall'esterno della top 30 alla top 5 su TerminalBench 2.0.
LangChain elabora milioni di chiamate agente al giorno, quindi l'obiezione merita attenzione. I loro benchmark sono pubblici. La vera divisione: la posizione di Tan è che ogni pezzo di logica nell'harness limita il ragionamento che il modello avrebbe potuto fare autonomamente. Più il modello migliora, più l'harness dovrebbe essere snello. La posizione di Chase è che l'ingegneria dell'harness estende la capacità del modello invece di sostituirla.
Entrambe le posizioni possono essere corrette per contesti diversi. Gli agenti consumer e personali, dove portabilità e longevità contano, favoriscono un harness snello. Le pipeline enterprise, dove contano affidabilità e auditabilità, possono giustificare un harness più robusto. Nessuna delle due parti contesta che le skill debbano essere fat. La domanda utile per il proprio progetto è da quale parte di questa linea si colloca il proprio caso d'uso.
La maggior parte delle aziende che costruisce funzionalità AI per la prima volta dovrebbe iniziare con un harness snello e aggiungere infrastruttura solo quando si scontra con specifici problemi di affidabilità. Non sa dove si colloca il suo progetto? Parli con webvise per capire quale architettura è più adatta.
Le sue istruzioni scadranno. Il suo contesto no.
Daniel Miessler ha pubblicato la diagnosi più acuta della settimana. La chiama il bitter lesson engineering audit, ispirata all'osservazione di Richard Sutton del 2019 secondo cui gli approcci generali scalati con la computazione battono costantemente gli approcci codificati a mano nel lungo periodo.
Applicato agli strumenti AI: la cattiva ingegneria dell'harness è fatta di istruzioni prescrittive. "Prima copia questo file, poi carica questo, poi fai questo, poi fai quello." Microgestione passo-passo dell'esecuzione dell'AI. Questo approccio degrada man mano che i modelli diventano più intelligenti: passaggi troppo rigidi impediscono al modello di applicare il proprio ragionamento.
La buona ingegneria dell'harness è contestuale. Chi si è, su cosa si sta lavorando, cosa si cerca di realizzare, come appare il buono e il cattivo risultato. Identità, gusto, standard, obiettivi. Il modello capisce il come.
La diagnostica di Miessler è semplice. Se la configurazione si legge come una ricetta (passo 1, passo 2, passo 3), si sta facendo cattiva ingegneria dell'harness. Se si legge come un documento di briefing (ecco chi sono, ecco cosa conta, ecco gli strumenti), si sta facendo buona ingegneria dell'harness. Il contesto su chi si è non scade mai. Le istruzioni prescrittive diventano obsolete ad ogni miglioramento del modello.
L'architettura non è complicata. Fat skills, thin harness, separazione spietata tra lavoro latente e deterministico. La parte difficile è la disciplina: codificare il giudizio in skill riutilizzabili invece di fare lavoro una tantum, mantenere l'harness snello quando la tentazione è aggiungere funzionalità, e fidarsi del modello per capire il "come" quando gli si fornisce il giusto "cosa" e "perché".
webvise costruisce sistemi basati su AI seguendo questi principi architetturali. Che si tratti di un workflow agentico, di una pipeline automatizzata o di un'integrazione AI di livello produttivo, l'architettura conta più del modello.
Le pratiche di webvise sono allineate agli standard ISO 27001 e ISO 42001.