I 5 livelli degli agenti AI: dal prompt alla produzione

Oggi ci sono cinque parole che tutti usano quando parlano di agenti. Context engineering, loop engineering, Jev engineering, harness engineering, eval engineering.

Sembrano cinque approcci in competizione tra loro. Non lo sono. Sono cinque livelli di un unico sistema, e ognuno risponde a una domanda precisa.

Il modo più semplice per capirli è immaginare di aver appena assunto un nuovo dipendente:

• Context – cosa c'è sulla sua scrivania quando gli chiedi qualcosa
• Loop – se segue la tua checklist o se capisce da solo qual è il passo successivo
• Jev – la reception che smista la posta, così lui vede solo ciò che conta
• Harness – il suo ufficio. Gli strumenti, le chiavi e chi controlla il suo lavoro
• Evals – lo stesso test ogni mese, per sapere se è davvero migliorato

Un agente AI è quel dipendente. Il modello è la persona, e questi cinque livelli sono tutto ciò che lo circonda. Se imposti bene questi cinque livelli, un piccolo team può farsi carico di lavori che prima richiedevano nuove assunzioni. Le attività ripetitive passano a un agente che regge in produzione, mentre le decisioni restano alle persone. Ecco come si scala senza aumentare l'organico nella pratica.

Per ogni livello ti spiegherò cos'è, come funziona, dove usarlo e come costruirlo.

E per ogni livello ho preparato anche una scorciatoia. Un modo più semplice per ottenere lo stesso risultato senza costruire tutto da zero, pensato per chi inizia. I miei amici di Viktor mi hanno aiutato a mettere insieme queste scorciatoie.

Viktor è un dipendente AI che vive nel tuo Slack o Microsoft Teams. Sta negli stessi canali di tutti gli altri e lavora come un collega: uno che aggiungi al team senza dover aprire una nuova posizione.

Lavorare con lui è come lavorare con una persona:

• Lo menzioni in un canale o in un thread e descrivi l'attività.
• Lui capisce i passaggi, esegue il lavoro sui tuoi strumenti e pubblica il risultato nello stesso thread.

La configurazione è semplice. Aggiungi Viktor al tuo workspace e comparirà tra i partecipanti esattamente come qualsiasi altro membro del team. Se vuoi provarlo mentre leggi, usa il codice YARCHI100.

pic1. I cinque livelli di un agente

1. Context engineering

Definizione

Prima di ogni domanda, metti dei documenti sulla scrivania del dipendente. Mettici le tre pagine giuste e ti risponderà in pochi secondi. Metticene trecento e la risposta sarà sepolta in mezzo alla pila. E lui non la troverà.

Il modello è il dipendente. La scrivania è la context window: tutto ciò che il modello vede prima di rispondere. Le tue istruzioni, la chat fino a quel punto, i documenti estratti da un database, l'output di ogni strumento che ha eseguito.

Il context engineering consiste nel decidere cosa va sulla scrivania, e dove.

Come funziona

Più contesto non significa risposte migliori. Superato un certo limite, significa risposte peggiori.

Stanford lo ha testato direttamente. Dai a un modello dai 20 ai 30 documenti e la sua precisione su quelli centrali scende a circa il 50-57%. Senza alcun documento, lo stesso modello otteneva il 56%. La risposta era nella finestra, eppure il modello ha fatto peggio che partendo da zero.

Due fattori guidano questo fenomeno:

• I modelli prestano la massima attenzione all'inizio e alla fine della finestra, e la minima al centro.
• Ogni token costa tempo e denaro, sia che serva sia che non serva.

L'unico meccanismo che vale la pena conoscere è il prompt caching. Il provider memorizza l'inizio del tuo prompt e lo riutilizza alla chiamata successiva; un token in cache costa circa dieci volte meno di uno nuovo.

Il trucco: la cache funziona solo se quell'inizio è identico, byte per byte. Cambia un solo carattere verso l'inizio e tutto ciò che segue verrà fatturato a prezzo pieno. Quindi la regola è: prima le cose stabili, alla fine quelle variabili.

Come costruirlo

Ogni elemento di contesto finisce in uno di quattro posti:

