Validate and document Harbor task and agent interoperability in NeMo Gym

[anwithk]

Parent: #1451
Related: #1701

Use cases, pain points, and background

Nemotron benchmark workflows increasingly need to run tasks and agents from the Harbor ecosystem through NeMo Gym. Many users may already have tasks authored in Harbor format, particularly for benchmarks such as Terminal-Bench.

The current Harbor Agent documentation describes Terminus as the reference integration and indicates that other agents may require a compatibility layer for Gym output schemas, trajectories, token metadata, and multi-turn training.

However, the current interoperability boundary is unclear:

• Can an existing Harbor task set run through NeMo Gym without modification?
• Can any Harbor-installed agent be selected through configuration alone?
• Does Terminal-Bench with Pi require Gym or Harbor code changes?
• Which combinations work for evaluation versus RL training?
• When both native Gym and Harbor-backed implementations exist, which path should Nemotron teams use?

This ambiguity affects benchmark support for Nemotron and allowing users to bring existing tasks and workflows into NeMo Gym.

Description

Define, validate, and document the current Harbor ↔ NeMo Gym interoperability contract.

At minimum, validate these representative scenarios:

Task source	Agent	Workflow
Terminal-Bench	Pi	Evaluation through Gym + Harbor
Terminal-Bench	Terminus	Evaluation through Gym + Harbor
Existing custom Harbor-format task set	Supported Harbor agent	Evaluation without modifying the tasks
Representative supported combinations	Pi and/or Terminus	RL rollout collection and training compatibility

For each scenario, determine whether it is:

1. Supported through configuration only
2. Supported with an existing Gym compatibility wrapper
3. Supported only after implementing a new adapter
4. Unsupported, with the limitation documented

The investigation should distinguish changes required at each layer:

• Harbor task format
• Harbor environment configuration
• Agent selection and initialization
• Gym agent wrapper
• Output and trajectory normalization
• Token metadata required for multi-turn RL training
• Verifier and reward propagation

If Terminal-Bench + Pi is an intended supported combination and currently requires code changes, implement or separately track the smallest compatibility layer needed to make it work.

Deliverables

• A documented support matrix for Harbor tasks, agents, and Gym workflows
• A reproducible Terminal-Bench + Pi example
• A reproducible example using an existing custom Harbor-format task set without task modification
• Commands, configuration, commit/version information, and representative logs or rollout artifacts for each validated path
• Clear guidance for Nemotron teams when both native Gym and Harbor-backed implementations are available
• Automated smoke coverage for combinations claimed to work through configuration alone

Acceptance Criteria

• Terminal-Bench is run through NeMo Gym + Harbor with Pi, and the result is documented.
• The issue explicitly states whether Terminal-Bench + Pi requires configuration changes, an agent adapter, or other code changes.
• At least one existing custom Harbor-format task set runs through NeMo Gym without modifying the task contents.
• Evaluation support is documented separately from RL training support.
• The supported-agent matrix identifies configuration-only, wrapped, and unsupported agents.
• Reproducible configs, commands, versions, and representative output artifacts are provided.
• Any compatibility code required for the intended supported paths has automated smoke coverage.
• The Harbor Agent README documents the supported interoperability contract and known limitations.
• Nemotron guidance is documented for benchmarks available through both native Gym and Harbor-backed paths.

Out of Scope

• Exhaustively testing every Harbor task and agent combination
• Replacing validated native Gym benchmark integrations
• Declaring all Harbor agents RL-compatible without verifying the required trajectory and token metadata
• Benchmark score-parity validation beyond what is necessary to validate the integration path