Ralph Loop は「Ralph Wiggum テクニック」という愛称でも呼ばれ、Geoffrey Huntley と Ryan Carson によって広められたハーネスパターンであり、単一セッションのコーディングエージェントをマルチセッションのエージェントに変えるためのものである。開発は多数の小さなタスクに分割され、エージェントはそれらを繰り返しのサイクルで処理していく。To-Do リストから次のタスクを選び、実装し、変更を検証し（テスト、型チェック）、チェックに通ればコミットし、タスクのステータスを更新して得られた知見を記録し、その後エージェントのコンテキストをリセットして繰り返す。イテレーションごとにコンテキストをリセットすることで、エージェントは以前のタスクに由来する混乱の蓄積を避け、単一の巨大なプロンプトを、範囲の限られたプロンプトの繰り返しに置き換える。
用法
この手法についての Huntley 自身の記事 「ソフトウェアエンジニア」としての Ralph Wiggum（2025 年 7 月 14 日）は、その最も単純な形を示している。Ralph はテクニックであり、最も純粋な形では、同じプロンプトファイルをコーディングエージェントに繰り返しパイプで渡す Bash のループ、すなわち while :; do cat PROMPT.md | claude-code ; done である。彼によれば、これはツール呼び出しや使用量に上限を設けていないどのツールでも実行できる。彼が説明するループは、1 つのリポジトリで自律的に動作し、イテレーションごとに 1 つのことを行う単一のプロセスであり、計画ファイル（fix_plan.md）から最も重要な項目を選ぶことはエージェントに任される。各イテレーションでは同じ計画と仕様がコンテキストに読み込まれる。主となるコンテキストウィンドウは、コストの高い作業をサブエージェントに渡すスケジューラーとして機能し、ビルドとテストを実行できるサブエージェントは 1 つだけに限られる。テスト、型チェッカー、静的解析ツールは不正なコードに対する バックプレッシャー として機能する。エージェントは、プロジェクトのビルドについて学んだことを AGENT.md ファイルに記録すること、そしてテストに通ったらコミット、プッシュ、タグ付けを行うことが許されている。エージェントが誤った振る舞いをするたびに、オペレーターはプロンプトに指示を追加してエージェントを「チューニング」する。記事で繰り返し用いられるイメージは、Ralph のために看板を立てることである。また、To-Do リストが尽きたり方向を誤ったりしたときには、別の計画用プロンプトが To-Do リストを再生成する。
Addy Osmani の記事が説明する形では、それ以外はステートレスなリセットをまたいで 4 つのメモリのチャネルが持続する。git のコミット履歴（各イテレーションの変更がコミットされるため、後のイテレーションは変更を思い出す代わりに差分を調べられる）、各サイクルで何が起きたかを記述するプレーンテキストの進捗ログ、残っている作業を追跡するタスク状態ファイル（例：各タスクに合否フラグを付けた JSON）、そして発見されたパターンや落とし穴を、どのイテレーションも読み書きできる長期的な意味記憶として蓄積する AGENTS.md ファイルである。これは、計画（目標をステップに分解して計画ファイルに記録すること）や planner/generator/evaluator の分割と並んで、モデルが早期に停止しがちなこと、複雑な問題をうまく分解できないこと、長い作業にわたって一貫性を失うことを回避する方法として提示されている。
適用される場面
これが当てはまるのは、タスクが単一のコンテキストウィンドウに収まる長さを超えて実行されると見込まれ、夜間のように無人で継続する必要がある場合である。前提となるのは、新しいコンテキストウィンドウのそれぞれが前回の続きから作業を再開するために読める、ファイルシステム上の永続的な状態と、明確な合否基準を持つ小さなタスク、そして無人の実行が害を及ぼさないようにする安全策である。報告されている安全策には、フィーチャーブランチ上でのみ実行すること、失敗したテストやビルドの出力をエージェントにフィードバックして自動的に再試行させること、同じエラーで 3 回以上のイテレーションにわたって行き詰まったエージェントを停止して作業を再割り当てすること、イテレーション数・時間・トークンに対するハードリミット（役割ごとの予算を含む）、そして自動的にマージするのではなく人間のレビューのためにプルリクエストを作成することが含まれる。
このパターンを説明する Addy Osmani の記事のうち 3 本は、これをどちらかの著者自身の発明として提示するのではなく、Geoffrey Huntley と Ryan Carson がこれを広めたとしており、そのうち 1 本は単体の ralph ツールの実装を特に Carson の功績としている。4 本目の「Agent Harness Engineering」（2026 年 4 月 19 日）は、このパターンを著者が以前にも書いたことのあるものとして論じ、考案者の名前は挙げていない。そこではこれを、モデルが終了しようとするのをインターセプトし、元のプロンプトを新しいコンテキストに再注入するフックとして説明している。
LangChain の 2 本の記事は、フックベースの形をハーネス設計の側から説明している。エージェントハーネスの解剖学 は Ralph Loop を、モデルの終了の試みをフックでインターセプトし、元のプロンプトをクリーンなコンテキストウィンドウに再注入することで、完了目標に向けてエージェントに作業を継続させるハーネスパターンと定義している。さらに、これを可能にしているのはファイルシステムであり、各イテレーションは新しいコンテキストで始まるが、前のイテレーションが残した状態を読み取るのだと付け加えている。ハーネスエンジニアリングによる Deep Agents の改善 はこれを「Ralph Wiggum Loop」、すなわち終了時にエージェントに実行の継続を強制するフックと呼び、その仕組みを別の目的のために借用したと報告している。それは、LangChain のコーディングエージェントが終了する前にインターセプトし、タスクの仕様に照らした検証のパスを実行するよう促すミドルウェアである。
Huntley の記事は、自らこの手法の限界を定めている。彼はこの手法を、グリーンフィールドのプロジェクトの立ち上げに適したものとして提示し、およそ 90% まで到達できると見込んでいる。既存のコードベースでは使わないと述べ、手法を導くにはシニアエンジニアの専門知識が依然として必要だとしている。彼が報告する失敗は、プレースホルダー的な実装や最小限の実装に偏るモデルの傾向、エージェントのコード検索が何かが欠けていると誤って結論づけたときに生じる重複実装（彼はこれをこの手法のアキレス腱と呼んでいる）、仕様そのものの誤り、そして朝起きるとコードベースがコンパイルできなくなっており、オペレーターがリセットするか新しいプロンプトを書くかを選ばなければならない事態である。これらは、彼自身がこの手法でプログラミング言語を構築した経験から得られたものであり、測定された比較に基づくものではない。