Multi-Agent Copilot for Data Protection and Cyber Resilience

druva · Tech · 2025 · source Agentic: yes · promotional bias: med · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: Enterprise data protection and cyber resilience

Druva needed a conversational copilot that could simplify backup troubleshooting, policy management, and operational support across complex enterprise data-protection environments.

Constraints:

Enterprise customers manage high volumes of backup, policy, and security data across distributed systems.
Read-only data retrieval and write actions have different risk profiles.
The copilot needed to select among many backend APIs without brittle manual routing.
Sensitive policy modifications and backup actions required human approval.

Architecture

Druva and AWS built a Bedrock-based multi-agent copilot with a supervisor agent coordinating data, help, and action agents. The data and action agents use semantic search over API documentation in Bedrock Knowledge Bases to select relevant APIs, while the help agent retrieves best-practice and troubleshooting guidance. Human-in-the-loop nodes gate sensitive operations such as policy changes or backup initiation.

Diagram confidence: reconstructed (reconstructed from prose).

flowchart LR
  supervisor-agent["Supervisor Agent"] --> data-agent["Data Agent"]
  supervisor-agent --> help-agent["Help Agent"]
  supervisor-agent --> action-agent["Action Agent"]
  data-agent --> api-knowledge-base["API Knowledge Base"]
  action-agent --> api-knowledge-base
  help-agent --> documentation-knowledge-base["Documentation Knowledge Base"]
  action-agent --> user-approval-node["User Approval Node"]

Drag to pan · scroll or use +/− to zoom · reconstructed from the source's described component topology

Components

Component	Role	Interacts with
`Supervisor Agent`	Coordinates conversation flow and delegates to specialized sub-agents.	`Data Agent`, `Help Agent`, `Action Agent`
`Data Agent`	Retrieves backup jobs, backup status, and other read-only operational details through GET APIs.	`API Knowledge Base`
`Help Agent`	Answers troubleshooting and best-practice questions from documentation and FAQs.	`Documentation Knowledge Base`
`Action Agent`	Handles sensitive write operations such as initiating backup jobs or modifying policies.	`API Knowledge Base`, `User Approval Node`
`API Knowledge Base`	Stores API documentation for semantic retrieval and dynamic API selection.	`Data Agent`, `Action Agent`
`Documentation Knowledge Base`	Stores user manuals, FAQs, and best-practice content for RAG guidance.	`Help Agent`
`User Approval Node`	Collects user feedback or approval before sensitive actions.	`Action Agent`

Data flow

A user asks an operational question such as why backups failed. The supervisor agent routes the query to a data, help, or action agent. Data/action agents retrieve top relevant APIs from Bedrock Knowledge Bases, ask an LLM to finalize API selection and parameters, and either fetch status, provide guidance, or request approval before executing write actions.

“At the center of the architecture is a supervisor agent that serves as the central coordination component, responsible for overseeing conversation flow”summary, stated

“when an input query is received, the system performs semantic search to retrieve the top K relevant APIs from the knowledge base.”summary, stated

Why this architecture

The supervisor-and-specialist architecture separates read, help, and write actions so higher-risk operations can be governed differently. Dynamic API selection combines semantic retrieval with LLM reasoning, narrowing the API search space before invoking the model to choose parameters.

“The separation of this agent from the data agent reflects sound production practices around safety and control, as write operations carry higher risk than read operations.”summary, stated

“This two-stage approach—semantic retrieval followed by LLM-based reasoning—balances efficiency with accuracy”summary, stated

Models used: Anthropic Claude · Amazon Nova · Amazon Bedrock models

Scale

The motivating example covered more than 500 servers across multiple regions.
“a global financial services company managing over 500 servers across multiple regions currently spends hours manually checking logs when backups fail.”summary, stated
Early API-selection evaluation showed 88-93% accuracy depending on model.
“Initial evaluation results showed 88-93% accuracy in API selection depending on the model used”summary, stated
Expert evaluators scored end-to-end testing at 3.3 out of 5 during early development.
“with end-to-end testing achieving 3.3 out of 5 scores from expert evaluators during early development phases.”summary, stated
The target outcome was reducing investigations from hours to minutes.
“The implementation promises to reduce investigation time from hours to minutes and enables 90% of routine data protection tasks through conversational interactions.”summary, stated

