Le skill come porte agli strumenti: scalare il contesto AI

Un caso di studio tecnico su NanthAI:Edge.

La maggior parte degli agenti AI cresce nel modo sbagliato: ogni nuova capacità aggiunge testo al prompt, schemi di strumenti e occasioni in cui il modello può scegliere male. In NanthAI:Edge, non è solo una teoria. Il catalogo attuale delle skill visibili occupa circa 5,1k token come metadati, contro circa 67k token per il corpo completo delle skill visibili. Il registro di base espone 4 strumenti, contro i 115 del registro completamente espanso. Questo non dimostra una maggiore riuscita dei compiti, ma dimostra che la superficie del contesto è radicalmente più piccola.

Sintesi

Gli agenti basati su modelli linguistici di grandi dimensioni (LLM) che usano strumenti affrontano una tensione strutturale tra ampiezza delle capacità ed economia del contesto. Ogni istruzione aggiuntiva sui flussi di lavoro e ogni schema di strumento aggiuntivo inseriti nel contesto del modello consumano token, aumentano latenza e costi e possono rendere meno affidabile la selezione degli strumenti. Questo articolo sviluppa lo schema progettuale dell’accesso progressivo agli strumenti regolato dalle skill, in cui un catalogo compatto di skill, stabile per la cache, media sia il caricamento delle istruzioni su richiesta sia l’espansione incrementale del registro degli strumenti eseguibili.

Una skill viene trattata come un pacchetto di istruzioni modulare e individuabile, con metadati, indicazioni comportamentali complete e requisiti dichiarati sui profili di strumenti. Anziché inserire tutte le skill e tutti gli strumenti in ogni richiesta, il sistema espone prima metadati leggeri delle skill; il modello richiama load_skill quando un compito corrisponde a una skill; le skill caricate introducono poi istruzioni dettagliate e attivano i profili di strumenti pertinenti.

L’articolo colloca questo schema rispetto alla letteratura sull’appesantimento dei prompt, sulla scalabilità delle chiamate di funzione, sulla selezione degli strumenti basata sul recupero, sulla cache dei prompt, sulla divulgazione progressiva e sull’architettura modulare degli agenti. Analizza poi NanthAI:Edge come caso di studio concreto usando dettagli di implementazione forniti dall’autore del sistema. NanthAI:Edge organizza le capacità su tre livelli: piano dell’account, skill e strumenti eseguibili. L’articolo spiega i benefici attesi, i rischi principali e i compromessi di implementazione di questa architettura.

Sintesi del flusso del registro degli strumenti, con accesso regolato dalle skill

1. Introduzione

I moderni sistemi LLM ad agenti vengono in genere costruiti componendo tre tipi di contesto in ogni richiesta: istruzioni di sistema, schemi degli strumenti e stato della conversazione. Man mano che gli agenti accumulano capacità, ogni livello tende a crescere. Nuovi flussi di lavoro aggiungono istruzioni al prompt. Nuove integrazioni aggiungono schemi di strumenti. Nuove preferenze e ricordi degli utenti aggiungono contesto. Il sistema risultante è capace, ma sempre più pesante.

Questo crea due problemi collegati:

1. L’appesantimento del prompt si verifica quando il prompt di sistema accumula istruzioni comportamentali estese, regole, indicazioni sui flussi di lavoro, esempi, memoria e regole contestuali.
2. L’appesantimento del registro degli strumenti si verifica quando molti strumenti eseguibili vengono esposti al modello indipendentemente dalla loro pertinenza al compito corrente.

Entrambi sono costosi. Consumano token in ingresso, aumentano la latenza e il costo per il provider e complicano la cache dei prompt. Soprattutto, possono peggiorare la qualità delle decisioni. Un modello chiamato a scegliere tra decine o centinaia di strumenti deve confrontare più candidati, prestare attenzione a più descrizioni e risolvere più sovrapposizioni semantiche.

Il lavoro recente sulla selezione degli strumenti potenziata dal recupero sostiene questa preoccupazione. Lo studio RAG-MCP di Gan e Sun riporta che recuperare gli schemi degli strumenti pertinenti, invece di passarli tutti, ha migliorato l’accuratezza della selezione dal 13,62% al 43,13% in una configurazione MCPBench WebSearch, riducendo i token del prompt di circa la metà. Queste cifre dipendono dallo specifico benchmark e non vanno generalizzate alla cieca, ma illustrano la pressione centrale: esporre tutti gli strumenti in un elenco piatto è spesso una cattiva architettura dell’informazione.

