収束するのかは、まだ分かりません
Whether Harnesses Converge Is Still Unknown
最後の質疑応答で、ハリソン・チェイスは、将来すべてのエージェント・ハーネスが同じ形に近づくのかという問いに答えます。話者は、収束するかどうかは分からないと明確に述べます。これは結論ではなく、現時点での予測の限界を示す発言です。
In the final question-and-answer session, Harrison Chase answers whether all agent harnesses will eventually move toward the same form. He clearly says that he does not know whether they will converge. This is not a conclusion; it shows the limits of the current forecast.
ただし、出発点についての勧めははっきりしています。まずは既製のハーネス（off-the-shelf harness）を使います。基本的な仕事なら、汎用ハーネスがよい開始点になり、価値を早く届けやすいからです。
However, his recommendation about where to start is clear. Start with an off-the-shelf harness. For basic tasks, a general-purpose harness is a good starting point and can deliver value quickly.
カスタマイズには連続した幅があります
Customization Has a Continuous Spectrum
話者の考えは、「既製か自作か」という二択ではありません。おおまかには、次の幅で考えられます。
The speaker's view is not a choice between only “off-the-shelf” and “build it yourself.” It is better understood as a spectrum.
- 既製のハーネス：汎用的なループと機能を、そのまま、または少し設定して使います。
- フックやミドルウェアを加えたハーネス：エージェントやモデル、ツールの呼び出しの前後に、確認、制限、処理を差し込みます。
- 完全にカスタムした認知アーキテクチャ：特定の仕事のために、検索、計画、実行、検証などの順序を明示的に設計します。ここでいう認知アーキテクチャ（cognitive architecture）は、特定の流れをエージェントに進ませる、目的に合わせた手順のことです。
- Off-the-shelf harness: Use a general loop and its capabilities as they are, or with a small amount of configuration.
- A harness with hooks or middleware: Insert checks, limits, or processing before and after agent, model, or tool calls.
- A fully custom cognitive architecture: Explicitly design the order of steps for a particular task, such as search, planning, execution, and validation. Here, a cognitive architecture means a purpose-built sequence that guides an agent through a specific flow.
この幅では、カスタム化は「すべてを書き直すこと」を意味しません。まず汎用ハーネスを使い、必要な場所だけにフックやミドルウェアを足す方法もあります。用途が狭くなるほど、より多くのゲートやチェックを加え、最後には明示的な独自フローを選ぶこともあります。
On this spectrum, customization does not mean rewriting everything. A team can start with a general-purpose harness and add hooks or middleware only where needed. As the use case becomes narrower, the team may add more gates and checks and eventually choose an explicit custom flow.
分布のずれと、予測しやすさ
Distribution Shift, Control, and Predictability
カスタマイズの理由は、仕事がモデルの得意な範囲から離れることです。ここでいう分布とは、モデルが学習してきた例や、その例に似た仕事の範囲です。用途がその範囲から遠くなる、つまり分布のずれ（distribution shift）が大きくなるほど、話者はハーネスを調整する必要が大きくなると考えます。これは境界が決まった二値の判定ではなく、連続した目安です。
One reason to customize is that the task moves away from the range where the model is strong. Here, distribution means the range of examples the model has learned from and the kinds of work similar to those examples. As a use case moves farther from that range—that is, as distribution shift grows—the speaker sees a stronger case for tuning the harness. This is a continuous heuristic, not a binary test with a fixed boundary.
また、仕事が分布の外にあるかどうかだけが理由ではありません。金融サービスの顧客のように、動作を細かく制御し、結果を予測しやすくしたいチームもあります。その場合、汎用ハーネスが使えるとしても、手順が見える、より明示的なアーキテクチャを好む可能性があります。制御と予測可能性も、カスタマイズを選ぶ理由です。
Distribution is not the only reason. Customers in financial services, for example, may want to control behavior closely and make results predictable. In that situation, they may prefer a more explicit architecture with visible steps even when a general-purpose harness is available. Control and predictability are also reasons to customize.
モデルとハーネスは一緒に変わります
Models and Harnesses Adapt Together
話者は、OpenAIのモデルとAnthropicのモデルでは、ファイル編集の方法が異なると述べます。したがって、すべてのモデルに同じファイル編集の実装を使うと、それぞれのモデルの強みを保てないことがあります。モデルを作る会社とハーネスを作る側は、異なる決まりや方法に合わせて、お互いに最適化できます。
The speaker says that OpenAI and Anthropic models use different methods for editing files. Therefore, one file-editing implementation for every model may fail to preserve each model's strengths. Model labs and harness builders can optimize around different conventions and methods.
質疑応答では、名前が示されていないベンチマークの参加者が、あるファイル編集の方法は別の方法より完全に優れていると考えた、という話も出ます。しかし、ベンチマーク名、指標、データは示されていません。したがって、これは紹介された観察であって、一般に証明された結論ではありません。
The Q&A also mentions that an unnamed benchmark participant thought one file-editing method was strictly better than another. However, no benchmark name, metric, or data is provided. This is therefore a reported observation, not a conclusion proven in general.
コーディングでは近づいても、他の領域では分かれるかもしれません
Coding May Converge While Other Domains Diverge
話者は、コーディングのような領域では、モデルとハーネスが似た方向へ収束する可能性を考えています。多くのモデルが似た作業を扱い、ファイル編集などの共通の仕組みが整えば、汎用的な方法が十分に強くなるかもしれません。ただし、これは確定した未来の説明ではありません。
The speaker considers that models and harnesses may move in a similar direction in a domain such as coding. If many models handle similar work and common mechanisms such as file editing become established, a general-purpose method may become strong enough. This is not a confirmed account of the future.
一方で、生物学のような別の領域では、専門的な知識や手順が必要になり、ハーネスが分かれていく可能性もあります。生物学の例は、実際に観測された結果ではなく、将来あり得る違いを示す仮の例です。つまり、コーディングでは収束し、別の領域では分岐するという両方の未来が考えられます。
In another domain, such as biology, specialized knowledge and procedures may instead cause harnesses to diverge. The biology example is hypothetical; it is not a reported result. It presents a possible future difference. In other words, both futures remain possible: convergence in coding and divergence in another domain.
速く変わる分野では、測定が必要です
Fast-Moving Fields Need Measurement
この不確かさを、印象だけで判断してはいけません。評価（evals）は、決めた仕事をどれだけうまく行えたかを測ります。可観測性（observability）は、どのコンテキストが入り、どんな手順やツールが動いたかを見えるようにします。評価は結果を比べ、可観測性はその結果になった道筋を調べます。両方があれば、既製のハーネス、途中までカスタムしたハーネス、完全にカスタムしたハーネスを同じ仕事で比較できます。
Teams should not make this uncertain choice from impressions alone. Evals measure how well the system performs a defined task. Observability makes visible what context entered the run and what steps and tools ran. Evals compare the outcome; observability examines the path that produced it. Together, they allow a team to compare an off-the-shelf harness, a partly customized harness, and a fully custom harness on the same work.
例：選択を小さく試す
Example: Test the Choice in Small Steps
たとえば、同じタスクのセットを使って、既製のハーネスと、ファイル編集の前後にチェックを入れたハーネスを実行します。評価で結果を比べます。差が見つかったら、可観測性の記録を開き、必要な情報がモデルに届かなかったのか、手順の制御が足りなかったのかを調べます。その結果をもとに、ハーネス、モデル、またはコンテキストのどこを次に変えるかを決めます。これは、選択を一度で決めるのではなく、測定しながら進める方法です。
For example, use the same set of tasks to run an off-the-shelf harness and a harness with checks before and after file editing. Compare their results with an eval. If a difference appears, open the observability record and ask whether the model lacked the needed information or whether the flow lacked sufficient control. Then decide whether to change the harness, the model, or the context. This approach moves forward by measuring the choice instead of deciding it once and for all.
基本的な仕事では、既製の汎用ハーネスから始めるのが実用的です。分布のずれが大きい場合や、制御と予測可能性が重要な場合は、フック、ミドルウェア、または完全にカスタムした認知アーキテクチャへ進みます。将来ハーネスが収束するのか、領域ごとに分かれるのかは、まだ未解決です。だからこそ、評価と可観測性を使って、実際の仕事で生じる小さな違いを測ることが重要です。
For basic tasks, starting with a general-purpose off-the-shelf harness is practical. When distribution shift is large, or when control and predictability matter, a team can move toward hooks, middleware, or a fully custom cognitive architecture. Whether harnesses will converge or diverge by domain is still unresolved. That is why evals and observability are important: they measure the small differences that appear in real work.