La corsa all’intelligenza artificiale agentica ha un mantra: più parametri, più potenza. Eppure un team di Microsoft Research ha appena scardinato questa equazione con Orchard, un framework open source che fa correre agenti software a livelli quasi‑frontier usando modelli con soli 3 miliardi di parametri attivi. Il segreto non è un trucco di ottimizzazione esotico, ma una riprogettazione radicale di ciò su cui si appoggiano quegli agenti: l’ambiente di esecuzione.

L’idea al centro di Orchard è tanto semplice quanto dirompente. Invece di incastrare l’infrastruttura di training e valutazione dentro un singolo framework, Orchard Env mette a disposizione un servizio Kubernetes leggero e condiviso che genera container isolati su larga scala. Lo stesso servizio – senza modifiche – alimenta agenti per la scrittura di codice (Orchard‑SWE), per la navigazione web (Orchard‑GUI) e per l’assistenza personale (Orchard‑Claw). Il risultato è un ambiente riutilizzabile per la distillazione dei dati, il fine-tuning supervisionato e il reinforcement learning, che abbatte i costi e azzera la dipendenza da sandbox proprietarie o servizi cloud blindati.

I numeri raccontano l’efficacia. Orchard‑SWE raggiunge il 69,7% su SWE‑bench Verified, il benchmark più severo per la riparazione automatica del codice. Con un modello MoE da 35 miliardi totali ma soli 3 miliardi di parametri attivi per token, il sistema sale al 73% aggiungendo un semplice reranking basato su un value model. Sono risultati che si avvicinano a sistemi con più di 10 volte i parametri attivi, e tutto senza ricorrere a colossi da centinaia di miliardi. Analogamente, Orchard‑GUI – un modello vision‑language da 4 miliardi – ottiene una media del 68,4% su tre benchmark di navigazione web, posizionandosi tra i migliori agenti aperti e allineandosi a soluzioni proprietarie di OpenAI e Google.

Eppure la vera novità non sta tanto nei punteggi, quanto nell’architettura che li ha resi possibili. Orchard sposta il baricentro dal modello all’infrastruttura. L’ambiente Kubernetes condiviso permette di addestrare gli agenti direttamente dentro gli harness reali di deployment – Codex, OpenClaw, ZeroClaw – anziché su surrogati semplificati. Un proxy leggero registra le chiamate al modello come dati di training, mentre ogni rollout corre nel proprio container. Così si elimina il mismatch tra addestramento e messa in produzione, e si impara dai tentativi parziali anziché scartarli.

Questa scelta ha implicazioni strutturali che vanno ben oltre il laboratorio. Se un’infrastruttura aperta e riutilizzabile permette a modelli compatti di eguagliare o avvicinare le prestazioni di mega‑modelli, il costo per token di un agente crolla. Non è più necessario affittare GPU cloud per servire modelli immensi; bastano cluster on‑premise dimensionati per l’inference di pochi miliardi di parametri attivi, con evidenti vantaggi in termini di TCO e di sovranità dei dati. Le aziende possono mantenere gli agenti dentro i propri confini, senza esporre codice e informazioni sensibili a servizi di terze parti.

Orchard rende concreta la prospettiva di un’AI agentica “commodity”, dove il vero differenziale competitivo si sposta sull’ambiente di esecuzione e sulle pipeline di dati, non sulla taglia del modello. Per chi oggi valuta il deployment on‑premise di LLM, il framework fornisce un modello di riferimento: un layer Kubernetes leggero, training data‑efficient (appena 400 dimostrazioni guidano Orchard‑GUI), e la possibilità di accumulare esperienza tra un addestramento e l’altro, distillando trajectory in value model riutilizzabili. È un cambio di paradigma che erode il fossato dei vendor cloud e restituisce alle organizzazioni il controllo sull’intero ciclo di vita degli agenti.

Non è una coincidenza che Orchard nasca in Microsoft Research ma venga rilasciato completamente open source. Il messaggio è chiaro: il futuro degli agenti non sarà scritto nei pesi di un singolo modello, ma nella capacità di orchestrare ambienti flessibili, riaddestrabili e sovrani. E quella capacità, oggi, è alla portata di chiunque abbia un cluster Kubernetes e la volontà di non delegare l’intelligenza.