Drafting Vendor Agreements for Claude Managed Agents: A GC's Clause Library

Your SaaS MSA Was Not Written for an Autonomous Agent

If you are deploying any autonomous AI agent in production—Claude Managed Agents, a custom-built agent on the Messages API, an OpenAI agent framework, or a self-hosted solution—your vendor agreement needs at minimum three provisions it almost certainly does not have: real-time event stream export rights (FRCP 37(e)), unilateral session termination authority (EU AI Act Article 26(5)), and sub-processor disclosure for the tool chain (GDPR Article 28(2)). This article provides those three plus twelve more, organized as a 15-clause library keyed to the KYA Five Pillars governance framework.

Standard SaaS master service agreements assume a predictable relationship: the customer sends input, the service processes it, the service returns output. The vendor controls the processing logic. The customer controls the data. The contract allocates risk between those two roles.

Claude Managed Agents breaks that model. The agent operates autonomously inside a sandbox Anthropic manages or, now, one the deployer hosts on its own infrastructure—executing shell commands, reading and writing files, searching the web, and connecting to external tools through MCP servers—with session persistence that can span hours and a Memory tool that decides what to store without the deployer’s explicit instruction.¹ The deployer is the controller. Anthropic is the processor. But between them sits an autonomous system that makes operational decisions neither party fully prescribed.

The contract must account for that gap. A standard SaaS MSA does not address who owns the agent’s decision logs, who can terminate a session mid-execution, what happens when the agent connects to a third-party tool the deployer did not approve, or how the deployer complies with a right-to-delete request for data the agent autonomously stored.

This article provides a clause library organized by the KYA Five Pillars—the governance framework that maps each Managed Agents feature to a specific regulatory obligation. Each clause includes the regulatory basis and a plain-language rationale a GC can show to the business side.

Key Takeaways

• Standard SaaS MSAs miss five categories of risk created by autonomous agent behavior: identity attribution, tool-scope creep, decision-log ownership, kill-switch authority, and autonomous data collection.
• The KYA Five Pillars provide the organizing framework—each pillar maps to a contract section, and each clause has a named regulatory anchor.
• Three clauses are non-negotiable before any production deployment: event-stream export rights (KYA-MON), session termination authority (KYA-IR), and sub-processor disclosure for the MCP server chain (KYA-COMP).
• The Memory tool requires its own DPA addendum because the agent—not the deployer—decides what data to store, creating a data-mapping gap that standard processor agreements do not address.
• Every clause in this library pairs regulatory basis with business rationale so the GC can explain to the CTO why the provision matters without invoking legal jargon.

What Must a Managed Agents Vendor Contract Cover That a Standard SaaS MSA Does Not?

A standard SaaS MSA allocates five categories of risk: uptime, data processing, security, intellectual property, and limitation of liability. For Managed Agents deployments, five additional categories emerge from the autonomous agent architecture:

1. Identity attribution—who authorized the agent’s deployment, and how is that authorization documented across sessions?
2. Tool-scope governance—which built-in tools (Bash, file operations, web search/fetch, MCP servers) are enabled, and what change-control process governs additions?
3. Decision-log ownership—who owns the session event stream, who can export it, and what retention obligations apply?
4. Kill-switch authority—who can terminate a running session, how fast, and what SLA governs the vendor’s cooperation?
5. Autonomous data collection—what happens when the agent stores personal data the deployer did not instruct it to collect?

Each of these maps to a KYA pillar. The clause library below addresses all five. The regulatory anchors span three jurisdictions: U.S. federal (FRCP 37(e), SEC Regulation S-P), California (CCPA/CPRA, AB 316), and EU (GDPR Articles 28 and 35, AI Act Articles 26 and 27)—making the framework applicable to any deployer with cross-border operations.

What KYA-ID Clauses Should the Contract Include?

Regulatory basis: The NIST NCCoE concept paper (February 5, 2026) asks industry how to address “identification, authorization, auditing and non-repudiation of AI agents, as well as controls to prevent and mitigate prompt injection techniques.”² Van Loon v. Department of the Treasury, 122 F.4th 549 (5th Cir. 2024), draws the line between sanctionable and non-sanctionable code: immutable smart contracts are not “property” under IEEPA, but “the rogue persons and entities who abuse it” remain squarely within OFAC’s reach.³ OFAC civil-penalty liability operates on a strict-liability standard under IEEPA, 50 U.S.C. § 1705, and 31 CFR Part 501—intent affects penalty severity, not whether liability attaches.⁴

