Module harness 

The thing being benchmarked: the host’s agent harness, behind the Harness trait, plus RunArtifacts — everything a single run produced EXCEPT scoring — and the structured ToolCall the artifacts carry.

eval-core knows nothing about HOW a run happens (which LLM, which tools, which world). The host implements Harness over its own World + Setup, and the generic runner (crate::run_eval) drives it: build a fresh world per case, run the instruction against it, then hand the resulting world AND the run’s RunArtifacts to a Scorer. The harness owns its own backend and reports its own token count — there is deliberately no backend/token-counting trait in this crate.

For the common case — scoring what the agent DID (tool calls, params, final text/number) rather than a custom world — a host can skip Harness/[Scorer]/World/Setup entirely and implement the one-method Agent trait, authoring Expectation predicates and calling run_suite. See that trait + the calculator example.

Structs

RunArtifacts

Everything a single run produced EXCEPT scoring. The Harness (or Agent) fills this in and returns it; the generic runner copies it onto the case’s CaseOutcome and also hands it to the Scorer so built-in assertions can inspect what the agent did.

ToolCall

One tool call the agent made: the tool’s name and the structured args it was invoked with.

Traits

Agent

The easy path: implement this single method for your harness — run ONE prompt, return what the agent did — and the framework does the rest.

Harness

The thing being benchmarked: the host’s agent harness. The host implements this over its own world.