Hermes Agent in produzione: l'operator layer per il giorno 30

L'operator layer di Hermes Agent è l'insieme di discipline che mantiene coerente un team multi-profile oltre il giorno 30. Quattro primitive: handoff contracts che possono bloccare, audit memory-KPI per profile, policy gates per ruolo e stato cron coordinato. Senza di essi, un team a 4 profile (Hermes + Alan + Mira + Turing) si confonde in un unico agente indistinto nel giro di un mese.

Ogni guida per operatori di Hermes disponibile online si ferma al bootstrap a 4 profile. Nessuno pubblica screenshot del giorno 30, perché il giorno 30 è quando i profile iniziano a suonare uguali, gli handoff si rompono silenziosamente, e una build di cui si era orgogliosi diventa indistinguibile da un setup a singolo agente.

Se si ha Hermes Agent versione 0.9.0 in esecuzione con i profile Alan, Mira e Turing, la build di base è completata. Quello che viene dopo è l'operator layer. Ogni primitiva qui sotto è tratta da pattern di deployment reali, abbinata al failure mode specifico che la rende necessaria.

• Gli handoff contracts sono reali solo se bloccano. Se la forma dell'input del profile ricevente è errata, l'handoff deve fallire, non solo avvertire.

• La memoria si deteriora per ogni profile. Eseguire un audit `memory-kpi` settimanale. Superare il 15% di note obsolete attiva un passaggio `brain-resolve`.

• I policy gates prevengono il privilege drift silenzioso. Alan non ottiene mai accesso shell. Solo l'orchestrator può approvare commit su main.

• Quattro failure mode al giorno 30 distruggono la maggior parte dei deployment. Profile drift, handoff rot, SOUL.md bloat, cron collision. Ognuno ha una contromisura specifica.

• Leggere prima la [guida alla definizione di Hermes Agent](/blog/hermes-agent-self-improving-ai) per il contesto cos'è-cosa-fa prima dell'operator layer.

Il punto di partenza a 4 profile (riepilogo)

Prima che l'operator layer sia rilevante, il team starter a 4 profile deve essere in esecuzione. La suddivisione canonica descritta di seguito è quella su cui converge la maggior parte dei deployment Hermes in produzione.

• Hermes (orchestrator). 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 fiducia allucinata.

• Mira (architetto narrativo). Chiarezza, struttura, consapevolezza del pubblico. Trasforma il materiale validato in comunicazione.

• Turing (builder e debugger). Implementazione, log, diff, riproducibilità. Si preoccupa dei test, non della resa narrativa.

I profile isolano sette parti di stato contemporaneamente: configurazione, sessioni, memoria, competenze, personalità, stato cron e stato gateway. Questo isolamento è la primitiva da cui dipende l'operator layer. Se si sta ancora usando un singolo profile che porta cinque ruoli, nessuno dei pattern qui sotto aiuterà. Correggere prima la primitiva.

Per decidere se un deployment Hermes a 4 profile si adatta al carico di lavoro reale del proprio team, webvise può accompagnarvi nel processo.

Handoff contracts: l'unica cosa che blocca il profile drift

Un handoff contract è una specifica a quattro campi memorizzata in `~/.hermes/team/handoffs/<from>-to-<to>.md`. Il contract è reale solo se può bloccare. Se l'input non corrisponde alla forma dichiarata, il harness fa fallire l'handoff e richiede revisione umana. I quattro campi obbligatori:

Il gate è fondamentale. La maggior parte dei team scrive documenti di handoff come suggerimenti e si chiede perché i profile si confondono. Un suggerimento non blocca mai. Senza un blocco, Alan alla fine invia 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.

Memory-KPI: la soglia del 15% di note obsolete

La memoria si deteriora all'interno di ogni profile nello stesso modo in cui un wiki condiviso si deteriora oltre le 100 pagine. Un audit settimanale intercetta il deterioramento prima che il profile inizi a citarsi da contesti obsoleti. Tre metriche per profile sono rilevanti:

• `source_backed_pct` -- percentuale di note che hanno ancora una fonte recuperabile. Scende quando le fonti danno 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 profile.

