HPE Zerto Agentic Troubleshooting Leva IA em Nuvem para a Recuperação On-Premises

A HPE Zerto lançou um sistema de troubleshooting agentic com três funções de agentes, mas seu aspecto mais importante é onde esses agentes operam. O ambiente de execução do troubleshooting agentic da HPE Zerto fica dentro do ambiente de cada cliente. Ele analisa localmente sinais ativos de recuperação de desastres, enquanto envia solicitações selecionadas de inferência e consulta de conhecimento à Amazon Web Services.

Essa divisão desafia a premissa de que agentes empresariais úteis precisam mover dados operacionais para uma aplicação centralizada na nuvem. Em vez disso, a HPE Zerto posicionou a orquestração ao lado da infraestrutura investigada. O Amazon Bedrock fornece acesso a modelos, recuperação de conhecimento, proteções e controles de apoio, sem se tornar o repositório de todo o fluxo de troubleshooting.

O sistema entrou em produção no segundo trimestre de 2026. HPE e AWS afirmam que mais de 20% dos clientes da Zerto o adotaram posteriormente. As empresas também relatam uma redução de 10% nos chamados de suporte nos fluxos de trabalho abrangidos pelo sistema. Esses números foram fornecidos pelas empresas e não receberam validação independente.

O resultado arquitetural importa para além de um único produto de recuperação. Ambientes de recuperação de desastres combinam logs sensíveis, configurações em constante mudança, controles de acesso rigorosos e intensa pressão de tempo. Um assistente incapaz de enxergar as condições atuais oferece conselhos genéricos. Um agente com acesso irrestrito cria um risco operacional diferente.

A HPE Zerto busca ocupar o espaço estreito entre esses dois resultados. Seus agentes recebem acesso estruturado a informações locais, dividem as investigações por domínio técnico e retornam uma resposta condensada por meio de um único orquestrador controlador. A questão central é se essa arquitetura consegue preservar contexto, segurança e comportamento previsível à medida que os ambientes reais se tornam mais complexos.

O HPE Zerto Agentic Troubleshooting Começa Dentro do Ambiente do Cliente

A mudança definidora não é a interface de chat. É a localização do ambiente de execução do agente ao lado dos sistemas e das evidências que ele precisa investigar.

O HPE Zerto Software oferece suporte à recuperação de desastres, à proteção contínua de dados e à resiliência cibernética em infraestruturas híbridas e multinuvem. Os operadores usam o produto para monitorar cargas de trabalho protegidas, prontidão de recuperação, integridade da replicação e exposição a acordos de nível de serviço.

Tradicionalmente, a resolução de problemas nesse ambiente exige informações de vários lugares. Um administrador pode inspecionar um alerta, examinar o log de um componente, revisar dados de configuração, pesquisar a documentação do produto e comparar as descobertas com um runbook. Durante uma interrupção, cada transferência entre essas fontes adiciona atraso e cria oportunidades para que evidências relevantes passem despercebidas.

O novo sistema incorpora uma experiência de chat à interface de gerenciamento existente da Zerto. Os operadores podem perguntar sobre o status de grupos de proteção, alertas recentes, práticas de configuração, atrasos de replicação, falhas de atualização ou problemas ativos no sistema. O assistente também pode destacar problemas de integridade e orientar ações de mitigação.

Segundo o relato conjunto sobre a arquitetura, a HPE implanta a camada agentic como um pod dentro do ambiente on-premises do cliente. Um pod é um grupo implantável de contêineres que funciona como uma unidade de aplicação. Nesse projeto, ele contém o ambiente de execução local dos agentes.

O ambiente usa Strands Agents, um framework open source desenvolvido pela AWS para criar agentes orientados por modelos. O histórico da sessão permanece armazenado localmente, e os agentes acessam informações ativas da Zerto por meio de um servidor local do Model Context Protocol.

O Model Context Protocol, ou MCP, define uma forma padronizada de uma aplicação de IA chamar ferramentas e obter dados contextuais. A HPE encapsulou APIs existentes do Zerto Manager em um servidor MCP, dando aos agentes acesso estruturado às informações atuais do ambiente.

