LangChain Blog公式発表·2026年7月9日 00:00·約20分

モデルではなくハネスを調整する：Nemotron 3 Ultra のプレイブック

#LLM #エージェント #ハネス最適化 #オープンソースモデル #コスト削減

整理・翻訳:ainew.jp 編集システムAIによる自動処理作り方と限界

本文の状態

日本語全文を表示中

詳細モードで約20分の本文を読めます。

同じ出来事の情報源

この情報源を基点に整理

LangChain Blog

まず要点

Nemotron 3 Ultra の重みを変更せず、ハネスのみを調整することで Deep Agents スイートで 0.86 のスコアを達成し、最前線の Opus 4.8 とほぼ同等の性能を約10分の1のコストで実現した。

AI深層分析を開く2026年8月7日 03:45

キーポイント

ハネス最適化によるコスト削減と性能向上

評価指標がハネス開発の訓練データとなる

すべての変更はトレース駆動のループを通じて検証され、安価なスクリーニングを経て複数の試行で勝者が確認されるまで採用されないという厳格なプロセスを確立した。

ハネスとモデルの適合性が性能を決定する

モデルに最適化されたハネスは能力を発揮させるが、適合しないハネスはモデルが足場との戦いを余儀なくさせ、重みを変えずともスコアに明確な差が生じる。

ハネス調整の限界とポストトレーニングの必要性

ハネス最適化は足場由来の失敗を修正できるが、モデル内部に存在しない能力を追加することはできず、調整で改善が見られない場合はポストトレーニングが必要となる。

ハネス調整の重要性

モデルとハネスが整合していない場合、モデルはタスクではなく足場との戦いやループに能力を費やす。

重要な引用

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.

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.

A matched harness lets the model spend its capability on the work; a mismatched one makes it fight the scaffolding.

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.

編集コメントを表示

編集コメント

モデルの重みを変更せずにハネスのみを調整するアプローチは、リソース制約のある環境における実用性を高める重要な示唆となる。この手法は、オープンソースモデルのポテンシャルを引き出すための新たな標準的な開発プロセスとして注目されるだろう。

Source Article

元記事を日本語で読む

本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。

重要なポイント

圧倒的なコスト効率で最前線級のエージェント品質を実現。 ハネス（システム構成）のチューニングのみで、Nemotron 3 Ultra は Deep Agents スイートで最高スコア 0.86 を達成しました。これは Opus 4.8 の最高スコア 0.87 にほぼ匹敵する結果です。一方で、実行コストは約 10 分の 1（フルスイートでの 1 回あたり約 4.48 ドル対 43.48 ドル）に抑えられ、レイテンシも同等でした。
評価データこそがハネス開発の訓練データである。 すべての変更はトレース駆動型のループを通じて検証され、まずは低コストでスクリーニングされます。結果が試行全体で一貫して勝利し、かつ他の機能を低下させない場合にのみ採用されました。
適合性が能力発揮度を決定する。 ハネスとモデルの相性が良ければ、モデルは本来の能力をタスク遂行に集中できます。逆に相性が悪ければ、モデルは足場（スキャフォールディング）との戦いにエネルギーを奪われ、その差が重み（ウェイト）に触れなくてもスコアに明確な影響として現れます。
ハネスチューニングには限界がある。 これは足場由来の失敗を修正するものですが、重みに含まれていない能力を追加することはできません。したがって、あらゆるハネス変更を通じて結果が横ばいになる場合、それはさらにフックを追加する問題ではなく、ポストトレーニング（学習後の調整）が必要な段階を示しています。

エージェントとは「モデル」と「ハネス」の組み合わせです。モデルは思考を行い、ハネス（システムプロンプト、ツール説明、ミドルウェアなど）はその思考が行われる足場となります。私たちはこれまで最前線のモデルを囲むハネスのチューニングを行ってきましたが、今回はオープンソースモデルでどこまで可能かを探ることに注力しました。

オープンモデルこそが、この分野の面白さを引き立てています。すでに本格的なエージェント作業に耐えうるレベルまで進化しており、最先端 API に比べてコストは桁違いに安価です。モデルの重み（weights）を入手できるため、自分でホストして微調整することも可能ですし、ロックインを避けながら複数のクラウドプロバイダーのエンドポイントを利用することもできます。

ただし注意すべき点は、能力のあるモデルでも、そのために設計されていないハネス（harness）では性能を発揮できない可能性があることです。これが私たちが解決しようとした課題です。

