# Cohesity tells LDS what an AI agent rollback cannot undo > Source: > Published: 2026-09-29 18:14:59+00:00 # Cohesity tells LDS what an AI agent rollback cannot undo Restoring an AI agent's memory cannot recall an email it has already sent. In written answers to LDS, Cohesity's Swami Ramany and Anu Paul Parayil explain which agent components can be recovered, why an immutable backup is not proof of a clean state, and how teams should test a return to service. Their answers also distinguish an intended recovery-time advantage from a measured benchmark. An AI agent can be restored to an earlier state while the consequences of its actions remain in place. An email may already have left the organization. Information may already have been disclosed. An external system may still contain a change that needs a separate correction. That boundary is central to Cohesity's written interview with Let's Data Science about Agent Resilience. Swami Ramany, GVP of Product Management, and Anu Paul Parayil, Senior Product Marketing Manager, describe recovery as a process involving protected agent state, connected resources and human decisions about when it is safe to resume work. The useful question for teams building agents is therefore more specific than whether a backup exists: what can be restored, what must be checked, and what remains to be repaired elsewhere? ### A map of dependencies is not a promise of recovery Cohesity announced Agent Resilience on September 16. Its public announcement describes initial availability for select customers using Amazon Bedrock AgentCore and Amazon Bedrock Agents, with general availability targeted for the end of 2026. That is a planned expansion, not a claim that every customer can use every capability today. In his answers to LDS, Ramany distinguishes discovering an agent's dependencies from protecting them. A topology map shows how the agent connects to memory stores, applications, databases and infrastructure. Being visible on that map does not mean a resource has been backed up or can be restored. The product provides immutable, point-in-time recovery points for supported agent components. Immutable means the captured recovery point cannot subsequently be altered. Agent memory, in this context, is stored information the agent uses across tasks; configuration determines aspects of how it operates. Connected resources have their own requirements. Ramany says an S3 bucket or database must already be supported by Cohesity and enrolled in protection before the customer can recover it through the applicable Cohesity workflow. Teams need to check the supported components and protection settings for their particular deployment, rather than assume that mapping an agent protects its entire environment. Support for Google Gemini Enterprise and Microsoft Foundry is on the roadmap, according to his response. ### From a suspicious memory change to a controlled restart Parayil illustrates the process with a procurement agent on Amazon Bedrock. It remembers approved suppliers and purchasing policies and has access to a knowledge base and supporting storage. This is an example supplied to explain the workflow, not a documented customer incident or a recovery test observed by LDS. The response team reviews the dependency map and connects an alert with a recent memory change. It then identifies the likely period of compromise. The application owner suspends the agent and restricts its access to downstream tools before the team restores the affected memory and configuration. Protected resources may need attention as well. If an S3 bucket or RDS database is supported and protected by Cohesity, the team can restore it to an earlier trusted point where appropriate. A resource outside that protection requires another recovery or remediation process. The separation between detection and recovery matters. Parayil writes: "Security and observability tools identify the issue; Agent Resilience provides the recovery path." Before restarting, the team runs known validation prompts, checks expected behavior and permissions, and looks for unintended changes. In her example, both the application owner and the security lead approve the return to production. A completed restore is one step in that decision, not the decision itself. ### An immutable recovery point can preserve a bad state A backup can faithfully preserve the wrong information. If an agent's memory had already been poisoned when the recovery point was captured, preventing later changes to that backup does not remove the earlier contamination. Ramany makes the distinction explicit: "Immutability prevents a recovery point from being altered after capture. It does not prove that the captured state was clean." Establishing the likely compromise window remains the customer's responsibility. Ramany identifies security alerts, agent and application logs, configuration history, memory changes and transactions in connected systems as useful evidence. When the starting time is uncertain, he recommends testing an older recovery point and accounting for legitimate context lost by going further back. Validation then combines several checks: scanning affected data with security tools, comparing memory and configuration against expected baselines, running a fixed set of tasks, and confirming current permissions. Cohesity supplies recovery points and visibility; the customer's application and security teams decide whether the restored version is safe. For agent recovery, Ramany describes an isolated clean-room validation environment as part of the broader roadmap. Teams should confirm its availability for their deployment rather than assume it is included in the initial release. ### Restoring memory does not retract a completed action Rolling back stored context does not automatically undo what the agent has already done. Ramany says an email remains sent and disclosed information remains disclosed. Some actions in external systems need separate reversal or remediation. "That is the practical boundary: restoring the state does not erase an action's real-world consequences." His answer assigns responsibility for idempotency and compensating actions to the application and external systems. In practical terms, idempotency helps prevent a retried operation from producing a duplicate effect. A compensating action is a separate step intended to correct an earlier one where correction is possible. The implication for a recovery plan is that teams need to reconcile external effects as well as restore agent state. They must know which operations completed and what should happen if the restored agent attempts them again. Recovery points can support that investigation, but they do not replace the application's business rules or undo an irreversible disclosure. ### The recovery-time claim is not a published benchmark LDS asked what evidence supported the claim of reducing recovery from hours to minutes. Parayil explains it as the intended advantage over manually reconstructing memory and configuration, rather than a published benchmark. The proposed benefit is understandable: restoring protected state could replace work otherwise performed through scripts, exports, logs and application-specific tools. The answers do not supply measured recovery times, comparative trials or a success rate that establishes how much faster that process will be for a particular team. That distinction also changes what to measure. A useful evaluation should include identifying a suitable recovery point, reconciling affected resources and checking the restored agent before approving its return. Timing only the restore operation would leave out important parts of the workflow described in the interview. ### A small recovery drill with clear pass conditions Parayil proposes a non-production exercise using a Bedrock agent connected to a test database or document store. Teams would need the relevant product access and protection configured; this is a proposed drill, not a claim that LDS ran the product. Start with audit logging, a recovery point, and a small set of known-good prompts with expected outcomes. Introduce a harmless memory or configuration change and allow a traceable update to test data. Then detect the issue, suspend the agent, restore the earlier state and reconcile the affected data separately. Her pass conditions give teams a concrete checklist: - •The restored version matches the selected recovery point. - •Expected behavior returns and no unexpected tool calls occur. - •The affected test data is correct after reconciliation. - •Current permissions are verified, and access revoked before recovery stays revoked. For agent builders, this is the most practical lesson in the interview: prove that the agent can resume work safely, including its interactions with other systems. Successfully loading an older memory is necessary for that workflow, but it does not settle everything that happened after the snapshot. ### Reporting note This LDS Exclusive is based on six original written answers supplied on September 29, 2026 and attributed individually to Swami Ramany and Anu Paul Parayil. Cohesity's official announcement and product material provide background. LDS has not independently tested Agent Resilience; the procurement scenario and recovery drill are illustrative, and no measured recovery-time benchmark was supplied. ## Key Points - 1Discovering an agent dependency does not mean it is protected: connected resources must be supported and enrolled before they can be restored through Cohesity. - 2An immutable recovery point is not proof of a clean state. Teams must investigate the compromise window, validate behavior and check current permissions. - 3Rollback cannot recall sent emails or undo disclosed information. External effects need separate reconciliation, and no measured recovery-time benchmark was supplied. ## Scoring Rationale A named original interview clarifies agent-recovery boundaries, protection prerequisites and a practical validation drill. The report distinguishes immutable backups from clean state and restoration from reversing external actions. No independent performance benchmark is established. ## Sources Original reporting, with the public references used alongside it. LDS Exclusive Reporting based on written answers given directly to Let's Data Science by **Swami Ramany, GVP of Product Management, and Anu Paul Parayil, Senior Product Marketing Manager, Cohesity**. Practice interview problems based on real data 1,625 SQL & Python problems across 15 industry datasets — the exact type of data you work with. [Try 250 free problems](https://letsdatascience.com/problems)