Business rationale: When regulators or litigants ask who authorized the agent, the contract is the first document subpoenaed. Van Loon separates immutable code (not OFAC-sanctionable) from the deployers and operators behind mutable agents (squarely within OFAC’s reach), and IEEPA’s civil-penalty regime imposes liability regardless of intent.⁴ The authorization chain must be traceable from the API key to a named human. If it is not, the deployer bears the consequence.

Clause 1—Deployment Authorization Register. Customer shall maintain a written register of each Agent configuration deployed in production, identifying (a) the named individual who authorized the deployment, (b) the date of authorization, (c) the business justification, and (d) the tools enabled. Vendor shall provide API-level metadata sufficient for Customer to populate and maintain this register.

Clause 2—Session Attribution. Each Session created under this Agreement shall be attributable to a specific Agent configuration in the Deployment Authorization Register. Vendor shall ensure that Session metadata includes the Agent ID, environment ID, and creation timestamp in a format Customer can export and retain independently.

If your contract does not establish a traceable authorization chain from the API key to a named human, you have no answer for the regulator who asks “who deployed this agent?”

What KYA-AUTH Clauses Govern Tool Scoping?

Regulatory basis: The OWASP Top 10 for Large Language Model Applications, item LLM06:2025 (Excessive Agency), counsels that AI agents “be granted only the minimum permissions and access necessary to limit the scope of undesirable actions”—an application of the least-privilege principle. The related principle of least agency, drawn from OWASP’s agentic-security work, counsels granting an agent only the autonomy its task actually requires.⁵ California AB 316, effective January 1, 2026, codifies the consequence: no defendant may assert that “AI autonomously caused the harm” as a defense to liability.⁶ The $460 million Knight Capital loss and $920.2 million JPMorgan spoofing penalty demonstrate what happens when algorithmic systems operate with insufficient authority boundaries.

Business rationale: Every tool enabled on the agent expands the deployer’s liability surface. The contract must prevent unilateral tool additions by the vendor and give the deployer a change-control veto.

Clause 3—Tool Enablement Baseline. The tools enabled for Customer’s Agent configurations are limited to those specified in Exhibit A (the “Tool Baseline”). Vendor shall not enable additional built-in tools, MCP server connections, or capabilities for Customer’s Agent configurations without Customer’s prior written approval.

Clause 4—Change Control for Tool Additions. Any modification to the Tool Baseline—including new built-in tools, new MCP server integrations, or changes to existing tool permissions—requires (a) written notice to Customer at least 30 days before the change takes effect, (b) Customer’s written approval, and (c) an updated Exhibit A reflecting the approved change. Customer may reject any proposed change without cause.

Clause 5—MCP Server Transparency. Vendor shall disclose, in Exhibit B, the complete list of MCP servers available for connection within Customer’s environment, including the provider name, data flows, and jurisdictions involved. Customer’s Agent configurations shall not connect to any MCP server not listed in Exhibit B without Customer’s prior written approval.

Every tool you did not approve is a tool you cannot defend. The contract must give you a veto, not just a notification.

What KYA-MON Clauses Cover Decision Logging?

Regulatory basis: FRCP 37(e) governs the loss of electronically stored information “that should have been preserved in the anticipation or conduct of litigation … because a party failed to take reasonable steps to preserve it.” Where that loss causes prejudice, Rule 37(e)(1) permits measures “no greater than necessary to cure the prejudice.” The more severe remedies—an adverse-inference instruction, or a direction that the jury “may or must presume the information was unfavorable to the party”—are available under Rule 37(e)(2) only on a finding that the party “acted with the intent to deprive another party of the information’s use in the litigation.”⁷ Zubulake v. UBS Warburg LLC, 229 F.R.D. 422 (S.D.N.Y. 2004), established that the preservation duty attaches when litigation is “reasonably anticipated”—not when it is filed.⁸

Business rationale: Session event streams are the agent’s decision chain. A deployer who cannot produce them risks the curative and adverse-inference sanctions that courts impose for spoliation of electronically stored information—the severest of which, under Rule 37(e)(2), turn on a finding of intent to deprive an opponent of the evidence. The deployer must own the logs, not just access them.