Nemotron コーリションの一員として、私たちは Deep Agents 内で Nemotron 3 Ultra を微調整するのが最適だと判断しました。NVIDIA はこのモデルをエージェントハネスの中で動作するように設計しており、その可能性をどこまで引き出せるか探ってみたかったのです。

ハネスこそが制御できる部分です

箱を開けた状態の汎用ハネスは、特定のモデルに合わせてチューニングされていません。モデルにハネスの調整を行わずに使うのは妥当なデフォルト選択ではありますが、最善の結果を得るための唯一の方法ではありません。

ハネスとはモデルを取り巻く環境全体を指し、モデルはその中にあるエンジンです。両者が適切にマッチしているとき、モデルは自らの能力をタスク遂行に集中できます。しかし、両者が適合していない場合、モデルは能力の多くを足場の構築や、すでに持っている情報の再確認、早期終了、あるいは無限ループへの陥入といった問題解決に費やすことになります。

モデルの性能以上に重要なのが、その使い方の「枠組み（ハネス）」です。これは以前から示してきた通りで、Terminal-Bench 2.0 では、モデル自体は一切変更せずに gpt-5.2-codex のスコアを 52.8 から 66.5 に引き上げました。当時、トップ 30 台からトップ 5 圏内への躍進です。

また、モデルごとの専用ハネスプロファイルを提供した際にも、プロンプティングガイドに準拠させることで、tau2-bench の厳選されたサブセットにおいて 10〜20 ポイントの向上を実現しました。同じ重みを持つモデルでも、その背後にある構造（スケフォールディング）が変われば、スコアは大きく異なるのです。

こうしたハネス側の最適化には、データドリブンなアプローチを採用し、失敗のパターンをトレースから掘り起こして改善を行いました。今回のケーススタディである「Nemotron 3 Ultra」は、もともと独自に高い性能を持つオープンモデルです。特に NVIDIA は、単なる一問一答のチャットだけでなく、長時間実行されるツール活用タスクにおいてエージェントとして一貫した振る舞いをするよう、このモデルを特別にポストトレーニングしています（詳細は NVIDIA の公式発表をご覧ください。そこではアジェンティックなポストトレーニングの背景やアーキテクチャについて解説されています）。

今回の実験では、モデル自体は固定したまま、ハネス側のみを変更しました。具体的にはシステムプロンプト、ツールの説明、そしてモデルとツール呼び出しを仲介するミドルウェアです。生成設定についてはベンダー推奨のデフォルト値を維持しており、温度（temperature）やトップ p、思考予算（thinking budgets）の変更による影響は一切含まれていません。

評価（evals）から始める

モデルに合わせてハネスを調整する際、まず手掛かりとなるのは評価（evals）です。学習の指標がない状態で調整を行えば、それは単なる推測に過ぎません。過去の事例に基づいて推測でハネスを調整すると、その特定のケースに過剰適合し、汎用性が失われてしまいます。

私たちはハネスエンジニアリングにおける評価をトレーニングデータとして捉えています。各事例は、エージェントが適切な行動をとったか、望ましい結果を生み出したかを判断する指標となり、そのフィードバックが次の改善点を導きます。

エージェントの開発プロセスは、通常のソフトウェア開発とは様子が異なります。通常のソフトウェアでは、入力と出力、そして期待される挙動を明確に把握できます。しかし、エージェントにおいては入力空間が広大であり、許容される出力も多岐にわたります。さらに、プロンプトやツール、オーケストレーションのわずかな変更が、あるケースは解決しても別のケースで不具合を引き起こす可能性があります。

そのため、開発は反復的なプロセスとなり、真実の基準となる LangSmith のトレースを参照しながらループを回していく必要があります。

評価（Evaluate）: モデルに対して行動検証スイートを実行する。
観察（Observe）: 失敗した実行のトレースを読み込み、どこでどのように失敗したかを特定する。
診断（Diagnose）: 失敗した軌跡をクラスタリングし、行動パターンとして分類する。
エンジニアリング（Engineer）: ハネスの一部に対して、ターゲットを絞った変更を加える。
再評価（Re-evaluate）: 変更のコストレベルを引き上げながら上位へプロモートし、その改善が持続する場合のみ採用する。

以下の図は、エージェント開発のライフサイクルループをベースに、評価環境を用いてハネス（実行枠組み）を調整する際に適用したバージョンです。

このループを正確に機能させるために、私たちは二つの原則を徹底しました。第一に、ランダム性によって結果がわずかに変動するため、一度の良好な実行では何も証明できません。そのため、変更が採用されるのは、複数の試行で再現され、かつ他の機能を悪化させない場合に限りました。第二に、テストコストを抑えつつ、評価の精度を損なわないようにしました。すべての変更に対してフルセットを実行するのではなく、候補はまず小さく安価なスクリーニングから始め、そこで有効性が確認されて初めて、より広範で高コストな実行に進みました。

