La risoluzione agentica dei problemi di HPE Zerto porta l'AI cloud nel ripristino on-premises
HPE Zerto ha rilasciato un sistema di risoluzione dei problemi basato su agenti con tre ruoli agentici, ma la sua caratteristica più importante è il luogo in cui questi agenti operano. Il runtime di risoluzione agentica dei problemi di HPE Zerto risiede all'interno dell'ambiente di ciascun cliente. Esamina localmente i segnali di disaster recovery in tempo reale, inviando al contempo query selezionate per inferenza e conoscenza ad Amazon Web Services.
Questa suddivisione mette in discussione l'ipotesi secondo cui gli agenti aziendali utili debbano trasferire i dati operativi in un'applicazione cloud centralizzata. HPE Zerto ha invece collocato l'orchestrazione accanto all'infrastruttura oggetto dell'indagine. Amazon Bedrock fornisce accesso ai modelli, recupero della conoscenza, guardrail e controlli di supporto senza diventare la sede dell'intero workflow di risoluzione dei problemi.
Il sistema è entrato in produzione nel secondo trimestre del 2026. HPE e AWS affermano che oltre il 20 percento dei clienti Zerto lo ha successivamente adottato. Riferiscono inoltre una riduzione del 10 percento dei casi di assistenza nei workflow coperti dal sistema. Questi dati provengono dalle aziende e non hanno ricevuto una convalida indipendente.
Il risultato architetturale è rilevante oltre il singolo prodotto di ripristino. Gli ambienti di disaster recovery combinano log sensibili, configurazioni variabili, rigorosi controlli di accesso e forte pressione temporale. Un assistente che non può vedere le condizioni correnti offre consigli generici. Un agente con accesso illimitato crea un diverso rischio operativo.
HPE Zerto tenta di collocarsi nello spazio ristretto tra questi due esiti. I suoi agenti ricevono accesso strutturato alle informazioni locali, suddividono le indagini per dominio tecnico e restituiscono una risposta sintetica attraverso un unico orchestratore di controllo. La domanda centrale è se questa architettura possa preservare contesto, sicurezza e comportamento prevedibile man mano che gli ambienti reali diventano più complessi.
La risoluzione agentica dei problemi di HPE Zerto inizia nell'ambiente del cliente
Il cambiamento decisivo non è l'interfaccia chat. È la collocazione del runtime degli agenti accanto ai sistemi e alle evidenze che deve analizzare.
HPE Zerto Software supporta il disaster recovery, la protezione continua dei dati e la cyber resilience nelle infrastrutture ibride e multi-cloud. Gli operatori utilizzano il prodotto per monitorare workload protetti, preparazione al ripristino, stato della replica ed esposizione agli accordi sul livello di servizio.
La risoluzione dei problemi in questo ambiente richiede tradizionalmente informazioni provenienti da più fonti. Un amministratore potrebbe ispezionare un avviso, esaminare il log di un componente, rivedere i dati di configurazione, cercare nella documentazione del prodotto e confrontare le conclusioni con un runbook. Durante un'interruzione, ogni passaggio tra tali fonti aggiunge ritardo e crea opportunità di trascurare evidenze rilevanti.
Il nuovo sistema colloca un'esperienza chat all'interno dell'interfaccia di gestione Zerto esistente. Gli operatori possono porre domande sullo stato dei gruppi di protezione, sugli avvisi recenti, sulle pratiche di configurazione, sui ritardi di replica, sugli errori di aggiornamento o sui problemi attivi del sistema. L'assistente può inoltre mettere in evidenza problemi di integrità e guidare la mitigazione.
Secondo il congiunto resoconto dell'architettura, HPE distribuisce il livello agentico come pod all'interno dell'ambiente on-premises del cliente. Un pod è un gruppo distribuibile di container eseguito come un'unica unità applicativa. In questo design, contiene il runtime agentico locale.
Il runtime utilizza Strands Agents, un framework open-source sviluppato da AWS per creare agenti guidati dai modelli. La cronologia delle sessioni resta memorizzata localmente e gli agenti raggiungono le informazioni Zerto in tempo reale attraverso un server Model Context Protocol locale.
Model Context Protocol, o MCP, definisce un modo standard per un'applicazione AI di chiamare strumenti e ottenere dati contestuali. HPE ha incapsulato le API esistenti di Zerto Manager in un server MCP, fornendo agli agenti accesso strutturato alle informazioni ambientali correnti.
Questo è sostanzialmente diverso dal copiare ogni log e record di configurazione in un chatbot remoto. Gli agenti Zerto possono richiedere i dati locali necessari a un'indagine mentre il runtime rimane all'interno dell'appliance. HPE afferma che solo le richieste di inferenza del modello e le query ad Amazon Bedrock Knowledge Bases lasciano la rete locale via HTTPS.
La distinzione richiede una formulazione attenta. Il sistema non è del tutto disconnesso dal cloud, né è una distribuzione di modello offline. Amazon Bedrock continua a elaborare le richieste ai modelli, mentre il suo servizio di conoscenza gestito recupera informazioni di prodotto pertinenti. Il design locale controlla l'orchestrazione e l'accesso operativo anziché eliminare l'elaborazione esterna.
Questo confine crea la tensione centrale dell'articolo. Un agente operato localmente può restare vicino alle evidenze sensibili, ma il suo ragionamento dipende comunque da servizi di modelli remoti e da richieste in uscita progettate con attenzione. L'utilità del sistema dipende quindi da quale contesto attraversa questo confine, da come viene filtrato e dal fatto che le indicazioni restituite rimangano fondate.
Il rilascio porta inoltre l'assistenza AI più in profondità nel workflow di ripristino. Non si limita più a spiegare la documentazione. Il sistema può ispezionare le condizioni correnti e assemblare un'indagine specifica per il problema, aumentando sia il suo valore operativo sia il costo di una conclusione errata.
Un design hub-and-spoke mantiene il controllo in un unico agente
HPE Zerto ha suddiviso la risoluzione dei problemi tra agenti specializzati, mantenendo al contempo un unico orchestratore come punto di controllo per la delega e le risposte finali.
L'architettura utilizza un agente orchestratore e almeno due sotto-agenti specializzati. L'orchestratore gestisce direttamente le domande di routine e delega indagini più approfondite quando un problema richiede un'analisi specializzata.
Un sotto-agente si concentra su Zerto Manager, chiamato anche ZVM. Analizza aree quali arresti anomali dei servizi, problemi di rete ed errori di aggiornamento. I suoi strumenti forniscono accesso ai dati ambientali pertinenti, mentre le competenze di dominio identificano conoscenze tecniche e schemi di log riconoscibili.
Un altro sotto-agente si concentra sullo Zerto Replication Engine, o VRA. Gestisce problemi di replica, networking tra siti, errori di installazione e ritardi. Riceve i propri strumenti, istruzioni, conoscenze di dominio e contesto operativo.
Questa suddivisione riflette un'importante scelta ingegneristica. Fornire a un unico agente generalista ogni log, strumento, istruzione e dettaglio della conversazione può produrre un contesto sovradimensionato con segnali in competizione. Rende inoltre difficile isolare gli errori, perché lo stesso componente esegue instradamento, analisi e generazione delle risposte.
HPE utilizza invece una struttura hub-and-spoke. L'orchestratore si trova nell'hub e gli agenti specializzati operano come raggi. I sotto-agenti riferiscono al genitore anziché chiamarsi direttamente tra loro.
AWS descrive questo modello multi-agente come agents-as-tools, in cui un agente di coordinamento invoca gli specialisti attraverso interfacce delimitate. Ogni specialista può utilizzare un prompt, contesto, modello e insieme di strumenti separati.
Per Zerto, questa separazione presenta tre vantaggi pratici. In primo luogo, un'indagine ricca di log non riempie il contesto dell'orchestratore con materiale diagnostico grezzo. Lo specialista restituisce un report più breve contenente le proprie conclusioni anziché l'intero processo di lavoro.
In secondo luogo, ciascun agente diventa testabile in modo indipendente. Gli ingegneri possono valutare se lo specialista VRA seleziona gli strumenti corretti senza richiedere che ogni test attraversi comportamenti ZVM non correlati. Questa separazione può rendere più semplice individuare le regressioni.
In terzo luogo, l'orchestratore resta responsabile della risposta finale. HPE afferma che rimuove segreti e log grezzi prima di presentare i risultati all'utente. Un unico percorso di output offre inoltre al prodotto un solo punto in cui applicare le regole di risposta.
La struttura hub-and-spoke limita l'autonomia laterale. Se uno specialista scopre che un altro componente è responsabile del problema, restituisce questa osservazione all'orchestratore. Non invoca autonomamente un peer.
Questo vincolo riduce la probabilità che conversazioni ricorsive tra agenti consumino token senza arrivare a una decisione. Crea inoltre una sequenza tracciabile per l'osservabilità. Ogni delega inizia e termina nello stesso punto di controllo.
Il compromesso è un potenziale attrito nell'instradamento. L'orchestratore deve riconoscere correttamente quando una domanda richiede specializzazione e selezionare l'agente appropriato. Anche uno specialista deve comprimere le proprie conclusioni senza rimuovere evidenze essenziali alla diagnosi finale.
HPE utilizza profili di modello diversi per queste responsabilità. Il lavoro di routine può restare all'orchestratore, mentre le indagini che richiedono maggiore ragionamento possono utilizzare un modello più potente. L'azienda afferma di aver inizialmente valutato modelli più grandi per stabilire la fattibilità, quindi di aver confrontato alternative in base a qualità della risposta, latenza e costo.
Questo approccio multi-modello evita di trattare ogni richiesta come un compito di pari difficoltà. Verificare lo stato di un gruppo di protezione non richiede lo stesso budget di ragionamento dell'interpretazione di una sequenza di errori estesa tra log e stato della rete.
Trasforma inoltre la selezione del modello da una decisione di approvvigionamento una tantum in un processo ingegneristico continuo. Con il cambiamento dei foundation model, HPE può rivalutare quale modello sia adatto a ciascun agente senza ricostruire l'intero prodotto attorno a un workflow specifico di un fornitore.
I dati di ripristino in tempo reale sono il vantaggio e il rischio
Il sistema diventa utile quando può interrogare l'infrastruttura corrente, ma lo stesso accesso rende fondamentali il grounding, le autorizzazioni e la selezione degli strumenti.
Un agente di risoluzione dei problemi necessita di più dei manuali del prodotto. La documentazione può spiegare il significato di un avviso, ma non può rivelare se un particolare motore di replica sia in ritardo, quale percorso di rete stia fallendo o se una recente modifica della configurazione abbia influito sulla preparazione al ripristino.
HPE collega i propri agenti ai dati operativi in tempo reale attraverso un server MCP locale. Il server espone API selezionate di Zerto Manager come strumenti strutturati. Anziché chiedere a un modello linguistico di interpretare un dump di dati grezzi, l'agente può chiamare un'operazione definita e ricevere un risultato tipizzato.
La pubblica specifica MCP separa strumenti, risorse e prompt attraverso un'interfaccia client-server concordata. Per il software aziendale, questa struttura può trasformare un'API di prodotto esistente in un livello accessibile agli agenti senza riscrivere i servizi operativi sottostanti.
L'accesso tipizzato aiuta, ma non garantisce una diagnosi corretta. L'agente deve comunque scegliere lo strumento appropriato, fornire parametri validi, interpretare le informazioni restituite e collegarle alla documentazione pertinente.
HPE combina gli strumenti locali con Amazon Bedrock Knowledge Bases. La retrieval-augmented generation, o RAG, recupera materiale sorgente pertinente prima che il modello crei una risposta. L'obiettivo è fondare le indicazioni su documentazione di prodotto e runbook approvati, anziché sulla sola memoria del modello.
Il servizio knowledge base di Amazon gestisce il recupero dei documenti e può restituire materiale sorgente pertinente a una query. Nel design di Zerto, questa conoscenza esterna integra lo stato dell'ambiente locale ottenuto tramite MCP.
La distinzione tra queste fonti è importante. La documentazione del prodotto descrive il comportamento previsto. Le API locali descrivono lo stato corrente del cliente. Una risoluzione affidabile dei problemi richiede che l'agente confronti i due elementi senza confondere una procedura generica con evidenze relative all'incidente attivo.
Consideriamo una domanda sul ritardo di replica. La documentazione potrebbe elencare vincoli di larghezza di banda, interruzioni di rete, variazioni del carico di lavoro o stato di salute dell'appliance come possibili cause. Gli strumenti locali devono stabilire quali condizioni siano presenti nell'ambiente del cliente. Una risposta utile dovrebbe restringere le possibilità anziché ripetere l'intero elenco.
HPE afferma che gli agenti specialistici utilizzano anche competenze di dominio contenenti pattern di log noti. Queste competenze forniscono al modello una guida strutturata per riconoscere segnali associati a componenti e guasti specifici.
Il sistema deve quindi preservare internamente la provenienza delle informazioni. Gli ingegneri dovrebbero poter distinguere tra un risultato supportato da dati in tempo reale e un'ipotesi dedotta dal modello. La descrizione pubblicata dell'account AWS parla di telemetria, valutazioni e output strutturati, ma non divulga il comportamento completo delle citazioni mostrato agli amministratori.
Il controllo degli accessi rappresenta un altro punto critico. Uno strumento MCP ampio può esporre più informazioni operative di quante ne richieda una domanda. Uno strumento ristretto riduce l'esposizione, ma può omettere il contesto necessario per la diagnosi. La progettazione del confine dello strumento diventa quindi una decisione di sicurezza e di prodotto, non solo un'attività di integrazione.
L'etichettatura delle richieste per tenant aggiunge un ulteriore controllo. L'architettura utilizza tag dei ruoli AWS Identity and Access Management associati a ciascun tenant. CloudWatch, DynamoDB e Lambda supportano il monitoraggio dell'utilizzo e l'applicazione dei limiti dei tenant.
Amazon Bedrock Guardrails controlla prompt e output attorno all'inferenza del modello. La documentazione AWS afferma che i suoi controlli dei guardrail possono filtrare contenuti selezionati, rilevare attacchi ai prompt, limitare argomenti negati e mascherare informazioni sensibili.
Questi filtri riducono rischi specifici, ma non possono verificare ogni conclusione operativa. Una risposta può restare entro un argomento approvato e raccomandare comunque una correzione errata. I guardrail disciplinano i confini dei contenuti, mentre valutazione e logica di prodotto devono affrontare la correttezza tecnica.
Per questo l'architettura locale di HPE non dovrebbe essere interpretata come una semplice dichiarazione sulla privacy. L'orchestrazione locale riduce la raccolta centralizzata e mantiene l'esecuzione degli strumenti vicina all'ambiente. Non elimina la necessità di controlli sui dati in uscita, progettazione dell'autorizzazione, test dei rischi del modello o giudizio umano durante incidenti ad alto impatto.
Risposte testate di HPE Zerto, percorsi degli strumenti, latenza e token
HPE ha trattato la valutazione come un sistema operativo, non come un singolo test di accuratezza eseguito prima del rilascio.
La valutazione degli agenti è difficile perché la risposta finale è solo un risultato osservabile. Un agente può produrre una risposta plausibile dopo aver selezionato lo strumento sbagliato, utilizzato prove irrilevanti o seguito un percorso eccessivamente costoso. Questo comportamento potrebbe fallire in condizioni leggermente diverse.
HPE ha realizzato i propri test con PyTest e il kit di sviluppo software per la valutazione di Strands Agents. Ha creato job che eseguono ripetutamente una suite più ampia man mano che cambiano agenti, modelli e prompt.
La prima categoria di test copre le query di base. Ogni test fornisce una singola richiesta e valuta la risposta. Questo approccio si adatta a domande stabili con un risultato atteso chiaro o criteri di valutazione definiti.
La seconda categoria valuta conversazioni multi-turno. Un modello simulatore di utente interagisce con l'agente dopo la query iniziale e l'intera conversazione viene sottoposta a valutazione. Questo formato verifica se il sistema richiede le informazioni mancanti e mantiene il contesto attraverso diversi scambi.
La terza categoria genera test dinamici. Il generatore di esperimenti di Strands crea casi a partire da criteri selezionati, offrendo a HPE un modo per esplorare scenari non rappresentati in un set di test fisso. La generazione dinamica amplia la copertura, anche se i test generati richiedono comunque criteri significativi e revisione.
Ogni test può applicare quattro valutatori. Un valutatore della risposta assegna un punteggio alla risposta rispetto a requisiti predefiniti. Un valutatore della traiettoria esamina se l'agente ha selezionato strumenti appropriati e seguito un percorso accettabile.
Un valutatore della latenza verifica il tempo di completamento rispetto a una soglia. Un valutatore dei token controlla se l'utilizzo resta entro limiti definiti. Insieme, queste misure riflettono il compromesso in produzione tra qualità diagnostica, tempo di risposta e consumo di inferenza.
La valutazione della traiettoria è particolarmente importante per un agente operativo. La formulazione finale può sembrare corretta anche quando il sistema vi è giunto attraverso una sequenza non sicura o inaffidabile. Testare il percorso può rivelare che un agente ha saltato la verifica in tempo reale, invocato un'API non correlata o fatto affidamento sulla documentazione quando erano disponibili dati attuali.
La suite di valutazione supporta anche la progettazione multi-modello. HPE può confrontare un modello più piccolo con uno più grande usando gli stessi criteri di risposta, traiettoria, latenza e token. Ciò rende la sostituzione del modello una decisione empirica anziché un'assunzione generale secondo cui un modello più grande funziona sempre meglio.
Il sistema trasmette lo stato di avanzamento dell'indagine all'interfaccia usando Server-Sent Events. SSE è un meccanismo web che consente a un server di inviare continuamente aggiornamenti a un browser tramite un'unica connessione. Gli utenti possono vedere l'avanzamento mentre uno specialista esamina un problema.
HPE afferma che lo streaming ha migliorato l'esperienza utente perché gli operatori non aspettano più senza feedback. Nel disaster recovery, l'avanzamento visibile aiuta anche a distinguere un'indagine in corso da un'interfaccia bloccata.
Tuttavia, l'attività trasmessa in streaming può creare una falsa fiducia se mostra passaggi senza spiegarne il valore probatorio. Un elenco di chiamate agli strumenti non equivale a una diagnosi verificata. L'interfaccia deve presentare progressi sufficienti a costruire fiducia senza trasformare il ragionamento interno in spettacolo.
La stessa cautela si applica alle affermazioni di HPE sull'adozione. L'azienda riferisce che oltre il 20 percento dei clienti utilizza attivamente il sistema e che i casi di supporto applicabili sono diminuiti del 10 percento. Questi risultati suggeriscono un uso reale del prodotto, ma il post pubblico non definisce l'uso attivo, la finestra di misurazione o la popolazione di workflow coperta.
Anche una riduzione dei casi di supporto può avere diverse spiegazioni. L'agente potrebbe risolvere con successo i problemi, reindirizzare gli utenti verso la documentazione esistente, modificare il modo in cui i casi vengono classificati o scoraggiare alcune escalation. Dati indipendenti sui tassi di risoluzione e sugli esiti offrirebbero una visione più chiara.
Per i team di ingegneria che stanno considerando un progetto simile, la lezione non è che quattro valutatori risolvano la questione dell'affidabilità. La lezione è che gli agenti in produzione necessitano di comportamenti misurabili a più livelli. Qualità della risposta, scelta degli strumenti, reattività e uso delle risorse possono fallire indipendentemente.
Una base di conoscenza ingegneristica ricercabile segue un principio correlato. Il recupero delle informazioni diventa più utile quando i documenti restano organizzati, aggiornati e collegati al lavoro svolto dagli ingegneri.
Le piattaforme di cloud recovery affrontano ora una questione di interfaccia
La pressione competitiva si sta spostando dalle sole funzionalità di replica verso chi riesce a interpretare lo stato di recovery e guidare un operatore durante un incidente.
HPE Zerto compete in un mercato che include già servizi di recovery cloud-native. Amazon Elastic Disaster Recovery replica i carichi di lavoro on-premises e cloud supportati in un'area di staging all'interno di un account AWS. Gli operatori possono avviare istanze di recovery per esercitazioni o incidenti reali.
Il servizio di recovery AWS enfatizza la replica continua, il recovery point-in-time, i test non invasivi e il failback. È strettamente integrato con l'infrastruttura AWS e punta al recovery in Amazon EC2.
Microsoft Azure Site Recovery gestisce replica, failover e failback per macchine virtuali e server fisici supportati. La sua piattaforma di recovery copre la replica da Azure ad Azure e diversi scenari on-premises con Azure come destinazione di recovery.
Questi servizi non corrispondono direttamente a ogni implementazione di Zerto. HPE Zerto supporta modelli operativi ibridi più ampi e mantiene una propria architettura di prodotto. Il confronto rilevante qui non è un elenco di funzionalità di replica.
La nuova pressione riguarda l'interfaccia operativa sopra tali funzionalità. I sistemi di recovery generano avvisi, stati di configurazione, metriche di replica e risultati delle esercitazioni. Un agente può potenzialmente tradurre queste informazioni in un'indagine guidata senza richiedere a ogni amministratore di sapere dove risiede ciascun segnale.
La mossa iniziale di HPE le offre l'opportunità di stabilire il comportamento degli agenti attorno al proprio contesto operativo proprietario. I suoi specialisti possono codificare pattern di log specifici per componente e utilizzare API già associate a Zerto Manager e ai motori di replica.
I provider cloud possiedono un vantaggio diverso. Controllano l'infrastruttura, la telemetria, i servizi di identità, le API di recovery e le piattaforme di IA gestita all'interno dei rispettivi cloud. Possono potenzialmente creare agenti con accesso diretto a una raccolta più ampia di segnali nativi.
Questo crea il principale antagonista dell'approccio di HPE Zerto: troubleshooting controllato localmente contro intelligence operativa incentrata sul cloud. La competizione non è semplicemente HPE contro AWS o Microsoft, perché AWS fornisce i modelli alla base del sistema Zerto. È una competizione tra posizioni architetturali di controllo e contesto.
Il controllo locale mantiene l'orchestrazione vicina all'infrastruttura protetta e può supportare ambienti con rigide politiche di residenza dei dati. I sistemi incentrati sul cloud possono attingere a telemetria integrata e servizi gestiti senza dover mantenere un runtime dell'agente nell'appliance di ogni cliente.
L'architettura HPE combina entrambe le strade. Gli agenti e gli strumenti operativi restano locali, mentre l'inferenza del modello e il recupero dei documenti usano AWS. Questa configurazione ibrida tenta di mantenere on-premises il confine di esecuzione più sensibile senza rinunciare ai modelli fondazionali gestiti.
L'approccio attribuisce inoltre a HPE responsabilità di distribuzione che un servizio cloud interamente gestito può evitare. Il pod locale deve restare compatibile con le release del prodotto, le politiche di rete dei clienti, i sistemi di autenticazione e le connessioni in uscita limitate. Il troubleshooting dell'agente di troubleshooting diventa parte del carico operativo.
Gli ambienti air-gapped rappresentano la limitazione più netta. HPE afferma che l'infrastruttura di disaster recovery è spesso air-gapped, sensibile alla latenza o soggetta a requisiti di residenza dei dati. Tuttavia, il sistema descritto necessita ancora di accesso HTTPS per l'inferenza del modello e le query alla knowledge base.
Le installazioni strettamente disconnesse non possono quindi utilizzare l'architettura esattamente come descritta. Altri clienti possono consentire traffico in uscita strettamente controllato, ma i team di sicurezza dovranno comunque esaminare destinazioni, contenuti delle richieste, controlli di identità, comportamento di conservazione e modalità di errore.
Anche la latenza si estende su due sedi. Le chiamate agli strumenti verso Zerto restano locali, mentre le richieste di ragionamento viaggiano verso AWS. Un'indagine complessa può richiedere diversi cicli tra decisioni del modello e risultati degli strumenti locali. Lo streaming può rendere visibile quell'attesa, ma non può eliminare la dipendenza dalla rete.
Il valore strategico dell'architettura dipende dal fatto che questo compromesso ibrido funzioni meglio delle alternative. Se fornisce indicazioni affidabili e basate su evidenze senza centralizzare dati operativi grezzi, offre ai fornitori di software enterprise un modello riutilizzabile. Se prevalgono vincoli di rete o errori di grounding, gli acquirenti potrebbero preferire un'assistenza più semplice o operazioni cloud interamente gestite.
Il prossimo test è se la diagnosi guidata diventerà operatività affidabile
Tre segnali mostreranno se il troubleshooting agentico di HPE Zerto sta diventando un'infrastruttura affidabile anziché un'interfaccia di supporto attraente.
Il primo segnale riguarda la qualità della risoluzione. I dati di adozione e il numero di casi di assistenza sono punti di partenza utili, ma non indicano se gli utenti abbiano scelto rimedi sicuri o risolto gli incidenti più rapidamente.
HPE dovrebbe infine comunicare misure dei risultati per i flussi di lavoro supportati. Segnali utili includono la risoluzione autonoma riuscita, l'escalation dopo l'interazione con un agente, gli incidenti ricorrenti, l'accettazione da parte degli amministratori e gli errori rilevati durante la revisione. Periodi di misurazione comparabili renderebbero questi risultati più significativi.
Se risultati verificati in modo indipendente dimostrassero una diagnosi accurata in diversi ambienti dei clienti, il caso a favore di operazioni agentiche locali diventerebbe più solido. Se la riduzione delle richieste di supporto arrivasse senza dati affidabili sulla risoluzione, la narrazione prestazionale pubblicata resterebbe incompleta.
Il secondo segnale è l'espansione oltre le attività di consulenza. HPE indica l'esecuzione di attività per gli utenti come uno degli obiettivi del sistema. L'architettura pubblica spiega principalmente l'assistenza, l'indagine, gli avvisi sullo stato di salute e le indicazioni di mitigazione.
Passare dalle raccomandazioni alle azioni modifica il modello di rischio. Una spiegazione errata fa perdere tempo, mentre una modifica di configurazione errata può compromettere la protezione o la prontezza al ripristino. Gli agenti che intraprendono azioni necessitano di autorizzazioni ristrette, approvazioni, audit trail completi, operazioni idempotenti e percorsi di rollback affidabili.
Qualsiasi release che consenta al sistema di modificare la configurazione dovrebbe quindi ricevere grande attenzione. Azioni limitate e reversibili, con conferma esplicita, rafforzerebbero l'architettura di HPE. Un'ampia correzione autonoma senza dettagli pubblicati sui controlli aumenterebbe l'incertezza.
Il terzo segnale riguarda il comportamento dell'agente durante una connettività degradata e gli incidenti gravi. Una normale richiesta di assistenza offre accesso di rete stabile e urgenza moderata. Un evento ransomware o un'interruzione dell'infrastruttura può compromettere gli stessi percorsi di identità, rete o cloud utilizzati dall'agente.
HPE deve definire chiaramente il comportamento quando Amazon Bedrock non è disponibile, una query di conoscenza va in timeout, uno strumento locale restituisce dati obsoleti o l'orchestratore non riesce a completare un'indagine. Un degrado sicuro dovrebbe distinguere le evidenze mancanti da un'infrastruttura sana e indirizzare gli operatori verso procedure di ripristino consolidate.
L'uso interno dell'azienda offre un ulteriore banco di prova. HPE afferma che i propri ingegneri usano il sistema per indagare sui problemi comuni, mentre il team di controllo qualità lo integra nei flussi di test. Questi utenti possono individuare modelli di errore prima che i clienti dipendano dallo stesso comportamento durante una crisi.
L'architettura contiene già diversi vincoli ragionevoli. Gli agenti specialistici ricevono responsabilità delimitate. La ricorsione peer-to-peer è vietata. L'orchestratore controlla l'output finale. Le API locali forniscono dati aggiornati, mentre valutazioni ripetute esaminano risposte e traiettorie degli strumenti.
Nessuno di questi controlli rende deterministico il ragionamento di un modello linguistico. Il sistema opera comunque attraverso versioni software in evoluzione, topologie dei clienti, formati di log, rilasci dei modelli e documentazione. La valutazione continua deve quindi accompagnare il prodotto dopo il deployment.
Per gli acquirenti enterprise, la domanda giusta non è se un agente possa riassumere un avviso. È se il sistema mostri da dove proviene la propria risposta, rispetti le autorizzazioni operative, riconosca le evidenze mancanti ed esegua un'escalation prima che l'incertezza si trasformi in azione.
Gli sviluppatori dovrebbero monitorare il confine degli strumenti. Un server MCP ben progettato può rendere le API esistenti utilizzabili dagli agenti, ma ogni operazione esposta amplia l'autorità del sistema. I team di prodotto dovrebbero trattare la progettazione degli strumenti con la stessa cura riservata alle API pubbliche e ai ruoli amministrativi.
I knowledge worker possono trarre una lezione più ampia dal deployment. L'AI diventa più utile quando può collegare materiale di riferimento affidabile al contesto di lavoro corrente. Questo vantaggio dipende dalla qualità delle fonti, dai confini di accesso e da una chiara distinzione tra fatti recuperati e giudizio generato.
HPE Zerto ha portato questa idea in uno degli ambienti meno indulgenti dell'informatica enterprise. Il sistema unisce orchestrazione locale, dati di disaster recovery in tempo reale, agenti specializzati e inferenza cloud gestita in un unico percorso operativo.
Ora le evidenze devono andare oltre l'adozione. Occorre osservare se HPE pubblicherà risultati sulla risoluzione, introdurrà azioni controllate e documenterà il comportamento in modalità degradata. Questi segnali determineranno se il modello di troubleshooting agentico di HPE Zerto diventerà un modello che altri fornitori di infrastrutture dovrebbero seguire.
