リポジトリのアーキタイプ

エージェントが一行のコードも変更する前に、それ以降のすべてを形作る一つの決定を下します。このリポジトリはどの種類か？　推測されたアーキタイプが、取り組み全体を通じてエージェントが推論する境界を定めます。どうオンボーディングするか、計画がどこまで及ぶか、そして状態がどこに置かれるか、です。判断を誤ると、エージェントは誤った対象範囲に作業をスコープします。これは長期的なタスクにおけるドリフトの最も一般的な原因です。正しく判断できれば、計画・オンボーディング・状態がすべてコードの実際の形に合致するため、何時間も自律的に動き続けられます。

DWP は三つのアーキタイプを認識します。ほとんどのリポジトリは最初のアーキタイプです。二番目は多くのリポジトリを調整するチームのために存在します。三番目は自律エージェントの長期的なワークスペースをカバーします。

個別リポジトリ

自己完結したコードベース

オーケストレーターハブ

サブリポジトリを統括

個別リポジトリ

一般的なケース：自己完結したコードベース、すなわちアプリケーション、ライブラリ、サービスです。推論すべき一つの一貫した対象があるため、計画はリポジトリ内のコードに直接作用し、オンボーディングはリポジトリ自身の構造と規約を読みます。エージェントはコードベース全体をコンテキストとして保持し、端から端まで処理します。

特徴：

• 単一の一貫したコードベース。
• 計画はこのリポジトリ内のファイルを変更する。
• .dwp/ 作業領域はリポジトリのルートに存在する。

オーケストレーターハブ

調整のケース：他のリポジトリを管理することを職務とするリポジトリです。ここでの作業単位はファイルではなく子リポジトリであるため、計画はサブリポジトリの中に子計画を生成することがあり、オンボーディングは単一のコードベースではなく、ハブが管理するリポジトリのレジストリを読みます。エージェントは境界と引き継ぎについて推論します。どのリポジトリがどの作業を担うか、そしてそれらの状態をどう一貫させるか、です。

特徴：

• 複数のサブリポジトリを調整する。
• 計画は子計画へ委譲することがある。
• 管理対象リポジトリのレジストリを維持する。
• ハブのルートにある .dwp/ 作業領域がリポジトリ横断の状態を追跡する。

エージェントワークスペース

v2.2 で追加された三番目のアーキタイプは、リポジトリである前にワークスペースであるものを説明します。自律エージェントの長期的な住処です。OpenClaw のワークスペース、Hermes のサービスディレクトリ、パーソナルアシスタントデーモンのデータディレクトリ、クラウドエージェントの永続ボリューム — いずれも実行すべき計画、使用すべきツール、維持すべきメモリーを持ちますが、出荷するコードベースは持たないかもしれません。

核心となる洞察は、ハーネスはワークスペースであり、特定のリポジトリではないということです。DWP がリポジトリにインストールするすべての要素 — AGENTS.md、docs/、.agents/、.dwp/ — は、ワークスペースに直接相当するものを持ちます。方法論のサーフェスはきれいに対応します。常設コンテキストファイルがルートの AGENTS.md を置き換え、プラットフォームのスキルディレクトリが .agents/ を置き換え、ワークスペースルートの .dwp/ フォルダーは変わりません。変わるのは git の役割です。リポジトリでは、git ログが状態を担い、計画をセッションをまたいで再開可能にします。git のないワークスペースでは、state.json がその仕事をします — だからこそ機械可読な状態レイヤーがエージェントワークスペースに必須なのです。

実際の効果は、一晩かけた無人計画です。OpenClaw クラスのプラットフォームでは、ハートビートまたはクロンターンがエージェントを起動し、DWP 再開プロトコルを実行し、次のアトミックタスクを実行し、state.json を更新し、終了します。継続性の単位はセッションではなく計画です。複数日にわたる計画が再起動、モデルの交換、セッション境界をまたいで生き残ります。なぜなら、次のターンが必要とするものはすべて計画ファイルに存在するからです。目標、チェックオフされた進捗、ゲートレコード、そして現在のタスク内の正確なチェックポイントです。

特徴：

• 自律エージェントプラットフォームの作業ディレクトリ。
• ワークスペースルートに AGENTS.md、.agents/、.dwp/ が存在する。
• Git は必須ではなく RECOMMENDED。
• Git がない場合、および無人実行では state.json が必須。
• 計画は通常、スケジュールされたハートビートまたはクロンによって無人で実行される。

分類のヒューリスティック

三つのアーキタイプはディスク上での見た目が異なり、エージェントは告げられたラベルではなく、自分で検証できる手がかりをもとに判断します。以下のデシジョンツリーがその道筋を示します。簡潔に言えば、プラットフォームのアイデンティティシグナルが存在する場合はエージェントワークスペースとして、証拠がそれを求める場合のみオーケストレーターハブとして、そうでなければ個別リポジトリとして分類してください。

リポジトリ

? 複数の入れ子リポジトリ、またはハブのレジストリですか。

いいえ

個別リポジトリ

• 単一のコードベース
• 計画はローカルファイルを変更します
• .dwp/ はリポジトリのルートに配置します

はい

オーケストレーターハブ

• サブリポジトリを統括します
• 計画は子の計画へ委譲します
• リポジトリ間で .dwp/ の状態を保持します

エージェントはまずエージェントワークスペースのシグナルを探すべきです。プラットフォームのアイデンティティファイル（OpenClaw の SOUL.md や HEARTBEAT.md など）、主要なアプリケーションスタックがない、内容が主としてエージェント自身の状態。これらがなければ、オーケストレーターのシグナルを探します。複数の入れ子になった git リポジトリやサブモジュール、管理対象リポジトリのレジストリやマニフェスト、または外部リポジトリを指す設定。両方がなければ、対象を個別リポジトリとして扱います。これが安全なデフォルトです。存在しない境界をまたいで計画を過剰にスコープすることは、実在する境界の内側で作業するよりも悪い結果をもたらすからです。

オンボーディングはどう異なるか

アーキタイプは装飾的なラベルではありません。エージェントが読むもの、計画が触れられるもの、そして状態が記録される場所を変えます。

実際の効果として、個別リポジトリのエージェントは一つのコードベースを端から端まで推論し、オーケストレーターのエージェントはリポジトリをまたいだ調整について推論し、エージェントワークスペースのエージェントはセッションをまたいだ継続性について推論します — 何が計画され、何が実行され、何がブロックされ、次は何かを。

アーキタイプを最初に固定することこそが、エージェントが監督なしに何時間も自律的に働けるようにします。計画、オンボーディング、状態を適切な境界に合わせて定めることで、エージェントは最初のタスクから最後まで、正しい対象範囲で動きます。