Isso é substancialmente diferente de copiar todos os logs e registros de configuração para um chatbot remoto. Os agentes da Zerto podem solicitar os fatos locais necessários para uma investigação enquanto o ambiente de execução permanece dentro do appliance. A HPE afirma que apenas solicitações de inferência de modelos e consultas ao Amazon Bedrock Knowledge Bases deixam a rede local via HTTPS.

A distinção exige uma formulação cuidadosa. O sistema não está totalmente desconectado da nuvem, nem é uma implantação de modelo offline. O Amazon Bedrock ainda processa solicitações de modelos, enquanto seu serviço gerenciado de conhecimento recupera informações relevantes sobre o produto. O projeto local controla a orquestração e o acesso operacional, em vez de eliminar o processamento externo.

Esse limite cria a tensão central do artigo. Um agente operado localmente pode permanecer próximo de evidências sensíveis, mas seu raciocínio ainda depende de serviços remotos de modelos e de solicitações de saída cuidadosamente projetadas. Portanto, a utilidade do sistema depende de qual contexto cruza esse limite, de como ele é filtrado e de se as orientações retornadas continuam fundamentadas.

O lançamento também leva a assistência de IA mais profundamente ao fluxo de recuperação. Ela não se limita mais a explicar a documentação. O sistema pode inspecionar as condições atuais e montar uma investigação específica para o problema, o que aumenta tanto seu valor operacional quanto o custo de uma conclusão equivocada.

Um Projeto Hub-and-Spoke Mantém Um Agente no Controle

A HPE Zerto dividiu o troubleshooting entre agentes especializados, mantendo um único orquestrador como ponto de controle para delegação e respostas finais.

A arquitetura usa um agente orquestrador e pelo menos dois subagentes especializados. O orquestrador trata diretamente as perguntas rotineiras e delega investigações mais profundas quando um problema exige análise especializada.

Um subagente se concentra no Zerto Manager, também chamado de ZVM. Ele investiga áreas como falhas de serviço, problemas de rede e falhas de atualização. Suas ferramentas fornecem acesso a dados ambientais relevantes, enquanto habilidades de domínio identificam conhecimento técnico e padrões reconhecíveis de logs.

Outro subagente se concentra no Zerto Replication Engine, ou VRA. Ele trata problemas de replicação, redes entre sites, falhas de instalação e atrasos. Ele recebe suas próprias ferramentas, instruções, conhecimento de domínio e contexto de trabalho.

Essa divisão reflete uma escolha de engenharia importante. Dar a um único agente geral todos os logs, ferramentas, instruções e detalhes de conversação pode produzir um contexto excessivamente grande, com sinais concorrentes. Isso também dificulta isolar falhas, pois o mesmo componente realiza o roteamento, a análise e a geração de respostas.

Em vez disso, a HPE usa uma estrutura hub-and-spoke. O orquestrador fica no hub, e os agentes especializados atuam como raios. Os subagentes reportam ao agente principal, em vez de chamarem uns aos outros diretamente.

A AWS descreve esse padrão multiagente como agents-as-tools, no qual um agente coordenador invoca especialistas por meio de interfaces delimitadas. Cada especialista pode usar um prompt, contexto, modelo e conjunto de ferramentas separados.

Para a Zerto, essa separação traz três benefícios práticos. Primeiro, uma investigação com muitos logs não preenche o contexto do orquestrador com material de diagnóstico bruto. O especialista retorna um relatório mais curto contendo suas descobertas, em vez de todo o seu processo de trabalho.

Segundo, cada agente se torna testável de forma independente. Os engenheiros podem avaliar se o especialista em VRA seleciona as ferramentas corretas sem exigir que cada teste percorra comportamentos não relacionados do ZVM. Essa separação pode facilitar a localização de regressões.

Terceiro, o orquestrador continua responsável pela resposta final. A HPE afirma que ele remove segredos e logs brutos antes de apresentar os resultados ao usuário. Um único caminho de saída também oferece ao produto um ponto para aplicar regras de resposta.

A estrutura hub-and-spoke restringe a autonomia lateral. Se um especialista descobrir que outro componente é responsável pelo problema, ele devolve essa observação ao orquestrador. Ele não invoca um par de forma independente.

