Filiera per agenti IA pratici: linguaggi, modelli, esecuzione e contesto

Jason Mars è salito sul palco di All Things Open con un’idea netta: gli agenti non sono utenti di fortuna degli strumenti, sono i soggetti che li usano. Il linguaggio Jac e il runtime Jaseci nascono per questo, trattano agenti e IA come entità di prima classe. “Non stiamo più usando questi strumenti. Stiamo usando gli agenti, e gli agenti stanno usando quegli strumenti”, ha detto al pubblico¹. Tesi: per avere agenti utili in produzione serve una filiera coerente, dal linguaggio al modello, dagli strumenti di sviluppo alla progettazione del contesto.

Perché serve una filiera coerente per agenti IA pratici

Le pipeline attuali vivono nella “complessità poliglotta”: più linguaggi, API disallineate, passaggi manuali. Funzionano per sviluppatori umani. Zoppicano quando un agente deve comporre capacità su sistemi eterogenei¹. Un agente utile non è un prompt in più. Ha stato, diritti, strumenti, un ciclo di azioni. Quel ciclo richiede un runtime che lo riconosca, un modello che non rompa il function calling, un ambiente di esecuzione e verifica vicino al codice, e un contesto progettato come un budget.

Senza coerenza, l’agente inciampa. Chiama uno strumento con un formato diverso da quello atteso. Perde stato tra un passaggio e l’altro. Riempie la finestra di contesto con rumore. Anche un modello capace sbaglia se la filiera lo spinge fuori traccia.

Linguaggi e runtime pensati per l’agente: Jac e Jaseci

Mars propone un cambio di baricentro. Jac ha la sintassi di famiglia Python, ma porta primitive e orchestrazione per agenti. Jaseci è il runtime che rende quell’identità operativa¹. Se l’agente è il soggetto che usa gli strumenti, il modello di programmazione deve rifletterlo. Non si incollano più tool pensati per umani. Si definiscono operazioni, stato, coordinamento e diritti come elementi di prima classe¹.

Il bersaglio è chiaro: ridurre l’attrito quando un agente attraversa servizi diversi. La poliglossia crea interstizi dove si perde informazione. Un runtime che esplicita ruoli e diritti evita che l’agente improvvisi. La scelta di mettere l’agente al centro consente anche politiche più chiare sugli accessi agli strumenti. Il flusso diventa più prevedibile: chi agisce, con quali permessi, su quali risorse.

Questo modello non sostituisce gli strumenti umani. Li riallinea. Gli strumenti restano, ma il contratto cambia: l’agente li orchestra, non li subisce¹. Per chi costruisce sistemi con più componenti, è un invito a spostare la logica dai collanti ad hoc a un runtime che parli il linguaggio dell’agente.

Modelli che mantengono il tool-calling: il caso Saluki 27B

Un agente senza tool-calling affidabile è un utente dimezzato. Saluki 27B mette il tema in chiaro: comprime Qwen3.8-27B in 7,9 GB, dichiara circa due bit per peso e, nei test degli autori, supera la build da 54 GB su 120 task di function calling del Berkeley Function Calling Leaderboard². La posta è pratica: mantenere le capacità di chiamata funzione in un profilo più leggero.

Il metodo conta. Il confronto usa file GGUF in una copia di llama.cpp senza modifiche. Gli autori affiancano Saluki e la quantizzazione di riferimento, poi ispezionano gli header tensor per tensor per cercare differenze nei metadati. Passano ai byte del contenuto per capire se Saluki riusa i bit o cambia la rappresentazione. Il controllo prosegue in runtime: ogni modello viene caricato in llama.cpp, sulla stessa cornice, su una singola GPU².

Il messaggio, per chi progetta agenti, è operativo. Non basta che il modello “entri” in memoria. Deve conservare la competenza di parlare con gli strumenti esterni. Se la quantizzazione rompe il function calling, il runtime agente-aware resta senza braccia. L’analisi byte per byte e la prova controllata in esecuzione sono un esempio di verifica quando la priorità è il tool-calling, non solo le metriche aggregate².

Esecuzione locale, verifica e la necessità di progettare il contesto

L’agente vive nella filiera di sviluppo. Astral apre una preview sperimentale che fa lavorare insieme uv e ty. L’ingresso è uv check, un comando che centralizza la verifica del progetto. Uv conosce ambiente e dipendenze. Ty conosce il codice. Unendo le due viste, compaiono funzioni che i singoli strumenti non offrono. La preview copre due capacità: gestione nativa degli script Python su riga di comando e negli editor, e un’unica verifica con uv check³.

L’integrazione non impone adozioni forzate. Ogni componente resta utile da solo, interoperabile con gli altri. Nel catalogo di Astral compaiono uv come package manager, Ruff per linting e formattazione, ty come type checker e language server. L’annuncio riguarda l’accoppiata uv più ty, scelta per mostrare come una rappresentazione condivisa del progetto abiliti capacità nuove rispetto ai singoli strumenti, con un controllo unificato via uv check³. In pratica, si accorcia il ciclo tra modifica, esecuzione locale e diagnosi.

Sul fronte utente, Sloth Inbox sceglie il locale. Legge file di testo sul computer, fa la prima scrematura, e non sposta i contenuti fuori. Restituisce un riassunto breve, un suggerimento di “casa” e una lista di azioni quando servono. Cura i casi di confine: un “no action required” non diventa un compito. Il progetto al momento vive in locale ed è presentato come submission per l’Hacktoberfes⁴. È un esempio di come interfacce semplici e scelte locali possano alimentare agenti che operano vicino ai dati.

Resta un vincolo trasversale: la progettazione del contesto. Con finestre arrivate a centinaia di migliaia di token, la tentazione è incollare tutto. È una trappola. Il contesto irrilevante diluisce l’attenzione e peggiora l’accuratezza, anche quando la risposta è già nella finestra⁵. Conviene trattare tutto come un budget unico. L’istruzione di sistema si imposta una volta e si riusa. I documenti vanno recuperati per pertinenza, non per volume. I risultati degli strumenti sono spesso la parte più rumorosa. La cronologia va potata in modo aggressivo nei loop lunghi⁵.

Qui la filiera torna utile. Un runtime che conosce stato e diritti aiuta a selezionare cosa passa al modello. Un tool-calling stabile evita di riversare nel contesto dati che un tool potrebbe sintetizzare meglio. Un uv check che unifica diagnosi accelera le iterazioni su come costruire il budget del contesto. Un’app locale come Sloth mostra che spesso basta un estratto mirato per decidere, non l’intero documento.

Una tendenza che riduce attrito, non che aggiunge strati

Questi pezzi, letti insieme, puntano tutti nella stessa direzione: meno collanti, più contratti chiari tra agenti, modelli e strumenti. Jac e Jaseci mettono l’agente al centro del linguaggio e del runtime¹. Saluki 27B segnala che la compressione può conservare, e talvolta migliorare, il function calling su benchmark mirati, partendo da file GGUF e prove in llama.cpp². Astral collega ambiente e codice con un controllo unico, uv check, dentro una preview sperimentale³. Sloth sposta la prima scrematura sui dispositivi degli utenti, senza uscire dal locale⁴. Le finestre lunghe obbligano a trattare il contesto come un budget da progettare, non come un cestino senza fondo⁵.

La prospettiva è concreta: se i team adottano contratti espliciti per agente, tool-calling e contesto, la prossima iterazione non sarà aggiungere un altro strato, ma togliere colla dove il runtime può parlare da sé.