スライス（一部）でのスクリーニングには、その範囲に含まれないタスクで性能が低下するリスクがあります。これを防ぐため、スクリーンは代表性を重視して設計しました。異なる振る舞いを網羅したサンプル全体で効果がある変更は、フルセットでも同様に機能すると考えられるからです。代表的なサンプリングを行うことで、高コストな最終評価前に確かな信頼を得ることができました。

2 つのレイヤー

プロンプト

プロンプト調整においては、まずシステムプロンプトの書き換えを試みるのが自然な発想です。変更コストが最も低いため、誰もがここから始めます。しかし、私たちの経験では、これは過大評価されすぎている部分です。広範な書き換えや「より良いエージェントになれ」といった一般的な指示は、効果的なモデルにおける本質的な失敗——それは単なる言葉遣いの問題ではない場合が多い——を解決するには無力で、結果として効果が薄れてしまいます。

成功するアプローチは、書き換えではなく、短く単一の目的を持つブロックです。これは、トレーシングで失敗した特定の振る舞い一つに焦点を当てたものです。例えば、モデルがタスクを完了しても結果を報告しない場合、その事実だけを記述すれば十分です。

code


__FENCE_0__

ただし注意が必要です。これらのブロックは相互に影響し合うからです。単独では何の効果もない指示も、ハネス内の別の箇所で変更を加えた組み合わせによって初めて効果を発揮することがあります。そのため、個々の要素だけでなく、組み合わせによるテストも行いました。

ミドルウェア

「ほとんどの場合」ではなく「毎回」発生する振る舞いに対しては、プロンプトだけでは対応できません。モデルやツール呼び出しの周囲で動作するミドルウェア（フック）には、二つの異なる役割があります。これらは明確に区別して扱うべきです。

一つ目はコードによる強制です。モデルやツールの呼び出し回数に上限を設けることで、タイムアウト前にループが無限に続くのを防ぎます。また、一時的なツール失敗に対しては「一度だけ再試行」する仕組みで対応します。これらはモデルに何かを要求するものではなく、ループの挙動そのものを変更するものです。

二つ目の役割、そして Nemotron において最も大きな成果をもたらしたのは文脈エンジニアリングです。これは、モデルが関連する必要がある瞬間に、適切な信号を提示することです。すべてのルールをシステムプロンプトに前もって詰め込んで「定着することを期待する」のではなく、トレーシングで軌跡を追跡し、モデルが誤った行動をとった地点でガイダンスを注入しました。

最も明確な事例の一つが、ファイル読み込み時に「1 ページ分の結果が返ってきたら、まだ続きがある可能性が高いと仮定して読み続ける」というルールでした。この文言は read_file ツールの説明欄に記述されていたのですが、何の効果もありませんでした。モデルは最初のページだけを読み、「これでファイル全体を把握した」と判断して回答を終了してしまったのです。

同じ文言を、ツールが返す結果の直前に配置しただけで状況は一変しました。するとモデルはその指示に従うようになりました。同じ言葉でも、置く場所が変わるだけで結果が正反対になるのです。これ以降、私たちは「ルールに何を記すべきか」だけでなく、「どこに記せば読まれるか」という点にも注力するようになりました。

同様の傾向は、信号を伝えるメッセージの位置にも見られました。単にプロンプト内にあるかどうかではなく、どのメッセージに乗せて伝えるかが重要だったのです。Nemotron は、必要なタイミングで会話内にメッセージとして送られるガイダンスに対して最も確実に反応しました。システムプロンプト内の恒久的なルールよりも、その方が効果的でした。

そこで私たちは、エージェントが行動する前に計画を立てるよう指示する中間層（ミドルウェア）を追加し、計画が記述された後に「実行前に計画を見直すよう」という第 2 のメッセージを注入する仕組みを導入しました。トレースログを見ると、モデルはこの注入されたメッセージを拾い上げ、実際に行動を起こしています。つまり、「計画を立ててから実行前の見直しを行う」というプロセスが機能したのです。一方、システムプロンプト内に同じ指示を記述しただけでは、その内容は埋もれてしまい、効果が薄れてしまう傾向がありました。

機能しなかった試み