Clause 6—Real-Time Event Stream Export. Vendor shall provide Customer with a real-time, machine-readable export of the complete server-sent events (SSE) stream for every Session, including all tool calls, tool results, agent reasoning, and status changes. The export shall be available via API without additional cost.

Clause 7—Retention Independence. Customer’s exported event stream data is Customer’s property. Vendor’s retention or deletion of session data on Vendor’s infrastructure shall not affect Customer’s independently retained copies. Vendor shall not delete session data from Vendor’s infrastructure before the earlier of (a) Customer’s written instruction or (b) 90 days after session termination, unless a longer period is specified in Exhibit C.

Clause 8—Litigation Hold Cooperation. Upon Customer’s written notice of a litigation hold, Vendor shall preserve all session data, event streams, and associated metadata for the Sessions identified in the notice. Vendor shall not delete, modify, or overwrite preserved data during the hold period. Vendor shall respond to preservation requests within 48 hours of receipt.

If the only copy of your agent’s decision history lives on the vendor’s infrastructure, you do not have a litigation-ready record. You have a dependency you cannot enforce.

What KYA-IR Clauses Address Kill-Switch Authority?

Regulatory basis: EU AI Act Article 26(5) (deployer obligation to “suspend the use” of high-risk AI systems when use presents a risk);⁹ In re Caremark International Inc. Derivative Litigation, 698 A.2d 959 (Del. Ch. 1996) (board duty to assure that a reasonable information and reporting system exists), as refined in Marchand v. Barnhill, 212 A.3d 805 (Del. 2019) (good-faith duty to oversee the corporation’s central compliance risks).¹⁰

Business rationale: The ability to terminate a running agent is not a feature request. It is a regulatory requirement for high-risk deployments and a board-level governance obligation under Caremark. The contract must guarantee the deployer can kill a session unilaterally, immediately, and without vendor approval.

Clause 9—Unilateral Session Termination. Customer may terminate any Session at any time, for any reason, without Vendor’s prior approval, by issuing a termination event through the API. Vendor shall process the termination within 5 seconds of receipt and confirm completion via the SSE stream.

Clause 10—Incident Notification. If Vendor detects anomalous behavior in any of Customer’s Sessions—including unauthorized tool calls, unexpected data access patterns, or resource consumption exceeding 200% of baseline—Vendor shall notify Customer within 1 hour of detection via the contact method specified in Exhibit D. Vendor shall provide sufficient detail for Customer to assess whether session termination is warranted.

Clause 11—Service Credit Escalator for Incident Response Failures. If Vendor fails to process a session termination request within the 5-second SLA specified in Clause 9, Customer shall receive a service credit equal to 10x the session runtime charges accrued between the termination request and actual termination. If Vendor fails to provide incident notification within the 1-hour SLA specified in Clause 10, Customer shall receive a service credit equal to 5x the session runtime charges for the affected Session.

The governance question is not whether you can stop the agent. It is whether the contract guarantees how fast.

What KYA-COMP Clauses Handle Data Processing and Regulatory Cooperation?

Regulatory basis: GDPR Article 28 (processor contract requirements, including sub-processor prior written authorization);¹¹ CCPA service provider contract requirements;¹² EU AI Act Article 27 (Fundamental Rights Impact Assessment);¹³ GDPR Article 35 (Data Protection Impact Assessment).¹⁴

Business rationale: The Memory tool is client-side—the deployer controls where the data is stored.¹⁵ But the agent decides what to write, creating a data-mapping gap that standard DPAs do not address. The contract must cover the full processing chain, including sub-processors the deployer has never heard of.

Clause 12—Memory Tool DPA Addendum. The parties shall execute a Data Processing Addendum specific to the Memory tool (the “Memory DPA”) that addresses: (a) the deployer’s obligation to instrument the write pipeline for user-identity tagging; (b) the vendor’s obligation to provide documentation sufficient for the deployer to implement the tagging infrastructure; (c) retention and deletion obligations keyed to user identity rather than session identity; and (d) the vendor’s cooperation with DSARs that require searching agent-generated memory files.