Questo articolo esamina un’alternativa strutturata: l’accesso progressivo agli strumenti regolato dalle skill.

Lo schema è semplice:

1. Esporre un catalogo compatto delle skill disponibili.
2. Lasciare che il modello carichi una skill pertinente tramite load_skill.
3. Inserire le istruzioni complete della skill solo dopo l’attivazione.
4. Espandere il registro degli strumenti attivi solo attraverso i profili richiesti dalle skill caricate.

Questo schema adatta la divulgazione progressiva dell’esperienza utente e l’occultamento dell’informazione dell’architettura software all’economia delle finestre di contesto degli LLM. Il dettaglio nascosto non viene nascosto a un utente umano: viene nascosto al modello finché il compito non ne giustifica l’esposizione.

Analizziamo questo schema attraverso NanthAI:Edge, un runtime commerciale per agenti la cui architettura implementa capacità dell’account a livelli, individuazione e caricamento delle skill ed espansione degli strumenti regolata dai profili. I dettagli specifici di NanthAI in questo articolo sono dettagli di implementazione del caso di studio forniti dall’autore del sistema.

L’articolo offre:

1. Un quadro concettuale delle skill come porte progressive verso istruzioni e strumenti.
2. Un’analisi dell’architettura a tre livelli di NanthAI:Edge come caso di studio.
3. Una discussione sulla stabilità della cache, sull’intento di instradamento e sull’espansione del registro basata sui profili.
4. Un catalogo dei rischi incentrato sulla selezione errata delle skill e sul loro mancato caricamento.

2. Contesto: crescita dei prompt, schemi e uso degli strumenti negli agenti

2.1 Chiamate di funzione ed esposizione degli strumenti

Le API per le chiamate di funzione richiedono di descrivere gli strumenti al modello mediante nomi, descrizioni in linguaggio naturale e schemi strutturati dei parametri. Il modello decide se chiamare uno strumento, quale chiamare e quali argomenti fornire. Benchmark come il Berkeley Function Calling Leaderboard valutano questa capacità in contesti a turno singolo, a più turni, paralleli e sensibili alla pertinenza.

L’uso degli strumenti non è una sola capacità. Si scompone in diverse capacità:

• Selezione dello strumento: scegliere la funzione giusta.
• Costruzione degli argomenti: produrre parametri validi e semanticamente corretti.
• Sequenziamento delle chiamate: richiamare gli strumenti nell’ordine giusto.
• Interpretazione dei risultati: usare correttamente i risultati degli strumenti.
• Completamento del compito: soddisfare l’intento effettivo dell’utente.

Un sistema può scegliere lo strumento giusto ma sbagliare gli argomenti. Può richiamare uno strumento plausibile ma non riuscire nel compito. Può riuscire una volta ma peggiorare lungo percorsi a più turni. Ecco perché valutare solo la risposta finale non basta per i sistemi ad agenti.

2.2 Appesantimento del prompt

L’appesantimento del prompt viene spesso presentata come un problema di costo, ma il problema più profondo è la focalizzazione. I prompt lunghi possono includere informazioni pertinenti e irrilevanti, istruzioni obsolete, regole duplicate e molte definizioni di strumenti. Finestre di contesto più grandi consentono di far stare queste informazioni, ma farle stare non equivale a usarle in modo affidabile.

Ricerche sui contesti lunghi come “Lost in the Middle” mostrano che i modelli possono usare le informazioni in modo meno affidabile a seconda della loro posizione nel contesto. Altri studi sui contesti lunghi e sulle chiamate agli strumenti suggeriscono che lunghezza del contesto, numero di strumenti e accumulo su più turni possano interagire in modi fragili. Le soglie esatte variano per modello e compito, quindi questo articolo evita affermazioni come “i modelli falliscono dopo N strumenti”. L’affermazione sostenibile è più circoscritta: istruzioni superflue e schemi irrilevanti aumentano la superficie decisionale esposta al modello e possono peggiorare le condizioni di instradamento.

2.3 Appesantimento del registro degli strumenti

L’appesantimento del registro degli strumenti è la versione dell’appesantimento del prompt che riguarda gli strumenti. Un grande registro piatto costringe ogni strumento disponibile a competere per l’attenzione in ogni compito. È particolarmente problematico quando gli strumenti si sovrappongono semanticamente: più strumenti di ricerca, più strumenti per documenti, per calendario, per spazio di lavoro o più varianti specifiche per singole integrazioni.