1. System prompt. Solo ciò che è vero a ogni chiamata: ruolo, vincoli, formato di output. Mantienilo identico byte per byte. Niente timestamp all'inizio, niente chiavi JSON in ordine casuale.
2. Tools. Non aggiungerli o rimuoverli a metà conversazione. Rompe la cache e porta il modello a chiamare strumenti che non esistono più. Per limitare uno strumento in un determinato passaggio, blocca la chiamata ma mantieni la definizione.
3. Disk. Tutto ciò che è grande o persistente va in un file, e nella finestra resta solo il percorso. Stessa cosa per una pagina web: tieni l'URL, scarta il corpo. Togli il contenuto, conserva la chiave per recuperarlo.
4. Tail. Ogni pochi passaggi, riformula l'obiettivo attuale vicino alla fine del contesto. Non puoi sistemare il centro, quindi tieni fuori da lì ciò che conta.

Anche gli strumenti hanno un limite. Anthropic ha misurato che 58 definizioni di tool divorano circa 55.000 token prima ancora che l'utente digiti una parola. Lasciare che il modello cercasse gli strumenti invece di caricarli tutti ha portato Opus 4 dal 49% al 74% nel loro benchmark.

Sotto i 20 strumenti circa, tienili caricati. Oltre, passa alla ricerca.

Un altro trucco per i lavori pesanti: invia un sub-agent. Legge i 50 file nella sua finestra e ti restituisce un riassunto di una pagina. Il tuo contesto principale vedrà sempre e solo il riassunto.

pic2. Cosa entra in una singola chiamata al modello

Scorciatoia

Viktor ti toglie gran parte di questo peso dalle spalle, perché il suo contesto vive a livello aziendale.

• Memory. Mantiene una memoria persistente della tua azienda condivisa con tutto il team. Quello che ha imparato dal tuo co-founder la settimana scorsa non deve essere incollato di nuovo nella tua richiesta di oggi.
• Connected sources. Con Notion, Google Drive o HubSpot collegati, smetti di incollare file nella chat. Nomini il documento o il record e lui legge la fonte. È la regola del disco, già pronta per te.
• Skills. Registra il tuo schermo mentre esegui un'attività una sola volta. Lui trasforma la registrazione in una procedura scritta, tu la correggi e la approvi. Da quel momento quell'istruzione è fissa e revisionata, proprio come un buon system prompt.

Cosa resta da fare a te:

• Scrivi un breve brief aziendale una volta sola: cosa vendi, chi compra, quali numeri contano, cosa non deve mai fare.
• Un'attività per thread, spiegando nel primo messaggio cosa significa "fatto".
• Se ha imparato qualcosa di sbagliato, cancella la sua memoria dalle impostazioni invece di correggerlo in ogni singolo thread.

2. Loop engineering

Definizione

Puoi dare al dipendente una checklist: apri il file, modifica la riga 12, salva. Oppure puoi dargli un obiettivo: fai passare il test.

Con un obiettivo, prova qualcosa, guarda cosa succede e decide cosa fare dopo. La checklist è un workflow. L'obiettivo è un loop.

Come funziona

Un loop è composto da quattro mosse che si ripetono: pensa, agisci, osserva, decidi. Correggere un bug funziona così:

1. Esegui i test. Tre falliscono.
2. Leggi il primo errore. Manca un import.
3. Aggiungi l'import, riesegui.
4. Un test fallisce ancora. Leggi quell'errore, correggilo, riesegui.
5. Passa tutto. Stop.

Nessuno ha scritto quei passaggi in anticipo. Il modello ha scelto ognuno di essi dopo aver visto il risultato precedente.

Questa è l'unica vera differenza. Cento passaggi scritti da te restano un workflow. Tre passaggi scelti dal modello sono un loop.

Usa un loop solo quando non puoi scrivere i passaggi in anticipo. Se puoi scriverli, fallo. Un workflow costa meno, gira in parallelo e, se il quarto passaggio fallisce, riesegui solo quello, non tutto il resto.

I loop sono anche costosi. Un agente usa circa quattro volte i token di una singola chiamata. Le configurazioni multi-agente arrivano a quindici volte tanto.

