EXPLAINER
wtf is Loop Engineer & how to setup for real
Loop Engineerは、エージェントに一回ずつ仕事を頼む人ではない。何を検知し、どの状態を読み、 どう実行し、どこへ記録し、次の判断へつなげるかを設計する役割である。
The Shift
元投稿の出発点は、著者のコードベースに深夜1時ごろ複数のPRが流れ込んだ、という観察だ。 チームが夜更かししていたのではなく、複数のagent loopが問題を見つけ、作業を拾い、検証し、PRを開いていたという。
同じ投稿では、SuperDesignDevでSEO loopが毎日20から40本のページを作り、著者が逐一見なくても流入を生んでいるとも説明されている。 ここで重要なのは、生成物の量ではない。仕事を発見し、実行し、結果から次の仕事を決める流れが、人間の単発プロンプトから離れ始めている点だ。
Prompting
人間が「このタスクをやって」と毎回決める。仕事の発見と優先順位は人間側に残る。
Automation
決まったトリガーで決まった処理を走らせる。継続実行はできるが、学習の蓄積は薄い。
Agent Loop
与えられた仕事を調査し、ツールを使い、検証しながら完了まで進める。
Outer Loop
何を起点にし、何を記録し、次の判断にどう使うかを設計する。
Two Loops
投稿では「agent harness」を、モデル本体以外の曖昧な周辺部として扱うのではなく、 agent loopとouter loopの二層に分ける。内側はタスク実行の信頼性を上げる層で、外側は仕事の発見と学習を扱う層だ。
| Layer | Main question | Design material | Failure when missing |
|---|---|---|---|
| Agent loop | このタスクをどう確実に完了させるか | コンテキスト、指示、skills、tools、検証手順、タスク分解 | 出力は出るが、品質が安定しない |
| Outer loop | 次に何をすべきか、結果から何を学ぶか | トリガー、状態、共有メモリ、監視、重複排除、改善ルール | 毎回人間が仕事を見つけ直す |
Loop Engineerの仕事は、エージェントにうまいプロンプトを渡すだけではない。 システムが「気づく、調べる、動く、記録する、検証する、次へ回す」ための環境を作ることだ。
Shared Memory
一つのloopが便利でも、事業全体の速度を変えるのは複数のloopが同じ学習面に書き込むときだ。 元投稿ではSupport、SEO、Product growth、Adsのloopが、それぞれの成果を共有artifactに残す例が挙げられている。
たとえばsupport loopが「exportの場所が分からない」という問い合わせを何度も見つけ、構造化されたsignalを作る。 SEO loopが流入は強いが転換しないページを見つける。Product growth loopはその両方と分析データを読み、単独のデータでは見えなかった摩擦を判断できる。
Signal
繰り返し観測された摩擦、機会、リスクを、再利用できる構造で残す。
Action
別のloopや人間が、signalを読んで調査、施策、タスク、ドキュメントへつなげる。
Signal is not a random note
投稿内の例では、signalにはkind、title、description、category、frequency、segments、tagsのような項目が入る。 重要なのは、自由メモではなく「後続のloopが読める単位」にすることだ。発生頻度、対象セグメント、根拠、次の行動がなければ、後で使いづらい。
type: signal status: open priority: high sources: - support-ticket-124 - support-ticket-131 # Observation Multiple users have asked how to export their work. # Evidence Five related support tickets in the past week. # Suggested next action Run a product investigation and test a clearer export entry point.
Setup Pattern
元投稿の実装パターンは、artifact、loop contract、global logの三つに分けると分かりやすい。 これは大きなプラットフォームを作る話ではなく、リポジトリやvaultの中に「継続実行に耐える読み書き面」を作る話である。
| Part | What it stores | Rule of thumb |
|---|---|---|
| Artifacts | signals、tickets、tasks、docsなど、loopが読む永続的な知識や作業単位 | typeごとに定義、schema、lifecycleを決める |
| Loop contracts | 各loopの目的、cadence、trigger、workflow、dedupe rules、timeline | 新しいagent sessionが読めば、何をしてよいか分かるREADMEにする |
| Global log | loopをまたぐ出来事、判断、参照artifact、手動介入の履歴 | 大きな作業前に直近5から10件を読み、作業後に一行で残す |
/artifacts
/signals
/tickets
/tasks
/docs
/loops
/support
README.md
LOG.md
support loopのcontract例では、1時間ごとに新規会話を取得し、返信またはエスカレーションし、 ticket artifactを作り、重複する摩擦は既存signalのfrequencyを増やし、明確なバグはtask化し、最後にtimelineへ短く記録する。
First Loop
最初から会社全体のAI operating systemを作ろうとすると重い。実用的には、繰り返し発生し、入力と出力が明確で、 人間の確認ポイントを置きやすい一つのloopから始めるのがよい。
- triggerを一つ決める。時間、issue、support ticket、analytics anomaly、競合ページ更新など。
- artifact typeを一つ決める。signal、ticket、task、docのどれを書くのかを曖昧にしない。
- dedupe ruleを先に置く。同じ発見を新規ファイルとして増やさず、既存artifactを更新する。
- verificationを明文化する。PR、返信、ページ生成、施策提案のどれを成功とみなすかを決める。
- timelineを残す。次のagentと人間が、なぜ今この状態なのかを追えるようにする。
Loop engineeringの最初の成果物は、派手な自律エージェントではなく、読み返せるartifactと、再実行できるcontractと、 次の判断を助けるlogである。
Source: Jason Zhou on X. The source also links to the Loop Engineer Setup template for scaffolding artifact structures, loop contracts, logs, skills, and a codebase harness checklist.