Il lavoro sulla selezione degli strumenti basata sul recupero affronta direttamente questo problema. RAG-MCP recupera gli schemi pertinenti prima di preparare il prompt, anziché esporre tutti gli strumenti. Tool Attention e gli approcci di caricamento dinamico degli schemi sostengono in modo simile la riduzione dell’insieme di candidati attivi. Questi approcci non dimostrano che l’accesso regolato dalle skill funzioni, ma sostengono l’idea più ampia che il modello non debba sempre vedere ogni capacità eseguibile.

2.4 Qualità delle descrizioni degli strumenti

Ridurre l’esposizione degli strumenti non basta. Gli strumenti e le skill che restano visibili devono essere descritti chiaramente. ToolACE riporta miglioramenti grazie a dati verificati e di alta qualità sulle chiamate di funzione, mostrando che la qualità di schemi e descrizioni influisce sull’accuratezza nell’uso degli strumenti. Studi sulla documentazione API suggeriscono analogamente che parametri documentati in modo poco chiaro e interfacce complesse aumentano gli errori.

Questo crea la tensione progettuale centrale:

• Istruzioni e schemi dettagliati migliorano l’esecuzione.
• Esporre globalmente tutte le istruzioni e tutti gli schemi dettagliati crea appesantimento.

L’accesso progressivo regolato dalle skill affronta questa tensione separando i metadati per l’individuazione dai dettagli per l’esecuzione.

2.5 Cache dei prompt

La cache dei prompt può ridurre latenza e costi quando vengono riutilizzati prefissi stabili. Ma la cache premia una struttura stabile del prompt. Se gli elenchi di strumenti o le istruzioni di sistema vengono riscritti in modo imprevedibile, il riutilizzo della cache può peggiorare.

Questo crea una seconda tensione progettuale:

• Il caricamento dinamico riduce il contesto irrilevante.
• L’inserimento dinamico può compromettere la stabilità della cache.

Un’architettura praticabile di accesso regolato dalle skill deve quindi gestire dove e come appaiono le istruzioni caricate. L’approccio di NanthAI:Edge, descritto più avanti, mantiene stabili il prompt di base e il catalogo, poi aggiunge blocchi normalizzati delle skill caricate in posizioni prevedibili.

3. Le skill come pacchetti modulari di istruzioni

Una skill è un pacchetto di capacità con un nome, individuabile dal modello. Non è solo uno strumento né solo un frammento di prompt. Si colloca tra l’intento dell’utente e le funzioni eseguibili.

Una skill include in genere:

• slug
• nome
• riepilogo
• runtimeMode
• istruzioni complete del flusso di lavoro
• ID degli strumenti richiesti
• profili di strumenti richiesti
• integrazioni richieste
• capacità dell’account richieste
• vincoli di policy
• metadati di versione

Uno strumento è un’operazione eseguibile. Una skill è una capacità a livello di flusso di lavoro che può usare zero, uno o molti strumenti.

Per esempio, uno strumento di generazione documenti può creare un file .docx. Una skill di “scrittura di articoli di ricerca” può definire regole di gestione delle fonti, rigore nelle citazioni, struttura, requisiti di sintesi e aspettative di generazione dei documenti, e può attivare strumenti per documenti, ricerca e analisi.

L’accesso progressivo regolato dalle skill opera su tre livelli di divulgazione:

Questa struttura trasforma le skill in primitive di gestione del contesto. Sono contemporaneamente:

• unità di capacità;
• unità di ambito delle istruzioni;
• unità di espansione del registro degli strumenti;
• unità di governance e osservabilità.

4. Il caso di studio NanthAI:Edge

Questa sezione riassume dettagli di implementazione del caso di studio forniti dall’autore del sistema. Va letta come documentazione architetturale, non come prova verificata in modo indipendente.

4.1 Modello delle capacità a tre livelli

NanthAI:Edge organizza le capacità su tre livelli:

1. Capacità e piano dell’account
2. Skill
3. Strumenti eseguibili

Il livello dell’account determina ciò a cui l’utente è autorizzato ad accedere. Gli utenti del piano gratuito ricevono una chat semplice senza un registro di strumenti richiamabili dal modello. Gli utenti Pro con modelli compatibili con gli strumenti ricevono un piccolo registro di base.