Come costruirlo

Un loop richiede quattro elementi. Togline uno qualsiasi e smette di funzionare:

1. Un obiettivo con un "fatto" chiaro. Non "correggi il bug". Piuttosto: "il test fallito in auth_test.py passa e nient'altro si rompe."
2. Un checker. Qualcosa di esterno al modello che dica pass o fail: una suite di test, un compilatore, un linter. La ricerca sull'autocorrezione è chiara su questo punto: funziona con un feedback esterno reale e fallisce quando il modello si limita a revisionare se stesso. Nessun checker significa nessun loop, solo spese a fondo perduto.
3. Una regola di stop. Il checker dà l'ok, oppure raggiungi il limite di turni, o gli ultimi due tentativi hanno prodotto lo stesso output.
4. Un budget. Sia in turni che in dollari.

Nel codice, il tutto sta in poche righe:

1for turn in range(MAX_TURNS):
2    action = model.next_step(goal, history)
3    result = run(action)
4    history.append(result)
5
6    if checker(result):       break   # completato
7    if repeated(history, 2):  break   # bloccato
8    if spent() > BUDGET:      break   # troppo costoso
9else:
10    fallback_workflow(goal)

La migliore configurazione in produzione che ho visto pubblicata è ibrida. Atlan esegue prima un filtro deterministico, e solo il 14% circa degli avvisi in arrivo raggiunge effettivamente l'agente.

Il loop ottiene poi un massimo di tre cicli. Se dopo tre cicli la confidenza è ancora sotto il 50%, subentra un workflow Python fisso.

Filtra prima, usa il loop brevemente, poi prevedi un fallback.

pic3. Come scegliere tra un workflow e un loop

Scorciatoia

Ogni attività che affidi a Viktor in un thread è un loop. Tu scrivi l'obiettivo, lui sceglie i passaggi, lavora sui tuoi strumenti e torna nel thread con il risultato.

I quattro elementi si mappano così:

• Goal. Fa resistenza davanti ai brief incompleti e chiede chiarimenti invece di tirare a indovinare. Nonostante ciò, scrivi cosa significa "fatto". "Report dei ricavi della scorsa settimana, totali corrispondenti a Stripe, pubblicato in #finance entro le 9 di lunedì mattina" batte di gran lunga "fai il report".
• Checker. Segnala i numeri che sembrano sballati prima di pubblicarli. Rendilo più solido indicando la fonte da usare come riferimento: il totale di Stripe, il conteggio delle righe, la suite di test.
• Stop rule. Le azioni sensibili vengono messe in pausa per l'intervento umano, e il risultato torna sempre a te.
• Budget. Crediti. Il tier di ragionamento stabilisce il prezzo di ogni passaggio e, nei lavori ricorrenti, la frequenza conta. Un report orario costa molto più di uno settimanale.

L'approccio ibrido di Atlan funziona anche senza codice. Il lavoro che si ripete diventa un'attività pianificata: lui la propone e rimane in pausa finché non la approvi. Questo è il tuo workflow.

Tutto ciò che è aperto e indefinito finisce in un thread, e quello è il tuo loop. Il fallback sei tu.

3. Jev engineering

Definizione

L'esperto in un ufficio non apre ogni singola busta. Qualcuno alla reception smista la posta: le bollette in una pila, lo spam nel cestino, i contratti all'avvocato.

Il tuo agente fa due tipi di lavoro: scrivere qualcosa e decidere qualcosa. In questo momento un unico grande modello fa entrambe le cose, quindi stai pagando l'avvocato per smistare la posta.

Jev è la reception. Non scrive mai. Si limita a scegliere.

Come funziona

Dai a Jev una domanda e le possibili risposte in anticipo. Restituisce una di tre cose, più un punteggio di confidenza:

• sì o no
• un'opzione da un set
• un numero su una scala

Poiché si limita a scegliere, è veloce ed economico. I numeri dichiarati sono da 70 a 500 millisecondi contro i 3-329 secondi, e $0.042 per milione di token in input con l'output gratuito.

Ora la parte onesta. Jev ha due settimane di vita e i test indipendenti stanno iniziando ad arrivare solo ora.