Essa restrição reduz a chance de conversas recursivas entre agentes consumirem tokens sem chegar a uma decisão. Ela também cria uma sequência rastreável para observabilidade. Toda delegação começa e termina no mesmo ponto de controle.

A contrapartida é um possível atrito de roteamento. O orquestrador precisa reconhecer corretamente quando uma pergunta exige especialização e selecionar o agente apropriado. Um especialista também precisa condensar suas descobertas sem remover evidências essenciais para o diagnóstico final.

A HPE usa perfis de modelo diferentes para essas responsabilidades. O trabalho rotineiro pode ficar com o orquestrador, enquanto investigações que exigem mais raciocínio podem usar um modelo mais robusto. A empresa afirma que inicialmente avaliou modelos maiores para estabelecer a viabilidade e, depois, comparou alternativas com base na qualidade das respostas, latência e custo.

Essa abordagem multimodelo evita tratar toda solicitação como uma tarefa de dificuldade equivalente. Verificar o status de um grupo de proteção não exige o mesmo orçamento de raciocínio que interpretar uma sequência extensa de falhas em logs e no estado da rede.

Ela também transforma a seleção de modelos de uma decisão única de aquisição em um processo contínuo de engenharia. À medida que os modelos fundacionais mudam, a HPE pode reavaliar qual modelo se adequa a cada agente sem reconstruir todo o produto em torno de um fluxo de trabalho específico de um provedor.

Dados Ativos de Recuperação São a Vantagem e o Risco

O sistema se torna útil quando pode consultar a infraestrutura atual, mas esse mesmo acesso torna fundamentais o embasamento, as permissões e a seleção de ferramentas.

Um agente de troubleshooting precisa de mais do que manuais de produto. A documentação pode explicar o que um alerta significa, mas não pode revelar se um mecanismo de replicação específico está atrasado, qual rota de rede está falhando ou se uma alteração recente de configuração afetou a prontidão para recuperação.

A HPE conecta seus agentes a dados operacionais ativos por meio de um servidor MCP local. O servidor expõe APIs selecionadas do Zerto Manager como ferramentas estruturadas. Em vez de pedir a um modelo de linguagem que interprete uma exportação bruta de dados, o agente pode chamar uma operação definida e receber um resultado tipado.

A especificação pública do MCP separa ferramentas, recursos e prompts por meio de uma interface cliente-servidor acordada. Para softwares empresariais, essa estrutura pode transformar uma API de produto existente em uma camada acessível a agentes, sem reescrever os serviços operacionais subjacentes.

O acesso tipado ajuda, mas não garante um diagnóstico correto. O agente ainda precisa escolher a ferramenta apropriada, fornecer parâmetros válidos, interpretar as informações retornadas e conectá-las à documentação relevante.

A HPE combina ferramentas locais com Amazon Bedrock Knowledge Bases. A geração aumentada por recuperação, ou RAG, recupera material-fonte relevante antes que o modelo crie uma resposta. O objetivo é fundamentar as orientações em documentação aprovada do produto e runbooks, em vez de depender apenas da memória do modelo.

O serviço de base de conhecimento da Amazon gerencia a recuperação de documentos e pode devolver material-fonte relevante para uma consulta. No projeto da Zerto, esse conhecimento externo complementa o estado do ambiente local obtido por meio do MCP.

A distinção entre essas fontes é importante. A documentação do produto descreve o comportamento esperado. As APIs locais descrevem o estado atual do cliente. Um troubleshooting confiável exige que o agente compare os dois sem confundir um procedimento genérico com evidências sobre o incidente ativo.

Considere uma questão sobre atraso de replicação. A documentação pode listar limitações de largura de banda, interrupção de rede, variação de carga de trabalho ou integridade do appliance como possíveis causas. As ferramentas locais precisam determinar quais condições existem no ambiente do cliente. Uma resposta útil deve restringir as possibilidades, em vez de repetir toda a lista.

A HPE afirma que os agentes especialistas também usam habilidades de domínio que contêm padrões de log conhecidos. Essas habilidades fornecem ao modelo orientação estruturada para reconhecer sinais associados a componentes e falhas específicos.