Il livello delle skill contiene pacchetti modulari di istruzioni con metadati e regole di attivazione.

Il livello degli strumenti eseguibili contiene gli schemi e le implementazioni effettive, ma le famiglie di strumenti pesanti non vengono esposte per impostazione predefinita. Vengono sbloccate dai profili dichiarati dalle skill.

4.2 Registro di base

Il registro di base contiene strumenti leggeri di uso generale come:

• load_skill
• list_skills
• search_chats
• fetch_image

Lo strumento cruciale è load_skill. Fa dell’instradamento un’azione a pieno titolo del modello. Il modello non ha bisogno di tutte le istruzioni fin dall’inizio; gli bastano metadati sufficienti per decidere quando sono necessarie istruzioni più approfondite.

4.3 Metadati delle skill

Le skill di NanthAI includono metadati strutturati:

• slug
• name
• summary
• runtimeMode
• requiredToolIds
• requiredToolProfiles
• requiredIntegrationIds
• requiredCapabilities

Questi metadati supportano sia l’individuazione da parte del modello sia l’applicazione delle regole nel runtime. Una skill che richiede Slack, per esempio, può essere nascosta se l’utente non ha collegato Slack. Una skill che richiede una capacità Pro può essere omessa per gli utenti del piano gratuito.

4.4 Catalogo delle skill disponibili

Le skill determinate come disponibili vengono rappresentate in un blocco XML <available_skills> nel prompt di sistema. Questo catalogo contiene metadati compatti, non istruzioni complete.

Un esempio semplificato:

<available_skills>
<skill slug="analytics_report">
<name>Report di analisi</name>
<summary>Usa quando l’utente ha bisogno di analisi dei dati, grafici o risultati analitici strutturati.</summary>
</skill>
<skill slug="document_drafting">
<name>Redazione di documenti</name>
<summary>Usa quando l’utente ha bisogno di un documento strutturato, una proposta, un promemoria o un file generato.</summary>
</skill>
</available_skills>

Il catalogo è una superficie di instradamento. Dice al modello quali capacità esistono senza costringerlo a elaborare integralmente ogni flusso di lavoro.

4.5 Stati delle skill

NanthAI risolve le skill su quattro ambiti:

• impostazioni dell’account;
• profilo Persona;
• chat;
• override a livello di turno.

A ogni skill può essere assegnato uno di tre stati:

• always: istruzioni complete inserite a ogni turno;
• available: elencata nel catalogo e caricabile su richiesta;
• never: esclusa completamente.

Questo permette regole granulari. Le regole universali possono essere sempre attive. I flussi specialistici possono essere disponibili. Le capacità non consentite o irrilevanti possono essere nascoste.

4.6 load_skill

Quando il modello determina che un compito corrisponde a una skill, richiama load_skill con lo slug della skill. Il runtime restituisce istruzioni complete e metadati di instradamento.

Anziché affidarsi alle trascrizioni grezze dei risultati degli strumenti, NanthAI normalizza le istruzioni caricate in un messaggio di sistema dedicato alle skill caricate. Questo rende esplicito lo stato delle istruzioni attive ed evita di accumulare una cronologia rumorosa di chiamate agli strumenti.

4.7 Profili progressivi di strumenti

Le skill dichiarano requiredToolProfiles. Caricare una skill può attivare uno o più profili di strumenti. I profili forniti dall’autore includono:

• docs
• analytics
• workspace
• persistentRuntime
• subagents
• google
• microsoft
• notion
• appleCalendar
• cloze CRM
• slack
• scheduledJobs
• skillsManagement
• personas

Esempi:

• docs sblocca strumenti di generazione e modifica di documenti e file.
• analytics sblocca Python e strumenti per i dati.
• workspace sblocca strumenti per file ed esecuzione nello spazio di lavoro.
• I profili di integrazione sbloccano strumenti specifici delle app solo quando sono collegate.
• subagents sblocca la creazione di sottoagenti solo quando è consentita.

Il registro si espande quindi in base alle skill attivate, non alla capacità totale della piattaforma.

4.8 Protezione del runtime

NanthAI include una protezione del runtime che istruisce il modello a non inventare strumenti non disponibili: nessun accesso al file system locale, nessuna shell, nessuna automazione del browser, nessun server MCP non configurato e nessuna richiesta diretta alla rete al di fuori degli strumenti espliciti di NanthAI.

