Question-led guide · diagnostic
Why is a golden dataset not enough for agent evaluation?
A measurement-contract approach that extends reference answers with environment state, tool trajectories, permissions, budgets, uncertainty, and serious failures.
Direct answer
A golden dataset usually maps an input to an expected answer. An agent also observes state, chooses tools, consumes budgets, changes the environment, retries, delegates, and may ask for review. Two runs can produce similar final text while one is unauthorized or causes the wrong effect. Keep golden examples, but place them inside a task contract that defines the world, permitted trajectory, outcome, serious failures, and evidence required for grading.
Scope
Use this approach for agents that retrieve, call tools, maintain state, delegate, or cause effects. A golden input-output pair may be adequate for a deterministic formatter or bounded classifier, but the evaluation surface expands when the system can choose and act.
Why it happens
Golden datasets are easy to understand and score. They become a shrine when the organization protects a static score instead of asking whether the tasks still represent the product. For an agent, the hidden environment can dominate performance: permissions, tool errors, data freshness, initial state, network behavior, budgets, and human review all shape the result.
Diagnosis
Inspect a passing example and ask:
- What was the initial environment state?
- Which tools and permissions were available?
- Which actions and state transitions occurred?
- Could the same answer hide an unauthorized or duplicate effect?
- Were retries, time, tokens, cost, and human intervention within budget?
- Which failures would block release even if the final answer looked correct?
- Can the environment be reset and the run reproduced with versioned artifacts?
Any missing answer is outside the golden pair and needs a task contract or explicit limitation.
Solution
Wrap each important example in a task card. Define initial state, user request, required and forbidden outcomes, allowed and forbidden tools, policy version, budgets, fault injections, reset procedure, deterministic checks, rubric checks, trace checks, serious failures, and reviewer roles.
Separate grades: outcome correctness, trajectory safety, policy compliance, efficiency, calibration, and operator handoff. Do not average a serious unauthorized effect into an otherwise strong score. Version the environment and graders, repeat stochastic runs, and report denominators and uncertainty by task slice.
Artifact
| Measurement-contract field | Question it answers |
|---|---|
| Decision | What release, rollback, routing, or supervision choice will this evidence inform? |
| Claim | Exactly what can a passing result support? |
| Task and environment | What world, user, initial state, tools, and faults are represented? |
| Outcome | What must and must not happen? |
| Trajectory | Which paths, permissions, approvals, and budgets matter? |
| Graders | Which checks are deterministic, rubric-based, model-assisted, or human? |
| Uncertainty | How many trials, which slices, and what coverage gaps remain? |
| Gate | Which thresholds and serious failures change the decision? |
Common mistakes
- Scoring only final text for an agent that can cause effects.
- Reusing one reference answer across changing tool and policy versions.
- Averaging serious failures with harmless style errors.
- Letting the same data drive prompt tuning, grader calibration, and final release decisions.
- Treating a benchmark improvement as proof of production impact.
Evidence
Context-specific evaluations need real-world examples, edge cases, expert criteria, and ongoing production feedback.
OpenAI's evaluation primer describes specifying workflow outcomes, drawing examples from real conditions, including rare costly cases, auditing graders, and continuing evaluation after launch.
Primary source · official-doc · checked Aug 25, 2026
Limit: It is provider guidance, not an independent standard, and does not define this site's task-contract schema.
AI evaluation is contextual and may require portfolios of tasks, testbeds, data, qualitative measures, and multiple characteristics.
NIST's TEVV program describes tasks, challenge problems, testbeds, meaningful datasets, quantitative and qualitative methods, and context-dependent evaluation.
Primary source · official-doc · checked Aug 25, 2026
Limit: The page describes a broad measurement program and does not prescribe one agent release gate.
A final-answer reference should be embedded in a versioned measurement contract for an acting system.
The contract makes state, authority, trajectory, budgets, effects, graders, uncertainty, and release decisions visible.
Signal Studio author framework · reviewed Aug 25, 2026
Limit: Task-specific domain experts must decide which paths are acceptable and which failures are serious.
Limitations
A richer evaluation still cannot prove all production behavior. Test environments omit some integrations, users adapt, models and tools change, and rare failures remain difficult to sample. Use the contract to state what the result supports rather than claiming general safety.
FAQ
- Should I delete my golden set?
- No. Keep it as one source of expected outcomes and expert judgment, then add task state, tools, policy, trajectory checks, serious failures, and versioned environments.
- Can an LLM grader evaluate the whole agent run?
- It can assist with rubric judgments, but deterministic effect and permission checks should remain deterministic, and the grader must be calibrated and audited against domain review.
Related guides
Continue within Agent evaluation, or use one of these adjacent diagnostics:
English editorial review: Codex native-English editorial review, .