Il livello operatore di Hermes Agent è l'insieme di discipline che mantiene coerente un team a più profili oltre il giorno 30. Quattro primitive: contratti di handoff che possono bloccare, audit memoria-KPI per profilo, policy gate per ruolo e stato cron coordinato. Senza di esse, un team a 4 profili (Hermes + Alan + Mira + Turing) mostra segnali di convergenza vocale nell'arco di un mese.
La maggior parte delle guide per operatori Hermes si ferma al bootstrap dei 4 profili; il materiale sul deployment al giorno 30 è scarso nella documentazione pubblica. È al giorno 30 che i profili iniziano a suonare uguali, gli handoff si interrompono in silenzio e una build di cui si era orgogliosi diventa indistinguibile da un setup a singolo agente.
Se Hermes Agent versione 0.9.0 è in esecuzione con il bootstrap standard che include i profili Alan, Mira e Turing, la build fondamentale è completa; il lavoro del giorno 30 parte da lì. Ogni primitiva descritta di seguito è tratta da pattern di deployment reali, abbinata al modo specifico in cui si manifesta il fallimento che la rende necessaria.
- I contratti di handoff sono reali solo se bloccano. Se la forma di input del profilo ricevente non corrisponde, l'handoff deve fallire, non solo avvertire.
- La memoria si deteriora per ciascun profilo. Eseguire un audit `memory-kpi` settimanale. Superare il 15% di note obsolete attiva un passaggio `brain-resolve`.
- I policy gate prevengono la deriva silenziosa dei privilegi. Alan non ottiene mai accesso alla shell. Solo l'orchestratore può approvare commit su main.
- Quattro modalità di fallimento al giorno 30 spiegano la maggior parte delle regressioni nei deployment osservati. Deriva del profilo, deterioramento degli handoff, bloat di SOUL.md, collisione cron. Ognuna ha una contromisura specifica.
- Leggere prima la [guida alla definizione di Hermes Agent](/blog/hermes-agent-self-improving-ai) per il contesto su cos'è il sistema, prima di affrontare il livello operatore.
Il team base a 4 profili (riepilogo)
Prima che il livello operatore abbia senso, il team di avvio a 4 profili deve essere operativo. La suddivisione canonica riportata di seguito è quella su cui converge la maggior parte dei deployment Hermes in produzione.
- Hermes (orchestratore). Pianifica, scompone, instrada, sintetizza. Controllore del traffico, non collo di bottiglia.
- Alan (specialista della ricerca). Basato sulle fonti, scettico, consapevole dell'incertezza. Protegge il team dalla confidenza allucinata.
- Mira (architetta narrativa). Chiarezza, struttura, consapevolezza del pubblico. Trasforma il materiale validato in comunicazione.
- Turing (costruttore e debugger). Implementazione, log, diff, riproducibilità. Si preoccupa dei test, non della resa narrativa.
I profili isolano sette elementi di stato contemporaneamente: configurazione, sessioni, memoria, skill, personalità, stato cron e stato gateway. Quell'isolamento è la primitiva su cui si regge il livello operatore. Chi sta ancora eseguendo un singolo profilo che porta cinque ruoli non trarrà beneficio da nessuno dei pattern seguenti. La primitiva va corretta prima.
Per valutare se un deployment Hermes a 4 profili si adatta al carico di lavoro reale del proprio team, webvise può guidare nell'analisi.
Contratti di handoff: l'unico strumento che blocca la deriva dei profili
Un contratto di handoff è una specifica a quattro campi salvata in `~/.hermes/team/handoffs/<from>-to-<to>.md`. Il contratto è reale solo se può bloccare. Se l'input non corrisponde alla forma dichiarata, il harness fa fallire l'handoff e richiede la revisione umana. I quattro campi obbligatori:
| Campo | Definizione | Esempio (Alan → Mira) |
|---|---|---|
| Forma dell'input | Cosa si aspetta il profilo ricevente | Affermazioni classificate con URL delle fonti, non estratti grezzi |
| Forma dell'output | Cosa restituirà il profilo ricevente | Sezione bozza con log delle modifiche, non un articolo finito |
| Azione in caso di errore | Cosa succede quando l'input non è valido | block, require-human-review o retry |
| Gate di verifica | Un'asserzione che deve essere vera prima che l'handoff si completi | Ogni affermazione ha un URL della fonte |
Il gate è portante. La maggior parte dei team scrive la documentazione degli handoff come suggerimenti e poi si chiede perché i profili derivano. Un suggerimento non blocca mai. Senza un blocco, Alan finisce per inviare trascrizioni grezze a Mira, Mira inizia a redigere senza attribuzione delle fonti e la qualità dell'output del team si erode un handoff silenzioso alla volta.
Memoria-KPI: la soglia del 15% di note obsolete
La memoria si deteriora all'interno di ciascun profilo nello stesso modo in cui un wiki condiviso decade oltre le 100 pagine. Un audit settimanale intercetta il deterioramento prima che il profilo inizi a citare se stesso da un contesto obsoleto. Tre metriche per profilo sono rilevanti:
- `source_backed_pct`: percentuale di note che hanno ancora una fonte recuperabile. Diminuisce quando le fonti restituiscono 404 o vengono eliminate.
- `stale_notes`: numero di note il cui codice, URL o configurazione di riferimento non corrisponde più alla realtà.
- `contradiction_notes`: numero di note che contraddicono qualcos'altro nella memoria dello stesso profilo.
Il comando di audit settimanale viene eseguito su ogni profilo specialistico: `for p in alan mira turing; do hermes -p $p memory-kpi --json | jq '.source_backed_pct, .stale_notes, .contradiction_notes'; done`. Monitorare `stale_notes`. Una volta che supera il 15% del totale delle note in un profilo, pianificare un passaggio `brain-resolve` prima che quel profilo inizi a citare se stesso da un contesto obsoleto.
Policy gate: permessi per ruolo
Nessun profilo ottiene più permessi di quanti ne richieda il suo ruolo. L'orchestratore è l'unico profilo autorizzato ad ampliare l'ambito di qualsiasi altro profilo. Annotare queste regole in una tabella da controllare settimanalmente è la differenza tra un team governato e quattro agenti che diventano lentamente tutti amministratori.
| Profilo | Classe di rischio | Permessi |
|---|---|---|
| Alan (ricerca) | sicuro | Lettura web e repo, scrittura solo in research/. Nessuna shell, nessuna scrittura fuori dalla sandbox. |
| Mira (scrittura) | sicuro | Lettura degli output di ricerca, scrittura solo in drafts/. Nessun accesso a segreti, nessuna esecuzione di codice. |
| Turing (engineering) | revisione | Lettura del repo, esecuzione di test in sandbox, scrittura su feature branch. Ogni commit su main richiede l'approvazione dell'orchestratore. |
| Hermes (orchestratore) | critico | Unico profilo autorizzato ad approvare i commit di Turing, unire branch o attivare chiamate API a pagamento oltre il tetto di budget. |
Il principio è portante. Un agente di ricerca con accesso alla shell finirà prima o poi per eseguire un comando che non avrebbe dovuto. Un profilo scrittore con accesso ai segreti finirà per includerli in una bozza. La deriva dei permessi avviene in silenzio ed è evidente solo a posteriori: un momento difficile per scoprire la lacuna.
Le quattro modalità di fallimento al giorno 30
Quattro specifiche modalità di fallimento spiegano la maggior parte delle regressioni nei setup Hermes multi-agente. Ognuna ha una contromisura diretta. Trascurarne una qualsiasi e il team funziona bene al giorno uno, è degradato al giorno 30.
1. Deriva del profilo
Le modifiche a SOUL.md si accumulano in silenzio. Mira diventa lentamente Turing. La soluzione: confrontare ogni SOUL.md settimanalmente rispetto alla versione del giorno uno. Ogni nuova responsabilità richiede un'approvazione registrata, altrimenti viene ripristinata. Nessuna eccezione per modifiche piccole, perché la deriva avviene proprio attraverso le modifiche piccole.
2. Deterioramento degli handoff
Il file del contratto esiste ma nessuno lo fa rispettare. Alan ricomincia a inviare trascrizioni grezze a Mira. La soluzione: collegare ogni file di handoff al harness in modo che un input non corrispondente blocchi. Un contratto che non può bloccare è documentazione, non controllo.
3. Bloat di SOUL.md
Ogni ruolo accumula paragrafi per casi limite finché l'agente perde la propria identità originale nel rumore. La soluzione: mantenere SOUL.md entro il limite di 400 parole. Tutto il resto va in AGENTS.md o in un file di riferimento per dominio. Il vincolo obbliga il team a mantenere l'identità ben definita.
4. Collisione cron
Più profili pianificano job alle 3:00 senza coordinamento. L'orchestratore si ritrova con quattro agenti in competizione per la stessa quota API. La soluzione: un unico `~/.hermes/team/cron.md` condiviso che elenca ogni task pianificato su ogni profilo con orario esatto, durata e dipendenze. Va consultato prima di aggiungere qualsiasi nuovo cron.
Adattabilità al team aziendale
Il livello operatore è ciò che trasforma una demo di Hermes in un'infrastruttura di produzione duratura. La maggior parte dei team che valuta framework multi-agente si concentra sul costo di setup iniziale e trascura il modello di manutenzione. Un team a 4 profili privo di contratti di handoff, audit della memoria e policy gate ha la stessa curva di fallimento di un singolo agente con un ritardo di sei settimane: funziona magnificamente all'inizio, decade in modo invisibile, crolla nel momento in cui serve di più.
Il valore composto di Hermes, la ragione per cui la libreria di skill conta, regge solo se regge il livello operatore. Le skill accumulate da un profilo che ha silenziosamente derivato verso un ruolo diverso sono skill per un ruolo che non esiste più.
webvise aiuta le aziende a progettare e gestire architetture di agenti AI, inclusi i team Hermes a più profili con la disciplina di governance necessaria per sopravvivere oltre il giorno 30. Per chi sta valutando un deployment Hermes o ne ha già uno che inizia a perdere coerenza, contattare per rafforzare il livello operatore prima che le modalità di fallimento si sommino.
Le pratiche di webvise sono allineate agli standard ISO 27001 e ISO 42001.