Clause 13—Sub-Processor Disclosure. GDPR Article 28(2) is explicit: “The processor shall not engage another processor without prior specific or general written authorisation of the controller.”¹¹ Vendor shall disclose, in Exhibit E, the complete chain of sub-processors involved in operating Customer’s Managed Agents sessions, including container infrastructure providers, model inference infrastructure, MCP server operators, and any third-party services accessed during session execution. In the case of general written authorization, Vendor shall provide 30 days’ prior written notice before engaging a new sub-processor, “thereby giving the controller the opportunity to object to such changes.”¹¹ Vendor shall not proceed if Customer objects within the notice period.

Clause 14—FRIA/DPIA Cooperation. Where Customer is required to conduct a Fundamental Rights Impact Assessment under EU AI Act Article 27 or a Data Protection Impact Assessment under GDPR Article 35, Vendor shall provide, within 30 days of Customer’s written request: (a) technical documentation describing the processing operations performed during Sessions; (b) a description of the data flows between Session components; (c) the results of any security assessments performed on the container environment; and (d) access to Vendor personnel with sufficient technical knowledge to answer Customer’s assessment questions.

Clause 15—Regulatory Change Support. If a change in applicable law materially affects Customer’s compliance obligations for Managed Agents deployments, Vendor shall provide reasonable cooperation—including updated documentation, modified APIs, or adjusted processing configurations—within 90 days of Customer’s written request describing the regulatory change and the required accommodation.

Your standard DPA was not written for a system where the processor’s AI decides what data to store. Update it before the first DSAR arrives.

Which Clauses Are Non-Negotiable?

Not every clause in this library carries equal weight. Three are deal-breakers—provisions a GC should not sign without, regardless of vendor pushback:

If the vendor will not agree to these three provisions, the deployer cannot satisfy the regulatory obligations that attach to production use. For the full doctrinal basis explaining why seven existing legal doctrines hold AI deployers directly liable, see the foundational article in this series.

What Does the Complete Claude Managed Agents Clause Library Look Like?

The fifteen clauses, each with its pillar, its regulatory anchor, and what it protects:

How Should a GC Approach This Negotiation?

The vendor agreement is the deployer’s first governance document—the one regulators, litigants, and the board will read before anything else. Three principles should guide the negotiation:

Lead with the regulatory basis, not the legal department’s preferences. A vendor who pushes back on event-stream export rights is pushing back on FRCP 37(e). A vendor who resists kill-switch SLAs is resisting EU AI Act Article 26(5)—which requires deployers to “suspend the use” of high-risk AI systems “without undue delay” when risks emerge.⁹ Frame each clause in terms of the regulation it satisfies, not the legal department’s risk appetite. The business side and the vendor understand regulatory requirements; they resist provisions that sound like legal overreach.

Negotiate the exhibits, not just the body. The Tool Baseline (Exhibit A), MCP Server List (Exhibit B), Retention Schedule (Exhibit C), Incident Contact Method (Exhibit D), and Sub-Processor Chain (Exhibit E) are where the operational detail lives. A well-drafted body with empty exhibits is a framework without governance.

Track the EU AI Act high-risk timeline. The deployer obligations for standalone (Annex III) high-risk systems—including the Article 26 and Article 27 duties the KYA-COMP clauses are built around—were originally scheduled to apply on August 2, 2026. Under the Digital Omnibus on AI, Regulation (EU) 2026/1744, signed July 8, 2026 and in force since July 27, 2026, those standalone Annex III obligations apply from December 2, 2027, and the Annex I obligations from August 2, 2028. The August 2, 2026 date was not vacated entirely: the Article 50 transparency obligations took effect on schedule, with a marking grace period to December 2, 2026 for generative systems already on the market. Build the contract to the substantive Article 26/27 standard now; the deferral moves the date, not the work.⁹

Contract Readiness Score

Before your next vendor negotiation, score your current Managed Agents agreement against this library. One point for each clause your contract substantively addresses:

The clause numbers in this library are designed to serve as a checklist. Print the complete map table above, mark which clauses your contract covers, and bring the gaps to the negotiation.

Frequently Asked Questions

What contract terms do I need for Claude Managed Agents? At minimum, your agreement needs real-time event stream export rights (Clause 6), unilateral session termination authority with a 5-second SLA (Clause 9), and sub-processor disclosure covering the full MCP server chain (Clause 13). The complete library contains 15 clauses organized by the KYA Five Pillars: Identity (2 clauses), Authority (3 clauses), Monitoring (3 clauses), Incident Response (3 clauses), and Compliance (4 clauses).