私たちが試したことの多くは採用されませんでした。これはあえて言うべきことですが、成功事例だけを報告するチューニングループは、往々にして過学習を起こしています。多くの妥当な変更は無効であり、いくつかの変更は状況を悪化させました。また、ある調整項目が単独で効果を発揮するのではなく、他の項目と組み合わさって初めて価値を発揮することも少なくありませんでした。

私たちが堅持したルールは、「振る舞いクラスの修正」を行い、「ベンチマーク対策」を行わないことです。優れた調整項目は、特定のテスト内容を知っている必要はありません。例えば、ファイル読み込みがフルページを返すような実際の条件において、すでに十分に構築されたツールと同じように機能するべきです。

ある変更案は、単一の評価（eval）で使われている特定のフレーズに依存していたため、採用を見送りました。これはスコアを飾るだけであり、次のエージェントに関する何の教訓も得られないからです。

チューニングがもたらしたもの

一つのスコアだけでは、エージェントが全体的に向上したのか劣化したのかはわかりますが、どこが改善されたかはわかりません。したがって、ハネス（評価枠組み）の変更を信頼する前に、LangChain の Deep Agents スイートに対して Nemotron を実行し、エージェントが時間を費やす主要なタスクごとに個別にスコアリングを行いました。具体的には、「ファイル操作」「ツール呼び出し」「情報取得」「多段階会話の維持」「長いコンテキストの要約」です。

このように細分化してスコアリングすることで、結果は特定の能力を指し示します。これにより、ハネス側の問題なのか、モデル自体の問題なのかを区別することが可能になります。

チューニングにより、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 ドル）でした。精度やプロンプトキャッシングの有無によっては、この優位性は 3 倍から 10 倍の範囲に及びます。また、中位数のレイテンシも Opus と同等のテストあたり約 10 秒で維持されました。

実務的なエージェントが実際に扱うタスクにおいて、より安価に実行可能な最前線に近い振る舞いが可能になることは、構築や評価の対象範囲を大きく変えるものです。

境界線はどこにあるか

ハネスの調整には限界があり、その限界がどこにあるかを理解することは、成功を収めることと同じくらい重要です。モデルへのプロンプト方法やツールの説明方法、結果・再試行・ループの処理方法など、失敗の原因が「足場」にある場合にこそ、ハネスの調整は有効な手段となります。

実際、生産環境でエージェントが不安定になる原因の多くはこの領域に存在するため、ハネスを調整することが、有能なモデルを実働させるための最速の方法であるケースがほとんどです。

しかし、ハネスの調整では、モデル自体に元々備わっていない能力を追加することはできません。モデル周囲のあらゆる設定を変えても改善が見られない場合、それは問題が「重み（ウェイト）」の中にあることを示すシグナルであり、解決策は別のフックを追加することではなく、ポストトレーニング（微調整後の学習）にあります。

どの種類の失敗に直面しているかを正確に見極めることが、継続して調整すべきか、それとも学習を始めるべきかの判断基準となります。

ハネスの作業の中にも、もう一つの境界線を引く必要があります。変更には、あらゆるエージェントに役立つコアなハネス改善と、特定のモデルに必要な設定を記述するプロファイル構成があります。

「読み進めるよう促す通知」は、全ページ読み込み時に発火するコアな改善であり、これはすべてのユーザーのためにハネス側に実装すべきものです。一方、Nemotron のガイダンスをシステムプロンプトではなくインバンドで提供することは、プロファイル構成の範疇です。

どの調整プロジェクトにおいても最も興味深い問いは、「特定の変更が実際にどこに位置するか」です。その分野における重要な姿勢とは、各変更を可能な限りコア側に押し上げることです。なぜなら、このモデルやこのタスクが姿を消した後も、長く価値を生み続けるのは、よりコアに近いバージョンだからです。

さらに読むべき記事

Harbor と LangChain の連携：エージェント評価のための統合スタック

N. Bohm、

N. Hollon

2026 年 6 月 30 日

7 分

事例紹介

Box AI の構築：エンタープライズ向けコンテンツプラットフォームがディープエージェントで AI ネイティブへ移行した方法

ソフィア・スリコフスキ（Sofia Sulikowski）

2026 年 6 月 12 日

分

ケーススタディ

ハーモニックが Deep Agents と LangSmith で Scout を再構築し、リテンションを 4 倍に引き上げた方法

ソフィア・スリコフスキー

2026年6月3日

分

エージェントが実際に何をしているかを確認する

エージェントエンジニアリングプラットフォーム「LangSmith」は、開発者がすべてのエージェントの意思決定をデバッグし、変更の評価を行い、ワンクリックでデプロイできるツールです。

原文を表示

要点

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.

code

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.

code

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.