Log Agent Trajectories Now, Train Later

Gartner predicts that 33% of enterprise software applications will include agentic AI by 2028. It also predicts that over 40% of agentic AI projects will be canceled by the end of 2027. Both can be true. The agents that survive will be the ones that improve after launch, and an agent improves from its own history: the cases it handled, the ones a person had to fix, and what happened afterward.

Research shows what that history is worth. In SWE-Gym, fine-tuning on 491 successful agent trajectories lifted a 32B coding agent to 20.6% on SWE-Bench Verified, a 13.6-point gain. The Agent Data Protocol project converted 13 existing agent datasets into one format, and fine-tuning on the unified data produced an average gain of ~20% over the base models. Its authors' diagnosis is the useful part: the bottleneck was less a shortage of agent data than data fragmented across heterogeneous formats, tools and interfaces.

Most enterprise agent deployments log for debugging: a request ID, latency, an error code, perhaps the final answer. A trajectory can't be rebuilt from that later. The cheapest moment to decide what to keep is before go-live, and the second cheapest is now.

What a trajectory needs to contain

At the episode level: the task or intent, the channel, the user's role (not identity), the agent version, model and sampling settings, the system prompt version, tool definition versions, policy document versions, IDs and versions of retrieved documents, the outcome, any human intervention, and the cost.

At the step level: what the model saw that is new since the last step, what it produced, the tool call with its arguments, the raw tool result, errors and retries, latency and tokens.

Four things teams most often forget:

Versions. A trajectory recorded under tool schema v3 is not valid training data for v4 without translation. Log definitions by hash at session start.
The human edit. When a reviewer changes the agent's draft before it goes out, the before-and-after pair is a preference label with an expert behind it.
The delayed outcome. The claim reversed on appeal 60 days later, the work order reopened, the refund charged back. These need a join key logged at the time.
The negative space. The clarifying question the agent didn't ask is invisible in the log. It shows up only when an expert reviews a sample against what should have happened.

A record that covers these looks like this:

{
  "episode_id": "ep-2026-04-14-07731",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "agent": {"name": "claims-intake", "version": "2.3.1", "model": "provider-model-2026-03", "temperature": 0.2},
  "versions": {"system_prompt": "sp-41", "tools_sha256": "a81f03c2", "policy_docs": ["CLM-12 rev 2026-02"], "semconv": "1.40.0"},
  "task": {"intent": "fnol_auto", "channel": "web_chat", "user_role": "policyholder"},
  "business_keys": {"claim_id_hash": "c3d9e1aa", "policy_id_hash": "7f20b6c4"},
  "steps": [
    {"i": 0, "type": "model", "output": {"tool_call": {"id": "call_01", "name": "lookup_policy", "arguments": {"policy_ref": "pol_7f20b6c4"}}}, "tokens_in": 2140, "tokens_out": 38},
    {"i": 1, "type": "tool", "call_id": "call_01", "is_error": false, "result_ref": "blob://ep-07731/1.json", "latency_ms": 310},
    {"i": 2, "type": "model", "output": {"message_ref": "blob://ep-07731/2.json"}, "tokens_in": 2905, "tokens_out": 212}
  ],
  "human": {"reviewed": true, "edited": true, "diff_ref": "blob://ep-07731/edit.diff", "reviewer_role": "senior_adjuster"},
  "outcome": {"status": "claim_opened", "verified_at": "2026-04-14T15:02:11Z", "followups": {"reopened_within_30d": false, "checked_at": "2026-05-14"}},
  "content_store": "restricted-enclave-east"
}

Content lives behind references in a restricted store. The record itself carries IDs, hashes, versions and measurements.

Use the OpenTelemetry conventions for the skeleton

You don't need to invent span names. The OpenTelemetry semantic conventions for generative AI, still marked Development as of v1.40.0, define invoke_agent and execute_tool spans with attributes such as gen_ai.agent.name, gen_ai.agent.version, gen_ai.conversation.id, gen_ai.tool.name, gen_ai.tool.call.id and token usage. Instrument with them and your traces will be readable by any tool that follows the same conventions, which matters when you change vendors.

Pay attention to what the conventions make optional. Message content, system instructions, tool definitions, tool-call arguments and tool results are all Opt-In attributes, and the specification warns that input and output messages are likely to contain sensitive information, including personal data. That points to a clean split. Send spans with IDs, timings and token counts to your observability backend, which keeps data for days or weeks. Write content to a separate, governed trajectory store, keyed by trace and span IDs, with retention set by policy rather than by your monitoring vendor's defaults. Because the conventions are still changing, record the version you implemented in every episode.

If your tools are served over the Model Context Protocol, log each tool's input and output schemas by hash, and keep the protocol's distinction between tool execution errors (returned with isError: true) and protocol errors. The specification describes execution errors as carrying feedback a model can use to correct itself, which makes them some of the most useful steps in the log.

Outcomes are the labels

A trajectory without an outcome is a transcript. Signals, from weakest to strongest:

Signal	What it tells you	Use
No complaint	Almost nothing	None alone
Accepted without edit	Weak positive	Candidate for fine-tuning, after sampling review
Accepted after edit	The edit is the correction	Preference pairs; fine-tuning on the edited version
Downstream state verified	The work was actually done	Fine-tuning data and RL task seeds
Expert review	Ground truth, with a rationale	Golden set and judge calibration

Design the join keys now. Put hashed business identifiers, such as claim, work order or account, on the episode, so outcomes recorded weeks later in other systems can be attached.

Governance from the first write

Trajectories concentrate sensitive data: customer messages, account details, sometimes health or financial information, all in one place.

Keep raw content in your tenant, in a restricted enclave with short retention, and produce a de-identified derivative for training, with the method documented.
Handle deletion and holds. Deletion requests and litigation holds have to reach the trajectory store, not just the CRM.
Record purpose. Whether your customer terms and notices permit use of interactions for training is a question for counsel. Record their answer with the dataset.
Write a manifest for every export: sources, date range, filters, redaction method, reviewers.

What the logs become

Every dataset in our agent trajectories and RL environments work starts from logs shaped like the record above. Five uses come up again and again:

Evaluation sets. Failures and escalations become golden-set candidates.
Fine-tuning data. Successful, verified trajectories feed rejection-sampling fine-tuning, also called filtered behavior cloning.
Preference pairs. Human edits pair the agent's draft with the expert's correction.
RL tasks. Logged starting states and outcomes become templates for an environment built from your workflows.
Verifier and judge data. Expert-reviewed episodes calibrate the graders.

Filter before you train. The SWE-Gym authors report that self-improvement wasn't working yet: fine-tuning on the agent's own on-policy trajectories dropped its SWE-Bench Lite score from 15.3% to 8.7%. Train on verified outcomes and human corrections, not on everything the agent happened to do.

Storage is rarely the constraint. At 10,000 episodes a day, 15 steps each and about 8 KB of new content per step, the store grows by roughly 1.2 GB a day, or about 440 GB a year, before deduplication. Store system prompts and tool definitions once by hash rather than on every step, or the footprint multiplies several times.

This quarter

Pick one production agent and write the episode schema before the next release.
Instrument invoke_agent and execute_tool spans using the OpenTelemetry GenAI conventions, and pin the version.
Stand up a separate trajectory store in your tenant, with retention, access control and deletion workflows.
Log versions of prompts, tool schemas and policy documents by hash on every episode.
Capture human edits as diffs, and log hashed business keys for delayed outcomes.
Have experts review 50 episodes a month and route failures to the golden set.
Agree with counsel on training use, and write it into the dataset manifest.

Log agent trajectories now, so you can train agents later