The memory an agent keeps is where the value compounds
Inspect what survives a runtime change: evidence, reviewed lessons, evaluation records, and the rights to use them.

Agent-memory ownership depends on access, data-use terms, retention, and usable exports. Hosted memory does not automatically belong to the provider, and local storage does not remove every dependency. Separate company evidence and reviewed lessons from model weights and runtime licenses. Nodes' complete automated company-learning loop remains product direction.
Company-specific memory can preserve what an agent tried, what a person corrected, and which outcome followed. That makes memory a useful enterprise asset alongside the models that use it. Anthropic's Dreaming work is a relevant example of investment in this layer. Its existence does not prove automatic improvement on every business task, and hosting location alone does not settle who owns the resulting record.
What the managed runtime provides
Claude Managed Agents supplies a configurable harness, persistent sessions, tools, and scheduled work. It is in beta; Dreaming has a more limited research-preview status. These are substantial components for an internal build. Evaluate their permitted data use and operating constraints in the current documentation.
The buying question is practical: can the customer retain and use the memory it needs when the runtime changes? A hosted store can expose usable exports; an internal store can be trapped behind undocumented schemas. Neither should be assumed. Ask for an actual export, its provenance, and a demonstration that another tool can interpret it.
Evaluation records are another asset to inspect. Test cases, definitions of success, expected outcomes, and observed failures may be as valuable as the accepted memory entries. Specify which artifacts are customer-specific, which remain licensed components, and how each can be retained or moved.
A choice between an integrated platform and a modular stack still leaves the ownership work to do. Buying memory, evaluations, and orchestration separately may change the replacement options. It can also move more integration and maintenance work onto the customer. Compare the artifacts and responsibilities that survive each option rather than treating the number of suppliers as the answer.
The mechanism that matters
A modular stack changes dependencies but does not eliminate them. An integrated platform can reduce coordination work; separate components may offer more control over replacement. Compare identity, access, retention, export, and operating responsibilities across the actual configuration. Private hosting is one boundary choice, not a substitute for that inspection.
A data-sensitive buyer should identify where memory is created, reviewed, stored, and retrieved, along with the permitted model routes. The selected boundary must meet the customer's requirements. Nodes supports private and hosted deployment options rather than one universal location rule.
Outcome evidence and human judgments need different treatment. A person can accept a recommendation without establishing that it worked. Later reports can show a different result. The proposed context model should retain both, with their sources and applicable scope. Model artifacts have a separate ownership and licensing question.
Three properties matter for company memory: an approved processing boundary, usable customer rights over separable intelligence, and an inspectable promotion path. Hosted processing does not inherently transfer ownership. Local processing does not establish that a draft became accepted knowledge correctly. Review the actual terms, supported exports, evidence lineage, and permissions. Nodes' complete automated learning loop remains product direction and should be evaluated with the same tests.
Ask for the curated memory in a form the customer can inspect. Determine which records another tool could use and which behavior depends on the original runtime. A structured export can preserve useful evidence even when it cannot reproduce the vendor's agent orchestration. The agreement should make that distinction explicit before a transition is urgent.
The suitability of a memory service depends on the records and operating obligations involved. Assess provider terms, the supported configuration, retention, and permitted uses with the customer's reviewers. Do not infer that every hosted service is acceptable or that every sensitive workload forbids one. Context, logs, backups, and connected tools all need explicit treatment.
Where this changes procurement
A diligence review should inspect both where reasoning runs and how memory is created, selected, stored, and reused. Hosting is one decision. The promotion of a tentative observation into reusable company knowledge is another. Neither should be hidden behind a general statement that the platform remembers the business.
Ask whether curation runs on a schedule, after a case closes, or only after a person accepts a change. Ask who can dispute an entry and how a correction reaches dependent summaries. Then inspect the output: source references, timestamps, applicability, uncertainty, and version history. Fine-tuned weights, if any, are a separate artifact rather than the assumed form of all memory.
A buyer choosing hosted memory should price the transition work before it becomes urgent. Can the company retain the useful facts, judgments, provenance, and applicable lessons? Can a replacement process read them? What still needs the original harness? These questions apply equally to a private vendor deployment and an internal build.
A memory export worth testing
Start with an illustrative onboarding intervention. A team believed that new hires needed more product training. An investigation found incomplete access to a required system. The manager approved an access repair before adding more training. The repair completed, but the next outcome report still showed no clear improvement in ramp. Each of those statements has a different status. The initial belief was a human judgment. The missing access was an observed fact. The proposed benefit was an estimate. The completed repair was an execution result. The unchanged ramp was later outcome evidence.
An export that contains only the final recommendation loses the reason the company might act differently next time. An export of the whole conversation may preserve words while making those distinctions difficult to retrieve. Ask for the linked records, source references, relevant dates, and unresolved uncertainty. A replacement reader should be able to distinguish what was known when the action was approved from what arrived afterward.
Then change the circumstance. Another team has full access but still has a ramp delay. A reusable lesson should not prescribe the earlier repair simply because it was approved before. It should identify why the prior case may be irrelevant and request different evidence. This tests the applicability of memory instead of rewarding a system for recalling a familiar story. It is a proposed evaluation, not a claim that Nodes has demonstrated this complete learning mechanism in production.
Permissions need the same practical treatment. A person authorized to inspect one team's development records may not be entitled to another team's details. A shared summary must not bypass that boundary by including a restricted fact. Test an export and a later retrieval under the identity that will use them, including what happens after access is revoked. Storage in one company database does not imply universal access throughout that company.
Finally, inspect a correction. Suppose the production report contained a duplicate or used the wrong date. Which derived finding is marked stale? Can a reviewer see the prior version and why it changed? Can the proposed lesson be withdrawn without erasing the original action record? Useful company memory needs that repair path. Otherwise a confident summary can outlive the evidence that once supported it.
Keep these examples in the acceptance criteria alongside operating cost and transition effort. Record what can be reconstructed without the original model, what needs the original runtime, and what remains unknown. The exercise can expose a missing schema or a contractual dependency early, while there is still time to agree on a usable handoff. More stored history is valuable only when the people and systems entitled to use it can understand its meaning and limits.
What the production reference establishes
Nodes' public production reference is candidate evaluation at one Fortune 500 insurance carrier. A separate Decision Traces study covers four years of production data and 10,765 historical agents. Outcome reports and retrospective analysis are separate from proof that software automatically learns from them. The broader graph, active-team runtime, and outcome-learning system remain product direction. There is no default pooling of confidential customer memory or training across tenants.
The intended asset is customer-specific evidence and applicable learning that remain useful across model and employee changes. Fine-tuning is optional. Retention and practical portability require agreed artifacts and formats; neither a private deployment nor an ownership slogan supplies them automatically.
What the buyer should ask next
Memory is worth evaluating as an asset in its own right. Keep the review concrete: which evidence and judgments will the company be able to inspect, reuse, challenge, and retain? Which parts still depend on licensed software? The strongest answer is a working reconstruction of one case, including an inconvenient outcome, after the original worker or model has changed.
Sources
- New in Claude Managed Agents: dreaming, outcomes, and multiagent orchestration
- Anthropic wants to own your agent's memory, evals, and orchestration, and that should make enterprises nervous
- Decision Traces: What Multi-System Data Fusion Reveals About Institutional Knowledge in Enterprise Hiring
Saad Bin Shafiq is the founder of Nodes, serving data-sensitive enterprises. Methodology: Decision Traces.