HPE Zerto Agentic Troubleshooting Brings Cloud AI Into On-Premises Recovery
HPE Zerto has released an agentic troubleshooting system with three agent roles, but its most important feature is where those agents operate. The HPE Zerto agentic troubleshooting runtime sits inside each customer's environment. It examines live disaster recovery signals locally, while sending selected inference and knowledge queries to Amazon Web Services.
That division challenges the assumption that useful enterprise agents must move operational data into a centralized cloud application. HPE Zerto instead placed orchestration beside the infrastructure being investigated. Amazon Bedrock supplies model access, knowledge retrieval, guardrails, and supporting controls without becoming the home of the complete troubleshooting workflow.
The system entered production in the second quarter of 2026. HPE and AWS say more than 20 percent of Zerto customers subsequently adopted it. They also report a 10 percent reduction in support cases across workflows covered by the system. Those figures come from the companies and have not received independent validation.
The architectural result matters beyond one recovery product. Disaster recovery environments combine sensitive logs, changing configurations, strict access controls, and intense time pressure. An assistant that cannot see current conditions offers generic advice. An agent with unrestricted access creates a different operational risk.
HPE Zerto attempts to occupy the narrow space between those outcomes. Its agents receive structured access to local information, divide investigations by technical domain, and return a condensed answer through one controlling orchestrator. The central question is whether that architecture can preserve context, safety, and predictable behavior as real environments grow more complicated.
HPE Zerto Agentic Troubleshooting Starts Inside the Customer Environment
The defining change is not the chat interface. It is the placement of the agent runtime beside the systems and evidence it must investigate.
HPE Zerto Software supports disaster recovery, continuous data protection, and cyber resilience across hybrid and multi-cloud infrastructure. Operators use the product to monitor protected workloads, recovery readiness, replication health, and service-level agreement exposure.
Troubleshooting that environment traditionally requires information from several places. An administrator might inspect an alert, examine a component log, review configuration data, search product documentation, and compare the findings with a runbook. During an outage, every transfer between those sources adds delay and creates opportunities to miss relevant evidence.
The new system places a chat experience within the existing Zerto management interface. Operators can ask about protection group status, recent alerts, configuration practices, replication delays, upgrade failures, or active system problems. The assistant can also surface health issues and guide mitigation.
According to the joint architecture account, HPE deploys the agentic layer as a pod inside the customer's on-premises environment. A pod is a deployable group of containers that runs as one application unit. In this design, it contains the local agent runtime.
The runtime uses Strands Agents, an open-source framework developed by AWS for building model-driven agents. Session history remains locally stored, and agents reach live Zerto information through a local Model Context Protocol server.
Model Context Protocol, or MCP, defines a standard way for an AI application to call tools and obtain contextual data. HPE wrapped existing Zerto Manager APIs in an MCP server, giving agents structured access to current environmental information.
That is materially different from copying every log and configuration record into a remote chatbot. The Zerto agents can request the local facts required for an investigation while the runtime remains within the appliance. HPE says only model inference requests and Amazon Bedrock Knowledge Bases queries leave the local network over HTTPS.
The distinction needs careful wording. The system is not entirely disconnected from the cloud, and it is not an offline model deployment. Amazon Bedrock still processes model requests, while its managed knowledge service retrieves relevant product information. The local design controls orchestration and operational access rather than eliminating external processing.
That boundary creates the article's central tension. A locally operated agent can remain close to sensitive evidence, but its reasoning still depends on remote model services and carefully designed outbound requests. The usefulness of the system therefore rests on what context crosses that boundary, how it is filtered, and whether the returned guidance remains grounded.
The release also moves AI assistance deeper into the recovery workflow. It is no longer limited to explaining documentation. The system can inspect current conditions and assemble a problem-specific investigation, which raises both its operational value and the cost of a mistaken conclusion.
A Hub-and-Spoke Design Keeps One Agent in Control
HPE Zerto divided troubleshooting among specialized agents, while retaining a single orchestrator as the control point for delegation and final responses.
The architecture uses an orchestrator agent and at least two specialized sub-agents. The orchestrator handles routine questions directly and delegates deeper investigations when an issue requires specialized analysis.
One sub-agent focuses on Zerto Manager, also called ZVM. It investigates areas such as service crashes, networking problems, and upgrade failures. Its tools provide access to relevant environmental data, while domain skills identify technical knowledge and recognizable log patterns.
Another sub-agent focuses on the Zerto Replication Engine, or VRA. It handles replication problems, cross-site networking, installation failures, and delays. It receives its own tools, instructions, domain knowledge, and working context.
This division reflects an important engineering choice. Giving one general agent every log, tool, instruction, and conversation detail can produce an oversized context with competing signals. It also makes failures difficult to isolate because the same component performs routing, analysis, and response generation.
HPE instead uses a hub-and-spoke structure. The orchestrator sits at the hub, and specialized agents operate as spokes. Sub-agents report back to the parent rather than calling one another directly.
AWS describes this multi-agent pattern as agents-as-tools, where a coordinating agent invokes specialists through bounded interfaces. Each specialist can use a separate prompt, context, model, and tool set.
For Zerto, that separation has three practical benefits. First, a log-heavy investigation does not fill the orchestrator's context with raw diagnostic material. The specialist returns a shorter report containing its findings rather than its complete working process.
Second, each agent becomes independently testable. Engineers can evaluate whether the VRA specialist selects the right tools without requiring every test to traverse unrelated ZVM behavior. That separation can make regressions easier to locate.
Third, the orchestrator remains responsible for the final answer. HPE says it strips secrets and raw logs before presenting results to the user. A single output path also gives the product one place to apply response rules.
The hub-and-spoke structure restricts lateral autonomy. If a specialist discovers that another component owns the problem, it returns that observation to the orchestrator. It does not independently invoke a peer.
That constraint reduces the chance of recursive agent conversations consuming tokens without reaching a decision. It also creates a traceable sequence for observability. Every delegation begins and ends at the same control point.
The tradeoff is potential routing friction. The orchestrator must correctly recognize when a question needs specialization and select the appropriate agent. A specialist must also compress its findings without removing evidence essential to the final diagnosis.
HPE uses different model profiles for those responsibilities. Routine work can remain with the orchestrator, while reasoning-heavy investigations can use a stronger model. The company says it initially evaluated larger models to establish feasibility, then compared alternatives across response quality, latency, and cost.
This multi-model approach avoids treating every request as an equally difficult task. Checking a protection group's status does not require the same reasoning budget as interpreting an extended failure sequence across logs and network state.
It also shifts model selection from a one-time procurement decision into an ongoing engineering process. As foundation models change, HPE can reassess which model fits each agent without rebuilding the entire product around one provider-specific workflow.
Live Recovery Data Is the Advantage and the Risk
The system becomes useful when it can query current infrastructure, but that same access makes grounding, permissions, and tool selection critical.
A troubleshooting agent needs more than product manuals. Documentation can explain what an alert means, but it cannot reveal whether a particular replication engine is delayed, which network route is failing, or whether a recent configuration change affected recovery readiness.
HPE connects its agents to live operational data through a local MCP server. The server exposes selected Zerto Manager APIs as structured tools. Instead of asking a language model to interpret a raw data dump, the agent can call a defined operation and receive a typed result.
The public MCP specification separates tools, resources, and prompts through an agreed client-server interface. For enterprise software, that structure can turn an existing product API into an agent-accessible layer without rewriting the underlying operational services.
Typed access helps, but it does not guarantee a correct diagnosis. The agent still needs to choose the appropriate tool, supply valid parameters, interpret the returned information, and connect it with relevant documentation.
HPE combines local tools with Amazon Bedrock Knowledge Bases. Retrieval-augmented generation, or RAG, retrieves relevant source material before the model creates an answer. The goal is to ground guidance in approved product documentation and runbooks rather than model memory alone.
Amazon's knowledge base service manages document retrieval and can return source material relevant to a query. In Zerto's design, that external knowledge complements the local environment state obtained through MCP.
The distinction between those sources matters. Product documentation describes expected behavior. Local APIs describe the customer's current state. Reliable troubleshooting requires the agent to compare the two without confusing a generic procedure with evidence about the active incident.
Consider a replication-delay question. Documentation might list bandwidth constraints, network interruption, workload churn, or appliance health as possible causes. The local tools must establish which conditions exist in the customer's environment. A useful response should narrow the possibilities rather than restate the entire list.
HPE says the specialist agents also use domain skills containing known log patterns. These skills give the model structured guidance for recognizing signals associated with particular components and failures.
The system then needs to preserve provenance internally. Engineers should be able to distinguish a finding supported by live data from a hypothesis inferred by the model. The published AWS account describes telemetry, evaluations, and structured outputs, but it does not disclose the complete citation behavior shown to administrators.
Access control presents another pressure point. A broad MCP tool can expose more operational information than a question requires. A narrow tool reduces exposure but may omit context necessary for diagnosis. Designing the tool boundary therefore becomes a security and product decision, not merely an integration task.
Per-tenant request tagging adds another control. The architecture uses AWS Identity and Access Management role tags associated with each tenant. CloudWatch, DynamoDB, and Lambda support usage monitoring and enforcement of tenant limits.
Amazon Bedrock Guardrails checks prompts and outputs around model inference. AWS documentation says its guardrail controls can filter selected content, detect prompt attacks, restrict denied topics, and mask sensitive information.
Those filters reduce specific risks but cannot verify every operational conclusion. A response can remain within an approved topic and still recommend the wrong remediation. Guardrails govern content boundaries, while evaluation and product logic must address technical correctness.
This is why HPE's local architecture should not be read as a simple privacy claim. Local orchestration reduces centralized collection and keeps tool execution close to the environment. It does not remove the need for outbound-data controls, authorization design, model-risk testing, or human judgment during high-impact incidents.
HPE Zerto Tested Responses, Tool Paths, Latency, and Tokens
HPE treated evaluation as an operational system, not a single accuracy test performed before release.
Agent evaluation is difficult because the final response is only one observable result. An agent can produce a plausible answer after selecting the wrong tool, using irrelevant evidence, or taking an excessively expensive path. That behavior might fail under slightly different conditions.
HPE built its tests with PyTest and the Strands Agents evaluation software development kit. It created jobs that repeatedly run a broader suite as the agents, models, and prompts change.
The first test category covers basic queries. Each test supplies a single request and evaluates the response. This approach fits stable questions with a clear expected result or defined scoring criteria.
The second category evaluates multi-turn conversations. A user-simulator model interacts with the agent after the initial query, and the complete conversation receives an evaluation. That format tests whether the system requests missing information and maintains context across several exchanges.
The third category generates dynamic tests. The Strands experiment generator creates cases from selected criteria, giving HPE a way to explore scenarios not represented in a fixed test set. Dynamic generation broadens coverage, although generated tests still need meaningful criteria and review.
Each test can apply four evaluators. A response evaluator scores the answer against predefined requirements. A trajectory evaluator examines whether the agent selected appropriate tools and followed an acceptable path.
A latency evaluator checks completion time against a threshold. A token evaluator checks whether usage remains within defined boundaries. Together, those measures reflect the production tradeoff between diagnostic quality, response time, and inference consumption.
Trajectory evaluation is especially important for an operational agent. The final wording might look correct even when the system reached it through an unsafe or unreliable sequence. Testing the path can reveal that an agent skipped live verification, invoked an unrelated API, or relied on documentation when current data was available.
The evaluation suite also supports the multi-model design. HPE can compare a smaller model with a larger one using the same response, trajectory, latency, and token criteria. That makes model replacement an empirical decision rather than a general assumption that a larger model always performs better.
The system streams investigation progress to the interface using Server-Sent Events. SSE is a web mechanism that lets a server continuously send updates to a browser over one connection. Users can see progress while a specialist examines a problem.
HPE says streaming improved the user experience because operators no longer wait without feedback. In disaster recovery, visible progress also helps distinguish a continuing investigation from a frozen interface.
However, streamed activity can create false confidence if it displays steps without explaining their evidentiary value. A list of tool calls is not the same as a verified diagnosis. The interface must present enough progress to build trust without turning internal reasoning into theater.
The same caution applies to HPE's adoption claims. The company reports that more than 20 percent of customers are actively using the system and that applicable support cases fell by 10 percent. Those results suggest genuine product use, but the public post does not define active usage, the measurement window, or the covered workflow population.
A support-case reduction also has several possible explanations. The agent might resolve issues successfully, redirect users toward existing documentation, change how cases are classified, or discourage some escalations. Independent resolution-rate and outcome data would provide a clearer view.
For engineering teams considering a similar design, the lesson is not that four evaluators settle reliability. The lesson is that production agents need measurable behavior at several layers. Answer quality, tool choice, responsiveness, and resource use can fail independently.
A searchable engineering knowledge base follows a related principle. Retrieval becomes more useful when documents remain organized, current, and connected to the work engineers are performing.
Cloud Recovery Platforms Now Face an Interface Question
The competitive pressure is shifting from replication features alone toward who can interpret recovery state and guide an operator during an incident.
HPE Zerto competes in a market that already includes cloud-native recovery services. Amazon Elastic Disaster Recovery replicates supported on-premises and cloud workloads into a staging area within an AWS account. Operators can launch recovery instances for drills or real incidents.
The AWS recovery service emphasizes continuous replication, point-in-time recovery, non-disruptive testing, and failback. It is closely integrated with AWS infrastructure and targets recovery into Amazon EC2.
Microsoft Azure Site Recovery manages replication, failover, and failback for supported virtual machines and physical servers. Its recovery platform covers Azure-to-Azure replication and several on-premises scenarios with Azure as the recovery target.
These services do not map directly onto every Zerto deployment. HPE Zerto supports broader hybrid operating patterns and maintains its own product architecture. The relevant comparison here is not a checklist of replication features.
The new pressure concerns the operational interface above those features. Recovery systems generate alerts, configuration states, replication metrics, and drill results. An agent can potentially translate that information into a guided investigation without requiring every administrator to know where each signal lives.
HPE's early move gives it a chance to establish agent behavior around its proprietary operational context. Its specialists can encode component-specific log patterns and use APIs already associated with the Zerto Manager and replication engines.
Cloud providers possess a different advantage. They control the infrastructure, telemetry, identity services, recovery APIs, and managed AI platforms inside their respective clouds. They can potentially build agents with direct access to a wider collection of native signals.
That creates the primary opponent for HPE Zerto's approach: locally controlled troubleshooting versus cloud-centered operational intelligence. The contest is not simply HPE against AWS or Microsoft because AWS supplies the models behind Zerto's system. It is a contest between architectural locations for control and context.
Local control keeps orchestration close to protected infrastructure and can support environments with strict residency policies. Cloud-centered systems can draw from integrated telemetry and managed services without maintaining an agent runtime inside each customer's appliance.
HPE's architecture combines both routes. The agents and operational tools stay local, while model inference and document retrieval use AWS. This hybrid arrangement tries to keep the most sensitive execution boundary on-premises without abandoning managed foundation models.
The approach also gives HPE deployment responsibilities that a fully managed cloud service can avoid. The local pod must remain compatible with product releases, customer network policies, authentication systems, and restricted outbound connections. Troubleshooting the troubleshooting agent becomes part of the operational burden.
Air-gapped environments present the sharpest limitation. HPE says disaster recovery infrastructure is often air-gapped, latency-sensitive, or subject to data residency requirements. Yet the described system still needs HTTPS access for model inference and knowledge queries.
Strictly disconnected installations therefore cannot use the architecture exactly as described. Other customers may allow narrowly controlled outbound traffic, but security teams will still need to inspect destinations, request contents, identity controls, retention behavior, and failure modes.
Latency also spans two locations. Tool calls against Zerto remain local, while reasoning requests travel to AWS. A complex investigation may require several cycles between model decisions and local tool results. Streaming can make that wait visible, but it cannot eliminate network dependence.
The architecture's strategic value rests on whether this hybrid compromise performs better than the alternatives. If it provides reliable, evidence-based guidance without centralizing raw operational data, it gives enterprise software vendors a reusable pattern. If network constraints or grounding errors dominate, buyers may prefer simpler assistance or fully managed cloud operations.
The Next Test Is Whether Guided Diagnosis Becomes Trusted Operations
Three signals will show whether HPE Zerto agentic troubleshooting is becoming dependable infrastructure rather than an attractive support interface.
The first signal is evidence about resolution quality. Adoption and support-case counts are useful starting points, but they do not show whether users selected safe remedies or resolved incidents faster.
HPE should eventually report outcome measures for supported workflows. Useful signals include successful self-service resolution, escalation after an agent interaction, repeated incidents, administrator acceptance, and errors discovered during review. Comparable measurement periods would make those results more meaningful.
If independently reviewed outcomes show accurate diagnosis across varied customer environments, the case for local agentic operations becomes stronger. If support reductions arrive without reliable resolution data, the published performance story remains incomplete.
The second signal is expansion beyond advisory tasks. HPE lists performing tasks for users as one of the system's goals. The public architecture mainly explains assistance, investigation, health alerts, and mitigation guidance.
Moving from recommendations to actions changes the risk model. A mistaken explanation consumes time, while a mistaken configuration change can affect protection or recovery readiness. Action-taking agents need narrow permissions, approvals, complete audit trails, idempotent operations, and dependable rollback paths.
Any release that lets the system modify configuration should therefore receive close attention. Limited, reversible actions with explicit confirmation would strengthen HPE's architecture. Broad autonomous remediation without published control details would increase uncertainty.
The third signal is how the agent behaves during degraded connectivity and major incidents. An everyday support question offers stable network access and moderate urgency. A ransomware event or infrastructure outage can disrupt the same identity, network, or cloud paths the agent uses.
HPE needs clear behavior when Amazon Bedrock becomes unavailable, a knowledge query times out, a local tool returns stale data, or the orchestrator cannot complete an investigation. Safe degradation should distinguish missing evidence from healthy infrastructure and direct operators toward established recovery procedures.
The company's internal use provides another testing ground. HPE says its engineers use the system to investigate common issues, while its quality assurance team integrates it into testing workflows. Those users can expose failure patterns before customers depend on the same behavior during a crisis.
The architecture already contains several sensible constraints. Specialist agents receive bounded responsibilities. Peer-to-peer recursion is prohibited. The orchestrator controls final output. Local APIs provide current data, while repeated evaluations examine responses and tool trajectories.
None of those controls makes language-model reasoning deterministic. The system still operates across changing software versions, customer topologies, log formats, model releases, and documentation. Continuous evaluation must therefore follow the product after deployment.
For enterprise buyers, the right question is not whether an agent can summarize an alert. It is whether the system shows where its answer came from, respects operational permissions, recognizes missing evidence, and escalates before uncertainty becomes action.
Developers should watch the tool boundary. A well-designed MCP server can make existing APIs usable by agents, but every exposed operation expands the system's authority. Product teams should treat tool design with the same care applied to public APIs and administrative roles.
Knowledge workers can draw a broader lesson from the deployment. AI becomes more useful when it can connect trusted reference material with current work context. That benefit depends on source quality, access boundaries, and a clear distinction between retrieved facts and generated judgment.
HPE Zerto has moved that idea into one of enterprise computing's least forgiving settings. The system joins local orchestration, live disaster recovery data, specialized agents, and managed cloud inference inside one operational path.
Now the evidence must move beyond adoption. Watch whether HPE publishes resolution outcomes, introduces controlled actions, and documents degraded-mode behavior. Those signals will determine whether the HPE Zerto agentic troubleshooting model becomes a pattern other infrastructure vendors should follow.