Il comando di audit settimanale viene eseguito su ogni profile specialista: `for p in alan mira turing; do hermes -p $p memory-kpi --json | jq '.source_backed_pct, .stale_notes, .contradiction_notes'; done`. Tenere d'occhio `stale_notes`. Una volta che supera il 15% del totale delle note in un profile, programmare un passaggio `brain-resolve` prima che quel profile inizi a citarsi da contesti obsoleti.

Policy gates: permessi per ruolo

Nessun profile ottiene più permessi di quanti ne richieda il suo ruolo. L'orchestrator è l'unico profile autorizzato ad ampliare lo scope di qualsiasi altro profile. Annotare questo in una tabella da verificare settimanalmente è la differenza tra un team governato e quattro agenti che lentamente diventano tutti amministratori.

Il principio è fondamentale. Un agente di ricerca con accesso shell alla fine eseguirà un comando che non avrebbe dovuto eseguire. Un profile writer con accesso ai segreti alla fine li farà trapelare in una bozza. Il privilege drift avviene silenziosamente ed è evidente solo a posteriori, che è il momento sbagliato per accorgersene.

I quattro failure mode del giorno 30

Quattro failure mode specifici sono responsabili della maggior parte dei collassi multi-agente di Hermes. Ognuno ha una contromisura diretta. Saltarne uno e il team funziona bene il primo giorno, si confonde entro il giorno 30.

1. Profile drift

Le modifiche a SOUL.md si accumulano silenziosamente. Mira diventa lentamente Turing. Soluzione: fare il diff di ogni SOUL.md settimanalmente rispetto alla versione del primo giorno. Qualsiasi nuova responsabilità richiede una voce di approvazione registrata, altrimenti viene ripristinata. Nessuna eccezione per modifiche piccole, perché le modifiche piccole sono il modo in cui avviene il drift.

2. Handoff rot

Il file del contract esiste ma nessuno lo fa rispettare. Alan inizia di nuovo a inviare trascrizioni grezze a Mira. Soluzione: collegare ogni file di handoff al harness in modo che l'input non corrispondente blocchi. Un contract che non può bloccare è documentazione, non controllo.

3. SOUL.md bloat

Ogni ruolo accumula paragrafi per casi limite finché l'agente perde la sua identità originale nel rumore. Soluzione: limitare SOUL.md a 400 parole. Tutto ciò che supera questo limite va in AGENTS.md o in un file di riferimento per dominio. Il vincolo costringe il team a mantenere l'identità concisa.

4. Cron collision

Più profile pianificano lavori alle 3 di notte senza coordinamento. L'orchestrator si sveglia con quattro agenti che si contendono la stessa quota API. Soluzione: un unico `~/.hermes/team/cron.md` condiviso che elenca ogni task pianificato in ogni profile con ora esatta, durata e dipendenza. Verificarlo prima di aggiungere qualsiasi nuovo cron.

Cosa significa per i team aziendali

L'operator layer è la parte che trasforma una demo di Hermes in un'infrastruttura di produzione duratura. La maggior parte dei team che valuta i framework multi-agente si concentra sul costo di configurazione iniziale e non considera il modello di manutenzione. Un team a 4 profile senza handoff contracts, audit della memoria e policy gates ha la stessa curva di fallimento di un agente a singolo profile con sei settimane di ritardo: funziona splendidamente all'inizio, si degrada invisibilmente, crolla quando è più necessario.

Il valore che si accumula nel tempo per Hermes, il motivo per cui la libreria di competenze è importante, vale solo se regge l'operator layer. Le competenze accumulate da un profile che è silenziosamente diventato un ruolo diverso sono competenze per un ruolo che non si ha più.

In webvise, aiutiamo le aziende a progettare e gestire architetture di agenti IA, inclusi team multi-profile di Hermes con la disciplina di governance necessaria per sopravvivere oltre il giorno 30. Se si sta valutando un deployment di Hermes o se ne ha già uno che inizia a confondersi, contattateci e vi aiuteremo a consolidare l'operator layer prima che i failure mode si compongano.