Who owns what AI learns about our company?
Check the contract and exactly what you want to keep. Company records, decision history and lessons are different from the vendor’s software or model. For Nodes, the company retains its context graph, Decision Traces and outcome history; Nodes retains its software. Confirm how your records can be exported and reused.
Illustrative example: An AI system recommends fixing an onboarding access problem. The manager approves the repair. A later report shows no clear reduction in the time until the customer can use the service. The company should be able to keep all three records: the evidence behind the recommendation, the approved action and the disappointing result. An export containing only the final recommendation would lose the reason to investigate again.
List the assets before discussing ownership
| Asset | What to check in the agreement and export |
|---|---|
| Source records | Who controls access and corrections? Can the company keep the originals? |
| Company context graph | Can it retain relationships, definitions, dates and access rules? |
| Decision Traces and outcomes | Can it reconstruct the evidence, human decision, action and later observation? |
| Evaluated lessons | Who approves reuse, limits its scope and withdraws a lesson that fails? |
| Model weights | Who owns or licenses a particular artifact? Is it needed to reproduce behavior? |
| Operational logs | Who may inspect, retain, export and delete execution records? |
| Vendor software | Which runtime, connectors, updates and support remain licensed? |
For every row, ask who can see it, reuse it, export it in a form another authorized tool can read, and delete it when required. Ownership, access, processing location and training use are different rights. Put the answers in the applicable agreement and try a sample export before a transition is urgent.
Nodes customers retain their context graph, Decision Traces and outcome history. Nodes retains its applications, updates and platform IP. Detailed retention, export and deletion duties depend on the agreement. Keeping history does not guarantee that a replacement model will behave the same way. Test it on the same cases, permissions, quality measures and total cost.
Test the export on an inconvenient case
Return to the onboarding repair. An inspectable record should show what the manager knew at the time, which source showed missing access, who approved the change, whether the target system confirmed it, and when the later onboarding report arrived. An outcome received months afterward must not appear as if it informed the earlier decision.
Now test a second team. Its people already have the required access, but customers still wait too long to start using the service. A stored lesson should not automatically prescribe the earlier repair. Ask whether the exported record retains the conditions under which the lesson was proposed, the evidence that challenged it, and its current review status. A favorable result in one case also needs this test before it becomes company policy.
Finally, correct a bad source record. Can an authorized reviewer see what changed and which earlier summaries need another look? Can the company withdraw the proposed lesson without erasing the original action record? Those capabilities make retained history useful for new work rather than merely large.
Test the export under the identity that will use it. A summary can reveal a restricted personnel fact even when the source record itself is protected. Revoked access should affect later retrieval. A private deployment does not remove these permission and exit questions. Hosted processing does not inherently transfer ownership. Security explains deployment options and boundaries.
Separate recorded events from learning
An approval shows that a person authorized an action. A destination response shows whether it ran. A later observation helps evaluate whether the business objective improved. None of these alone proves the proposed lesson is reusable. Preserve failed and inconclusive results too. Then test any proposed change on relevant later cases before a named owner accepts it for a workflow.
That learning can live in selected context, an updated rule, a changed workflow or a model artifact. Fine-tuning is optional. The company-intelligence guide explains the review and testing steps. A replacement model can use retained company history, but it still needs configuration and evaluation.
What Nodes and the buyer should demonstrate
Nodes Engine creates the company context graph and connects evidence, human judgment, decisions, approved actions and later outcomes. Nodes Connector connects the required systems; Nodes AI FDE configures and tests the job. The public production reference is one Fortune 1000 insurance carrier, where Nodes supports hiring, licensing progress and educational support. The separate Decision Traces study covers historical hiring research. Those records do not prove that every proposed lesson is promoted automatically.
Ask for a reconstruction of one decision after changing the model or worker. Check the export, the access boundary, the exceptions and the licensed components still needed to use it. This is a practical ownership test. A paragraph saying “you own your data” cannot answer it.
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.