エージェントハーネスの解剖学
LangChainのブログ記事は、AIエージェントを構成する「ハーネス」（モデルを実用的な作業エンジンに変えるシステム）の定義、構成要素、設計アプローチを解説し、モデル単体ではできない機能をハーネスが補完する重要性を論じている。
キーポイント
エージェントの構成定義
エージェントは「モデル（知性）」と「ハーネス（実用化システム）」の和として定義され、生のモデルはハーネスによって状態管理、ツール実行、フィードバックループなどの機能を付与されて初めて実用的なエージェントとなる。
ハーネスの具体的構成要素
ハーネスには、システムプロンプト、ツール/スキル/MCP、インフラ（ファイルシステム、サンドボックス）、オーケストレーションロジック（サブエージェント生成、モデルルーティング）、決定論的実行のためのフック/ミドルウェアなどが含まれる。
ハーネスが必要な理由
モデル単体では、インタラクションを超えた永続的な状態の維持、コードの実行、リアルタイム知識へのアクセス、作業環境のセットアップなどが不可能であり、これらの機能を実現するためにハーネスが必須である。
ハーネスエンジニアリングのアプローチ
望ましいエージェントの振る舞いから逆算してハーネスを設計する「ハーネスエンジニアリング」により、人間は有用な事前知識を注入してエージェントの行動を導き、モデルの能力を拡張・補正することができる。
ファイルシステムの重要性
エージェントがデータを読み書きし、コンテキストを超えた情報をオフロードし、セッションを超えて作業を永続化するための基盤的なハーネスプリミティブとして機能する。
Bashとコード実行による汎用ツール化
事前に設計されたツールセットに制約されず、エージェントがコードを書いて実行することで自律的に問題を解決できるようにする。
コンテキスト管理の重要性
コンテキストローテーション（Context Rot）は、コンテキストウィンドウが埋まるにつれてモデルの推論能力が低下する現象であり、ハーネスは効果的なコンテキストエンジニアリング戦略を提供する必要がある。
影響分析・編集コメントを表示
影響分析
この記事は、AIエージェント開発の実践的なフレームワークを提供し、単にモデルの性能向上を追うだけでなく、システム設計（ハーネス）の重要性を業界に認識させる可能性がある。特に、エージェントの実用化を目指す開発者や企業にとって、設計指針となる概念整理と具体例を示している点で影響が大きい。
編集コメント
エージェント開発の現場で暗中模索されがちな「モデル以外の部分」を「ハーネス」として明確に定義し、その設計思想を体系化した点が実務的価値が高い。今後のエージェント開発の共通言語となる可能性を秘めた解説記事。
imageBy Vivek Trivedy
TLDR: エージェント = モデル + ハーネス。ハーネスエンジニアリングとは、モデルを作業エンジンに変えるために、モデルの周りにシステムを構築する方法です。モデルは知性を含み、ハーネスはその知性を有用なものにします。本稿ではハーネスとは何かを定義し、現在および将来のエージェントが必要とするコアコンポーネントを導き出します。
誰か「ハーネス」を定義してください！
エージェント = モデル + ハーネス
もしあなたがモデルでないなら、あなたはハーネスです。
ハーネスとは、モデル自体以外のすべてのコード、設定、実行ロジックのことです。生のモデルはエージェントではありません。しかし、ハーネスが状態、ツール実行、フィードバックループ、強制可能な制約などを与えることで、エージェントになります。
具体的には、ハーネスには以下のようなものが含まれます：
システムプロンプト
ツール、スキル、MCP（Model Context Protocol）＋ それらの説明
バンドルされたインフラストラクチャ（ファイルシステム、サンドボックス、ブラウザ）
オーケストレーションロジック（サブエージェントの生成、ハンドオフ、モデルルーティング）
決定論的実行のためのフック/ミドルウェア（圧縮、継続、リントチェック）
エージェントシステムの境界をモデルとハーネスの間で分割する方法は、多くの乱雑な方法があります。しかし私の意見では、これは最も明確な定義です。なぜなら、モデルの知性を中心にシステムを設計することを考えさせるからです。
この記事の残りの部分では、コアハーネスコンポーネントを順を追って説明し、モデルというコアプリミティブから逆算して、各要素が存在する理由を導き出します。
なぜハーネスが必要なのか…モデルの視点から
モデルがそのままではできないことを、エージェントにさせたいことがあります。ここでハーネスが登場します。
モデルは（ほとんど）テキスト、画像、音声、動画などのデータを受け取り、テキストを出力します。それだけです。そのままでは、以下のことはできません：
インタラクションを超えた永続的な状態の維持
コードの実行
リアルタイム知識へのアクセス
作業を完了するための環境のセットアップとパッケージのインストール
これらはすべてハーネスレベルの機能です。LLM（大規模言語モデル）の構造上、有用な作業を行うためには、何らかの機械装置でラップする必要があります。
例えば、「チャット」のような製品UX（ユーザー体験）を得るために、以前のメッセージを追跡し、新しいユーザーメッセージを追加するwhileループでモデルをラップします。これを読んでいる皆さんは、すでにこの種のハーネスを使用したことがあります。主な考え方は、望ましいエージェントの振る舞いを、ハーネスの実際の機能に変換したいということです。
望ましいエージェントの振る舞いからハーネスエンジニアリングへ逆算する
ハーネスエンジニアリングは、人間が有用な事前知識を注入してエージェントの振る舞いを導くのに役立ちます。そして、モデルがより高性能になるにつれて、ハーネスは以前は不可能だったタスクを完了するために、モデルを外科的に拡張・修正するために使用されてきました。
すべてのハーネス機能の網羅的なリストを説明するつもりはありません。目標は、モデルが有用な作業を行うのを助けるという出発点から、一連の機能を導き出すことです。以下のようなパターンに従います：
望む（または修正したい）振る舞い → モデルがこれを達成するのを助けるハーネス設計
永続的ストレージとコンテキスト管理のためのファイルシステム
エージェントに永続的ストレージを持たせ、実際のデータとインターフェースし、コンテキストに収まらない情報をオフロードし、セッションを超えて作業を維持させたいと考えます。
モデルは、そのコンテキストウィンドウ内の知識に対してのみ直接操作できます。ファイルシステム以前は、ユーザーはコンテンツを直接モデルにコピー/ペーストする必要がありましたが、それは扱いにくいUXであり、自律エージェントでは機能しません。世界はすでにファイルシステムを使って作業を行っており、モデルはそれらを使用する方法に関する何十億ものトークンで自然に訓練されていました。自然な解決策は次のようになりました：
ハーネスはファイルシステムの抽象化とファイルシステム操作のためのツールを提供します。
ファイルシステムは、それが可能にするもののために、最も基本的なハーネスプリミティブと言えるでしょう：
エージェントは、データ、コード、ドキュメントを読み取るためのワークスペースを手に入れます。
作業は、すべてをコンテキストに保持するのではなく、段階的に追加およびオフロードできます。エージェントは中間出力を保存し、単一のセッションを超えて持続する状態を維持できます。
ファイルシステムは自然なコラボレーションの場です。複数のエージェントと人間が共有ファイルを通じて調整できます。エージェントチームのようなアーキテクチャはこれに依存しています。
Gitはファイルシステムにバージョン管理を追加し、エージェントが作業を追跡し、エラーをロールバックし、実験をブランチできるようにします。以下でファイルシステムについて再度取り上げます。なぜなら、それは私たちが必要とする他の機能のための重要なハーネスプリミティブであることが判明するからです。
汎用ツールとしてのBash + コード
人間があらかじめすべてのツールを設計する必要なく、エージェントに自律的に問題を解決させたいと考えます。
現在の主要なエージェント実行パターンはReAct（Reasoning and Acting）ループです。モデルが推論し、ツール呼び出しを介してアクションを取り、結果を観察し、whileループで繰り返します。しかし、ハーネスはロジックを持っているツールしか実行できません。あらゆる可能なアクションに対してユーザーにツールを構築させる代わりに、より良い解決策は、エージェントにbashのような汎用ツールを与えることです。
ハーネスはbashツールを提供し、モデルがコードを記述・実行することで自律的に問題を解決できるようにします。
Bash + コード実行は、モデルにコンピュータを与え、残りを自律的に解決させるための大きな一歩です。モデルは、事前に設定された固定セットのツールに制約されるのではなく、コードを介して独自のツールをその場で設計できます。
ハーネスは他のツールも提供しますが、コード実行は自律的問題解決のためのデフォルトの汎用戦略となっています。
作業を実行・検証するためのサンドボックスとツール
エージェントは、安全に行動し、結果を観察し、進捗を遂げるために、適切なデフォルトを持つ環境を必要とします。
モデルにストレージとコードを実行する能力を与えましたが、それらすべてはどこかで発生する必要があります。エージェントが生成したコードをローカルで実行することはリスクが高く、単一のローカル環境は大規模なエージェントワークロードには拡張できません。
サンドボックスはエージェントに安全な操作環境を与えます。ローカルで実行する代わりに、ハーネスはサンドボックスに接続してコードを実行し、ファイルを検査し、依存関係をインストールし、タスクを完了できます。これにより、コードの安全で隔離された実行が可能になります。セキュリティを強化するために、ハーネスはコマンドを許可リスト化し、ネットワーク分離を強制できます。サンドボックスはまた、オンデマンドで環境を作成し、多くのタスクに分散させ、作業が完了したら破棄できるため、スケールを可能にします。
良い環境には良いデフォルトのツールが付属します。ハーネスは、エージェントが有用な作業を行えるようにツールを設定する責任があります。これには、言語ランタイムとパッケージの事前インストール、gitとテストのためのCLI（コマンドラインインターフェース）、ウェブインタラクションと検証のためのブラウザが含まれます。
ブラウザ、ログ、スクリーンショット、テストランナーなどのツールは、エージェントが作業を観察・分析する方法を与えます。これは、アプリケーションコードを書き、テストを実行し、ログを検査し、エラーを修正できる自己検証ループを作成するのに役立ちます。
モデルは、そのままでは独自の実行環境を設定しません。エージェントがどこで実行されるか、どのツールが利用可能か、何にアクセスできるか、どのように作業を検証するかを決定することは、すべてハーネスレベルの設計上の決定です。
継続的学習のためのメモリと検索
エージェントは、見たことを覚え、訓練時に存在しなかった情報にアクセスできるべきです。
モデルは、その重みと現在のコンテキストにあるもの以外に追加の知識を持ちません。モデルの重みを編集するアクセス権がない場合、「知識を追加する」唯一の方法はコンテキスト注入を介することです。
メモリについては、ファイルシステムが再びコアプリミティブです。ハーネスはAGENTS.mdのようなメモリファイル標準をサポートし、エージェント起動時にコンテキストに注入されます。エージェントがこのファイルを追加・編集するにつれて、ハーネスは更新されたファイルをコンテキストにロードします。これは、エージェントが一つのセッションから知識を永続的に保存し、その知識を将来のセッションに注入する継続的学習の一形態です。
知識カットオフ（knowledge cutoff）は、ユーザーが直接提供しない限り、モデルが更新されたライブラリバージョンのような新しいデータに直接アクセスできないことを意味します。最新の知識については、Web検索やContext7のようなMCPツールが、トレーニングが停止した後に存在しなかった新しいライブラリバージョンや現在のデータなど、知識カットオフを超えた情報にエージェントがアクセスするのを助けます。
Web検索と最新のコンテキストをクエリするためのツールは、ハーネスに組み込むのに有用なプリミティブです。
コンテキスト腐敗（Context Rot）との戦い
エージェントのパフォーマンスは、作業の過程で低下すべきではありません。
コンテキスト腐敗（Context Rot）は、コンテキストウィンドウが埋まるにつれて、モデルの推論とタスク完了能力が低下する様子を説明します。コンテキストは貴重で希少なリソースであるため、ハーネスはそれを管理する戦略を必要とします。
今日のハーネスは、主に優れたコンテキストエンジニアリングのための配信メカニズムです。
圧縮（Compaction）は、コンテキストウィンドウがほぼ埋まったときに何をするかに対処します。圧縮がなければ、会話がコンテキストウィンドウを超えたらどうなるでしょうか？一つの選択肢はAPIエラーですが、それは良くありません。ハーネスはこのケースに対して何らかの戦略を使用する必要があります。したがって、圧縮は既存のコンテキストウィンドウをインテリジェントにオフロードおよび要約し、エージェントが作業を継続できるようにします。
ツール呼び出しオフロード（Tool call offloading）は、有用な情報を提供せずにコンテキストウィンドウを雑然とさせる可能性のある大きなツール出力の影響を軽減するのに役立ちます。ハーネスは、しきい値トークン数を超えるツール出力の先頭と末尾のトークンを保持し、完全な出力をファイルシステムにオフロードして、モデルが必要に応じてアクセスできるようにします。
スキル（Skills）は、エージェント起動時にコンテキストにロードされるツールやMCPサーバーが多すぎて、エージェントが作業を開始する前にパフォーマンスが低下する問題に対処します。スキルは、段階的開示（progressive disclosure）を介してこれを解決するハーネスレベルのプリミティブです。モデルは起動時にスキルのフロントマターをコンテキストにロードすることを選択しませんでしたが、ハーネスはこれをサポートして、モデルをコンテキスト腐敗から保護できます。
長期的な自律実行
エージェントに、複雑な作業を、自律的に、正確に、長期間にわたって完了させたいと考えます。
自律的なソフトウェア作成は、コーディングエージェントにとっての究極の目標です。しかし、現在のモデルは早期停止、複雑な問題の分解における課題、そして作業が複数のコンテキストウィンドウにまたがる際の一貫性の欠如に悩まされています。優れたハーネスは、これらすべてを考慮して設計されなければなりません。
ここで、先に述べたハーネスの基本要素が複合的に作用し始めます。長期的な作業には、複数のコンテキストウィンドウにわたって作業を継続するための、永続的な状態、計画、観察、および検証が必要です。
セッションをまたいだ作業を追跡するためのファイルシステムとgit。エージェントは長いタスクの中で数百万のトークンを生成するため、ファイルシステムは作業を永続的に記録し、時間の経過に伴う進捗を追跡します。gitを追加することで、新しいエージェントが最新の作業とプロジェクトの履歴を迅速に把握できるようになります。複数のエージェントが協働する場合、ファイルシステムはエージェントが協力できる作業の共有台帳としても機能します。
作業を継続するためのラルフループ。ラルフループは、フックを介してモデルの終了試行を傍受し、クリーンなコンテキストウィンドウに元のプロンプトを再注入することで、エージェントに完了目標に向けた作業の継続を強制するハーネスのパターンです。ファイルシステムは、各イテレーションが新鮮なコンテキストで開始されるが、前のイテレーションから状態を読み取るため、これを可能にします。
軌道を維持するための計画と自己検証。計画とは、モデルが目標を一連のステップに分解するときのことです。ハーネスは、適切なプロンプティングと、ファイルシステム内の計画ファイルの使用方法に関するリマインダーの注入によってこれをサポートします。各ステップを完了した後、エージェントは自己検証を通じて自身の作業の正確性を確認することで恩恵を受けます。ハーネスのフックは、事前定義されたテストスイートを実行し、失敗時にエラーメッセージとともにモデルにループバックしたり、モデルに自身のコードを独立して自己評価するよう促したりできます。検証は、ソリューションをテストに基づかせ、自己改善のためのフィードバック信号を生成します。
ハーネスの未来
モデルトレーニングとハーネス設計の結合
今日のClaude CodeやCodexのようなエージェント製品は、モデルとハーネスをループ内に含めて事後学習されています。これは、ハーネス設計者がモデルが本質的に得意であるべきと考えているアクション（ファイルシステム操作、bash実行、計画、サブエージェントとの作業の並列化など）において、モデルが改善するのに役立ちます。
これはフィードバックループを生み出します。有用な基本要素が発見され、ハーネスに追加され、次世代のモデルをトレーニングする際に使用されます。このサイクルが繰り返されるにつれ、モデルはトレーニングされたハーネス内でより有能になっていきます。
しかし、この共進化は一般化において興味深い副作用をもたらします。それは、ツールのロジックを変更するとモデルのパフォーマンスが悪化するといった形で現れます。良い例は、ファイルを編集するためのapply_patchツールロジックに関するCodex-5.3プロンプティングガイドで説明されています。真に知的なモデルであれば、パッチ方法の切り替えにほとんど苦労しないはずですが、ハーネスをループ内に含めたトレーニングは、この過剰適合を生み出します。
しかし、これはあなたのタスクに最適なハーネスが、モデルが事後学習されたハーネスであることを意味しません。Terminal Bench 2.0 Leaderboardは良い例です。Claude Code内のOpus 4.6は、他のハーネス内のOpus 4.6よりもはるかに低いスコアです。以前のブログでは、ハーネスを変更するだけで、当社のコーディングエージェントをTerminal Bench 2.0でTop 30からTop 5に改善した方法を示しました。あなたのタスクに合わせてハーネスを最適化することで、まだ多くの効果を引き出す余地があります。
imageハーネスエンジニアリングの行方
モデルがより有能になるにつれ、今日ハーネス内にあるものの一部はモデルに吸収されていくでしょう。モデルは、計画、自己検証、長期的な一貫性を本質的により上手く行えるようになり、例えば、コンテキスト注入の必要性が少なくなるでしょう。
それは、ハーネスの重要性は時間とともに低下するはずであることを示唆しています。しかし、プロンプトエンジニアリングが今日でも価値を持ち続けているのと同様に、ハーネスエンジニアリングも優れたエージェントを構築するために有用であり続ける可能性が高いです。
確かに、今日のハーネスはモデルの欠陥を一時的に修正しますが、それらはまた、モデルの知能をより効果的にするために、その周囲にシステムを設計します。適切に設定された環境、適切なツール、永続的な状態、検証ループは、その基本知能に関わらず、あらゆるモデルをより効率的にします。
ハーネスエンジニアリングは、LangChainで当社のハーネス構築ライブラリdeepagentsを改善するために使用している、非常に活発な研究領域です。以下は、現在私たちが探求しているいくつかの未解決で興味深い問題です：
共有コードベースで並行して作業する数百のエージェントを調整すること
自身のトレースを分析してハーネスレベルの障害モードを特定し修正するエージェント
事前設定されるのではなく、与えられたタスクに対して必要なツールとコンテキストをジャストインタイムで動的に組み立てるハーネス
このブログは、ハーネスとは何か、そしてそれが私たちがモデルに行わせたい仕事によってどのように形作られるかを定義する試みでした。
モデルは知能を含み、ハーネスはその知能を有用にするシステムです。
より多くのハーネス構築、より良いシステム、そしてより良いエージェントへ。
原文を表示
imageBy Vivek Trivedy
TLDR: Agent = Model + Harness. Harness engineering is how we build systems around models to turn them into work engines. The model contains the intelligence and the harness makes that intelligence useful. We define what a harness is and derive the core components today's and tomorrow's agents need.
Can Someone Please Define a "Harness"?
Agent = Model + Harness
If you're not the model, you're the harness.
A harness is every piece of code, configuration, and execution logic that isn't the model itself. A raw model is not an agent. But it becomes one when a harness gives it things like state, tool execution, feedback loops, and enforceable constraints.
Concretely, a harness includes things like:
System Prompts
Tools, Skills, MCPs + and their descriptions
Bundled Infrastructure (filesystem, sandbox, browser)
Orchestration Logic (subagent spawning, handoffs, model routing)
Hooks/Middleware for deterministic execution (compaction, continuation, lint checks)
There are many messy ways to split the boundaries of an agent system between the model and the harness. But in my opinion, this is the cleanest definition because it forces us to think about designing systems around model intelligence.
The rest of this post walks through core harness components and derives why each piece exists working backwards from the core primitive of a model.
Why Do We Need Harnesses…From a Model's Perspective
There are things we want an agent to do that a model cannot do out of the box. This is where a harness comes in.Models (mostly) take in data like text, images, audio, video and they output text. That's it. Out of the box they cannot:
Maintain durable state across interactions
Execute code
Access realtime knowledge
Setup environments and install packages to complete work
These are all harness level features. The structure of LLMs requires some sort of machinery that wraps them to do useful work.For example, to get a product UX like "chatting", we wrap the model in a while loop to track previous messages and append new user messages. Everyone reading this has already used this kind of harness. The main idea is that we want to convert a desired agent behavior into an actual feature in the harness.
Working Backwards from Desired Agent Behavior to Harness Engineering
Harness Engineering helps humans inject useful priors to guide agent behavior. And as models have gotten more capable, harnesses have been used to surgically extend and correct models to complete previously impossible tasks.
We won’t go over an exhaustive list of every harness feature. The goal is to derive a set of features from the starting point of helping models do useful work. We’ll follow a pattern like this:
Behavior we want (or want to fix) → Harness Design to help the model achieve this.
Filesystems for Durable Storage and Context Management
We want agents to have durable storage to interface with real data, offload information that doesn't fit in context, and persist work across sessions.
Models can only directly operate on knowledge within their context window. Before filesystems, users had to copy/paste content directly to the model, that’s clunky UX and doesn't work for autonomous agents. The world was already using filesystems to do work so models were naturally trained on billions of tokens of how to use them. The natural solution became:
Harnesses ship with filesystem abstractions and tools for fs-ops.
The filesystem is arguably the most foundational harness primitive because of what it unlocks:
Agents get a workspace to read data, code, and documentation.
Work can be incrementally added and offloaded instead of holding everything in context. Agents can store intermediate outputs and maintain state that outlasts a single session.
The filesystem is a natural collaboration surface. Multiple agents and humans can coordinate through shared files. Architectures like Agent Teams rely on this.
Git adds versioning to the filesystem so agents can track work, rollback errors, and branch experiments. We revisit the filesystem more below, because it turns out to be a key harness primitive for other features we need.
Bash + Code as a General Purpose Tool
We want agents to autonomously solve problems without humans needing to pre-design every tool.
The main agent execution pattern today is a ReAct loop, where a model reasons, takes an action via a tool call, observes the result, and repeats in a while loop. But harnesses can only execute the tools they have logic for. Instead of forcing users to build tools for every possible action, a better solution is to give agents a general purpose tool like bash.
Harnesses ship with a bash tool so models can solve problems autonomously by writing & executing code.
Bash + code exec is a big step towards giving models a computer and letting them figure out the rest autonomously. The model can design its own tools on the fly via code instead of being constrained to a fixed set of pre-configured tools.
Harnesses still ship with other tools, but code execution has become the default general-purpose strategy for autonomous problem solving.
Sandboxes and Tools to Execute & Verify Work
Agents need an environment with the right defaults so they can safely act, observe results, and make progress.
We've given models storage and the ability to execute code, but all of that needs to happen somewhere. Running agent-generated code locally is risky and a single local environment doesn’t scale to large agent workloads.
Sandboxes give agents safe operating environments. Instead of executing locally, the harness can connect to a sandbox to run code, inspect files, install dependencies, and complete tasks. This creates secure, isolated execution of code. For more security, harnesses can allow-list commands and enforce network isolation. Sandboxes also unlock scale because environments can be created on demand, fanned out across many tasks, and torn down when the work is done.
Good environments come with good default tooling. Harnesses are responsible for configuring tooling so agents can do useful work. This includes pre-installing language runtimes and packages, CLIs for git and testing, browsers for web interaction and verification.
Tools like browsers, logs, screenshots, and test runners give agents a way to observe and analyze their work. This helps them create self-verification loops where they can write application code, run tests, inspect logs, and fix errors.
The model doesn’t configure its own execution environment out of the box. Deciding where the agent runs, what tools are available, what it can access, and how it verifies its work are all harness-level design decisions.
Memory & Search for Continual Learning
Agents should remember what they've seen and access information that didn't exist when they were trained.
Models have no additional knowledge beyond their weights and what's in their current context. Without access to edit model weights, the only way to "add knowledge" is via context injection.
For memory, the filesystem is again a core primitive. Harnesses support memory file standards like AGENTS.md which get injected into context on agent start. As agents add and edit this file, harnesses load the updated file into context. This is a form of continual learning where agents durably store knowledge from one session and inject that knowledge into future sessions.
Knowledge cutoffs mean that models can't directly access new data like updated library versions without the user providing them directly. For up-to-date knowledge, Web Search and MCP tools like Context7 help agents access information beyond the knowledge cutoff like new library versions or current data that didn't exist when training stopped.
Web Search and tools for querying up-to-date context are useful primitives to bake into a harness.
Battling Context Rot
Agent performance shouldn’t degrade over the course of work.
Context Rot ****describes how models become worse at reasoning and completing tasks as their context window fills up. Context is a precious and scarce resource, so harnesses need strategies to manage it.
Harnesses today are largely delivery mechanisms for good context engineering.
Compaction addresses what to do when the context window is close to filling up. Without compaction, what happens when a conversation exceeds the context window? One option is that the API errors, that’s not good. The harness has to use some strategy for this case. So compaction intelligently offloads and summarizes the existing context window so the agent can continue working.
Tool call offloading helps reduce the impact of large tool outputs that can noisily clutter the context window without providing useful information. The harness keeps the head and tail tokens of tool outputs above a threshold number of tokens and offloads the full output to the filesystem so the model can access it if needed.
Skills address the issue of too many tools or MCP servers loaded into context on agent start which degrades performance before the agent can start working. Skills are a harness level primitive that solve this via progressive disclosure. The model didn't choose to have Skill front-matter loaded into context on start but the harness can support this to protect the model against context rot.
Long Horizon Autonomous Execution
We want agents to complete complex work, autonomously, correctly, over long time horizons.
Autonomous software creation is the holy grail for coding agents. But today's models suffer from early stopping, issues decomposing complex problems, and incoherence as work stretches across multiple context windows. A good harness has to design around all of this.
This is where the earlier harness primitives start to compound. Long-horizon work requires durable state, planning, observation, and verification to keep working across multiple context windows.
Filesystems and git for tracking work across sessions. Agents produce millions of tokens over a long task so the filesystem durably captures work to track progress over time. Adding git allows new agents to quickly get up to speed on the latest work and history of the project. For multiple agents working together, the filesystem also acts as a shared ledger of work where agents can collaborate.
Ralph Loops for continuing work. The Ralph Loop is a harness pattern that intercepts the model's exit attempt via a hook and reinjects the original prompt in a clean context window, forcing the agent to continue its work against a completion goal. The filesystem makes this possible because each iteration starts with fresh context but reads state from the previous iteration.
Planning and self-verification to stay on track. Planning is when a model decomposes a goal into a series of steps. Harnesses support this via good prompting and injecting reminders how to use a plan file in the filesystem. After completing each step, agents benefit from the checking correctness of their work via self-verification. Hooks in harnesses can run a pre-defined test suite and loop back to the model on failure with the error message or models can be prompted to self-evaluate their code independently. Verification grounds solution in tests and creates a feedback signal for self-improvement.
The Future of Harnesses
The Coupling of Model Training and Harness Design
Today's agent products like Claude Code and Codex are post-trained with models and harnesses in the loop. This helps models improve at actions that the harness designers think they should be natively good at like filesystem operations, bash execution, planning, or parallelizing work with subagents.
This creates a feedback loop. Useful primitives are discovered, added to the harness, and then used when training the next generation of models. As this cycle repeats, models become more capable within the harness they were trained in.
But this co-evolution has interesting side effects for generalization. It shows up in ways like how changing tool logic leads to worse model performance. A good example is described here in the Codex-5.3 prompting guide with the apply_patch tool logic for editing files. A truly intelligent model should have little trouble switching between patch methods, but training with a harness in the loop creates this overfitting.
But this doesn't mean that the best harness for your task is the one a model was post-trained with. The Terminal Bench 2.0 Leaderboard is a good example. Opus 4.6 in Claude Code scores far below Opus 4.6 in other harnesses. In a previous blog, we showed how we improved our coding agent Top 30 to Top 5 on Terminal Bench 2.0 by only changing the harness. There's a lot of juice to be squeezed out of optimizing the harness for your task.
imageWhere Harness Engineering is Going
As models get more capable, some of what lives in the harness today will get absorbed into the model. Models will get better at planning, self-verification, and long horizon coherence natively, thus requiring less context injection for example.
That suggests harnesses should matter less over time. But just as prompt engineering continues to be valuable today, it’s likely that harness engineering will continue to be useful for building good agents.
It’s true that harnesses today patch over model deficiencies, but they also engineer systems around model intelligence to make them more effective. A well-configured environment, the right tools, durable state, and verification loops make any model more efficient regardless of its base intelligence.
Harness engineering is a very active area of research that we use to improve our harness building library deepagents at LangChain. Here are a few open and interesting problems we’re exploring today:
orchestrating hundreds of agents working in parallel on a shared codebase
agents that analyze their own traces to identify and fix harness-level failure modes
harnesses that dynamically assemble the right tools and context just-in-time for a given task instead of being pre-configured
This blog was an exercise in defining what a harness is and how it’s shaped by the work we want models to do.
The model contains the intelligence and the harness is the system that makes that intelligence useful.
To more harness building, better systems, and better agents.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み