Questa protezione a livello di prompt non è, da sola, un confine di sicurezza. Il confine di sicurezza effettivo deve essere applicato tramite autorizzazione del runtime ed elenchi di strumenti consentiti. La protezione rafforza però la comprensione del modello delle capacità attive.

5. Analisi dell’architettura

5.1 Modello del costo in token

In un’impostazione monolitica, il costo del prompt per turno è approssimativamente:

base_prompt + all_skill_instructions + all_tool_schemas + conversation_state

Con l’accesso progressivo regolato dalle skill, il costo è approssimativamente:

base_prompt + skill_catalog_metadata + loaded_skill_instructions + active_profile_tool_schemas + conversation_state

La distinzione critica è ciò che cresce con la capacità totale della piattaforma. Nell’impostazione monolitica, i costi pesanti di istruzioni e schemi crescono con tutte le capacità disponibili. In quella progressiva, crescono con le capacità attivate. Il catalogo cresce comunque, ma solo come metadati compatti.

È questo il nucleo economico dell’architettura.

5.2 Il catalogo come superficie di instradamento stabile per la cache

Il blocco available_skills è pensato per restare stabile tra i turni, a meno che non cambino le capacità dell’utente, il profilo Persona, le impostazioni della chat o quelle specifiche del turno. La stabilità conta perché la cache dei prompt dipende da prefissi riutilizzabili. Un catalogo compatto e stabile può rimanere adatto alla cache, mentre i corpi completi delle skill restano rimandati a dopo.

5.3 Blocco delle skill caricate

Normalizzare le istruzioni delle skill caricate in un messaggio di sistema dedicato ha due benefici:

1. Mantiene pulito lo stato delle istruzioni. Il modello vede le indicazioni delle skill caricate come contesto di sistema attivo, anziché come risultato storico di uno strumento.
2. Aiuta a preservare la struttura della cache dei prompt. Se le skill caricate vengono aggiunte dopo il prompt di base stabile e il contenuto del catalogo, le nuove attivazioni estendono il contesto senza riscrivere il prefisso stabile.

È una delle intuizioni architetturali più importanti del design di NanthAI: l’espansione dinamica delle capacità e la cache dei prompt non sono naturalmente compatibili, quindi la struttura dei messaggi deve conciliarle esplicitamente.

5.4 Espansione del registro basata sui profili

I profili di strumenti creano un livello intermedio tra skill e strumenti. È preferibile che ogni skill possieda direttamente un lungo elenco di singoli schemi di strumenti.

Questo livello intermedio ha diversi vantaggi:

• più skill possono condividere un profilo;
• i profili possono essere verificati come insiemi di capacità;
• la disponibilità delle integrazioni può essere controllata una volta per profilo;
• gli strumenti correlati possono essere esposti insieme;
• le regole possono essere applicate a livello di profilo;
• il registro attivo rimane spiegabile.

Per esempio, molte skill possono richiedere la generazione di documenti. Anziché duplicare gli elenchi di strumenti per documenti tra le skill, possono attivare il profilo docs.

5.5 Intento di instradamento

In un registro piatto, l’intento è implicito. Se il modello richiama uno strumento, gli sviluppatori devono dedurne il perché. In un sistema regolato dalle skill, l’intento di instradamento diventa esplicito:

compito dell’utente → skill caricata → profilo attivato → strumento selezionato

Questo migliora l’osservabilità. Gli errori possono essere scomposti per livello:

• La skill corretta era visibile?
• È stata caricata?
• Ha attivato il profilo giusto?
• È stato selezionato lo strumento giusto?
• Gli argomenti erano corretti?
• La risposta finale ha soddisfatto il compito?

È un vantaggio sostanziale nella valutazione rispetto ai prompt monolitici.

6. Obiezione centrale: l’instradamento tramite metadati può fallire

L’obiezione più forte all’accesso progressivo regolato dalle skill è che nascondere le istruzioni complete può danneggiare l’instradamento.

Un modello potrebbe non riuscire a distinguere skill simili solo dai metadati. Se i riepiloghi del catalogo sono troppo brevi, vaghi o sovrapposti, il modello può:

• caricare la skill sbagliata;
• non caricare alcuna skill;
• caricare troppe skill;
• attivare il profilo di strumenti sbagliato;
• produrre una risposta plausibile ma non abbastanza specifica.