• Sulla classificazione delle email, una semplice regressione logistica ha ottenuto il 98,9% contro il 98,6% di Jev.
• Sul rilevamento del phishing, Jev ha raggiunto il 62,6% mentre Claude Haiku 4.5 è arrivato all'81,3%.
• Il dato sulle "zero allucinazioni" arriva con una nota a piè di pagina degli stessi autori: non è empirico, significa solo che l'output corrisponde sempre allo schema.

Anche il punteggio di confidenza non è una vera probabilità appena tolto dalla scatola. Trattalo come un ranking e imposta le soglie sui tuoi dati etichettati.

Come costruirlo

L'impostazione più sensata è un cancello davanti al modello costoso:

1. Arriva tutto.
2. Jev risponde a una domanda molto specifica su ogni elemento.
3. Sicuro e ordinario: gestito a basso costo. Etichettato, instradato o scartato.
4. Incerto o insolito: passa al modello principale.

1d = jev.choose(item, options=["spam", "order_status", "refund", "other"])
2
3if d.confidence >= 0.7 and d.option != "other":
4    handle_cheap(d.option, item)
5else:
6    main_model(item)   # fail closed: l'incertezza va al percorso costoso

Prima di tutto questo, prova la cosa più banale che potrebbe funzionare. Etichetta qualche centinaio di esempi reali, addestra un classificatore base e sali di livello solo se non è abbastanza buono.

Sono trenta minuti di lavoro, ed è la baseline che qualsiasi promessa dei vendor deve battere.

pic4. I tre tipi di domande a cui Jev risponde

Scorciatoia

Jev non fa parte dello stack ufficiale di Viktor, ma l'idea si applica in due punti che controlli tu:

• Il tier di ragionamento. Ne ha tre a disposizione: Smart su Claude Opus, Balanced su Claude Sonnet a circa metà del costo, Ultra su Claude Fable a circa il doppio. Smistare richieste o estrarre un singolo numero non richiede il livello massimo.
• Il cancello davanti a lui. Se vuoi che gestisca un flusso come le email di supporto o gli avvisi, non affidargli l'intero flusso. Metti prima un classificatore o una chiamata a Jev, così solo gli elementi che richiedono giudizio diventeranno attività per lui.

Questo è uno dei due livelli in cui il tuo lavoro di ingegneria conta ancora, anche con Viktor.

4. Harness engineering

Definizione

Stesso dipendente, due uffici. Nel primo ha gli strumenti giusti, un manuale appeso al muro, un collega che controlla il suo lavoro e nessuna chiave della cassaforte. Nel secondo ha un portatile e la tua password di amministratore.

Stesse competenze, risultati completamente diversi. Il dipendente è il modello. L'ufficio è l'harness.

Agente = modello + harness.

Come funziona

L'harness è tutto ciò che non è il modello: strumenti, permessi, sandbox, file che spiegano il progetto, controlli sull'output.

È diventata una disciplina a sé stante nel 2026 perché le persone hanno iniziato a misurare, e il modello spiegava meno di quanto ci si aspettasse:

• Anthropic ha modificato solo le risorse del container e ha spostato il punteggio di un benchmark di 6 punti.
• LangChain ha congelato il modello e ha spostato lo stesso benchmark di 13,7 punti cambiando solo l'harness.
• Poi hanno ottimizzato l'harness attorno a un modello open dieci volte più economico, fino a fargli raggiungere 0,86 contro lo 0,87 di Opus 4.8.

Non stai più comprando un modello. Stai comprando un modello e un harness insieme.

Ne hai bisogno nel momento in cui l'agente tocca qualcosa di reale: un repo, una casella di posta, un pagamento, un database di produzione.

Come costruirlo

Costruisci dall'esterno verso l'interno:

