Lo stack degli agenti si sta dividendo in due

L'errore più costoso nella progettazione di agenti, in questo momento, è usare lo stesso modello per tutto. Prendi un modello frontier per decidere se chiamare un'API, e poi usi lo stesso modello per formattare il payload JSON. Per uno di quei compiti serve un fisico; per l'altro basta un impiegato competente. Pagare tariffe da fisico per lavoro d'ufficio non è solo uno spreco — è cattiva ingegneria. Accoppia l'intelligenza del tuo agente al suo costo operativo in un modo che peggiora entrambi.

Il rilascio di Muse Ember da parte di Meta rende concreta questa divisione. È un modello piccolo costruito specificamente per ciò in cui gli agenti passano la maggior parte dei loro cicli: chiamate a strumenti, routing ed estrazione dati [1]. A 10 centesimi per milione di token in input, batte Claude Haiku 5.5 e GPT-6 Luna con un margine ampio [3]. Meta sostiene che offra più intelligenza per dollaro su questi compiti ripetitivi, ammettendo apertamente che resta indietro nella programmazione vera e propria [1]. Quella ammissione è la parte interessante. Non stanno vendendo un modello che fa tutto; stanno vendendo un modello che fa le parti noiose dell'agency a costi estremamente bassi.

Il layer di esecuzione diventa una commodity

Negli ultimi due anni, l'architettura predefinita degli agenti è stata monolitica. Un modello — di solito uno frontier — gestisce pianificazione, ragionamento, selezione degli strumenti e il lavoro meccanico di strutturare gli output. Questo aveva senso quando i modelli più piccoli non riuscivano a produrre in modo affidabile chiamate di funzione valide o a seguire istruzioni di routing. Ma quella soglia di affidabilità è stata superata. Muse Ember non è il primo modello piccolo a gestire l'uso di strumenti in modo competente, ma il suo prezzo e il posizionamento esplicito di Meta come motore di esecuzione per agenti segnalano che questo layer è ora un mercato commodity.

L'implicazione per chi costruisce è che l'architettura del tuo agente ha ora una giuntura evidente. Il layer di ragionamento — dove serve vera intelligenza per scomporre compiti, gestire ambiguità o scrivere codice — resta con un modello frontier. Il layer di esecuzione — dove servono output veloci, affidabili e strutturati da pattern noti — si sposta su qualcosa come Ember. I due layer possono essere modelli diversi, di provider diversi, ottimizzati per cose diverse.

Cosa significa per la valutazione

Questa divisione complica la valutazione in modi utili. Non puoi più fare benchmark del tuo agente come un'unica scatola nera e considerarlo finito. Un agente che fa routing intelligente ma formatta le chiamate agli strumenti in modo sciatto ha un problema diverso da uno che formatta perfettamente ma fa routing stupidamente. Quando i modelli di ragionamento e di esecuzione vengono da vendor diversi, servono eval che isolino ciascun layer. Questo significa test per l'aderenza allo schema delle chiamate a strumenti, l'accuratezza del routing sotto variazione dei prompt e la fedeltà di estrazione che girino indipendentemente dalle tue eval di pianificazione.

Cambia anche il modo in cui pensi al fallback. Se il tuo modello di esecuzione è abbastanza economico, puoi permetterti di eseguirlo più volte con prompt diversi e votare l'output — uno schema proibitivamente costoso con i modelli frontier. L'affidabilità tramite ridondanza diventa una strategia legittima quando le chiamate ridondanti costano frazioni di centesimo.

La lezione di Instagram

C'è un secondo segnale che vale la pena notare, anche se arriva da una direzione diversa. L'Effect Builder di Instagram ora genera filtri AR da prompt AI [2]. Non è infrastruttura per agenti — è una funzionalità consumer. Ma illustra lo stesso pattern dal lato opposto: l'AI si sta spostando in ruoli di esecuzione dove l'output è un artefatto strutturato, non una conversazione. Un prompt produce un filtro, non un messaggio in chat. Il modello sta facendo uso di strumenti, solo impacchettato in un'interfaccia user-friendly.

Per chi costruisce agenti, questo è un promemoria che l'output strutturato sta diventando l'aspettativa predefinita, non una capacità specializzata. Quando le app consumer trattano il passaggio prompt-a-artefatto come una funzionalità normale, la capacità del tuo agente di produrre JSON valido al primo tentativo smette di essere impressionante e inizia a essere il minimo indispensabile. La differenziazione si sposta a monte, verso il ragionamento che decide quale JSON produrre e perché.

Il takeaway pratico è diretto. Guarda il consumo di token del tuo agente e separalo in lavoro di ragionamento e lavoro di esecuzione. Se più della metà della tua spesa è in generazione di output strutturato, decisioni di routing o aderenza a schemi, hai una giuntura dove un modello come Muse Ember ha senso. La differenza di costo non è marginale — è un ordine di grandezza — e il beneficio ingegneristico di disaccoppiare l'intelligenza dall'esecuzione si accumulerà man mano che entrambi i layer evolvono a velocità diverse.