ometere123/the-skills-bible/agent-evaluation-engineer

Agent Evaluation Engineer

Purpose

Measure whether an agent completes real workflows safely and efficiently, not whether its intermediate reasoning sounds convincing.

Use this skill when

• A tool-using or multi-step agent needs evaluation.
• Agent runs are variable and difficult to score.
• Autonomy, recovery, and tool safety require evidence.
• Several orchestration designs must be compared.

Do not use this skill as the primary workflow when

• The application performs one LLM generation only.
• The task can be evaluated entirely by final text.
• No simulation or safe environment exists for actions.

Required inputs

• Agent task contracts.
• Tools, permissions, and environments.
• Reference outcomes and state checks.
• Budgets and human-review policy.
• Historical failures and adversarial scenarios.

Classify missing information as blocking, important, or optional. Inspect the actual product requirements, workflows, data, models, prompts, tools, permissions, evaluations, traces, incidents, policies, and production constraints before asking for information that can be verified directly.

Core operating principles

• Start from the decision, workflow, user outcome, or automation need rather than from a model or vendor.
• Use the simplest deterministic method that can satisfy the requirement before adding probabilistic components.
• Separate model capability, application logic, tools, memory, retrieval, policy, and human authority.
• Treat prompts, datasets, tools, schemas, model versions, policies, and evaluations as versioned production artefacts.
• Ground consequential outputs in authoritative evidence and expose uncertainty, provenance, and limitations.
• Constrain permissions, data access, actions, spending, recursion, and runtime before granting autonomy.
• Evaluate representative tasks, edge cases, adversarial inputs, failures, and affected user groups before release.
• Preserve privacy, security, accessibility, human agency, appeal, and safe failure throughout the lifecycle.
• Make model and agent behaviour observable without logging secrets, private reasoning, or unnecessary personal data.
• Design rollback, fallback, escalation, incident response, and decommissioning before production deployment.

Workflow

1. Define task environments

• Create deterministic or controlled sandboxes with realistic tools, data, identities, delays, and failures.

2. Define completion oracle

• Check authoritative final state, artefacts, external effects, unresolved items, and policy compliance.
• Do not rely on agent self-report.

3. Measure trajectory

• Record plans, tool calls, observations, state changes, retries, approvals, and decisions without requiring private reasoning disclosure.

4. Measure tool use

• Assess correct selection, arguments, unnecessary calls, permission denials, idempotency, and unknown-outcome handling.

5. Measure efficiency

• Track steps, tokens, latency, cost, parallel work, duplicate effort, and human burden.
• Set budgets.

6. Test recovery

• Inject tool errors, stale data, interruption, missing permissions, conflicting evidence, and partial completion.
• Verify resume and cancellation.

7. Test safety

• Evaluate injection, privilege escalation, unsafe destinations, high-impact actions, budget exhaustion, and policy conflict.

8. Test escalation

• Confirm the agent asks for clarification, approval, or specialist help at appropriate thresholds.

9. Handle stochasticity

• Run multiple trials, seeds, environments, and orderings and report success distributions and failure modes.

10. Compare baselines

• Compare fixed workflow, single-agent, multi-agent, and human-assisted variants on outcome, safety, cost, and reliability.

Decision rules

Required outputs

• Evaluation environments.
• Completion oracle.
• Trajectory traces.
• Tool-use metrics.
• Efficiency metrics.
• Recovery tests.
• Safety tests.
• Escalation evaluation.
• Reliability distributions.
• Baseline comparison.

AI system quality gates

• Problem gate: The intended outcome and the reason to use AI are explicit.
• Data gate: Sources, rights, quality, lineage, privacy, and retention are controlled.
• Model gate: Model capability, limits, version, configuration, and fallback are documented.
• Grounding gate: Claims and actions use suitable evidence, tools, or deterministic checks.
• Authority gate: The model cannot exceed the permissions, spending, scope, or actions granted by policy.
• Evaluation gate: Representative, adversarial, failure, and subgroup evaluations meet approved thresholds.
• Human gate: High-impact, ambiguous, irreversible, or exceptional outcomes receive appropriate human review.
• Safety gate: Abuse, injection, privacy, harmful content, and unsafe action paths are tested and bounded.
• Observability gate: Inputs, outputs, tools, state, latency, cost, and outcomes are diagnosable with data minimisation.
• Lifecycle gate: Versioning, rollout, rollback, monitoring, incident response, and retirement are operational.

Evidence standard

For consequential AI conclusions, identify the exact model, model version, system prompt, tool set, retrieval index, dataset, policy, evaluation set, configuration, environment, and time window. Distinguish observed behaviour, measured estimates, supported inference, and unknowns. Do not claim capability, safety, fairness, or reliability from a few demonstrations.

Failure handling and escalation

Pause or escalate when:

• The system's intended authority, affected users, or acceptable error is unclear.
• Training, retrieval, or evaluation data lacks provenance, permission, or privacy controls.
• A model or agent may send messages, move money, change records, execute code, or access sensitive systems beyond approved scope.
• Prompt injection, tool compromise, data poisoning, identity confusion, or uncontrolled recursion is plausible.
• A high-impact outcome cannot be independently verified or appealed.
• Evaluation evidence is missing, stale, non-representative, or materially regresses.
• Residual safety, privacy, legal, financial, or operational risk exceeds delegated authority.

Report the exact blocker, verified state, affected outcome, safe options, and smallest required decision.

Common anti-patterns

• Agent judges its own success.
• Final answer graded while side effects ignored.
• Only successful trajectories inspected.
• No budget or unnecessary-tool metric.
• Simulation tools behave unlike production with no caveat.
• One run per task.
• Unsafe completion counted as success.

Completion checklist

• [ ] Success uses authoritative outcomes.
• [ ] Trajectory and tools are observable.
• [ ] Recovery and injection are tested.
• [ ] Human escalation is evaluated.
• [ ] Variability is reported.
• [ ] Simpler baselines are included.

AI implementation record

# AI Implementation Record
 
## Outcome
[Task, user need, decision, or automation result]
 
## Scope and authority
[Users, systems, data, tools, permissions, budgets, and exclusions]
 
## Architecture
[Models, prompts, retrieval, memory, tools, policies, humans, and fallback]
 
## Data and provenance
[Sources, rights, lineage, privacy, retention, and quality]
 
## Evaluation
[Tasks, datasets, metrics, thresholds, adversarial cases, and subgroup results]
 
## Safety and security
[Injection, abuse, harmful output, tool constraints, privacy, and escalation]
 
## Deployment
[Versioning, routing, rollout, rollback, compatibility, and cost]
 
## Observability
[Traces, outcomes, latency, tokens, tool calls, incidents, and redaction]
 
## Residual risk
[Known limits, owner, acceptance, expiry, and user communication]
 
## Follow-up
[Monitoring, retraining, index refresh, policy updates, and decommission triggers]

Related skills

• agent-orchestration-engineer
• multi-agent-systems-engineer
• autonomous-workflow-safety-engineer
• ai-evaluation-architect

Maintenance rules

Review this skill when models, datasets, policies, tools, regulations, or workflows change; evaluations or incidents reveal a missing safeguard; the workflow becomes tied to one vendor; the file approaches 500 lines; or reusable schemas, evaluators, test sets, or guardrail policies would improve execution.