How HPE Zerto Built an Agentic Troubleshooting System with Amazon Bedrock

Enterprise disaster recovery (DR) is an operational domain where failure is not an option. When continuous data protection (CDP) replication halts, or Virtual Protection Groups (VPGs) enter an error state, storage and infrastructure administrators must diagnose complex telemetry, network topologies, and storage array logs within tight Recovery Time Objectives (RTOs). Traditional rule-based alerting systems often bombard engineers with symptoms rather than root causes.

To solve this, HPE Zerto engineered an autonomous, agentic troubleshooting system powered by Amazon Bedrock and integrated with the Strands Agents framework. Operating on-premises within sensitive customer environments, this multi-agent architecture turns unstructured log streams and complex state graphs into actionable remediation paths. In this article, we examine how HPE Zerto designed this system, the engineering hurdles of grounding LLMs in live disaster recovery data, and how developers can build resilient enterprise AI systems using unified gateways like n1n.ai.

The Architectural Problem: On-Premises DR Meets Generative AI

Disaster recovery systems operate under strict constraints that make standard cloud-native LLM integrations difficult:

Data Privacy and Sovereignty: Customers cannot stream raw system telemetry, IP addresses, or VM metadata to public, multi-tenant AI endpoints.
State Complexity: A Zerto Virtual Manager (ZVM) handles hundreds of parallel replication pipelines. Identifying why a specific VPG snapshot failed requires inspecting VSS writers, storage I/O queues, and WAN latency metrics across multiple hypervisors.
Deterministic Execution: AI models must never trigger destructive actions (e.g., initiating a unintended failover or wiping a journal log) based on hallucinations.

To solve these challenges, HPE Zerto deployed an agentic architecture on-premises. Rather than relying on a single large prompt (Single-Prompt RAG), the system distributes tasks across specialized autonomous agents running via Strands Agents, with LLM reasoning provided securely through Amazon Bedrock endpoints.

+-----------------------------------------------------------------------------------+
|                         On-Premises Customer Environment                          |
|                                                                                   |
|  +-----------------------+    +-----------------------+    +-------------------+  |
|  |   HPE Zerto VVM/ZVM   |    | Telemetry Collector   |    | Strands Agent     |  |
|  |   (Replication Logs)  |    | (Log Streams & VPG)   |    | Orchestrator      |  |
|  +-----------+-----------+    +-----------+-----------+    +---------+---------+  |
|              |                            |                      |                |
+--------------|----------------------------|----------------------|----------------+
               |                            |                      |
               +----------------------------+                      |
                                                            HTTPS / PrivateLink
                                                                   |
                                                                   v
                                                  +---------------------------------+
                                                  |     Amazon Bedrock / API Gateway|
                                                  |  (Claude 3.5 Sonnet / Haiku)    |
                                                  +---------------------------------+

Architecture Breakdown: The Multi-Agent Design Pattern

The core of Zerto’s architecture relies on the Supervisor-Worker Agent Pattern. Instead of expecting one foundation model to handle log parsing, root-cause analysis, and solution generation, the workload is partitioned among distinct agents:

1. The Diagnostic Orchestrator (Supervisor)

The supervisor agent receives the initial incident report (e.g., VPG_BITMAP_SYNC_FAILED). It maintains the context graph and decomposes the troubleshooting process into sub-tasks. It decides which specialized tool or sub-agent to invoke next.

2. The Log & Telemetry Parsing Agent

This worker agent interacts directly with local Zerto APIs and log files. It filters out noise, normalizes timestamps across distributed Zerto Virtual Appliances (ZVAs), and extracts structured JSON context.

3. Knowledge Grounding Agent (RAG)

The knowledge agent queries an indexed knowledge base containing Zerto technical documentation, known issue databases, and resolution runbooks. It retrieves relevant solution patterns matching the parsed error parameters.

4. Safety & Validation Agent

Before suggesting or executing any diagnostic script, this agent checks proposed actions against system policies, verifying that latency impact is < 50ms and that destructive parameters are absent.

Architectural Comparison: Troubleshooting Paradigms

Feature	Traditional Scripting / Alerts	Single-Prompt RAG	HPE Zerto Agentic (Amazon Bedrock)
Context Adaptation	Rigid (Static IF-THEN rules)	Moderate (Limited by window size)	Dynamic (Multi-step tool calling)
Root Cause Accuracy	Low (Reports symptoms only)	Medium (Prone to missing subtle context)	High (Multi-agent verification loop)
Data Sovereignty	Local (No AI)	Variable (Often requires Cloud sync)	Hybrid (Local execution, secure Bedrock endpoint)
Execution Safety	Deterministic but fragile	Low (High risk of prompt drift)	High (Guarded by deterministic safety agents)
Extensibility	Hardcoded code changes	System prompt modifications	Modular tool & agent addition

Implementation: Orchestrating Agents with Tools

Below is a simplified implementation showing how developers can implement a multi-agent diagnostic step inspired by the HPE Zerto pattern using Python and Amazon Bedrock models. For enterprises needing multi-cloud resilience across Amazon Bedrock, OpenAI, and Anthropic, managing endpoints via n1n.ai simplifies endpoint failover and unified telemetry.

import json
import boto3
from typing import Dict, Any, List

# Initialize Bedrock Runtime client
# Pro Tip: In production, route through https://n1n.ai for unified multi-provider fallback
bedrock_client = boto3.client(
    service_name="bedrock-runtime

Source: https://aws.amazon.com/blogs/machine-learning/how-hpe-zerto-built-an-agentic-troubleshooting-system-with-amazon-bedrock/