Em seguida, o sistema precisa preservar a proveniência internamente. Os engenheiros devem conseguir distinguir uma descoberta sustentada por dados em tempo real de uma hipótese inferida pelo modelo. A conta publicada da AWS descreve telemetria, avaliações e saídas estruturadas, mas não revela o comportamento completo de citação exibido aos administradores.

O controle de acesso representa outro ponto de pressão. Uma ferramenta MCP ampla pode expor mais informações operacionais do que uma pergunta exige. Uma ferramenta restrita reduz a exposição, mas pode omitir o contexto necessário para o diagnóstico. Projetar o limite da ferramenta torna-se, portanto, uma decisão de segurança e de produto, e não apenas uma tarefa de integração.

A marcação de solicitações por tenant acrescenta outro controle. A arquitetura usa tags de função do AWS Identity and Access Management associadas a cada tenant. CloudWatch, DynamoDB e Lambda oferecem suporte ao monitoramento de uso e à aplicação dos limites de cada tenant.

O Amazon Bedrock Guardrails verifica prompts e saídas em torno da inferência do modelo. A documentação da AWS afirma que seus controles de proteção podem filtrar conteúdos selecionados, detectar ataques a prompts, restringir tópicos proibidos e mascarar informações sensíveis.

Esses filtros reduzem riscos específicos, mas não conseguem verificar todas as conclusões operacionais. Uma resposta pode permanecer dentro de um tópico aprovado e ainda assim recomendar a correção errada. As proteções controlam os limites de conteúdo, enquanto a avaliação e a lógica do produto precisam tratar da correção técnica.

É por isso que a arquitetura local da HPE não deve ser interpretada como uma simples alegação de privacidade. A orquestração local reduz a coleta centralizada e mantém a execução das ferramentas próxima ao ambiente. Ela não elimina a necessidade de controles sobre dados enviados externamente, projeto de autorização, testes de risco do modelo ou julgamento humano durante incidentes de alto impacto.

Respostas Testadas da HPE Zerto, Caminhos de Ferramentas, Latência e Tokens

A HPE tratou a avaliação como um sistema operacional, e não como um único teste de precisão realizado antes do lançamento.

A avaliação de agentes é difícil porque a resposta final é apenas um resultado observável. Um agente pode produzir uma resposta plausível após selecionar a ferramenta errada, usar evidências irrelevantes ou percorrer um caminho excessivamente caro. Esse comportamento pode falhar em condições ligeiramente diferentes.

A HPE criou seus testes com PyTest e o kit de desenvolvimento de software de avaliação do Strands Agents. Ela criou tarefas que executam repetidamente uma suíte mais ampla à medida que os agentes, modelos e prompts mudam.

A primeira categoria de testes abrange consultas básicas. Cada teste fornece uma única solicitação e avalia a resposta. Essa abordagem é adequada para perguntas estáveis com um resultado esperado claro ou critérios de pontuação definidos.

A segunda categoria avalia conversas com múltiplos turnos. Um modelo simulador de usuário interage com o agente após a consulta inicial, e a conversa completa recebe uma avaliação. Esse formato testa se o sistema solicita informações ausentes e mantém o contexto ao longo de várias interações.

A terceira categoria gera testes dinâmicos. O gerador de experimentos do Strands cria casos com base em critérios selecionados, oferecendo à HPE uma forma de explorar cenários não representados em um conjunto de testes fixo. A geração dinâmica amplia a cobertura, embora os testes gerados ainda precisem de critérios relevantes e revisão.

Cada teste pode aplicar quatro avaliadores. Um avaliador de respostas pontua a resposta em relação a requisitos predefinidos. Um avaliador de trajetória examina se o agente selecionou ferramentas apropriadas e seguiu um caminho aceitável.

Um avaliador de latência verifica o tempo de conclusão em relação a um limite. Um avaliador de tokens verifica se o uso permanece dentro de limites definidos. Em conjunto, essas medidas refletem o equilíbrio em produção entre qualidade do diagnóstico, tempo de resposta e consumo de inferência.

A avaliação de trajetória é especialmente importante para um agente operacional. A redação final pode parecer correta mesmo quando o sistema chegou a ela por meio de uma sequência insegura ou pouco confiável. Testar o caminho pode revelar que um agente ignorou a verificação em tempo real, invocou uma API não relacionada ou se baseou na documentação quando dados atuais estavam disponíveis.

