On July 1, Alex Karp went on CNBC's Squawk Box and said what his customers now demand from the companies selling them models. They want "control over their compute, their models, their data stack, and their alpha." He gave their questions for a vendor in two short lines: "Are you keeping the data? Are you going to enter our business?" One of the anchors told him he sounded pretty angry (Mediaite, July 1, 2026).
The sovereignty debate is about weights and where inference runs, and I think it points at the wrong asset. For a company running agents, the thing that encodes how it actually works is the record of every run: the prompt, the plan, each tool call and what came back, the diffs, the decisions, and how it ended. Those records are the trajectories. Whoever stores them holds the alpha.
The sovereign stack runs on traces
Two days before the interview, Palantir announced the answer it sells: an engine for deploying NVIDIA's open Nemotron models "in sovereign environments," where agencies and companies fine-tune on their own data and keep the result (Palantir press release, June 29, 2026). NVIDIA's announcement the same day says customers "retain full ownership of the resulting models, including the weights that encode their operational knowledge" (NVIDIA blog, June 29, 2026).
Read the release past the headline. The sentence that does the work sits in the middle: "The intelligent engine collects and stores user telemetry and trace data, then uses that data to post-train and align the model to areas where AI can add the most value." The next one names the mechanism: "With this feedback loop, the model continually improves at supporting specific operational tasks."
Follow the order of operations. The weights encode operational knowledge because they were trained on trace data. The trace data came first. A fine-tuned checkpoint is a compressed, lossy copy of the run records that produced it, frozen on the day the training job ended. Keep the checkpoint and lose the records, and you own last quarter's snapshot with no way to make the next one.
So the sovereign stack, as its own vendors describe it, runs on trajectories. The weights are what the loop produces. The records are what it eats.
Three things a vendor can keep
"Are you keeping the data?" can mean three different things, and they age at different speeds.
The weights are a snapshot. An open checkpoint is a download, and the next open release replaces it. A vendor that keeps a copy of your fine-tune keeps a head start that the next release erases anyway.
Your documents are what most sovereignty plans protect: contracts, tickets, code, customer records. They matter a great deal, and you already have them. They sit in your systems before any agent touches them, and they change at the pace of your business.
The trajectories are new. They exist only because an agent ran. Each one records how a task in your company gets done: which file it read first, which command failed, which approach it dropped, which review comment changed the plan, and whether the result held. Before agents, pieces of this were written down in build logs, shell histories, tickets and runbooks, but the whole sequence from request to result was split across those systems and people's heads, and much of it left when the people did. Now the whole sequence is written to disk on every run, by whoever operates the runtime.
What one week of run records holds
To see what is actually in these records, I counted ours. From July 1 to July 7, our team ran nine coding-agent sessions in the Rush repository on our own machines. The transcripts come to 5.4 MB of JSON lines. I counted entries by type.
The people wrote 93 turns. The agents answered with 261 replies, 267 reasoning blocks and 328 tool calls, among them 222 shell commands, 40 file reads, 33 edits, 15 sub-agents dispatched and 5 questions sent back to a person. For every turn a human typed, the agent took about three and a half actions on our systems that the human never typed.
The prompt is the smallest part of the record. A copy of our prompts would tell a competitor what we asked for. The 328 tool calls would tell them how we work: what our build looks like, where the tests live, which shortcuts fail in this codebase, and what we check before we call something done.
Honest limits. This is one week, nine sessions and one small team, measured by counting entries in local transcripts. It says nothing about quality, and a week of repository work leans toward shell commands. An agent that writes reports or works in a browser will show a different mix. I expect the shape to hold: a short request, then a long tail of actions taken inside your systems.
Three jobs that need the record
Post-training needs it, as the release says plainly. Preference tuning and reinforcement fine-tuning both want examples of the task done in your environment, with an outcome attached. A trajectory with its result, merged or reverted or sent back, is exactly that example.
Evals need it. To know whether a new model is better at your work, you score it against the tasks your agents actually performed. Your past trajectories are that test set. Without them, every model swap is a bet placed on someone else's benchmark.
Debugging needs it. When an agent ships something wrong, the question is which step went wrong, and the answer is in the record: the file it skipped, the error it read past. A checkpoint carries no memory of any particular run.
In April I wrote that once the agent's full reasoning trace is kept and linked from its work, the firm's memory becomes explicit (Agents Are Eating the Org Chart). That frame is why the storage question outranks the inference question. You can replace a model at the next release. You cannot recreate a year of run records.
It is also why Karp's second question lands. A vendor that holds your trajectories holds a worked example of every task you sell. In The Three-Bet Era I wrote that the model vendor watches the wrapper. With agents, whoever stores the runs can watch the work itself.
A sovereignty checklist for agents
If the trajectories are the asset, the checklist is short:
- Every run writes a complete record: the request, each step, every tool call with its result, the changes it made, and the outcome.
- The record lives beside the result, in your tenant, readable by your people.
- You can read all of it, or a slice of it, through an API.
- A run that is missing its proof ends
needs_review.
Where the model is served is a separate decision and a real one. It is also the easier one to change later.
Where Rush sits
This is why Rush captures the trajectory of every cloud run. A caller sends a request, an agent does the work in a cloud sandbox, and the result comes back beside the session transcript of what the agent did: each turn, each tool call and what came back. For code, the result is a pull request. The transcript is captured when the run finishes, and also when it is cancelled or loses its machine partway through, so the runs that went wrong keep their record too.
Karp's list was compute, models and data stack. For a company running agents I would add a fourth item and put it first: the record of every run. The next release will replace the weights. The record of how your work gets done exists in one place, and you should know whose place it is.
