モデルではなくハネスを調整する：Nemotron 3 Ultra のプレイブック
LangChain Blog は、Nemotron 3 Ultra の性能最大化においてモデル自体の改修ではなく、実行環境であるハネス（枠組み）の最適化が鍵となる戦略を提示している。
キーポイント
ハネス最適化アプローチの提唱
モデルパラメータの変更や再学習に依存せず、推論時の実行環境や設定（ハネス）を調整することで性能を最大化する手法が紹介されている。
Nemotron 3 Ultra の特性活用
特定のモデルアーキテクチャの強みを引き出すために、柔軟な実行フレームワークの調整が必要であるという前提に基づいたプレイブックが提供されている。
実装コストと効率性の向上
大規模なモデル改修に要するリソースを削減し、既存インフラ上で即座に性能を発揮させるための具体的な調整手順が含まれている。
影響分析・編集コメントを表示
影響分析
このアプローチは、AI モデルの導入コストと時間を削減し、現場での迅速な実装を可能にする重要な示唆を含んでいます。特に大規模モデルの運用において、ハードウェアやパラメータの限界を超えて性能を引き出すための実用的な指針として、開発者コミュニティに広く受け入れられる可能性があります。
編集コメント
モデルの性能限界に直面した際、再学習という重労働ではなく、設定や環境の微調整で突破口を開く発想は非常に実用的です。
主要なポイント
- 費用の大幅削減により、最前線レベルのエージェント品質を実現。ハネス（注：エージェントを動作させるためのシステム構成やプロンプト群）のみをチューニングした結果、Nemotron 3 Ultra は Deep Agents スイートで最高スコア 0.86 を達成し、Opus 4.8 の最高スコア 0.87 にほぼ匹敵しました。これは、1 回あたりのコストが約 10 分の 1（フルスイートでの実行コストはそれぞれ約 4.48 ドル対 43.48 ドル）でありながら、レイテンシも同等であることを意味します。
- 評価（Evals）はハネス作業におけるトレーニングデータです。すべての変更はトレース駆動型のループを通じて行われ、まず低コストでスクリーニングされ、試行全体で勝利が再現され、かつ他の機能に悪影響を及ぼさない場合にのみ採用されました。
- 適合性が、タスクに到達する能力の量を決定します。ハネスとモデルが適切にマッチしていれば、モデルは自身の能力を作業に集中させることができます。一方、不適合であればモデルは足場（スキャフォールディング）と戦うことになり、その差は重み（ウェイト）に触れなくてもスコアとして現れます。
- ハネスのチューニングには上限があります。これは足場に起因する失敗を修正しますが、重みに含まれていない能力を追加することはできません。したがって、ハネスの変更を通じて結果が一向に改善しない場合は、別のフック（接続点）ではなく、ポストトレーニング（学習後の調整）の段階である可能性を示唆しています。
エージェントとは「モデル＋ハネス」です。モデルは思考を行い、ハネス（システムプロンプト、ツール説明、ミドルウェアなど）はそのモデルが動作する足場となります。私たちはこれまで最前線のモデルを囲むハネスをチューニングしてきましたが、今回はオープンソースのモデルでどこまで到達できるかを確認したかったのです。
オープンモデルこそがこの議論を面白くするポイントです。これらのモデルは、実際のエージェント作業に真剣に取り組めるほど十分に良くなり、フロンティア API の一部のコストで済みます。重み（weights）を手に入れることができるため、自分でモデルをホストしてファインチューニングすることもできますし、ロックインなしでさまざまなクラウドプロバイダーのエンドポイントを利用することも可能です。ただし、課題として、そのモデル用に設計されていないハネス（harness）では、能力のあるモデルでも期待通りの性能を発揮できない場合があります。これが私たちが解決しようとした部分です。
Nemotron コーリションの一員として、私たちは Deep Agents 内でチューニングすべきモデルは Nemotron 3 Ultra だと考えました。NVIDIA は Nemotron をエージェントハネス内で動作するように構築しており、それがどこまで引き出せるかを確認したかったのです。
ハネスこそがあなたが制御できる部分です
箱から出したままの状態で、汎用的なハネスはそのモデル用にチューニングされていません。ハネスのチューニングを行わずにモデルを使用することは合理的なデフォルトですが、最善策ではありません。
ハネスとはモデルを取り巻くすべての要素であり、モデルはそれの中にあるエンジンです。この 2 つが適切にマッチしている場合、モデルはその能力をタスク遂行に集中させることができます。しかし、マッチしていない場合は、その能力を足場（scaffolding）との戦いや、すでに持っている詳細の再要求、早期停止、あるいはループに費やしてしまいます。
適合性は、多くの人が予想する以上に重要であり、私たちは以前にもそれを示しました。Terminal-Bench 2.0 では、gpt-5.2-codex を 52.8 から 66.5 に引き上げました。これは当時、上位 30% から上位 5% への飛躍であり、モデル自体には一切手を加えていません。モデルごとのハーネスプロファイル をリリースした際にも、プロンプティングガイドに準拠させることで、選別された tau2-bench のサブセットで 10 から 20 ポイントの向上を実現しました。同じ重みでも、異なるスケルトン（基盤構造）を使用すれば、スコアは異なります。
私たちはこのハーネス側の作業を、データ駆動型のアプローチで行いました。つまり、失敗パターンを検出するためにトレースデータを掘り起こす手法です。ケーススタディの対象となったのは Nemotron 3 Ultra です。これはすでに独自に大きな進歩を遂げたオープンモデルですが、NVIDIA はこれを単なる単発チャットではなく、長期実行型のツール使用タスクの一大スイートにおいて、エージェントハーネス全体で一貫した動作をするように特別にポストトレーニング（再学習）しました (NVIDIA の発表記事 では、このアジェンティックなポストトレーニングと背後にあるアーキテクチャについて解説されています)。
モデルは固定したまま、ハーネスのみを変更しました。具体的にはシステムプロンプト、ツール説明、およびモデル呼び出しとツール呼び出しの間のミドルウェアです。生成設定はベンダー推奨のデフォルト値のまま維持しており、温度（temperature）、top-p、思考予算（thinking budgets）の変更による影響は一切含まれていません。
評価（evals）から始める
モデルに適合するハネスを調整する際は、常に評価（evals）から始めます。学習シグナルがなければ推測することになり、推測によって調整されたハネスは直前に見たデータに対して過学習を起こしてしまいます。私たちは 評価をハネスエンジニアリングのトレーニングデータとして扱っています：各ケースは、エージェントが適切な行動を取ったか、あるいは適切な結果を生み出したかについてのシグナルを提供し、そのシグナルが次の変更を導きます。
エージェントの開発は通常のソフトウェア開発とは異なります。通常のソフトウェアでは、通常、入力、出力、そして期待される動作が明確に知られています。しかし、エージェントにおいては入力空間が広く、多くの出力が許容され、プロンプトやツール、オーケストレーションへのわずかな変更が一つのケースを修正する一方で別のケースを壊してしまう可能性があります。したがって、この作業は反復的に行われ、LangSmith のトレース（trace）を唯一の真実源として ループ として実行されます。
- 評価。モデル全体に対して行動テストスイートを実行する。
- 観察。各失敗した実行のトレースを読み、どこでどのように失敗したかを確認する。
- 診断。失敗した軌跡を行動パターンごとにクラスタリングする。
- エンジニアリング。ハネスの一部に対して、1 つのターゲットを絞った変更を加える。
- 再評価。コスト段階を上昇させて変更を適用し、その成果が持続する場合のみ採用する。
以下の図は、上記のループに基づいて評価環境を用いたハネスの調整に特化して修正された、当社のエージェント開発ライフサイクルループの変形版です：
このループを誠実に保つために、2 つの分野が機能しました。第一に、見た目上好しい実行 1 つでは何も証明できません。ランダム性により実行結果はわずかに変動するためです。この点を踏まえ、変更が認められるのは、試行全体で再現され、かつ他の機能を後退させない場合のみでした。第二に、信号（シグナル）を失うことなくテストコストを低く抑えました。すべての変更に対してフルスイートを実行するのではなく、候補はまず小さく安価なスクリーニングから始め、それが実証されて初めてより広範で高コストの実行に進むようにしました。
スライス（断片）でのスクリーニングにおけるリスクは、そのスライスが対象としないタスクを後退させてしまうことです。これを防ぐため、スクリーンは代表性を持たせました：異なる行動を網羅するサンプル全体で一貫して機能する変更は、通常、フル実行でも機能します。代表性のあるサンプリングを行うことで、高コストのパスに入る前に確かな信頼性を確保しました。
2 つのレイヤー
プロンプト
プロンプトにおいては、最初の直感としてシステムプロンプトの書き換えを試みました。変更コストが最も低いため誰もがここから始めますが、私たちの経験では、これは過大評価されすぎているようです。広範な書き換えや「より優れたエージェントになるように」といった一般的な指示は、能力のあるモデルにおける真の問題が言葉遣いの問題ではないため、効果が薄れてしまいます。
その地位を確立するのは、書き換えの対極にあるものです：特定の振る舞いにおいてトレーシングで失敗したことを観察し、それに対して単一の目的を持つ短いブロックです。モデルがタスクを完了しても結果を報告しない場合、その事象のみを記述し、他は何も加えません。
<final_answer_completeness>
ツール呼び出しが成功した後、最終回答はタスクが完了したという事実だけでなく、具体的な結果を報告しなければなりません。ユーザーの要求に応えるための主要なエンティティ、アクション、識別子、タイトル、受信者、サービス、ステータス、または値を含めてください。ユーザーが複数の質問をした場合は、それぞれの質問に対して対応するツールの出力から回答してください。
</final_answer_completeness>
ただし、これらのブロックは相互に作用するため注意が必要でした。単独では何の効果もない指示も、ハネス（harness）内の他の場所の変更と組み合わされることで効果を発揮し始めるため、組み合わせについてもテストを行いました。
ミドルウェア
すべての場合に発生する必要がある振る舞いに対しては、プロンプトだけでは対応できません。モデルとそのツール呼び出しの周囲で実行されるフックであるミドルウェアには2つの異なる役割があり、これらを区別して扱う価値があります。
第一はコードによる強制です。モデルやツールの呼び出し数に上限を設けることで、タイムアウトする前にループが終了します。一度限りのリトライにより、一時的なツールの失敗も吸収されます。これらはモデルに対して何も要求するものではなく、ループの動作そのものを変更するものです。
第二の仕事、そして Nemotron において最も多くの作業を担ったのは文脈エンジニアリングです。これは、関連性のある瞬間に適切なシグナルをモデルの前に配置することです。すべてのルールをシステムプロンプトに前もって読み込ませてそれが定着することを期待するのではなく、トレース内の軌跡を観察し、モデルが誤ったポイントでガイダンスを注入しました。
最も明確な例は、遵守したかったルールでした。「ファイルの読み込み結果が 1 ページ分返ってきた場合、さらに続きがあると仮定して読み続ける」というものです。これを read_file ツールの説明に記述しても何の効果もありませんでした。モデルは最初のページだけを読み、ファイル全体を取得したと誤認して回答しました。同じ言葉をそのまま変更せず、ツールが返す内容の中に移動させたところ、機能し始めました。なぜなら、今やそれはモデルが読み込んでいるデータのすぐ隣に表示されるようになったからです。同じ言葉でも、置かれた場所が変われば結果は正反対になります。これ以降、ルールを「何と記すべきか」だけを問うのではなく、「どこに現れるべきか」を問うようになりました。
必ず JSON 形式で返してください。translation フィールドのみ。他のフィールド (technical_terms 等)は一切追加しないこと — 余計なフィールドを書こうとして本文翻訳がトークン上限で打ち切られる事故を防ぐため:
{"translation": "翻訳全文"}
同じパターンは、信号がどのメッセージに乗って伝わるかという点でも現れました。単にプロンプト内にあるかツール結果にあるかだけでなくです。Nemotron は、システムプロンプト内の恒久的なルールよりも、必要なタイミングで会話のメッセージとして提供されるガイダンスに対して最も確実に反応しました。そこで、エージェントが行動する前に計画を立てるよう指示するミドルウェアを追加し、計画が記述された後に実行前にその計画を見直すよう求める第 2 のメッセージを注入しました。トレースを見ると、Nemotron はこれらの注入されたメッセージを検知してそれに基づき行動し、計画を立てた後で自分の作業を確認しに戻りました。一方、システムプロンプト内の同じ指示は、この文脈では効果が薄れてしまう傾向がありました。
機能しなかったアプローチ
私たちが試したことの多くが採用されませんでした。これははっきりと述べる価値があります：勝利報告しか行わないチューニングループは、通常過学習を起こしているのです。多くの妥当な変更は何の効果ももたず、いくつかの変更は状況を悪化させました。また、複数のレバー（調整要素）は単独では効果を発揮せず、他のレバーとの組み合わせで初めてその役割を果たすことがわかりました。
私たちが堅持したルールは、振る舞いクラスの修正を行うことであり、ベンチマーク用のトリックに頼らないことです。優れたレバーは、特定のテスト内容を知っている必要なく、すでに適切に構築されたツールが動作するのと同じように、実際の条件（例えば、完全なページを返すファイル読み込みなど）に対して機能します。私たちはある変更を却下しました。それは単一の評価（eval）からの特定のフレーズに依存していたためです。この変更はスコアを artificially に高めることには成功したかもしれませんが、次のエージェントに関する何の教訓も得られませんでした。
ハーネスの調整がもたらしたもの
単一のスコアでは、エージェントが改善したか悪化したかはわかるものの、どこがどう変わったかはわかりません。そのため、ハーネスの変更を信頼する前に、Nemotron を LangChain の Deep Agents スイートに対して実行し、エージェントが時間を費やす業務ごとに個別にスコアリングを行いました。具体的には、ファイルの扱い、ツールの呼び出し、情報の取得、多段階の会話の維持、長いコンテキストの要約などです。このようにスコアリングすることで、結果は特定の能力を指し示すため、ハーネスの問題とモデルの問題を見分ける手がかりとなります。
調整により、Nemotron 3 Ultra はプロファイルなしのベースライン（約 0.80）から、典型的な実行で約 0.84 に向上しました。最高値は 0.86 で、Opus 4.8 の最高値 0.87 にほぼ匹敵する結果でした（Opus は通常 0.86 程度で動作します）。プロファイルなしで約 0.80 からスタートするのは、非常に優れた初期性能であり、NVIDIA のアジェンティック事後トレーニングの直接的な成果です。このモデルはすでにツール使用や多段階作業に流暢であるため、ハーネスが構築する土台として高い底値を提供しています。
要約タスクは当初最も改善の余地が大きく、チューニングによってその課題は完全に解消されました。プロファイルがない場合、ハネスは圧縮に関するガイダンスを提供せず、そのため大規模な新しいタスクに移行する際に圧縮をスキップするか、オフロードされた履歴ファイルを読み込む代わりに要約された会話から回答するという問題が発生しました。プロファイルには明示的な圧縮ガイダンスが追加され、モデルを適切な圧縮動作へと誘導します。ツールの使用も大幅に改善されました。検索およびファイル操作は最初からすでに強力であり、これはモデルが実際のエージェント作業向けにポストトレーニング済みであることを示すもう一つの兆候ですが、チューニングによってさらに向上しました。これらの改善を合計すると、エージェントが実際に依存するタスクで良好に動作するモデルが完成します。
会話タスクは例外であり、その平坦な線自体が重要な示唆を与えています。これらはハネスが修正するような低レベルの失敗ではありません。これは、長期的な多段階タスクを通じてバックエンドの状態を保持するなど、長期にわたる振る舞いの問題です。このような課題は、スキャフォールディングではなくモデルのポストトレーニングによって解決されるべきものです。プロファイルでこれらをチューニングすることは、汎用性のあるプロファイルを構築するのではなく、ベンチマークの形状に合わせて適合させることを意味してしまいます。ハネスが到達できるすべての状況を通じて安定した結果を示すことは、ハネスを超えた方向を指しており、継続的なポストトレーニングとハネス作業が相乗効果を発揮する領域に明確に対応しています。
これらすべてを行う価値がある理由はコストです。同等の最良の実行品質において、チューニングされたオープンモデルは、Opus に比べて 1 回あたりの実行コストが約 10 分の 1 で、フルスイート全体で約 4.48 ドル対 43.48 ドルでした。精度やプロンプトキャッシング（prompt caching）の状況によっては、この優位性は 3 倍から 10 倍の間で維持されます。また、中位数のレイテンシも、テストあたり約 10 秒という点で Opus と同等に保たれていました。実際のワークエージェントが実行するタスクにおいて、1 回あたりのコストを抑えながら最前線に近い振る舞いを実現することは、構築や評価に許容できる範囲を根本的に変えるものです。
境界線はどこにあるか
ハルネス（harness）のチューニングには上限があり、その限界を知ることは成果を上げるのと同等に重要です。モデルへのプロンプト設計やツールの説明方法、結果・リトライ・ループの処理方法など、失敗が「足場」に起因する場合には、これが適切な手段となります。生産環境でエージェントが信頼性を欠く原因の多くはここに存在するため、ハルネスをチューニングすることが、有能なモデルを実働させるための最速の方法であるケースがほとんどです。
しかし、モデル自体に内在していない能力を追加することはできません。モデル周囲の設定を変更しても失敗が改善しない場合、それは問題が「重み（weights）」の中に存在しているというシグナルであり、解決策は別のフックを追加することではなく、ポストトレーニング（post-training）によるものです。どのような種類の失敗に対処しようとしているかを理解することが、継続してチューニングを行うべきか、それともトレーニングを開始すべきかを判断する鍵となります。
もう一つ引くべきラインがあり、それはハルネス作業そのものの内部を走るものです。変更は、あらゆるエージェントに役立つコアとなるハルネスの改善である場合もあれば、特定のモデルが必要とするものを符号化したプロファイル設定である場合もあります。「読み続ける」通知はコアとなる改善であり、全ページ読取時に発火するため、すべての人のためのハルネスに含まれるべきです。Nemotron のガイダンスをシステムプロンプトではなくインバンドで提供するのはプロファイル設定です。あらゆるチューニングプロジェクトにおける最も興味深い質問は、特定の変更が実際にどこに位置するかという点であり、その規律とは、各変更を正直に可能な限りコア側に押しやることです。なぜなら、このモデルとこのタスクが消えた後も利益をもたらすのは、そのようなバージョンだからです。
さらに読む
- ハルネスエンジニアリングによるディープエージェントの改善
- より良いハルネス：評価を用いたハルネスのヒルクライミングのためのレシピ
- 異なるモデルとよく連携するようにディープエージェントをチューニングする
関連コンテンツ
観測可能性と評価 (Observability & Evals)
パートナー
Harbor x LangChain: エージェント評価のための統一スタック
N. Bohm,
N. Hollon
2026 年 6 月 30 日
7
分
事例研究
Box AI の構築：エンタープライズ向けコンテンツプラットフォームが Deep Agents でどのように AI ネイティブへ移行したか
ソフィア・スリコフスキ (Sofia Sulikowski)
2026 年 6 月 12 日
6
分
事例研究
Harmonic が Deep Agents と LangSmith を活用して Scout を再構築し、リテンションを 4 倍に引き上げた方法
ソフィア・スリコフスキ (Sofia Sulikowski)
2026 年 6 月 3 日
8
分
エージェントが実際に何をしているかを確認する
LangSmith は、エージェントエンジニアリングプラットフォームとして、開発者がすべてのエージェントの意思決定をデバッグし、変更の評価を行い、ワンクリックでデプロイできるように支援します。
原文を表示
Key Takeaways
- Near-frontier agent quality at a fraction of the cost. Tuning the harness alone took Nemotron 3 Ultra to a best run of 0.86 on the Deep Agents suite, nearly matching Opus 4.8's best of 0.87, at roughly 10x lower cost per run (about $4.48 against $43.48 on the full suite) with latency at parity.
- Evals are the training data for harness work. Every change ran through a trace-driven loop, screened cheaply first, and earned its place only if the win repeated across trials and regressed nothing else.
- Fit decides how much capability reaches the task. A matched harness lets the model spend its capability on the work; a mismatched one makes it fight the scaffolding, and the gap between the two shows up in the score without touching the weights.
- Harness tuning has a ceiling. It fixes failures that come from the scaffolding, but it can't add what isn't in the weights, so a result that stays flat through every harness change points to post-training rather than another hook.
An agent is a model plus a harness. The model does the thinking, and the harness (the system prompt, the tool descriptions, the middleware) is the scaffolding it works inside. We've tuned harnesses around frontier models before, but, this time, we wanted to see how far we could get with an open model.
Open models are where this gets interesting. They've gotten good enough to take seriously for real agent work, and they cost a fraction of a frontier API. You get the weights, so you can host and fine-tune the model yourself, or you can use an endpoint from a variety of Cloud providers without lock-in. The catch is that a capable model can still underperform in a harness that wasn't built for it, which is the part we set out to fix.
As a member of the Nemotron Coalition, we thought Nemotron 3 Ultra was the right model to tune inside Deep Agents. NVIDIA built Nemotron to work inside agent harnesses, and we wanted to see how far we could take it.
The harness is the part you control
Out of the box, a generic harness is not tuned to the model. Using a model without harness tuning is a reasonable default but not best you can do.
The harness is everything around the model, and the model is the engine inside it. When the two are matched, the model spends its capability on the task. When they are not, it spends capability fighting the scaffolding, re-asking for details it already has, stopping early, or looping.
The fit matters more than most people expect, and we've shown it before. On Terminal-Bench 2.0, we took gpt-5.2-codex from 52.8 to 66.5, roughly Top 30 to Top 5 at the time, without touching the model. When we shipped per-model harness profiles, we improved a curated subset of tau2-bench by 10 to 20 points by conforming to prompting guides. The same weights with different scaffolding lead to a different score.
We did that harness-side work using a data-driven approach, mining traces for failure patterns. The case study is Nemotron 3 Ultra, an open model that already comes a long way on its own, because NVIDIA post-trained it specifically to behave consistently across agent harnesses, not just single-turn chat, on a large suite of long-running, tool-using tasks (NVIDIA's launch post covers the agentic post-training and the architecture behind it).
We kept the model fixed and changed only the harness: the system prompt, the tool descriptions, and the middleware around model and tool calls. Generation settings stayed at the vendor-recommended defaults, so nothing below comes from changing temperature, top-p, or thinking budgets.
Start with evals
Tuning a harness to a model always starts with evals. Without a learning signal you are guessing, and a harness tuned by guessing overfits to whatever you looked at last. We treat evals as the training data for harness engineering: each case contributes a signal about whether the agent took the right action or produced the right outcome, and that signal guides the next change.
Agent development does not look like normal software. With normal software you usually know the inputs, the outputs, and the expected behavior. With an agent the input space is wide, many outputs are acceptable, and a small change to the prompt, the tools, or the orchestration can fix one case and break another. So the work is iterative, run as a loop with the LangSmith trace as the source of truth:
- Evaluate. Run the behavioral suite across the models.
- Observe. Read each failing run's trace to see where and how it failed.
- Diagnose. Cluster the failing trajectories into behavior patterns.
- Engineer. Make one targeted change of a piece of the harness.
- Re-evaluate. Promote the change up a cost ladder, and keep it only if the win survives.
The diagram below is a variation of our agent development lifecycle loop, specifically modified for tuning a harness using an eval environment based on the above loop:
Two disciplines kept the loop honest. First, a single good-looking run proved nothing since runs change slightly due to randomness. With this in mind, a change earned its place only if it repeated across trials and regressed nothing else. Second, we kept the cost of testing low without giving up signal. Rather than run the full suite on every change, a candidate started on a small, cheap screen and only earned a broader, more expensive run once it proved out.
The risk in screening on a slice is regressing a task the slice doesn't touch. We kept the screen representative to guard against that: a change that holds across a sample spanning the different behaviors usually holds on the full run too. By taking representative samples, our screens bought real confidence before the expensive pass.
The two layers
Prompts
With prompting, our first instinct was to rewrite the system prompt. It's the cheapest thing to change, so it's where everyone starts, but, in our experience, it's the most overrated. Broad rewrites and general "be a better agent" instructions tend to wash out, because a capable model's real failures usually aren't wording problems.
What earns its place is the opposite of a rewrite: short, single-purpose blocks aimed at one behavior you've watched fail in the traces. If a model finishes a task but never states the result, you write exactly that and nothing more.
After tool calls succeed, the final answer must report the concrete result, not just that the task is done. Include the key entity, action, identifier, title, recipient, service, status, or value that answers the user's request. If the user asked multiple questions, answer each one from its matching tool output.
We had to be careful, however, because these blocks interacted. An instruction that does nothing on its own can start pulling its weight once it's paired with a change elsewhere in the harness, so we also tested combinations.
Middleware
When a behavior has to happen every time instead of most of the time, prompting won't get you there. Middleware, the hooks that run around the model and its tool calls, does two different jobs, and they're worth separating.
The first is enforcement in code. A cap on model and tool calls ends a run that's looping before it times out. A one-shot retry absorbs a transient tool failure. Neither asks the model for anything; they change what the loop does.
The second job, and the one that did most of the work for Nemotron, is context engineering: putting the right signal in front of the model at the moment it's relevant. Instead of front-loading every rule into the system prompt and hoping it stuck, we watched the trajectory in the trace and injected the guidance at the point where the model went wrong.
The clearest example was a rule we wanted followed: when a file read comes back a full page long, assume there's more and keep reading. Written into the read_file tool's description, it did nothing. The model read the first page, assumed it had the whole file, and answered. We moved the same words, unchanged, into what the tool returned, and it started working, because now it showed up right next to the data the model was reading. Same words, different home, opposite result. After that we stopped asking only what a rule should say and started asking where it had to appear to get read.
The same pattern showed up in which message a signal rides in, not just whether it's in the prompt or the tool result. Nemotron responded most reliably to guidance delivered as a message in the conversation at the point of need, rather than a standing rule in the system prompt. So we added middleware that told the agent to plan before acting, then, once the plan was written, injected a second message asking it to review the plan before executing. In the traces it picked those injected messages up and acted on them, planning and then going back to check its work, where the same instructions in the system prompt tended to wash out.
What didn't work
Most of what we tried didn't survive, which is worth saying out loud: a tuning loop that only ever reports wins is usually overfitting. Plenty of plausible changes did nothing, a couple made things worse, and more than one lever only earned its place in combination with another rather than on its own.
The rule we held to was to keep behavior-class fixes, not benchmark tricks. A good lever fires on a real condition (say, any file read that returns a full page) the way a well-built tool already would, with no knowledge of the specific tests in front of it. We threw out one change that helped precisely because it leaned on a phrase from a single eval: it would have flattered the score and taught us nothing about the next agent.
What the tuning bought us
A single score tells you an agent got better or worse, not where. So before trusting any harness change, we ran Nemotron against LangChain's Deep Agents suite, which scores it separately on the jobs an agent spends its time on: working with files, calling tools, retrieving information, holding a multi-turn conversation, summarizing long context. Scored that way, a result points at a specific capability, which is how you tell a harness problem apart from a model one.
Tuning took Nemotron 3 Ultra from a no-profile baseline of about 0.80 to about 0.84 on a typical run, with a best run of 0.86 that nearly matched Opus 4.8's best of 0.87 (Opus typically runs about 0.86). Starting near 0.80 with no profile at all is a strong out-of-the-box result and a direct payoff of NVIDIA's agentic post-training: the model shows up already fluent in tool-using, multi-step work, which gave the harness a high floor to build on.
Summarization had the most headroom going in, and tuning cleared it entirely. Without a profile, the harness gave no compaction guidance, so runs either skipped compaction when moving to a new large task or answered from the summarized conversation instead of reading the offloaded history file. The profile adds explicit compaction guidance that nudges the model towards proper compaction behavior. Tool use also improved significantly. Retrieval and file operations were already strong out of the box, another sign the model came post-trained for real agent work, and tuning still pushed both higher. Add these improvements up, and you have a model that performs well on tasks agents actually lean on.
Conversation is the exception, and the flat line is informative on its own. These weren't the low-level failures a harness fixes. They were long-horizon behavior, like holding backend state across a long multi-turn task, which is the kind of thing model post-training addresses rather than scaffolding. Tuning for them in the profile would have meant conforming to the benchmark's shape instead of building a profile that generalizes. A result that holds steady through everything the harness can reach is pointing past the harness, and it maps cleanly onto where continued post-training compounds with harness work.
The reason any of this is worth doing is cost. At matched best-run quality, the tuned open model ran roughly 10x cheaper per run than Opus, about $4.48 against $43.48 on the full suite, and the advantage holds anywhere from 3x to 10x depending on precision and prompt caching. Median latency also stayed at parity with Opus at around ten seconds per test. Near-frontier behavior on the work agents actually do, for less per run, changes what you can afford to build and to evaluate.
Where the lines are
Harness tuning has a ceiling, and knowing where it is matters as much as the wins. It's the right tool when the failure comes from the scaffolding: how the model is prompted, how its tools are described, how results, retries, and loops are handled. Most of what makes an agent unreliable in production lives there, so tuning the harness is usually the fastest way to get a capable model working.
What it can't do is add what isn't in the model. When a failure doesn't respond to anything you change around the model, that's the signal it lives in the weights, and the fix is post-training, not another hook. Knowing which kind of failure you're looking at is what tells you whether to keep tuning or start training.
There's a second line worth drawing, and it runs inside harness work itself. A change can be a core harness improvement that helps any agent or a profile configuration that encodes what one model needs. The keep-reading notice is a core improvement: it fires on any full-page read, so it belongs in the harness for everyone. Delivering Nemotron's guidance in-band rather than in the system prompt is profile configuration. The most interesting question in any tuning project is where a given change actually sits, and the discipline is pushing each one as far toward core as it honestly goes, because that's the version that keeps paying off after this model and this task are gone.
Further reading
- Improving Deep Agents with harness engineering
- Better Harness: a recipe for harness hill-climbing with evals
- Tuning Deep Agents to work well with different models
Related content
Observability & Evals
Partner
Harbor x LangChain: A Unified Stack for Evaluating Agents
N. Bohm,
N. Hollon
June 30, 2026
7
min
Case Studies
Building Box AI: How an Enterprise Content Platform Went AI-Native with Deep Agents
Sofia Sulikowski
June 12, 2026
6
min
Case Studies
How Harmonic Rebuilt Scout on Deep Agents and 4x'd Retention with LangSmith
Sofia Sulikowski
June 3, 2026
8
min
See what your agent is really doing
LangSmith, our agent engineering platform, helps developers debug every agent decision, eval changes, and deploy in one click.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み