A suíte de avaliação também oferece suporte ao design multimodelo. A HPE pode comparar um modelo menor com um maior usando os mesmos critérios de resposta, trajetória, latência e tokens. Isso transforma a substituição de modelos em uma decisão empírica, em vez de uma suposição geral de que um modelo maior sempre tem melhor desempenho.

O sistema transmite o progresso da investigação para a interface usando Server-Sent Events. SSE é um mecanismo web que permite a um servidor enviar atualizações continuamente a um navegador por uma única conexão. Os usuários podem acompanhar o progresso enquanto um especialista examina um problema.

A HPE afirma que o streaming melhorou a experiência do usuário porque os operadores deixaram de esperar sem retorno. Na recuperação de desastres, o progresso visível também ajuda a diferenciar uma investigação em andamento de uma interface travada.

No entanto, a atividade transmitida pode criar falsa confiança se exibir etapas sem explicar seu valor probatório. Uma lista de chamadas de ferramentas não é o mesmo que um diagnóstico verificado. A interface precisa apresentar progresso suficiente para gerar confiança sem transformar o raciocínio interno em encenação.

A mesma cautela se aplica às alegações de adoção da HPE. A empresa informa que mais de 20 por cento dos clientes estão usando ativamente o sistema e que os casos de suporte aplicáveis caíram 10 por cento. Esses resultados sugerem uso real do produto, mas a publicação pública não define uso ativo, a janela de medição nem a população de fluxos de trabalho coberta.

Uma redução nos casos de suporte também pode ter várias explicações. O agente pode resolver problemas com sucesso, direcionar usuários à documentação existente, alterar a forma como os casos são classificados ou desestimular algumas escaladas. Dados independentes sobre taxa de resolução e resultados ofereceriam uma visão mais clara.

Para equipes de engenharia que consideram um design semelhante, a lição não é que quatro avaliadores resolvem a questão da confiabilidade. A lição é que agentes em produção precisam de comportamento mensurável em várias camadas. A qualidade da resposta, a escolha de ferramentas, a capacidade de resposta e o uso de recursos podem falhar de forma independente.

Uma base de conhecimento de engenharia pesquisável segue um princípio relacionado. A recuperação de informações se torna mais útil quando os documentos permanecem organizados, atualizados e conectados ao trabalho que os engenheiros realizam.

As Plataformas de Recuperação em Nuvem Agora Enfrentam uma Questão de Interface

A pressão competitiva está mudando de recursos de replicação isolados para quem consegue interpretar o estado da recuperação e orientar um operador durante um incidente.

A HPE Zerto compete em um mercado que já inclui serviços de recuperação nativos da nuvem. O Amazon Elastic Disaster Recovery replica cargas de trabalho compatíveis, locais e em nuvem, para uma área de preparação dentro de uma conta AWS. Os operadores podem iniciar instâncias de recuperação para testes ou incidentes reais.

O serviço de recuperação da AWS enfatiza replicação contínua, recuperação para um ponto no tempo, testes não disruptivos e failback. Ele é fortemente integrado à infraestrutura da AWS e tem como destino a recuperação em Amazon EC2.

O Microsoft Azure Site Recovery gerencia replicação, failover e failback para máquinas virtuais e servidores físicos compatíveis. Sua plataforma de recuperação abrange replicação de Azure para Azure e diversos cenários locais, com o Azure como destino de recuperação.

Esses serviços não correspondem diretamente a todas as implantações do Zerto. A HPE Zerto oferece suporte a padrões operacionais híbridos mais amplos e mantém sua própria arquitetura de produto. A comparação relevante aqui não é uma lista de verificação de recursos de replicação.

A nova pressão diz respeito à interface operacional acima desses recursos. Os sistemas de recuperação geram alertas, estados de configuração, métricas de replicação e resultados de testes. Um agente pode potencialmente traduzir essas informações em uma investigação guiada sem exigir que cada administrador saiba onde cada sinal está localizado.