1. Containment. Ciò che l'agente fisicamente non può raggiungere. Un container, un branch separato, un utente database in sola lettura, nessuna rete tranne un'allowlist. Fallo prima del primo prompt.
2. Guides. Ciò che lo indirizza prima che agisca. Un file nel repo come AGENTS.md, descrizioni degli strumenti abbastanza chiare da far scegliere al modello quello giusto, alcuni esempi di buon output.
3. Sensors. Ciò che lo controlla dopo che ha agito. Linter, type checker, suite di test: veloci e deterministici, quindi eseguili su tutto. I controlli più lenti, come un secondo modello che revisiona un diff, solo su ciò che conta.
4. Permissions. Quando gli agenti chiedono l'approvazione, le persone la concedono nel 93% dei casi. Il prompt di approvazione non protegge quasi nulla. La vera protezione sono le azioni che semplicemente non sono disponibili. Riserva l'approvazione per le poche cose davvero irreversibili.

Un file guida non deve essere lungo. Quattro righe cambiano già il comportamento:

1# AGENTS.md
2- Monorepo: /api (FastAPI), /web (Next.js), /jobs (cron)
3- Esegui i test con `make test`. Devono passare prima di qualsiasi commit
4- Non modificare mai /migrations a mano, usa `make migration`
5- L'accesso al DB è in sola lettura. Chiedi prima di qualsiasi modifica allo schema

Gli hook sono la versione forzata della stessa idea. In Claude Code, un hook è un piccolo script che viene eseguito prima della chiamata a uno strumento e può bloccarla. "Non fare mai push su main" funziona come hook, non come riga nel prompt.

Un avvertimento. Ogni componente del tuo harness è una scommessa sul fatto che il modello non possa fare qualcosa, e quelle scommesse scadono. Anthropic ha eliminato un intero componente di scaffolding dopo che un aggiornamento del modello lo ha reso inutile.

Rileggi il tuo harness ogni pochi mesi e cancella ciò che il modello ha superato.

pic5. I quattro anelli di un harness

Scorciatoia

Se agente = modello + harness, gran parte di ciò che ottieni con Viktor è harness. Il modello sottostante è Claude. Tutto ciò che circonda il modello arriva già pronto:

• Tools. Più di 3.200 integrazioni: GitHub, Linear, HubSpot, Stripe, Notion, Google Drive e molte altre. Per uno strumento senza connessione pronta, può costruirla da solo.
• Guides. Skills. Invece di scrivere tu stesso AGENTS.md, registri lo schermo, lui bozza la procedura, tu la modifichi.
• Sensors. Segnala i dati che non tornano e mette in discussione i brief con pezzi mancanti. E ogni passaggio finisce in un thread Slack che il tuo team può leggere.
• Permissions. Le email dei clienti e le modifiche finanziarie vengono messe in pausa per l'approvazione. Le nuove automazioni pianificate restano in pausa finché qualcuno non le attiva.

La parte che nessun prodotto può costruire per te è il containment, perché è fatto delle credenziali che gli consegni. Ricorda quel 93% e collegalo con il minimo accesso necessario per svolgere il lavoro:

• un utente database in sola lettura
• una chiave Stripe limitata
• una casella di supporto condivisa, non quella personale
• un token GitHub limitato a repository specifici

Ciò che non può raggiungere, non può romperlo.

pic6. L'harness di Viktor

5. Evals engineering

Definizione

Come fai a sapere se un nuovo assunto è migliorato? Gli dai lo stesso test che gli hai dato il mese scorso e confronti i risultati.

Senza lo stesso test, ogni modifica che fai è un terno al lotto. Gli evals sono quel test per il tuo agente: un set di attività di cui conosci già la risposta corretta, da eseguire ogni volta che cambi qualcosa.

Come funziona

Esistono due tipi di controlli:

• End to end. La risposta finale è corretta? Ti dice che il punteggio è cambiato, ma non perché.
• Behavioral. È successa una cosa specifica? Ha chiamato la ricerca prima di rispondere? Ha fatto una domanda di chiarimento quando la richiesta era vaga? Ha verificato prima di dire "fatto"?

I controlli comportamentali girano sulla trace, il log di tutto ciò che l'agente ha fatto, non solo sulla risposta finale. La regola di Google è che questa suite dovrebbe terminare in meno di cinque secondi, così da poter essere eseguita a ogni modifica.

Se è un modello a valutare, allora è un judge, e anche il judge va controllato. Airbnb ha scoperto che circa tre quarti delle risposte di riferimento generate dal loro modello cambiavano esito nelle esecuzioni ripetute dello stesso input. Il loro eval stava misurando il proprio rumore.

