AIエージェントの暴走を止めるためのオープンソース実行ランタイム層「Cycles」を作った（フィードバック募集中）

AIエージェントを試していると、きっとこの問題にぶつかるはずです。エージェントがツール、API、モデル、メールシステム、データベース、ジョブなどを呼び始めると、その先に何が起こるのかをコントロールしづらくなることがあります。

権限（Permissions）への答えはこうです：「このエージェントは、このツールを使うことがまったく可能ですか？」

レート制限（Rate limits）への答えはこうです：「どれくらいの速さで呼び出せますか？」

しかし、エージェントは別の形で失敗します。リトライし続けたり、ループしたり、処理を広げて（fan out）しまったり、高価なモデルを呼び出したり、メールを送りすぎたり、ジョブを発火させたり、あるいは実行がすでに想定から外れてしまった後も動き続けたりします。

私はこの問題に取り組むためにCyclesを作りました。

Cyclesは、AIエージェントのためのオープンソースのランタイム権威レイヤーです。エージェントがコストの高い、またはリスクのあるアクションを取る前に、Cyclesはそのアクションが許可された予算やポリシーの範囲内にまだ収まっているかを確認します。はいなら、許容量を予約し、アクションを実行し、その後、実際に何が起きたかをエージェントがコミットします。いいえなら、実行前にそのアクションはブロックされます。

目的は、以下の状況でエージェントの実行をより安全にすることです：

• 暴走するリトライのループ
• 予期しないモデル/APIの費用
• 複数ステップにわたるエージェントのワークフロー
• 同じ予算を共有する複数の同時エージェント
• ユーザーごと／テナントごとの制限
• メール、DBへの書き込み、API呼び出し、ジョブのトリガーのようなリスクの高いアクション

これは、オブザーバビリティやトレーシングを置き換えるためのものではありません。そうしたものは今でも有用です。ギャップがあるのは、請求や副作用がすでに発生した後ではなく、実行の直前です。

Repo: https://github.com/runcycles

皆さんは今日これをどのように扱っていますか？

実行前にエージェントのアクションを制御（ゲート）していますか？
それとも、事後に主にログ／アラートに頼っていますか？

予約 → 実行 → コミットというモデルは、実際のエージェントシステムで役に立つでしょうか？それとも、早すぎる過剰なインフラに感じますか？