## Gli eval sono funzionalità, non prodotti Sono a questo incontro di agenti di coding stasera con OAI, Any, GDM, Cursor, Factory, Delphi, Exa, @theo ecc. La conclusione sorprendente di questo panel, se posso essere così audace da parafrasare, è stata che theo ha detto che ci sono troppe startup di eval e thariq, nate e romain hanno sorprendentemente concordato che sì, dovresti andare avanti e costruire più agenti, non preoccuparti degli agenti di biglab, sono anche fondamentalmente piccole startup interne comunque, e probabilmente avrai un punto di vista diverso e il mondo ha bisogno di vederlo. ALLORA e solo allora costruirai buoni eval.

ci sono un sacco di opinioni sull'ingegneria degli agenti "keep it simple, stupid" che fondamentalmente lo riducono a "agente = llm + strumenti + ciclo + obiettivo" questo è un agente minimo e va bene! ma il motivo per cui questa definizione è troppo minimalista per essere utile è che ti fa dimenticare tutto ciò che rende gli agenti BUONI: - pianificazione - memoria - fiducia/autenticazione - valutazioni* a febbraio ho esaminato tutte le risposte alle richieste di definizioni di Simon e le ho già raggruppate per te. con un acronimo bonus per SMETTERE DI DIMENTICARE MEMORIA E PIANIFICAZIONE E FLUSSI DI AUTENTICAZIONE "agente = llm + Intent + Memoria + Pianificazione + Autenticazione/fiducia + Flusso di controllo + Uso degli strumenti" *aha! pensavi che fossi mr hate evals? perché pensi solo in binario?

è un po' ironico che abbiamo risolto il problema MxN -> M+N con MCP e poi la cosa successiva che tutti stanno facendo ora è lanciare i propri registri MCP (ne conto almeno 6 al momento) babel pianse