Non è un caso limite minore. È il compromesso centrale. L’accesso progressivo scambia un problema, l’appesantimento globale, con un altro: richiamo e precisione dell’instradamento.

L’architettura è più solida quando:

• il catalogo delle skill ha dimensioni moderate;
• i riepiloghi delle skill le distinguono chiaramente;
• le skill non si sovrappongono molto;
• è consentito chiedere chiarimenti quando necessario;
• le decisioni di instradamento vengono registrate e valutate;
• il recupero semantico può aiutare a trovare corrispondenze nel catalogo.

È più debole quando:

• ci sono migliaia di skill simili;
• i riepiloghi sono generici;
• i compiti richiedono distinzioni sottili;
• il modello viene scoraggiato dal fare domande di chiarimento;
• il mancato caricamento di una skill produce silenziosamente un risultato scadente ma plausibile.

Un’implementazione robusta dovrebbe quindi combinare il giudizio del modello con controlli deterministici, recupero, gestione delle versioni e valutazione.

7. Rischi e modalità di errore

R1: Selezione della skill sbagliata

Il modello carica una skill simile ma non corretta. Questo può introdurre istruzioni sbagliate e attivare strumenti irrilevanti.

Mitigazioni: riepiloghi distintivi, esempi, note su “quando non usare”, test di instradamento offline, soglie di confidenza.

R2: Mancato caricamento delle skill

Il modello procede senza caricare una skill. È pericoloso perché il risultato può sembrare accettabile pur violando i requisiti del flusso di lavoro.

Mitigazioni: indicazioni di caricamento più forti, rilevatori di skill mancate, classificatori a posteriori, richiesta di chiarimenti.

R3: Istruzioni obsolete

Le istruzioni caricate possono persistere dopo l’aggiornamento di una skill.

Mitigazioni: ID di versione delle skill, invalidazione della cache, regole di ricaricamento, test di compatibilità.

R4: Accoppiamento nascosto

Skill e profili possono divergere. Una skill può presupporre strumenti che non sono realmente disponibili nel suo profilo.

Mitigazioni: requiredToolProfiles, requiredToolIds, test dei profili, controlli statici delle dipendenze.

R5: Latenza aggiuntiva

load_skill aggiunge un ciclo di chiamata a uno strumento prima dell’inizio del lavoro.

Mitigazioni: mantenere i flussi più frequenti come always, precaricamento speculativo o registro di base ibrido.

R6: Invalidazione della cache

I contenuti dinamici inseriti troppo presto possono impedire il riutilizzo della cache.

Mitigazioni: disciplina dei prefissi stabili, blocco delle skill caricate con sole aggiunte in coda, test della cache.

R7: Prompt injection

Le skill scritte dagli utenti possono contenere istruzioni non sicure.

Mitigazioni: revisione delle skill, controlli statici delle regole, isolamento in sandbox, ambiti di autorizzazione, applicazione dei controlli nel runtime.

R8: Eccessivo affidamento sul giudizio del modello

In condizioni di ambiguità, il modello può instradare male.

Mitigazioni: instradamento assistito dal recupero, controlli deterministici delle regole, chiarimenti all’utente, telemetria.

8. Discussione

L’accesso progressivo regolato dalle skill riformula la registrazione degli strumenti come architettura delle capacità. Anziché un elenco piatto di strumenti, il runtime dell’agente diventa stratificato:

regole dell’account → catalogo delle skill → caricamento delle skill → attivazione dei profili → esecuzione degli strumenti

Questo ha diverse implicazioni:

1. Le skill diventano l’unità primaria di governance. Accesso per piano, stato delle integrazioni, profili di strumenti e modalità del runtime possono essere tutti espressi tramite i metadati delle skill.
2. L’instradamento diventa ispezionabile. Gli eventi load_skill possono essere registrati, misurati e valutati.
3. I marketplace di skill diventano più gestibili. Le skill scritte dagli utenti possono dichiarare i propri requisiti ed essere ammesse con un ambito di capacità delimitato.
4. Le soluzioni ibride sono probabilmente le migliori. I piccoli strumenti universali dovrebbero rimanere nel registro di base. L’accesso a strumenti specialistici, ad alto rischio, costosi o usati raramente dovrebbe essere regolato. Le skill always dovrebbero essere rare. available dovrebbe essere l’impostazione predefinita per i flussi specialistici. never dovrebbe escludere le capacità non consentite.
5. La qualità del catalogo delle skill diventa una superficie del prodotto. I riepiloghi del catalogo non sono etichette interne: sono interfacce di instradamento rivolte al modello. Richiedono lo stesso rigore della documentazione API.

