ルールベースのゲートとは、エージェントのアクションにいつ人間が必要かを決める、静的で決定的なガードレールである。条件は事前に書かれ、ゲートは毎回同じようにそれをチェックする。答えは設定済みのルールによってすでに決まっているため、その場で判断されることは何もない。この用語は 本当にすべてのループに人間が必要か？ で提案された対の一方であり、もう一方は リスクベースのゲート である。その記事は両者を決め方において正反対のものと位置づけている。すなわち、自分が所有する固定されたチェックリストと、エージェントがその場で下す判断との対比である。
用法
挙げられている具体例は、重要度の低いサービスで低深刻度のインシデントが発生し、修復エージェントが自力でそれを直して誰も呼び出されない、というケースである。このケースでは人間は決して必要ないとルールが定めているからである。この説明によれば、こうしたゲートが信頼しやすいのは、ロジックが自分のものであり、書き留められていて、自分で変えない限り変わらないからである。そのため誰でも後からルールを見て、なぜエージェントが実行を許された、あるいは許されなかったのかを正確に知ることができる。予測可能性と監査可能性が、述べられている強みである。
適切に運用するための記事の指針は 3 つの部分からなる。条件を明示し、所有者を割り当てて、偶然に発見されるのではなく意図的に監査・変更できるようにすること。条件がハードコードされた推測ではなく実データを読むようにして、「低リスクのインシデント」といった言い回しが実際に低リスクのインシデントを意味するようにすること。そして、ゲートが発動するたびにログを残し、何がなぜゲートされたのかを誰でも後から追跡できるようにすることである。
適用される場面
示されている判定基準は、その条件を書き下せるかどうかである。トリガーを毎回正しいルールとして表現できるなら、ルールベースのゲートが適切な選択である。記事はこれに時間枠も含まれることを明言しており、ルールは「何」だけでなく「いつ」も扱える。この境界線のこちら側の例として挙げられているのは、サービスのティアが固定された事実である tier-1 サービスへのデプロイ、時間枠であっても事前に明示できる条件である金曜日のリリースフリーズ中のあらゆるデプロイ、そしてデータ分類によって決まる、顧客データに触れるあらゆるアクションである。
述べられている限界は、その強みの裏返しである。ルールは、自分が思いついて書いた条件と同じ程度にしか賢くない。ルールは予期していたケースと事前に名指しできる事実を扱うが、判断が明確に列挙できない信号の比較衡量に依存するようになった途端、固定されたルールにはチェックする対象がなくなる。また、ルールもコンテキストに依存する。条件はその背後にあるデータと同じ程度にしか良くなく、古いコンテキストや部分的なコンテキストを読むゲートは、自信満々に誤った判断を下す。この定式化は 1 つのベンダーによるもので、そのベンダー自身のプラットフォームを推奨して締めくくられる記事の中で提示されている。また記事は、ほとんどのチームがどちらか一方を選ぶのではなく、両方の種類のゲートを運用することを想定している。