1 つのサーバーで 60 のコンテナ
1 台のベアメタルで、数十から数百の Hoody コンテナを動かす。KSM と BTRFS の重複排除で、限界コストはほぼゼロ。
コンテナ·スナップショット
タイプ新しいプリミティブ
ステージ本番環境
難易度中程度
ジョブタスクを自動化
対象AI ビルダー
対象バックエンド開発者
サービスCron
サービスエージェント
Hoody の利点AI ネイティブ
Hoody の利点HTTP ネイティブ
タイプ新しいプリミティブ
ステージ本番環境
難易度中程度
ジョブタスクを自動化
対象AI ビルダー
対象バックエンド開発者
サービスCron
サービスエージェント
Hoody の利点AI ネイティブ
Hoody の利点HTTP ネイティブ
タイプ新しいプリミティブ
ステージ本番環境
難易度中程度
ジョブタスクを自動化
対象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 は /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