Architettura AI / 10 min di lettura
Ottimizzare Hermes Agent richiede disciplina architetturale
Hermes Agent diventa costoso o fragile quando contesto, tool, skill, memoria, subagent e job schedulati non sono governati. L’ottimizzazione corretta è architetturale: instradare il lavoro, limitare il contesto, governare l’automazione e riservare il ragionamento costoso ai task che lo richiedono.
Hermes Agent non è soltanto un'interfaccia conversazionale collegata a un modello. È un runtime agentico sempre attivo: può chiamare tool, caricare skill, usare memoria persistente, connettere server MCP, generare subagent, eseguire job schedulati e operare su più superfici.
Questa potenza cambia il problema dell'ottimizzazione.
Con un chatbot tradizionale, il costo dipende soprattutto dalla lunghezza del prompt e dal modello scelto. Con un runtime agentico, costo e affidabilità dipendono anche da tutto ciò che entra silenziosamente nella context window: schemi dei tool, intestazioni delle skill, memoria, capacità MCP, output dei file, job in background, impostazioni di delega e cronologia della conversazione.
Il risultato è semplice: una configurazione Hermes poco governata può consumare token anche quando l'utente non sta chiedendo attività particolarmente complesse. Una configurazione ben ottimizzata, invece, tratta Hermes come un'architettura da progettare.
L'obiettivo non è rendere l'agente più piccolo a ogni costo. L'obiettivo è spendere contesto e capacità di ragionamento dove generano valore.
Partire dal vero modello di costo: ogni turno porta payload nascosto
Il prompt visibile è solo una parte della richiesta inviata al modello.
Un turno Hermes può includere:
- system prompt e istruzioni di progetto
- cronologia della conversazione o summary compresso
- definizioni dei tool disponibili
- metadata delle skill abilitate
- memoria e profilo utente
- tool MCP esposti dai server configurati
- output rilevante da file o terminale
- sintesi di subagent o risultati di task in background
Questo significa che l'ottimizzazione dovrebbe iniziare da una domanda che molti team si pongono troppo tardi: cosa viene caricato di default, e questo profilo ne ha davvero bisogno?
Se un profilo viene usato per ricerca, potrebbe non avere bisogno di code execution. Se viene usato per delivery software, potrebbe non avere bisogno di tutti i tool media, browser o social. Se un server MCP espone decine di tool ma solo due sono rilevanti per il workflow, l'architettura sta trasportando carico cognitivo e token non necessari.
Hermes rende tutto questo configurabile tramite profili, toolset, skill e configurazione MCP. Il pattern pratico è creare profili più stretti per i workflow ricorrenti, invece di far passare ogni attività da un agente universale.
Trattare i profili come confini di workload
I profili sono uno dei principali strumenti di ottimizzazione in Hermes.
Un profilo può isolare configurazione, memoria, skill, tool e scelta dei modelli per una classe di lavoro. Questo conta perché un agente per ricerca commerciale, un agente di coding, un agente di monitoraggio e un assistente personale non hanno bisogno della stessa superficie di contesto.
Una configurazione matura tende a separare almeno tre profili:
- Profilo assistente interattivo — abbastanza ampio per l'uso quotidiano, ma non sovraccarico di ogni tool.
- Profilo engineering — codice, terminale, GitHub, debugging e skill orientate ai test.
- Profilo automazione — job schedulati, monitoraggio, sintesi e notifiche, con limiti di turni più rigidi.
Questo riduce il bloat del contesto e abbassa la probabilità che Hermes scelga il tool sbagliato o spenda ragionamento costoso su un task di basso valore.
La regola operativa è chiara: se due workflow hanno tool, rischi, requisiti di modello o budget di costo diversi, probabilmente meritano profili diversi.
Ottimizzare il contesto prima del modello
Molti team reagiscono ai costi cambiando prima il modello. Aiuta, ma spesso manca il problema più grande: il modello potrebbe ricevere troppo contesto irrilevante.
Hermes espone diversi controlli relativi al contesto che vanno regolati insieme.
Limiti dell'output dei tool
Log lunghi da terminale, errori di test, payload JSON e documenti di policy possono consumare rapidamente la context window. Se i limiti sono troppo bassi, l'agente perde evidenze importanti. Se sono troppo alti, ogni turno diventa più costoso.
Il valore corretto dipende dal workload:
- debugging e analisi CI hanno bisogno di output sufficiente per catturare stack trace e contesto
- analisi documentale può richiedere finestre di lettura più ampie
- automazione ricorrente dovrebbe in genere mantenere output più stretti e sintetizzare in modo aggressivo
Non usare un'impostazione globale come sostituto della progettazione dei workflow. Un profilo di coding/debugging può tollerare output più ampi; un profilo di monitoraggio schedulato dovrebbe essere più restrittivo.
Compression threshold e target ratio
La compressione del contesto non è solo una comodità. È un meccanismo di controllo dei costi e di affidabilità.
Se la compressione avviene troppo presto, l'agente può perdere dettagli utili durante un'attività lunga. Se avviene troppo tardi, ogni turno trasporta troppa cronologia grezza. La soglia ottimale dipende dalla context window del modello e dal tipo di lavoro.
Per sessioni tecniche lunghe, una soglia più alta può preservare meglio il contesto operativo. Per job in background ricorrenti, una compressione anticipata può essere preferibile perché il job non dovrebbe avere bisogno di una lunga traccia conversazionale.
Lo stesso vale per il target ratio: mantenere più contesto non compresso migliora la continuità, ma aumenta anche il costo per turno. Va trattato come una decisione di workload, non come una preferenza universale.
Instradare il ragionamento: i modelli costosi non devono fare lavoro economico
La vera ottimizzazione dei modelli non consiste nel scegliere un solo modello più economico. Consiste nel routing.
Hermes può usare modelli diversi per classi diverse di lavoro: interazione principale, task ausiliari, delega e operazioni in background. Questo conta perché non ogni step interno richiede ragionamento frontier-level.
Esempi di attività che spesso funzionano bene con modelli più piccoli o economici:
- sintesi semplice da web o file search
- sintesi di memoria o profilo
- compressione ordinaria
- formattazione e classificazione
- ricerca leggera tramite subagent
- summary schedulati ricorrenti
Il modello principale dovrebbe essere riservato ai task in cui la profondità di ragionamento cambia davvero il risultato: decisioni architetturali, design del codice, debugging multi-step, valutazione di trade-off o sintesi finale.
È lo stesso pattern dei sistemi AI in produzione: separare orchestrazione ed esecuzione, e instradare ogni unità di lavoro verso il modello più economico che soddisfa il requisito di qualità.
Governare i subagent come calcolo distribuito
I subagent sono potenti perché permettono indagini parallele e ragionamento isolato. Sono anche facili da usare troppo.
Ogni subagent è di fatto un'altra sessione, con il proprio contesto e le proprie chiamate al modello. Se un agente padre avvia più worker, il consumo di token cresce rapidamente. Se la delega annidata viene abilitata senza disciplina, il sistema può diventare costoso e difficile da ispezionare.
Una policy pratica sui subagent dovrebbe definire:
- quando la delega è consentita
- numero massimo di subagent concorrenti
- profondità massima di spawn
- modello/provider usato dai worker delegati
- se l'auto-approval è accettabile
- quale evidenza deve restituire un subagent
Per la maggior parte dei casi enterprise, una delega superficiale è più sicura di una ramificazione autonoma profonda. Usa i subagent per ricerca indipendente, code review o diagnosi parallela; evita di usarli come riflesso automatico per ogni attività.
La regola è: delegare quando il parallelismo riduce l'incertezza, non quando l'agente padre non ha ancora ragionato abbastanza.
Le skill sono memoria procedurale, ma vanno curate
Le skill sono una delle scelte di design più forti di Hermes Agent. Trasformano procedure ripetute in conoscenza operativa riutilizzabile.
Ma le skill creano anche un requisito di governance. Man mano che il numero di skill cresce, l'agente ha più procedure possibili da considerare e più metadata possono entrare nel prompt. Una grande libreria di skill è utile solo se resta rilevante, trovabile e mantenuta.
Buone pratiche:
- mantenere skill specifiche per workflow ricorrenti
- disabilitare o archiviare skill non più usate
- aggiornare le skill quando cambiano comandi, API o pattern operativi
- separare procedure di progetto da procedure generiche
- usare profili in modo che ogni workflow veda solo le skill necessarie
Il punto non è minimizzare le skill. Il punto è evitare che la memoria procedurale diventi rumore nel prompt.
I server MCP sono superfici di capacità
MCP è un meccanismo di estensione importante per Hermes perché permette a tool e servizi esterni di diventare capacità native dell'agente. Questo significa anche che ogni server MCP espande la superficie di azione.
Un server MCP dovrebbe essere valutato come un'integrazione in un'architettura enterprise:
- quali tool espone?
- quale profilo ne ha davvero bisogno?
- richiede segreti o accessi privilegiati?
- quanto schema di tool aggiunge al contesto?
- può essere separato o limitato per workflow?
Connettere ogni server MCP utile a ogni profilo è comodo, ma raramente è ottimale. Il pattern migliore è esporre la minima capacità necessaria: collegare il server solo dove serve e mantenere stretto il set di tool abilitati.
La memoria deve essere compatta, durevole e ad alto segnale
La memoria persistente è preziosa perché evita all'utente di ripetere preferenze stabili, dettagli dell'ambiente e contesto di lungo periodo. Ma la memoria non è un deposito per appunti di sessione: dovrebbe essere compatta, durevole e ad alto segnale.
Una buona policy distingue tra:
- fatti durevoli che devono sopravvivere tra sessioni
- avanzamento temporaneo dei task, che appartiene alla cronologia di sessione
- procedure dettagliate, che appartengono alle skill
- materiale sorgente, che appartiene a un repository o knowledge base
Questa distinzione migliora sia qualità sia costo. Una memoria compatta dà all'agente continuità utile senza caricare rumore operativo obsoleto in ogni turno futuro.
Per i team enterprise, è anche una questione di governance. La memoria dovrebbe contenere contesto operativo durevole, non registri incontrollati di ogni attività svolta.
I job schedulati hanno bisogno di budget espliciti
L'automazione cron è il punto in cui il costo agentico può diventare invisibile.
Un job schedulato può sembrare innocuo quando viene testato una volta. Ma se gira ogni ora, usa un modello forte, carica tool ampi, legge file grandi e non ha limiti di turni rigorosi, diventa un centro di costo ricorrente.
Ogni workflow Hermes schedulato dovrebbe avere un perimetro operativo esplicito:
- modello e provider
- massimo numero di turni
- tool consentiti
- dimensione attesa dell'input
- destinazione della notifica
- comportamento in caso di errore
- policy di logging e notifiche
L'automazione in background va progettata come automazione di produzione: delimitata, osservabile e stretta.
Usare i controlli di sicurezza in modo intenzionale
L'ottimizzazione non riguarda solo il costo. Riguarda anche ridurre l'attrito operativo senza rimuovere le protezioni necessarie.
Per sviluppo locale trusted, modalità di approvazione più rapide possono ridurre interruzioni. Per ambienti simili alla produzione, approvazione manuale o esposizione più restrittiva dei tool può essere più appropriata. Per il troubleshooting, esecuzioni isolate che ignorano la configurazione utente possono aiutare a distinguere un problema di Hermes da un problema specifico di profilo.
Il principio è rendere esplicita la postura di sicurezza per profilo e workflow. Un profilo personale di sperimentazione e un profilo di automazione produttiva non dovrebbero avere le stesse impostazioni di approvazione e accesso ai tool.
Checklist pratica di ottimizzazione
Per una configurazione Hermes Agent seria, il processo di ottimizzazione dovrebbe essere questo:
- Inventariare i profili — capire quali workflow condividono oggi la stessa configurazione.
- Ridurre i tool — disabilitare i toolset non necessari per ciascun profilo.
- Rivedere l'esposizione MCP — rimuovere server ampi o inutilizzati dai profili generali.
- Curare le skill — mantenere abilitate solo quelle rilevanti per il workflow e aggiornare quelle che restano.
- Ridimensionare la memoria — salvare preferenze e fatti ambientali durevoli, non log dei task.
- Regolare i limiti di contesto — impostare output dei tool e lettura file in base al workload.
- Regolare la compressione — allineare threshold e target ratio a contesto del modello e durata del task.
- Instradare i modelli — usare modelli ausiliari o di delega più economici per lavoro a bassa complessità.
- Limitare i subagent — definire concorrenza, profondità e policy di approvazione.
- Budgettizzare i job schedulati — definire max turns, modello, tool e gestione degli errori per ogni workflow cron.
- Misurare l'uso — rivedere periodicamente il consumo di token e ottimizzare i workflow che generano davvero la spesa.
La lezione più importante: ottimizzare agenti è systems engineering
Hermes Agent è potente perché combina memoria, tool, skill, MCP, automazione e delega multi-agent. Sono proprio queste funzioni a renderlo utile — e sono proprio queste funzioni a richiedere disciplina architetturale.
Il mindset sbagliato chiede: quale impostazione rende Hermes più economico?
La domanda migliore è: quale architettura agentica assegna contesto, tool e ragionamento al lavoro giusto nel momento giusto?
È questa la differenza tra un assistente intelligente e un sistema AI operativo.
Riferimenti
Sull'autore
Dario Cargnino
Senior Pre-Sales Manager, Solution Architect e Agentic Engineer
Lavoro tra strategia AI, solution architecture e sistemi digitali enterprise, con particolare attenzione alla fiducia operativa, alla concretezza nella delivery e alla resilienza delle piattaforme nel lungo periodo.
Dati articolo
In sintesi
- Pubblicato
- 5 luglio 2026
- Tempo di lettura
- 10 min di lettura
- Categoria
- Architettura AI
Argomenti