Do I need a separate DPA for the Memory tool? Yes. The Memory tool is client-side—you control storage—but the agent decides what to write. Standard DPAs reference “the personal data processed under this agreement,” which does not cover data the AI autonomously stored. Clause 12 provides the Memory DPA framework, including user-identity tagging, retention keyed to user identity, and DSAR cooperation.

Does my AI agent vendor contract need kill-switch provisions? EU AI Act Article 26(5) requires deployers to “suspend the use” of a high-risk AI system where its use presents a risk. The standalone Annex III high-risk deployer obligations, originally set for August 2, 2026, apply from December 2, 2027 under the Digital Omnibus on AI, Regulation (EU) 2026/1744, in force since July 27, 2026. Clause 9 guarantees unilateral termination within 5 seconds. Clause 11 attaches service credit penalties if the vendor fails the SLA. Without these provisions, the deployer cannot satisfy Article 26(5).

What is the KYA Five Pillars framework for AI agent governance? KYA (Know Your Agent) is a five-pillar governance framework for AI agent deployment developed by Chante Eliaszadeh, a former SEC Honors Program intern in the SEC’s Cyber Unit, at Astraea Counsel APC. The five pillars—Identity (KYA-ID), Authority (KYA-AUTH), Monitoring (KYA-MON), Incident Response (KYA-IR), and Compliance (KYA-COMP)—each map to a specific regulatory obligation under U.S. federal law, California privacy law, and the EU AI Act, and to a corresponding set of vendor contract clauses.

How do I know if my current AI agent vendor agreement is adequate? Use the Contract Readiness Score: score one point for each of the 15 clauses in the KYA clause library that your agreement substantively covers. A score of 12-15 indicates production readiness. A score of 8-11 means gaps in one or two KYA pillars requiring targeted amendment. A score below 8 indicates material governance gaps across multiple pillars—the agreement should be renegotiated before production deployment of any autonomous AI agent.

---

Disclaimer: This article provides general information for educational purposes only and does not constitute legal advice. The clause language presented is illustrative and must be adapted to your specific business context, jurisdiction, and regulatory obligations. Consult qualified legal counsel before incorporating these provisions into a binding agreement.

---

Footnotes

1. Anthropic, “Claude Managed Agents overview,” Claude Platform Documentation, https://platform.claude.com/docs/en/managed-agents/overview (accessed April 10, 2026; re-read September 4, 2026, when the page described the product as still in beta and an environment as “an Anthropic-managed cloud sandbox, or a self-hosted sandbox on your own infrastructure”). For the Memory tool’s autonomous data storage problem, see Chante Eliaszadeh, “You Cannot Delete What You Do Not Know the Agent Stored,” Astraea Counsel (April 21, 2026). ↩

2. National Institute of Standards and Technology, National Cybersecurity Center of Excellence, “Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization” (concept paper, February 5, 2026), https://csrc.nist.gov/pubs/other/2026/02/05/accelerating-the-adoption-of-software-and-ai-agent/ipd. ↩

3. Van Loon v. Department of the Treasury, 122 F.4th 549 (5th Cir. 2024) (holding Tornado Cash’s immutable smart contracts are not “property” under IEEPA, and OFAC overstepped its statutory authority by sanctioning them; the opinion distinguishes “open-source, self-executing software” from “the rogue persons and entities who abuse it,” leaving the latter squarely within OFAC’s reach). ↩

4. 50 U.S.C. § 1705 (IEEPA civil-penalty provision); 31 CFR Part 501 (OFAC regulations and economic sanctions enforcement guidelines). OFAC operates a strict-liability standard for civil penalties—a person subject to U.S. jurisdiction may be held liable for sanctions violations regardless of whether the person knew or had reason to know the conduct violated U.S. sanctions laws; the level of culpability affects the penalty amount but not the threshold determination of liability. ↩ ↩²