Alternatives considered (roads not taken)

Hardcode API routing logic

Rejected because: The API surface is complex enough that semantic retrieval plus LLM reasoning was more flexible.

“rather than hardcoding API routing logic, the system embeds API knowledge in a retrievable format and uses LLM reasoning”summary, stated

Use a single agent for read and write operations

Rejected because: Write actions have higher safety risk, so Druva separated the action agent from the data agent.

“The separation of this agent from the data agent reflects sound production practices around safety and control”summary, stated

Fully automate sensitive operations

Rejected because: The architecture includes user feedback and approval nodes before critical changes.

“The architecture incorporates explicit human-in-the-loop controls, particularly for critical actions.”summary, stated

Patterns

`multi-agent-orchestration` (architecture)

A supervisor agent delegates to data, help, and action agents with different operational responsibilities.

“a sophisticated multi-agent architecture consisting of a supervisor agent coordinating specialized data, help, and action agents.”summary, stated

`rag-retrieval` (knowledge)

The help agent uses Bedrock Knowledge Bases over documentation, manuals, and FAQs.

“The help agent provides guidance on best practices, step-by-step instructions, and troubleshooting tips by drawing upon an extensive knowledge base”summary, stated

`tool-use-orchestration` (execution)

Data and action agents dynamically select APIs and parameters to fetch or modify operational state.

“Once candidate APIs are identified, the agent prompts the LLM to parse these candidates and finalize API selection along with the required parameters.”summary, stated

`human-in-the-loop-gate` (safety)

Sensitive action paths include approval before modifying policies or initiating backups.

“users can provide additional information or explicit approvals before the copilot performs sensitive operations like modifying policies”summary, stated

Tradeoffs

Use semantic retrieval before LLM API selection

Chose Top-K API retrieval followed by LLM reasoning over Letting the LLM search the entire API space directly.

Rationale: The retrieval step narrows the candidate space and balances efficiency with accuracy.

“This two-stage approach—semantic retrieval followed by LLM-based reasoning—balances efficiency with accuracy”summary, stated

Separate action and data agents

Chose Dedicated action agent for POST operations over One tool agent for all API calls.

Rationale: Write operations require stronger controls than read-only retrieval.

“write operations carry higher risk than read operations.”summary, stated

Gotchas (what bit them)

Dynamic API selection is a production bottleneck for copilot systems.

Root cause: Enterprise products expose many backend APIs, so the agent must choose the right API and parameters for each query.

Resolution: Druva used semantic search over API documentation before LLM-based candidate parsing.

“A particularly sophisticated aspect of the implementation is the dynamic API selection process, which represents a critical production challenge”summary, stated

Read and write operations need different safety treatment.

Root cause: Policy changes or backup initiation can affect enterprise data-protection posture.

Resolution: The system separates data and action agents and gates sensitive operations through user approval.

“The action agent handles critical operations by interacting with POST API endpoints to execute actions like initiating backup jobs or modifying data protection policies.”summary, stated

Evaluation

The case reports API-selection accuracy by model and expert scoring for early end-to-end tests.

Metrics: 88-93% API-selection accuracy · 3.3 out of 5 expert evaluator score · target of 90% routine task enablement

“Initial evaluation results showed 88-93% accuracy in API selection depending on the model used, with end-to-end testing achieving 3.3 out of 5 scores”summary, stated

Outcomes

Druva built a multi-agent copilot for backup troubleshooting, policy support, and operational guidance.
The system promised to reduce investigations from hours to minutes.
Early evaluation showed useful but still-imperfect API selection and end-to-end results.

The motivating scenario involved more than 500 servers across multiple regions and early accuracy scores of 88-93%.

“The implementation promises to reduce investigation time from hours to minutes and enables 90% of routine data protection tasks through conversational interactions.”summary, stated