09 — Assistenti PyroTwin (agentic)

PyroTwin è un insieme di piccoli assistenti AI dall'ambito ben delimitato che osservano i dati operativi, segnalano il lavoro che merita la tua attenzione sotto forma di findings e propongono azioni di scrittura accuratamente circoscritte da approvare. Sono di supporto alle decisioni: a comandare restano un operatore umano, l'RBAC e l'audit trail.

Cosa non sono. Gli assistenti non sostituiscono il simulatore PyroWISE, non disegnano le mappe e non hanno accesso diretto al database o ai file. Leggono attraverso una ristretta superficie di strumenti e possono solo proporre modifiche — nulla viene scritto finché un amministratore non lo approva.

Accesso. Tutta quest'area è riservata agli amministratori (il permesso agentic.useTools). Le voci compaiono sotto Amministrazione: Agentic dashboard, Agent findings, Agent actions, Agent runs.

I sei assistenti (capacità)

Un sidecar Python (su timer di sistema) esegue gli assistenti e chiama la superficie di strumenti del cockpit; tutto ciò che fa viene persistito in tre tabelle di audit che consulti qui: runs, findings e actions.

Il modello di sicurezza (perché l'approvazione conta)

Le scritture sono filtrate a più livelli, così un assistente può suggerire molto ma da solo non cambia nulla:

• un interruttore generale e un flag per-capacità di abilitazione / dry-run;
• dry-run per impostazione predefinita sulle run manuali (scegli deliberatamente di optare per una run live);
• ri-controlli lato server delle reti di sicurezza di ogni azione al momento dell'approvazione;
• un token di approvazione monouso registrato con il tuo user id per ciascuna azione eseguita;
• limiti di frequenza (es. limiti orari di notifica globali e per-destinatario); le notifiche redatte non vengono mai inviate automaticamente — vanno alla UI della matrice allerte.

Agentic dashboard — /agentic/index

La tua pagina iniziale e panoramica di triage.

• Findings backlog by status — striscia di badge (new / triaged / accepted / rejected / done), ciascuno con link all'elenco filtrato dei findings, più Open findings triage →.
• By kind — una tabella di tipi di finding × stato.
• Manual runs — una card per capacità con i badge cron on/off e dry-run/live, una casella Dry run (selezionata per impostazione predefinita) e un pulsante Run now (conferma "Start … now?"). Le run manuali scelgono solo da una allow-list fissa di capacità — non c'è esecuzione arbitraria di comandi, e gli effetti collaterali richiedono comunque l'approvazione.
• Recent runs — capacità, stato, avvio, token in/out, costo (¢USD), modello, dry-run.

Agent findings — /agentic/findings

La coda di triage dei suggerimenti. Ogni finding attraversa un ciclo di vita:

new ─▶ triaged ─▶ accepted ─▶ done
  └────▶ rejected           (any state can be re-opened to new)

Accettare un finding te lo assegna. Le transizioni sono validate — una mossa illecita viene rifiutata.

L'elenco: filtra per Kind, Status, Since (7/30/90/all), testo del titolo e Assigned to me; una toolbar bulk applica uno stato a tutte le righe spuntate. Le colonne mostrano stato, kind, titolo (→ dettaglio), la run di origine, impatto, sforzo, assegnatario e data di creazione, con pulsanti per riga per ogni stato successivo consentito.

La pagina di dettaglio: il corpo del finding (Markdown), una card Evidence (link + dati chiave/valore), un thread di Discussion (aggiungi commenti) e una barra laterale destra con i pulsanti di Triage, i metadati (impatto/sforzo/assegnatario) e la run di origine (capacità, modello, token, costo).

Il tuo flusso di lavoro: scorri il backlog → apri un finding → leggine il corpo e le evidenze → discuti se necessario → spostalo a triaged / accepted / rejected / done (oppure applica in blocco su molti).

Agent actions — /agentic/actions

La coda delle azioni di scrittura proposte in attesa di approvazione.

Strumenti approvabili (quelli con un executor in-app): simulation_runs.classify, simulation_runs.delete, maintenance.create_event, alerts.classify, alerts.suppress, alerts.notify_draft.

L'elenco: badge di coda per strumento (conteggi pending / executed), filtri per strumento, stato, run id e since; le righe mostrano lo strumento, lo stato, la run, l'orario proposto e un riepilogo su una riga degli argomenti, con Detail e (quando approvabile) Approve.

La pagina di dettaglio: il JSON esatto di Arguments e Result e una card Approve — "Approving executes the action server-side and records your user id + a one-time approval token. Safety nets are re-checked first." Se non può essere approvata, ne viene mostrato il motivo (già eseguita, stale-rejected, oppure nessun executor in-app — nel qual caso la dispacci tramite la UI propria di quello strumento).

Il tuo flusso di lavoro: apri un'azione pending → ispeziona gli argomenti → Approve and execute (il server ri-controlla la sicurezza) oppure gestiscila nello strumento nativo.

alerts.notify_draft si limita a redigere una notifica — esaminala e inviala dalla UI della matrice allerte; non viene mai inviata automaticamente.

Agent runs — /agentic/runs

La cronologia di esecuzione, con un riepilogo dei costi — usala per individuare una run che non è scattata o è fallita.

Stati della run: running / succeeded / failed / aborted. La pagina di dettaglio mostra lo stato, eventuali errori e il payload di trigger, i findings che ha sollevato e le actions che ha proposto (ciascuno con link di approfondimento) e una barra laterale destra con il costo (token, ¢USD, ≈ EUR) e i metadati (modello, provider, dry-run).

Il tuo flusso di lavoro: apri una run → leggine l'errore/payload → salta ai findings o alle actions che ha prodotto.

Correlati

• 08 — Amministrazione — la matrice allerte in cui finiscono le notifiche redatte; l'RBAC che presidia quest'area.
• 04 — Come simulare — le run di simulazione di cui il janitor propone la pulizia.
• 03 — Tabelle di log — l'audit trail più ampio.