1 つのサーバーで 60 のコンテナ
1 つのベアメタルボックスで数十から数百の Hoody コンテナを実行。KSM と BTRFS のデデュプでマージナルコストはほぼゼロ。
コンテナ·スナップショット
タイプ新しいプリミティブステージ本番環境難易度中程度ジョブタスクを自動化対象AI ビルダー対象バックエンド開発者サービスCronサービスエージェントHoody の利点AI ネイティブHoody の利点HTTP ネイティブ
タイプ新しいプリミティブステージ本番環境難易度中程度ジョブタスクを自動化対象AI ビルダー対象バックエンド開発者サービスCronサービスエージェントHoody の利点AI ネイティブHoody の利点HTTP ネイティブ
use-cases / schedule-the-agent / hero
CRON · エージェント · 0 7 * * *
スクリプトではなくエージェントをスケジュールする
従来の cron 行は午前 2 時に reconcile.sh を実行します。Hoody の cron 行は hoody-agent にプロンプトを POST します。スケジュールは固定。仕事は違います。エッジケースは保守する分岐ではなくなり、エージェントが推論するコンテキストになります。
agent.containers.hoody.com · 実行
https://agent.containers.hoody.com/runs?cron=morning-reports実行中 · 最終実行 07:02
CRON0 7 * * *→POST /api/v1/agent/tasks
直近 5 回の実行- 2026-05-0407:00·2m 14s実行Regenerated 3 reports — orders.parquet schema changed (added refund_reason), remapped to legacy column.
- 2026-05-0307:00·0m 04sスキップSkipped — no new rows in orders since last successful run (08:32 May 2). Saturday, low volume.
- 2026-05-0207:00·1m 51s実行Standard daily run. 4,182 rows reconciled. No anomalies. Sent digest to ops@.
- 2026-05-0107:00·3m 47s異常Refund spike (+412% vs 14-day median). Halted email send, opened ticket, paged on-call.
- 2026-04-3007:00·4m 02s適応Month-end: included monthly close, reconciled deferred revenue, reran on tax-adjusted ledger.
CRONTAB エントリ · 1 行 · 編集されたことなし0 7 * * * curl -X POST /api/v1/agent/tasks -d '{"description":"昨日の注文を照合してください。データ形状が変わったら、再マッピングしてください。ボリュームが異常なら、停止してオンコールに通知してください。月末なら、月次決算を含めてください。"}'
5 つの朝 · 5 つの異なる決定 · 1 つの crontab 行
use-cases / schedule-the-agent / mechanism
2 つの URL、1 つのプロンプト
Hoody Cron はすべてのコンテナ上のマネージド crontab です。Hoody Agent は同じコンテナ上の組み込み自律エージェントです。cron エントリがエージェントを curl します。エージェントが日付を読み、データを読み、その日が何を必要としているかを決定します。両方のサーフェスは HTTP です — cron は /api/v1/cron/users/me/entries に、エージェントは /api/v1/agent/tasks にあります。両者の間にグルーコードはありません。
cron-1.containers.hoody.com · entry
POST · cron/users/me/entries# POST /api/v1/cron/users/me/entries { "schedule": "0 7 * * *", "command": "curl -X POST $AGENT/api/v1/agent/tasks \ -d @prompt.json", "comment": "morning-reports" }
agent-1.containers.hoody.com · task
POST · agent/tasks# prompt.json — the body of the POST { "description": "昨日の注文を照合してください。スキーマがドリフトしたら再マッピングしてください。異常スコアが 3 を超えたら停止してオンコールに通知してください。今日が月の最終日なら、税調整済み台帳に月次決算を含めてください。", "mode": "code" }
POST 2 回で完了です。crontab 行は二度と変わりません — 保守する唯一のファイルはプロンプトです。新しいエッジケース? 1 文を追加。新しい異常ルール? 1 文を追加。スケジュールは発火し続け、エージェントが各発火が何を意味するかを理解します。
use-cases / schedule-the-agent / powers
プロンプトがスクリプトにできない 3 つのこと
エージェントが受け取る作業の形は常に同じです — 日付、データセット、目標。変わるのは、エージェントがそれらに対して何を決定するかです。
推論
日付を読み、データを読み、決定する
エージェントは cron が発火した後に動きます。カレンダーをチェックします — 月末、休日、会計期末。データセットをサンプリングします — スキーマ、ボリューム、異常スコア。6 か月前にあなたが書いた静的な if ツリーからではなく、そのコンテキストで次のアクションを選びます。
適応
新しいカラム? 新しい通貨? 同じプロンプト。
昨日のエクスポートが refund_reason カラムを追加したとき、スクリプトは壊れてあなたを呼び出します。エージェントはスキーマを読み、レガシーフィールドにマッピングし、変更を実行サマリに記録します。crontab 行は何も知る必要がありませんでした。
可観測性
すべての実行は段落であり、リターンコードではない
各実行は、エージェントが何を決定し、なぜかを返信します。履歴は平易な日本語です — 「スキップ: 新しいデータなし」、「適応: refund カラム追加」、「異常: refund スパイク +412%、オンコールに通知」 — exit code 0 / exit code 1 ではありません。cron のログはジャーナルになります。
use-cases / schedule-the-agent / flow
スケジュールから決定へ
3 ステップ — cron が発火し、エージェントが推論し、決定が着地します。中央のステップは、あなたが 17 のエッジケース分岐を持つ 400 行のシェルスクリプトで自分で書いていたものです。今はプロンプトです。
3 ステップの日次ループ1 つのプロンプト · 無限のエッジケース
07:00
cron が発火
Hoody Cron がエントリを実行します。crontab 行は 1 つの curl です: プロンプト本体を持つ POST /api/v1/agent/tasks。あなたが書いたリトライもなく、ログプラミングもなく — cron サービスがエントリをシステム crontab に挿入し、実行を追跡します。
07:00 + ε
エージェントが推論
エージェントは記述を受け取り、ツール — ターミナル、ファイル、sqlite、ブラウザ、exec — を開いて、アクションプランを選びます。実行、スキップ、適応、または通知するかもしれません。選択は毎日変わります。指示は変わりません。
07:00 — 07:04
決定が着地
実行が完了します。エージェントはサマリ行を返信します: レポートを再生成、新しいデータがないためスキップ、異常で停止。あなたは朝食をとりながら携帯で読みます。
スケジュールは変わっていません。スクリプトも変わっていません。変わったのは、人間であるあなたが起きて対処する必要があったかどうかです。エージェントがループに入ると、答えはほぼ常に no — そして実行履歴がその理由を教えてくれます。
use-cases / schedule-the-agent / capacity
cron + agent ペアから得られるもの
Hoody Cron と Hoody Agent は、同じコンテナ上の 2 つのサービスで、両方とも HTTP として到達可能です。数値は文書化されたサーフェスから来ています — 捏造したベンチマークではありません。
- CRONTAB サイズ1 行
crontab に 1 つの curl、永遠に。プロンプト本体が、あなたが書き直す唯一のもの — そしてそれは crontab -e を実行することではなく、JSON ファイルで行います。
- エージェントエンドポイント100+
hoody-agent はフルサーフェスを公開します — ターミナル exec、ファイル読み書き、sqlite クエリ、ブラウザ自動化、デーモン制御 — をエージェントのタスクに対してプレーンな HTTP コールとして。
- グルーの行0
cron とエージェントの間に SDK はありません。1 つの URL に POST し、もう 1 つを読みます。両方のサービスは同じコンテナにあるので、コールはローカルネットワーク高速です。
Hoody Cron は標準の 5 フィールド表現 (* * * * *) とマクロ (@hourly、@daily、@weekly、@monthly、@yearly) をサポートします。Hoody Agent タスク作成は 1 回の POST /api/v1/agent/tasks。ライブ更新は /api/v1/agent/ws でストリーミングされます。
use-cases / schedule-the-agent / punchline
cron エントリはジョブを実行しません — エージェントにジョブを理解させるのです。
before · 分岐するスクリプトafter · 分岐するプロンプト
古い CRON エントリが指していたもの0 2 * * * /usr/local/bin/reconcile.sh # 412 行 · 17 エッジケース新しい月末ルールはスクリプトを編集して祈ることを意味した
今は何を指しているか0 7 * * * curl POST agent/tasks -d @prompt.json1 行、永遠に — プロンプトが保守する唯一のアーティファクト
use-cases / schedule-the-agent / replaces
これが置き換えるもの
cron がファイルしか実行する方法を知らなかったため、reconcile.sh の中に書いていたもの一式。それぞれが分岐、フラグ、設定であり、スケジュールが知る必要のないものです。エージェントがその日を読んで決定します。
- 壊れやすいスクリプト化された cron ジョブ1 つの入力カラムが動くとクラッシュする bash 分岐
- 変わるスキーマのための手動メンテナンス上流のエクスポートにフィールドが増えるたびに reconcile.sh を編集
- 手書きの ETL スクリプトチームで 1 人しか理解していない .sh ファイルのフォルダ
- if X then Y else Z の cron ロジック月末、休日、異常 — 1 つのスクリプトに配線された 3 つのフラグ
- 変更ポーリングスクリプト最初の cron の出力を監視して決定する別の cron
- 手書きの if-else スケジューラどのスクリプトを実行するかを選ぶことだけが仕事の 200 行ディスパッチャ
use-cases / schedule-the-agent / cta
cron スクリプトの保守をやめましょう。プロンプトの保守を始めましょう。スケジュールが発火し、エージェントが理解します。
use-cases / schedule-the-agent / related
他のユースケースを読む