O movimento inicial da HPE lhe dá a oportunidade de estabelecer o comportamento dos agentes em torno de seu contexto operacional proprietário. Seus especialistas podem codificar padrões de log específicos por componente e usar APIs já associadas ao Zerto Manager e aos mecanismos de replicação.

Os provedores de nuvem possuem uma vantagem diferente. Eles controlam a infraestrutura, a telemetria, os serviços de identidade, as APIs de recuperação e as plataformas de IA gerenciadas dentro de suas respectivas nuvens. Eles podem potencialmente criar agentes com acesso direto a uma coleção mais ampla de sinais nativos.

Isso cria o principal concorrente da abordagem da HPE Zerto: solução de problemas controlada localmente versus inteligência operacional centrada na nuvem. A disputa não é simplesmente HPE contra AWS ou Microsoft, pois a AWS fornece os modelos por trás do sistema da Zerto. Trata-se de uma disputa entre localizações arquitetônicas para controle e contexto.

O controle local mantém a orquestração próxima à infraestrutura protegida e pode atender ambientes com políticas rigorosas de residência de dados. Sistemas centrados na nuvem podem recorrer à telemetria integrada e a serviços gerenciados sem manter um runtime de agente dentro do appliance de cada cliente.

A arquitetura da HPE combina ambas as rotas. Os agentes e as ferramentas operacionais permanecem locais, enquanto a inferência de modelos e a recuperação de documentos usam a AWS. Esse arranjo híbrido tenta manter o limite de execução mais sensível no ambiente local sem abandonar os modelos de fundação gerenciados.

A abordagem também impõe à HPE responsabilidades de implantação que um serviço de nuvem totalmente gerenciado pode evitar. O pod local deve permanecer compatível com as versões do produto, as políticas de rede dos clientes, os sistemas de autenticação e as conexões de saída restritas. Solucionar problemas do agente de solução de problemas passa a fazer parte da carga operacional.

Ambientes isolados da rede apresentam a limitação mais evidente. A HPE afirma que a infraestrutura de recuperação de desastres costuma ser isolada da rede, sensível à latência ou sujeita a requisitos de residência de dados. Ainda assim, o sistema descrito continua precisando de acesso HTTPS para inferência de modelos e consultas à base de conhecimento.

Portanto, instalações estritamente desconectadas não podem usar a arquitetura exatamente como descrita. Outros clientes podem permitir tráfego de saída estritamente controlado, mas as equipes de segurança ainda precisarão inspecionar destinos, conteúdos das solicitações, controles de identidade, comportamento de retenção e modos de falha.

A latência também abrange dois locais. As chamadas de ferramentas ao Zerto permanecem locais, enquanto as solicitações de raciocínio viajam para a AWS. Uma investigação complexa pode exigir vários ciclos entre decisões do modelo e resultados das ferramentas locais. O streaming pode tornar essa espera visível, mas não pode eliminar a dependência da rede.

O valor estratégico da arquitetura depende de esse compromisso híbrido apresentar desempenho melhor que as alternativas. Se fornecer orientação confiável e baseada em evidências sem centralizar dados operacionais brutos, ele oferece aos fornecedores de software empresarial um padrão reutilizável. Se as restrições de rede ou os erros de fundamentação predominarem, os compradores poderão preferir assistência mais simples ou operações de nuvem totalmente gerenciadas.

O Próximo Teste É Saber Se o Diagnóstico Guiado Se Torna Operações Confiáveis

Três sinais mostrarão se a solução de problemas agêntica da HPE Zerto está se tornando uma infraestrutura confiável, em vez de uma interface de suporte atraente.

O primeiro sinal é evidência sobre a qualidade da resolução. As contagens de adoção e de casos de suporte são pontos de partida úteis, mas não mostram se os usuários escolheram soluções seguras ou resolveram incidentes mais rapidamente.

A HPE deveria, futuramente, divulgar métricas de resultados para fluxos de trabalho com suporte. Indicadores úteis incluem resolução bem-sucedida por autoatendimento, escalonamento após uma interação com um agente, incidentes recorrentes, aceitação por administradores e erros identificados durante a revisão. Períodos de medição comparáveis tornariam esses resultados mais significativos.