È questa la direzione che stiamo seguendo in NanthAI:Edge: le capacità dovrebbero essere individuabili senza essere inserite permanentemente e gli strumenti potenti dovrebbero apparire solo quando il flusso di lavoro attivo li giustifica.

9. Misurazioni statiche dell’architettura

Sebbene la validazione completa del comportamento richieda una suite di benchmark, alcune affermazioni possono essere valutate direttamente dall’attuale implementazione di NanthAI:Edge. In particolare, il codice permette di misurare la superficie del contesto esposta dal catalogo delle skill e dal registro progressivo degli strumenti.

Queste misurazioni quantificano il lato dell’economia del contesto dell’argomento: quanto materiale del prompt e degli schemi degli strumenti si evita esponendo metadati compatti delle skill e un piccolo registro di base anziché inserire fin dall’inizio il corpo di ogni skill e ogni schema di strumento.

9.1 Compressione del catalogo delle skill

L’attuale catalogo di sistema di NanthAI:Edge contiene 55 skill visibili e 11 skill nascoste o non visibili. Le skill visibili vengono rappresentate nel catalogo available_skills rivolto al modello come metadati leggeri: nome della skill, riepilogo e indicazioni sui requisiti. I corpi completi delle istruzioni non vengono inclusi finché una skill non viene caricata esplicitamente.

Misurazione rispetto all’attuale catalogo visibile:

Questo significa che la superficie predefinita per individuare le skill è grande circa un tredicesimo dell’intero insieme delle istruzioni delle skill visibili. Il modello può comunque vedere che le capacità esistono, ma non paga il costo completo delle istruzioni a meno che un compito non ne richieda davvero una.

Questo sostiene la prima affermazione dell’architettura sull’economia del contesto: l’individuazione delle skill può rimanere ampia mentre l’attivazione delle istruzioni resta selettiva.

9.2 Compressione del registro degli strumenti

L’effetto sul registro degli strumenti è ancora più marcato. Nell’attuale registro progressivo, l’insieme di base espone solo quattro strumenti di uso generale:

• load_skill
• list_skills
• search_chats
• fetch_image

Quando tutti i profili di strumenti sono espansi, il registro contiene 115 strumenti. La differenza in token degli schemi è sostanziale:

Questo sostiene la seconda affermazione sull’economia del contesto: lo spazio predefinito delle azioni eseguibili del modello è molto più piccolo dell’insieme totale delle capacità della piattaforma.

In un’impostazione monolitica, il modello vedrebbe l’intero registro a ogni turno compatibile con gli strumenti. Con l’espansione progressiva, vede solo gli strumenti di base finché una skill caricata non attiva uno o più profili.

9.3 Esempi di costi dei profili attivi

Flussi di lavoro diversi attivano profili di strumenti diversi. I risparmi dipendono quindi dal compito. Un flusso di analisi circoscritto espone molti meno strumenti di uno di generazione documenti, ed entrambi ne espongono molti meno di un registro completamente espanso.

Questi esempi illustrano perché il livello intermedio basato sui profili conta. Un compito di analisi dei dati non ha bisogno di strumenti per calendario, Slack, modifica dei documenti, attività pianificate o gestione dei profili Persona. Un compito su Slack non ha bisogno dell’esecuzione di Python o di strumenti di generazione documenti. Un compito sui documenti può richiedere il profilo docs, relativamente pesante, ma evita comunque la maggior parte degli strumenti di integrazione e runtime, salvo richiesta esplicita.

Il sistema sposta quindi il costo degli schemi degli strumenti da “tutto ciò che è disponibile all’utente” a “tutto ciò che è giustificato dal flusso di lavoro attualmente attivo”.

9.4 Interpretazione

Queste misurazioni convalidano la premessa di riduzione del contesto dell’architettura, non la sua intera promessa comportamentale.

Mostrano che il design progressivo di NanthAI:Edge riduce materialmente:

• l’esposizione predefinita delle istruzioni delle skill;
• l’esposizione predefinita degli schemi degli strumenti;
• la dimensione dello spazio di azione rivolto al modello;
• il materiale del prompt che deve restare stabile per la cache;
• i candidati irrilevanti tra gli strumenti prima dell’attivazione specifica per il compito.