5. OWASP Foundation, “OWASP Top 10 for Large Language Model Applications,” item LLM06:2025 (Excessive Agency), https://genai.owasp.org/llmrisk/llm062025-excessive-agency/. The Excessive Agency entry counsels granting AI agents and LLM extensions only the minimum permissions and access necessary to limit the scope of undesirable actions (an application of least privilege). The distinct principle of least agency—minimizing an agent’s autonomy—is stated in OWASP GenAI Security Project, “OWASP Top 10 for Agentic Applications 2026” (Version 2026, Dec. 2025), https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ (accessed Sept. 4, 2026), at 6: “We expand on the concepts of Least-Privilege and Excessive Agency by citing Least-Agency”; “deploying agentic behavior where it is not needed expands the attack surface without adding value.” ↩

6. California AB 316 (Stats. 2025, ch. 672), codified at Cal. Civ. Code § 1714.46, effective January 1, 2026, providing that a defendant who developed, modified, or used artificial intelligence may not assert as a defense that the AI autonomously caused the harm. The statute does not create strict liability and does not displace other defenses such as causation and foreseeability. ↩

7. Fed. R. Civ. P. 37(e). Rule 37(e)(1) permits, on a finding of prejudice from lost electronically stored information, measures no greater than necessary to cure the prejudice; Rule 37(e)(2) permits an adverse-inference instruction, dismissal, or default judgment only on a finding that the party “acted with the intent to deprive another party of the information’s use in the litigation.” ↩

8. Zubulake v. UBS Warburg LLC, 229 F.R.D. 422, 431-32 (S.D.N.Y. 2004) (establishing duty to preserve ESI when litigation is reasonably anticipated). ↩

9. Regulation (EU) 2024/1689 (EU Artificial Intelligence Act), Article 26(5). Deployers shall “suspend the use” of a high-risk AI system and inform the provider and market surveillance authorities “without undue delay” where its use presents a risk within the meaning of Article 79(1). As amended by Regulation (EU) 2026/1744 of the European Parliament and of the Council of 8 July 2026 (Digital Omnibus on AI), OJ L, 2026/1744, 24.7.2026, http://data.europa.eu/eli/reg/2026/1744/oj, Article 113, third paragraph, point (c) provides that Chapter III, Sections 1, 2 and 3 “shall apply from: (i) 2 December 2027 as regards AI systems classified as high-risk pursuant to Article 6(2) and Annex III; and (ii) 2 August 2028 as regards AI systems classified as high-risk pursuant to Article 6(1) and Annex I.” Article 50 transparency obligations applied from August 2, 2026; the new Article 111(4) gives providers of generative systems placed on the market before that date until December 2, 2026 to comply with Article 50(2). ↩ ↩² ↩³

10. In re Caremark International Inc. Derivative Litigation, 698 A.2d 959 (Del. Ch. 1996) (duty to assure that a reasonable information and reporting system exists); Marchand v. Barnhill, 212 A.3d 805 (Del. 2019) (directors must make a good-faith effort to implement and monitor a system to oversee the corporation’s central compliance risks). ↩

11. Regulation (EU) 2016/679 (GDPR), Article 28(2): “The processor shall not engage another processor without prior specific or general written authorisation of the controller. In the case of general written authorisation, the processor shall inform the controller of any intended changes concerning the addition or replacement of other processors, thereby giving the controller the opportunity to object to such changes.” Article 28(4): same data protection obligations imposed on sub-processors by contract. ↩ ↩² ↩³

12. California Privacy Protection Agency regulations require service provider contracts to restrict retention, use, and disclosure of personal information and to flow obligations to sub-contractors. See Cal. Civ. Code Section 1798.100(d). ↩

13. Regulation (EU) 2024/1689 (EU Artificial Intelligence Act), Article 27 (Fundamental Rights Impact Assessment for certain deployers of high-risk AI systems, including public bodies and certain Annex III deployers). Originally scheduled for August 2, 2026; applies from December 2, 2027 for Annex III systems under Regulation (EU) 2026/1744 (Digital Omnibus on AI), which also replaces Article 27(4) so that a deployer may, when conducting the FRIA, “include cross-references to the relevant sections of that data protection impact assessment or include relevant parts thereof in the fundamental rights impact assessment.” ↩

14. Regulation (EU) 2016/679 (GDPR), Article 35 (Data Protection Impact Assessment required for processing likely to result in high risk to rights and freedoms of natural persons). ↩

15. Anthropic, “Memory tool,” Claude Platform Documentation, https://platform.claude.com/docs/en/agents-and-tools/tool-use/memory-tool. “The memory tool operates client-side: you control where and how the data is stored through your own infrastructure.” ↩