Skip to navigation
IntegrationsConsumer Integrations

Harbor

View as Markdown

Use nemo_fabric.integrations.harbor:FabricAgent when Harbor should own task materialization, environments, verification, rewards, and retries while NeMo Fabric selects and runs the agent harness.

One Harbor trial consumes one complete NeMo Fabric config. Compare harnesses or capability variants by holding the Harbor task and verifier fixed and starting a separate run with a different config or explicit Harbor skill/MCP input. The checked-in Harbor workflows qualify Hermes Agent, Claude, and the NVIDIA-labs Object Oriented Agents (NOOA) BenchAgent end to end.

Refer to the repository examples for installation and runnable Harbor workflows:

Run NeMo Fabric agents with Harbor

Model Provider

Omit fabric_model_provider to retain provider inference from the model name. Override it only when the selected adapter requires a different value; an OpenAI-compatible endpoint alone is not a reason to set openai. For adapters that honor models.default.provider, such as Qwen, use fabric_model_provider=openai for an OpenAI-compatible endpoint whose served model ID starts with another vendor prefix. For example, combine it with model_name="nvidia/nemotron-3-ultra-550b-a55b" and fabric_model_base_url to select the OpenAI protocol while preserving the exact served model ID. Without an override, the provider is inferred from the model prefix as before. The override requires a model and remains subject to the selected adapter’s model schema. Mini-SWE and OpenHands construct their LiteLLM model name from both the provider and model ID. With provider nvidia, both adapters prepend nvidia_nim/ unless that prefix is already present. With other providers, they prepend <provider>/ only to slash-free model IDs and preserve IDs that contain /. Selecting openai for the nvidia/... example therefore prevents adding nvidia_nim/; it does not add an openai/ prefix. LiteLLM cannot infer a provider from that unchanged nvidia/... ID, so keep the inferred nvidia provider for Mini-SWE and OpenHands in this example.

Model Settings

Pass adapter-declared model settings with fabric_model_settings, for example --ak 'fabric_model_settings={"cost_tracking":"disabled"}' for an explicitly unpriced Mini-SWE model. Pair that policy with a positive fabric_max_turns. The bridge copies these settings into models.default.settings; the selected adapter’s model schema and runtime validation still apply. This option requires a model. Keep credentials in managed environment variables, outside model settings. This option applies to the SDK bridge; native Harbor owns a separate implementation.

Registered Workflow Targets

Use fabric_workflow_target_id to select a registered workflow while keeping fabric_adapter_id explicit. For example, select nvidia.nooa.coding-agent with adapter nvidia.fabric.nooa. Pass construction settings through fabric_workflow_settings; the target descriptor’s schema validates them before task setup. These settings are separate from adapter fabric_harness_settings, and cannot be supplied without a target ID.

Host admission reads adapter and target metadata from the matching catalog, without importing a harness SDK or target factory. For an external target, pass its canonical host-readable JSON file as fabric_target_descriptor, separately from fabric_adapter_descriptor. Missing target metadata, mismatched adapter bindings, unsupported target types, and invalid settings fail admission.

Install the executable descriptors inside the task environment or configure fabric_discovery_paths there. Host descriptor paths are not execution discovery paths. Before starting the harness, the task runner verifies a fingerprint of both normalized descriptors against host admission, including the registered factory reference and settings schema. Use matching host and task versions.

Workflow selection preserves the existing skill, MCP, environment, and lifecycle contracts. Capability admission is a metadata claim; verify task execution, accounting, and any requested skill/MCP behavior separately.

Resource Stats

For an example of collecting resource stats inside a task container, follow the SWE-bench walkthrough. The Resource Usage and Stats guide explains the configuration model, collection scope, and metric interpretation.

Environment Forwarding

Harbor delivers values into the task environment. NeMo Fabric forwards values from its task-side process to the adapter. Listing a variable in environment.env_names does not deliver it from the Harbor host to the task.

The existing FabricAgent bridge follows this flow for fabric_environment_env:

  1. The bridge resolves host-variable references, such as {"GITHUB_TOKEN": "${GITHUB_TOKEN}"}, and adds the values to Harbor’s managed extra_env.
  2. The retained run specification contains only the names in its environment_env_names payload field.
  3. Harbor supplies the values to the task runner’s execution environment.
  4. The task runner looks up the names and inserts the values into config.environment.env before calling NeMo Fabric.

environment_env_names is Harbor’s existing transport field. environment.env_names is the core NeMo Fabric forwarding field described in Set Environment Values Or Forward Them By Name. This addition does not migrate the Harbor bridge to the core field: Harbor’s retained run specification contains names, but its runner still puts resolved values in environment.env, where values are serialized into the NeMo Fabric run plan.

Keep using Harbor’s managed environment and redaction rules for credentials. Core env_names does not replace Harbor’s secret delivery or redaction.