Evaluate with a NeMo Fabric Harness
NeMo Fabric runs an agent harness rather than a single
agent. Which harness runs is selected entirely by config["harness"]["adapter_id"], so one runtime
covers several agent frontends without changing your evaluation. Fabric returns an ATIF
trajectory alongside the final answer, so a metric can score how the agent worked, not just what
it answered.
The result and bundle are the same as the quickstart — only the runner changes.
Harnesses
This runner is not zero-dependency. It needs:
-
The harness adapters, from the
fabricextra: -
The
nemo-relaygateway binary, which captures the trajectory for out-of-process harnesses. The pip package ships bindings only, so the daemon comes from a GitHub release asset: -
The harness’s own CLI, for
transport: cliharnesses —codexonPATHand authenticated.
The fabric extra installs the Codex, Claude, and Hermes adapters. The deepagents adapter is
deliberately excluded from it, because that adapter does not support the Relay observability
configuration Fabric streaming generates; install its harness separately if you need it.
The agent config
One mapping describes the whole agent — harness, runtime, environment, and model. This is a working Codex configuration:
An environment.workspace set here is overridden per task — the runtime gives every task its own
fresh workspace under work_root, so setting one in the config has no effect.
Across harnesses the shape differs mainly in adapter_id, runtime.transport, and any
harness-specific harness.settings. Codex runs as a subprocess (transport: cli) while the Hermes
SDK harness runs in-library (transport: library). For complete Codex-CLI and Hermes-SDK
configurations, see examples/fabric_harness_runtimes.py in the SDK.
The Codex adapter requires an explicit model provider. It does not fall back to the Codex CLI’s
own configured default, and starting without models.default fails the adapter lifecycle with
codex_invalid_configuration.
Fold the complete configuration into this mapping. Fabric profile overlays are not used here.
Run it
Configuration
Seed files into the workspace
Every task runs in its own fresh workspace. Put files the agent should start from in the task’s
inputs["files"], and the runtime stages them before the harness runs:
With no files key this is a no-op, so tasks that need no starting state cost nothing.
Read the results
The answer is on the trial, and scores come back under the metric’s type:
Evidence
This is where Fabric differs from the other runners. Each trial carries several evidence streams, so a metric can score how the agent worked rather than only its final answer:
The workspace tree is what lets a metric grade artifacts the agent produced on disk, and trace
is what lets it grade the process. See
Writing Metrics for reading evidence,
and Score by Component for combining
several signals into one reported score.
Submit as a platform job
FabricRunnerTarget carries the same config into a durable job:
Submit it with nemo evaluator agent-evaluate submit, or as the target of an
AgentEvalInputSpec. See
Targets and Runners.
Running in a sandbox
FabricContainerRuntime takes the same config and runs it inside a sandbox rather than on the host:
Use it when the agent should not run on the host — untrusted tasks, or a workspace that must be discarded per task. The host runtime is otherwise the simpler choice.