Trajectories and Experiments

An agent can reach the right answer through a dangerous, wasteful, or fragile path. Outcome evaluation alone misses that.

Outcome, trajectory, and process

• Outcome: Was the final state correct?
• Trajectory: Which observations, model calls, and tools produced it?
• Process: Were policy, authorization, and resource rules followed?

Signal Room might identify the right deployment but invent a citation. A coding agent might make tests pass by deleting them. A media agent might generate a good clip after reading an unauthorized asset.

Grade all three layers where risk justifies it.

Trace assertions

trait TraceAssertion {
    fn check(&self, trace: &RunTrace) -> AssertionResult;
}

Useful assertions:

• no external write before approval;
• no model received evidence outside its data policy;
• tool calls remained below the budget;
• every repair followed a recorded violation;
• a stronger model was used only after router escalation;
• final citations appeared in the context actually shown to the model;
• cancellation stopped new billable calls.

Avoid requiring one exact “ideal” trajectory when many paths are valid. Assert invariants and measure efficiency.

Build a failure taxonomy

Classify each failure:

task specification
context selection
tool design
tool execution
model capability
model instruction following
output decoding
semantic verification
authorization
grader error
infrastructure

The taxonomy determines the next intervention. A retrieval miss will not be fixed by LoRA. A broken grader should not select a new model.

Compare one hypothesis at a time

An experiment requires:

• a written hypothesis;
• baseline and candidate identifiers;
• frozen dataset and graders;
• controlled model parameters;
• primary metric;
• guardrail metrics;
• a decision threshold.

Example:

Hypothesis:
Adding a deterministic OCR tool lets the small vision model match the large model
on screenshot field extraction while cutting cost by at least 50%.

Primary:
exact field accuracy

Guardrails:
citation validity, p95 latency, severe hallucinations

Run enough repeated trials when sampling is stochastic. Keep raw per-case results.

Do not overfit the harness

If every failed case receives a special instruction, the prompt becomes a hidden lookup table. Use:

• a development set for diagnosis;
• a held-out set for selection;
• a shadow or production sample for realism;
• periodic refresh for changing distributions.

Prefer changes that explain a class of failures.

Pareto comparisons

AI systems have multiple objectives:

quality ↑    latency ↓    cost ↓    risk ↓

There may be no single winner. Plot or tabulate candidates on the Pareto frontier. A fast local model may be best for interactive extraction while a slower routed system is best for final incident review.

Optimize the program, not only the prose

Research on DSPy and MIPRO shows that instructions and demonstrations in multi-stage language-model programs can be optimized against downstream metrics. The transferable lesson is:

1. express the program as modules;
2. define a metric;
3. collect traces;
4. search over changes;
5. select on held-out behavior.

Whether you use a framework or write the optimizer yourself, preserve the scientific loop.

Practice

Run three Forge candidates on the same cases:

• one large model;
• one small model with a long prompt;
• one small model with decomposition, a lookup tool, and a verifier.

Compare outcome pass rate, severe errors, mean calls, p95 latency, and cost. Then inspect the five cases where the rankings disagree. Those traces are more educational than the aggregate table.