Se resultados analisados de forma independente demonstrarem diagnósticos precisos em diversos ambientes de clientes, o argumento em favor de operações agentivas locais se fortalecerá. Se a redução no suporte ocorrer sem dados confiáveis sobre resolução, a narrativa de desempenho divulgada continuará incompleta.

O segundo sinal é a expansão para além das tarefas de aconselhamento. A HPE inclui a execução de tarefas para usuários como um dos objetivos do sistema. A arquitetura pública explica principalmente assistência, investigação, alertas de integridade e orientações de mitigação.

A passagem de recomendações para ações altera o modelo de risco. Uma explicação equivocada consome tempo, enquanto uma mudança de configuração equivocada pode afetar a proteção ou a prontidão para recuperação. Agentes que executam ações precisam de permissões restritas, aprovações, trilhas de auditoria completas, operações idempotentes e caminhos confiáveis de reversão.

Por isso, qualquer lançamento que permita ao sistema modificar configurações deve receber atenção rigorosa. Ações limitadas e reversíveis, com confirmação explícita, fortaleceriam a arquitetura da HPE. Uma remediação autônoma ampla, sem detalhes publicados sobre os controles, aumentaria a incerteza.

O terceiro sinal é como o agente se comporta durante conectividade degradada e incidentes graves. Uma pergunta cotidiana de suporte oferece acesso de rede estável e urgência moderada. Um evento de ransomware ou uma interrupção de infraestrutura pode afetar os mesmos caminhos de identidade, rede ou nuvem usados pelo agente.

A HPE precisa definir claramente o comportamento quando o Amazon Bedrock fica indisponível, uma consulta de conhecimento expira, uma ferramenta local retorna dados desatualizados ou o orquestrador não consegue concluir uma investigação. A degradação segura deve distinguir evidências ausentes de uma infraestrutura saudável e direcionar os operadores para procedimentos de recuperação já estabelecidos.

O uso interno da empresa oferece outro ambiente de testes. A HPE afirma que seus engenheiros usam o sistema para investigar problemas comuns, enquanto sua equipe de garantia de qualidade o integra aos fluxos de testes. Esses usuários podem revelar padrões de falha antes que os clientes dependam do mesmo comportamento durante uma crise.

A arquitetura já contém várias restrições sensatas. Agentes especializados recebem responsabilidades delimitadas. A recursão ponto a ponto é proibida. O orquestrador controla a saída final. APIs locais fornecem dados atuais, enquanto avaliações repetidas examinam respostas e trajetórias das ferramentas.

Nenhum desses controles torna o raciocínio de modelos de linguagem determinístico. O sistema continua operando entre versões de software em constante mudança, topologias de clientes, formatos de logs, lançamentos de modelos e documentação. Portanto, a avaliação contínua precisa acompanhar o produto após a implantação.

Para compradores corporativos, a pergunta certa não é se um agente consegue resumir um alerta. É se o sistema mostra de onde veio sua resposta, respeita permissões operacionais, reconhece evidências ausentes e escala o caso antes que a incerteza se transforme em ação.

Os desenvolvedores devem observar o limite das ferramentas. Um servidor MCP bem projetado pode tornar APIs existentes utilizáveis por agentes, mas cada operação exposta amplia a autoridade do sistema. As equipes de produto devem tratar o design de ferramentas com o mesmo cuidado aplicado a APIs públicas e funções administrativas.

Os profissionais do conhecimento podem extrair uma lição mais ampla dessa implantação. A IA se torna mais útil quando pode conectar material de referência confiável ao contexto atual de trabalho. Esse benefício depende da qualidade das fontes, dos limites de acesso e de uma distinção clara entre fatos recuperados e julgamento gerado.

A HPE Zerto levou essa ideia para um dos ambientes menos tolerantes a falhas da computação corporativa. O sistema reúne orquestração local, dados ativos de recuperação de desastres, agentes especializados e inferência gerenciada em nuvem em um único caminho operacional.

Agora, as evidências precisam ir além da adoção. Observe se a HPE divulga resultados de resolução, introduz ações controladas e documenta o comportamento em modo degradado. Esses sinais determinarão se o modelo de solução de problemas agentiva da HPE Zerto se tornará um padrão que outros fornecedores de infraestrutura devem seguir.