Due metodi insegnano agli agenti LLM dalle proprie azioni

ACE e ALTK‑Evolve trasformano la storia d’esecuzione di un agente LLM in istruzioni operative da rimettere nel contesto, in inferenza. Nessun aggiornamento dei pesi. Nessuna etichetta umana¹.

Il banco di prova è concreto: dividere un conto, trovare una canzone, riconciliare un ordine su nove app simulate. Qui gli agenti non falliscono per mancanza di conoscenza. Sbagliano la paginazione di un’API. Risolvono l’identità sbagliata. Restituiscono un valore non richiesto¹. Il modello “conosce” le API; non le usa in modo affidabile. Le traiettorie passate contengono già le correzioni. Basta riportarle davanti al modello, al momento giusto¹.

Il post introduce ALTK‑Evolve e lo mette accanto a ACE, progettati per lo stesso tipo di agente. Entrambi estraggono “lezioni” dalle esecuzioni e le riutilizzano su task multi‑passo realistici. La memoria è agentica: non addestra, seleziona e ripresenta esperienze rilevanti¹.

Lessico e struttura contano. “Lezione” è il frammento grezzo appreso dall’agente. ACE organizza tutte le lezioni in un playbook unico e in evoluzione. ALTK‑Evolve le consolida in linee guida recuperabili una per una. Materia prima identica, due contenitori diversi¹. La differenza pratica è nella consegna: come recuperare e iniettare le lezioni durante l’esecuzione¹.

Scelta chiave condivisa: niente compressione. I due sistemi non riducono le lezioni a riassunti. Mantengono il contenuto integro per non perdere segnali operativi che guidano i passaggi sensibili, come la paginazione o la risoluzione di identità¹.

Lo scenario d’uso resta lo stesso. In presenza di errori ricorrenti legati all’orchestrazione delle API, le lezioni derivate dalle traiettorie colmano il divario tra “sapere” e “saper fare”. Il recupero in contesto prova a stabilizzare il comportamento senza interventi sui pesi né supervisione manuale¹.

ALTK‑Evolve, presentato nel post, applica la strategia per linee guida singole. ACE, invece, punta su un playbook unitario che cresce con l’esperienza. Obiettivo comune: ridurre gli errori e rendere più affidabile l’uso delle API durante l’esecuzione¹.

Il confronto apre una scelta progettuale chiara per chi costruisce agenti su API: partire dalle stesse lezioni non compresse e decidere il canale di consegna. Playbook unico oppure linee guida recuperabili, ma sempre con memoria dalle traiettorie e senza fine‑tuning¹. Implicazione operativa: il punto di leva non è il modello, è il contesto. Estrarre lezioni precise dalle esecuzioni e rimetterle, intatte, dove contano: nel prompt dell’agente al momento dell’azione¹.