Tuttavia, le misurazioni non dimostrano che il modello instradi meglio, scelga gli strumenti con più accuratezza o completi i compiti con maggiore successo. Queste affermazioni richiedono una valutazione del comportamento.

Le misurazioni statiche rispondono a una domanda:

L’accesso progressivo regolato dalle skill riduce davvero il contesto e l’esposizione degli schemi in questa implementazione?

La risposta è sì. Nell’implementazione attuale la riduzione è grande: circa 92,5% per le istruzioni delle skill e 97,7% per il registro di base degli strumenti rispetto all’esposizione completa.

10. Conclusione

I sistemi AI ad agenti affrontano un crescente problema di architettura dell’informazione. Man mano che si accumulano strumenti, integrazioni, flussi di lavoro e regole, le impostazioni monolitiche con prompt e registro degli strumenti diventano sempre più costosi e difficili da valutare. Le grandi finestre di contesto aiutano con la capacità, ma non risolvono pertinenza, instradamento, stabilità della cache o governance.

L’accesso progressivo agli strumenti regolato dalle skill offre un’alternativa fondata su principi chiari. Un catalogo compatto rende individuabili le skill. load_skill fornisce un’attivazione esplicita. Le istruzioni delle skill caricate forniscono indicazioni specifiche per il compito. I profili di strumenti permettono un’espansione delimitata del registro. Autorizzazione e protezioni del runtime mantengono i confini delle capacità.

Il caso di studio NanthAI:Edge mostra come questo schema possa essere implementato tramite piani dell’account, stati delle skill a livelli, cataloghi delle skill disponibili, messaggi normalizzati delle skill caricate, registri regolati dai profili e protezioni del runtime. L’architettura è promettente perché allinea il costo del contesto alla capacità attivata anziché alla capacità totale della piattaforma.

La domanda centrale irrisolta è empirica: il costo di instradamento introdotto dalla selezione delle skill a partire dai metadati supera i benefici della riduzione dell’appesantimento di prompt e registro? La risposta dipenderà dalle dimensioni del catalogo, dalla sovrapposizione tra skill, dalla famiglia di modelli, dalla distribuzione dei compiti e dalla qualità dell’implementazione.

Le piattaforme per agenti dovrebbero esporre progressivamente le capacità, rendere osservabile l’instradamento e attivare gli strumenti solo quando il compito li giustifica.

Riferimenti

• Gan, T., & Sun, Q. (2025). RAG-MCP: Mitigating Prompt Bloat in LLM Tool Selection via Retrieval-Augmented Generation. arXiv. https://arxiv.org/abs/2505.03275

• Liu et al. (2025). Lost in the Middle: How Language Models Use Long Contexts. https://arxiv.org/abs/2307.03172

• Gim, I., Chen, G., Lee, S.-s., Sarda, N., Khandelwal, A., & Zhong, L. (2024). Prompt Cache: Modular Attention Reuse for Low-Latency Inference. Proceedings of MLSys 2024. https://proceedings.mlsys.org/paper_files/paper/2024/file/a66caa1703fe34705a4368c3014c1966-Paper-Conference.pdf

• Liu, W., et al. (2024). ToolACE: Winning the Points of LLM Function Calling. arXiv. https://arxiv.org/html/2409.00920v2

• Yang, S., et al. (2023). Improving Planning with LLMs: A Modular Approach. arXiv. https://arxiv.org/html/2310.00194v4

• Wang, et al. (2025). Evaluating Position Bias in Large Language Model Recommendations. arXiv. https://arxiv.org/html/2508.02020v1

• Berkeley Function Calling Leaderboard. https://gorilla.cs.berkeley.edu/leaderboard.html

• Nielsen, J. (2006). Progressive Disclosure. Nielsen Norman Group. https://www.nngroup.com/articles/progressive-disclosure/

• Fowler, M. Function calling using LLMs. https://martinfowler.com/articles/function-call-LLM.html

• AWS. AI agents in enterprises: Best practices with Amazon Bedrock AgentCore. https://aws.amazon.com/blogs/machine-learning/ai-agents-in-enterprises-best-practices-with-amazon-bedrock-agentcore/

• Descrizione dell’architettura di NanthAI:Edge. Materiale del caso di studio fornito dall’autore; non verificato indipendentemente.

Pubblicato anche su LinkedIn.