What to take into an interview
- Separate task outcome, process quality, safety, latency, and cost.
- Evaluate complete trajectories when tool choice and order matter.
- Use repeated runs and reviewed datasets to manage nondeterminism.
Define the behavior before the metric
Begin with a concrete success policy. State what the agent should accomplish, which tools it may use, what evidence it must cite, and which actions are prohibited. Metrics are useful only when they represent this policy.
Use category-level scores when tradeoffs matter. A task can be correct but unsafe, grounded but unnecessarily expensive, or efficient but incomplete. Preserve these distinctions instead of collapsing them immediately into one number.
Evaluate outputs and trajectories
Output checks include exact match, structured-field validation, semantic criteria, citation verification, and rubric-based judgments. Trajectory checks inspect tool selection, argument validity, ordering, retries, observations, and terminal states.
- Prefer deterministic checks when the requirement can be encoded directly.
- Calibrate model-based judges against reviewed human examples.
- Keep hidden cases to detect overfitting to visible examples.
- Store failure categories so regressions can be grouped and prioritized.
Account for nondeterministic runs
Run important cases more than once and report pass rates or score distributions. Fix the model version, prompt version, tool definitions, and sampling settings in the evaluation record so changes are attributable.
Averages can hide rare severe failures. Track worst-case categories and safety violations separately, and define release thresholds appropriate to the consequence of error.
Build a useful evaluation lifecycle
Start with a small reviewed set covering normal, edge, and adversarial cases. Run it in development and before releases. Sample production failures carefully, remove sensitive data, label them, and promote representative cases into the regression suite.
During interviews, be explicit about judge limitations, data leakage, annotation disagreement, and monitoring after deployment. Evaluation is an operating process, not a one-time benchmark.
Hands-on practice
Related coding problems
Score Agent Behavior with a Rubric
Convert test evidence into transparent category-level scores.
Open problemCompare Expected vs Actual Tool Traces
Evaluate the sequence of decisions, tools, and observations.
Open problemDetect Prompt Injection in Model Output
Add a focused adversarial behavior check to an eval suite.
Open problemBuild the foundation
Related curriculum tracks
Common questions
Frequently asked questions
Are model-based judges reliable enough for agent evals?
They can help with nuanced criteria, but they need calibration, stable prompts, reviewed examples, and deterministic checks wherever possible.
How many times should an agent evaluation run?
Use enough repetitions to estimate variability for the decision you are making. Higher-risk or less stable workflows justify more runs and stricter thresholds.
What belongs in an agent trace?
Capture model and prompt versions, structured decisions, tool calls, validated arguments, observations, errors, timing, token or cost data, and the terminal result while excluding secrets.
Practice next
Make agent behavior measurable
Practice rubric scoring and trajectory comparison, then add adversarial cases so your evaluation story covers quality, reliability, and safety.