ループ仕様（loop specification）とは、人間が設計してエージェントハーネスに渡す、範囲が限定された再利用可能な成果物であり、これによってエージェントは逐一のプロンプトに代わって自らゴールを追求する。この用語は コーディングエージェントの手取り足取りをやめよ：逐一のプロンプトに代わるループのエンジニアリング で提案されたもので、同論文はこれを ループエンジニアリングの対象を指す名前として用いている。同論文によれば、ループ仕様は 5 つの部分からなる。ループを開始するトリガー（人、スケジュール、またはイベント）、できれば検証可能なゴール、エージェントが作業する実行フェーズ（理想的には実績のある名前付きのスキルを呼び出して行う）、結果を実際に確かめる検証、そしてエラーを成功と取り違えることなく、ループを名前付きの終了状態 — 成功、no-op、ブロック、停滞、枯渇 — へと導く停止ルールである。進捗と決定のメモリは、会話の中ではなくディスク上に置かれ、ターンをまたいで保持される。
使われ方
同論文はこの用語を導入することで、「ループ」という語を共有する 3 つのものを区別している。すなわち、単なる制御フローである通常のプログラミング上のループ、モデルが停止条件に照らしてツールを実行する内部的なエージェントサイクル（これは エージェントハーネスの一部であり、誰かが設計するかどうかにかかわらず存在する）、そして人間が書いてそのハーネスに渡す外部の成果物としてのループ仕様である。同論文はこの区別を「ハーネスはエンジンを供給し、ループエンジニアリングはパイロットを書く」とまとめ、これらの意味を混同することこそ「プロンプトをやめよ」というスローガンが招く混乱だと論じている。
同論文は、ループ仕様を設計者が選択する次元に沿って整理している。トリガー、ゴールの種類（検証可能、モデルによる判定、またはその混合）、5 段階の 検証のはしご 上での検証の厳密さ、アーキテクチャ（単独、作成者と別個の確認者、または補助エージェントを統率するマネージャー）、そして名前付きの終了状態である。同論文が実践者の記述から採用した運用上の形では、実際のループシステムは、スケジュール実行される自動化、分離されたワークツリー、スキル、プラグインとコネクタ、そして作成者と確認者を分けるサブエージェントを組み合わせ、メモリはファイルに保持する。同論文に付随するスキルである sandeco-loop は、ループ仕様を単一のドキュメントとして書き出す。
適用される場面
同論文の「黄金律」は、ループ仕様が単なるスケジュール実行のプロンプトより正当化されるのは、1 ターンの結果が次の行動を変える場合に限られる、というものである。直前の実行から次の実行へ何も引き継がれない、決まった頻度で行う決まったタスクは、スケジュールされた単発の実行であってループではない。同論文は、ループが適切な手段ではない場合をさらに挙げている。ゴールが再現可能なチェックを持たない純粋な好みの問題である場合、正しい方向性が分からない曖昧なゼロからの構築作業である場合、そしてループのコストが見合わない場合である。また、内部的なエージェントサイクルをすでに備えたハーネスと、ディスク上に置くことのできる状態とを前提としている。
同論文が挙げる失敗モードには、名前付きのスキルも実際のチェックもないまま生のモデルを際限のない再試行で包むだけのループ、同じモデルが作業を生み出しかつ採点するループ、ループがチェックの字面は満たしてもその趣旨は満たさない仕様ゲーミング、モデルによる判定者の意見をあたかも決定論的なチェックであるかのように報告すること、そしてタスクに関連した停止ルールも停滞検出器も予算上限もないまま無人で暴走することが含まれる。
この用語の定着度については、ポジションペーパーにおける単一著者の提案である。その裏付けとなる証拠は、50 個のループを収めた 1 つの公開カタログを手作業でコーディングした記述的な読解であり、設計原則は主に内部的なエージェントサイクルを研究した文献に基づいている。著者自身、この転用を測定された結果ではなく論証によるアナロジーだと述べている。