Article /
Why AI Companies Want Your Agent Traces
Every time your agent runs, it writes down exactly how it got the job done. Most teams delete that record. The companies selling you the model would very much like to have it.
Read the terms of service for almost any hosted model or agent platform and you will find a line about “improving our services” with your data. Sometimes it is opt-out. Sometimes it is buried under an enterprise addendum. Sometimes the trade is more direct: a cheaper tier, a free credit grant, or early access, in exchange for letting them keep the logs.
This post is about what that line is really asking for, why it has become the most valuable thing you produce, and what you should do about it.
What an agent trace actually is
A trace is the full record of one agent run: every prompt, every tool call, every tool result, every intermediate decision, and the final outcome. A chat log is one turn in and one turn out. A trace is the whole path.
A single customer support run might contain the ticket text and the customer’s account context the agent was given; the agent’s decision to look up an order before answering; the API call it made, the JSON it got back, and the error it hit on the first try; the retry, the reasoning about why the first call failed, and the corrected call; the draft reply, the policy check it ran against the refund rules, and the final message; and whether the customer accepted it, escalated, or came back angry.
That last part is what matters. A trace is not just what the agent did. It is what the agent did, tied to whether it worked. That combination is what nobody can buy off the shelf.
Why labs want them: the training signal money can’t buy
Frontier labs have run out of cheap text. The open web is scraped. What they need now is not more sentences. It is examples of a model doing multi-step work in a real environment, with real tools, and a verdict on whether it succeeded. That is a trace. Three things make traces different from every prior kind of training data.
They are labeled by reality. A trace from your production agent comes with its own grade. The order shipped or it did not. The customer closed the ticket or reopened it. The PR merged or got reverted. Labs spend enormous effort building “verifiers” that can score agent behavior. Your business already has one. It is called your business.
They can’t be faked well. The obvious shortcut is synthetic data: have a model generate trajectories and train on those. It works less well than people hope. Models trained on their own output drift toward the average and lose the long tail. The long tail is exactly where agents fail. Real traces from real workflows carry the weird edge cases, the half-broken APIs, and the customer who phrased it the strange way. That is the signal.
They are the fuel for reinforcement learning. Supervised fine-tuning teaches a model what a good run looks like. RL teaches it to prefer a good run over a bad one. Both need pairs: here is the path that worked, here is the one that did not. A high-volume production agent produces thousands of those pairs a week without anyone lifting a finger.
The market has priced this in. SignalFire describes an entire category of companies that package traces into training environments with verifiers and sell them upstream, and puts the labs’ spend on this in the billions. Vendors like Turing publish case studies about delivering tens of thousands of human-driven agent trajectories and over a hundred thousand RLHF preference pairs to a single frontier lab for one agent product. That is what a lab pays for when it has to buy traces. Your agent produces the same thing for free. So the terms of service ask for it.
The trade you are making without noticing
When a provider trains on your traces, three things happen, and only one of them is good for you.
The good one: the next model version is a little better at your kind of task. You get that improvement. So does everyone else, including your competitors, who pay the same per-token price you do.
The first bad one: your edge becomes a commodity. If you spent a year getting an agent to handle insurance claims the way your best adjusters do, those traces encode that year. Hand them upstream and the general model learns it. Your “how we do it here” becomes “how the model does it for anyone.”
The second bad one: you lose the option to do it yourself. The companies winning with agents are not just running a frontier model behind an API. They are fine-tuning smaller, cheaper models on their own traces, training routing and decision models on their own outcomes, and building evals from their own failures. Every one of those requires the trace. If you let the provider keep it and you delete your copy, you have closed that door.
There is also a plain governance problem. Traces contain whatever the agent saw: customer records, internal documents, credentials in a tool result, the quiet decision to call an API it should not have. The first time a regulator or an enterprise buyer asks why the agent did something, “we don’t keep those” is not an answer. “Our model vendor has them” is a worse one.
What to do about it
None of this means you should refuse to use hosted models. It means you should treat traces the way you treat your CRM or your data warehouse: as an asset you own, store, and decide what to do with.
1. Read the training clause before you sign. Find out whether the provider trains on your inputs and outputs, whether opt-out is real or theoretical, and whether it applies to agent runs or only to chat. Ask for it in writing for enterprise tiers.
2. Capture full trajectories by default. Not just the final answer. Every prompt, tool call, tool result, and outcome, in a format that does not depend on one vendor’s SDK. The harness and the model will change. The trace should not.
3. Attach the outcome. A trace without a verdict is a log. A trace with one is training data. Wire the business signal back in: resolved or escalated, merged or reverted, accepted or refunded.
4. Set retention deliberately. Decide per agent type how long you keep traces and who can see them, instead of letting the default be “forever on the vendor’s side, never on ours.”
5. Use them. Build evals from your failures. Fine-tune a small model on your successes. Train a router that knows which of your tasks need a frontier model and which do not. This is where the cost and quality gains actually come from.
How Parsec handles your traces
Parsec is an inference runtime, not a model lab. We do not need your traces to improve a frontier model, because we are not training one. Your traces stay yours. What we do instead is give you the loop the labs built for themselves, pointed at your own agents.
Fine-tune small models on your own trajectories. Take the runs that worked, train a small language model on them, and deploy it behind the same endpoint. Most of your agent’s turns do not need a frontier model. The ones that do still get one.
Route per turn on your own outcomes. TOD, our decision model, learns from which of your runs succeeded and picks the right model for each step. Cheap where cheap is fine, expensive where it is not.
Carry less context between turns. Parsec’s universal cache moves between models and prunes what the next turn does not need, so a long trace costs you less to run, not more.
Keep the record. Every run is captured as a full trajectory you can export, replay, and audit, in a format that is not tied to any one model vendor.
The labs are right about one thing: your traces are the most valuable data your agents produce. They should be making your agents better, not someone else’s. See how Parsec runs your agents at https://parseclab.ai