Come costruirlo

1. Parti dai fallimenti reali. Analizza le esecuzioni concrete, trova cosa è andato storto, trasforma ogni caso in un test case. I golden set di Airbnb girano su 50-100 esempi, e i fallimenti sono obbligatori.
2. Scrivi un controllo comportamentale per caso. Un caso, una cosa da verificare.
3. Controlla il tuo judge. Valuta un campione a mano e vedi quanto spesso tu e il modello siete d'accordo prima di fidarti.
4. Campiona la produzione. Airbnb estrae il 5% del traffico live ogni giorno. Il tuo set di eval decade man mano che l'uso reale se ne allontana.

Un singolo caso può essere così piccolo:

1input: "Rimborso ordine #1042, il cliente dice che è arrivato rotto"
2expect:
3  - cerca l'ordine prima di rispondere
4  - chiede l'approvazione prima di emettere il rimborso
5check:
6  - la trace contiene get_order prima di send_reply
7  - la trace contiene approval_request prima di refund

Non guardare solo il tasso di superamento complessivo. Può salire mentre un comportamento specifico si rompe silenziosamente. Guarda i singoli controlli.

pic7. Da dove nascono i buoni casi di eval

Scorciatoia

Nessun prodotto può fornirti questo livello già pronto, perché solo tu sai che aspetto ha la risposta giusta per la tua azienda. Il metodo, però, si applica direttamente:

• Dopo due settimane, scegli 20 dei suoi thread in cui conosci la risposta corretta. Includi tutti quelli in cui hai dovuto correggerlo.
• Scrivi un semplice controllo per ogni caso. Ha linkato una fonte per ogni numero? Ha chiesto chiarimenti quando il brief era vago? Si è fermato prima che qualcosa uscisse dall'azienda?
• Riesegui il set dopo ogni modifica: una nuova skill, un brief modificato, un tier diverso. Passare da Smart a Balanced fa risparmiare circa metà dei crediti, quindi testalo prima di cambiare definitivamente.
• Una volta a settimana, valuta a mano cinque thread casuali.

Mettere tutto insieme

Cinque livelli, cinque domande. Il context è ciò che vede. Il loop è chi decide. Jev gestisce le decisioni economiche. L'harness è ciò che può raggiungere e chi lo controlla. Gli evals sono il modo in cui lo sai.

Con Viktor, tre di questi sono per lo più integrati: context, loop e harness. Jev, gli evals e le credenziali che gli consegni restano compito della tua ingegneria.

Se inizi oggi, ecco la mossa utile più economica per ciascuno:

• Context: sposta le istruzioni stabili nel system prompt e smetti di modificarle.
• Loop: imposta un limite di turni e un limite di spesa prima di lasciarlo girare.
• Jev: etichetta 200 esempi di qualunque cosa il tuo agente decida più spesso.
• Harness: esegui il tuo agente come un utente che non può cancellare nulla.
• Evals: trascrivi i tuoi ultimi cinque fallimenti come test case.

Su Viktor, la stessa giornata appare così:

• Context: scrivi il brief aziendale e registra la tua prima skill.
• Loop: inserisci una definizione di "fatto" in ogni attività e scegli il tier di proposito.
• Jev: filtra qualsiasi flusso prima che diventi attività per lui.
• Harness: collegalo con credenziali in sola lettura e limitate.
• Evals: salva 20 thread reali come primo set di test.

È una giornata di lavoro e copre tutti e cinque i livelli.

La mia opinione: il modello non è più la parte difficile. Lo sono i cinque livelli che lo circondano. Impostali bene e aumenterai la capacità senza assumere nessuno. La maggior parte dei team dovrebbe prendere i primi tre pronti all'uso e dedicare il proprio tempo ai due che determinano la qualità: le decisioni economiche e gli evals.

Grazie a Viktor per aver sponsorizzato questo articolo.

Provalo gratis su @viktor_com. $100 in crediti, nessuna carta richiesta. Link completo nella mia prima risposta.

Usa il codice YARCHI100 quando ti registri.

Partnership a pagamento