なぜルーティングルールではなくオーケストレーターを作ったのか
キャンバスが 2〜3 エージェントを超えると、静的なトリガー/変換ルールはスケールしにくくなります。MadoHub がルーティングを固定ルールではなく本物のツール呼び出しループ経由で行うようになった理由と、それでもルールを使うべき場面。
MadoHub の歴史の大部分で、エージェント間のルーティングはルールエンジンでした。コネクションはトリガー（on-idle、on-complete、on-keyword、always）、変換（AI routing、prompt-wrap、full-output、raw、summary）、ループ保護のノブを持っていました。一度設定すれば毎回同じように発火します。このモデルはまだ存在し — エージェントルーティング と Flows が文書化するもので、peer review のような既知のパターンのために 2 つのタイルを配線する最速の方法のままです。しかし、具体的に言及する価値のあるスケール問題があります。
問題は単一のルールではない。数だ。
「on idle → prompt-wrap」のコネクションは推論しやすい — ソースは終わったか？ 終わったなら転送する。トラブルはキャンバスが 2〜3 タイルを超え、コネクションが独立でなくなったときに始まります。
5 つのエージェントと 8 つのコネクションでは、すべてのルールが他のすべてのルールと相互作用します。A の出力は B の on-keyword トリガーのキーワードマッチと見なすべきか？ C は同じターゲットが 1 秒に 2 回ヒットしないよう D のクールダウンを待つべきか？ これらに間違った答えはありません — トリガータイプ、変換、優先度フラグをもう 1 つ追加すればどれも解決できます。しかし各答えは新しいルールであり、ルールは合成せず乗算します。N エージェントのトポロジーは N ルールではなく、エッジケース処理として N² に近い数を必要とします — なぜならルールはキャンバスの他で何が起きているかのモデルを持たず、出力テキストにパターンマッチして盲目で発火するからです。
これがオーケストレーターを支持する本当の議論です — ルールが悪いのではなく、固定ルールは何をするか決める前にワークスペースの残りを見られず、2〜3 エージェントを超えるワークスペースがまさにそれを必要とすることが増えるからです。
MadoHub がどう扱うか
より大きなルールではなく、ツールループ
代替は「AI 変換を追加する」ことではありません — MadoHub は既にそれを持っていました。代替はルーティング決定にワークスペースへのアクセスを与えることです。デフォルトで、発火したコネクションは MadoAgent サブターンを開きます — キャンバスのスナップショット（すべてのタイル、すべてのコネクションのトリガーと変換とラウンド状態、最近の出力）を見て 1 つのルーティング決定を下し、停止する本物のツール呼び出しループです。
その決定は意図的に狭いです — ファイルを読む、git status を確認する、コネクションを列挙する、ルーティング履歴を調べる、セッションを検索する、メモリを呼び出すことに加え、ちょうど 1 つのアクション（メッセージを転送するかスキップする）を取れます。キャンバスを書き換える、コネクションを変更する、ワークフローを実行することはできません。指示は単純です — 実質的な内容（計画、コード、レビュー）があるときは転送し、ソース出力がユーザーへの質問や空のおしゃべりならスキップする。パターンマッチではなく、実際の会話に対する判断です。
パスに関わらずループ保護は適用される
決定的なディスパッチャをモデル呼び出しに置き換えるのは、1 日目から全幅の信頼で行う変更ではないため、ルールベースシステムからの安全柵はそのまま引き継がれます。ループ保護はコネクションが自動停止する前に実行するサイクル数をキャップし（デフォルト 5）、トリガー間の最小間隔を強制し（デフォルト 3 秒）、LGTM のような停止キーワードが現れた瞬間にループを終了できます。毎ラウンド転送を決めるサブターンであっても暴走できません — キャップとクールダウンはその決定から独立して強制されます。
信頼を構築するためのシャドウモード
新しいパスを、振る舞いを変えずに試したいなら、シャドウモードはレガシールーターをライブで走らせ、その決定が転送される — ユーザー向け振る舞いは変わらない — と同時に、同じトリガーで MadoAgent サブターンを並行して純粋に比較信号として走らせます。ライブ判断を任せる前に、実際のトラフィックで新しいパスが古いものとどこで合意するかを見られます。レガシーパスはその信頼が構築される限り設定で選択可能なままです。
実践的な指針
- 既知の良い形には Flows を使いましょう。 3 つの組み込み（Peer review、Pipeline、Watcher）は固定ルールセットのままです — 繰り返しパターンのためにドロップされたテンプレートが毎回の発火でモデルに再疑義されるべきではありません。
- 特注または大きいトポロジーにはオーケストレーターを使いましょう。 固定ルールセットがキャンバスをうまく記述しないとき、決める前にワークスペースの残りを見られるツール呼び出しループは、もう一つのルールよりも一般化します。
- 1 回限りの精密さには手動配線を使いましょう。 2 つのタイル間でコネクションを引くのは、単一のリンクを完全に制御したいがテンプレートも会話も要らないときの最速の道のままです。
- ループ保護をオンのままに。 ルーティングループ内の LLM は出力が実質的か誤判断でき、ルールが転送したものをスキップし、テンプレートマッチにはない往復のレイテンシとトークンを追加する可能性があります。ループ保護と配信ゲートは、間違った決定が無限ループに螺旋状に発展しないこと、転送がもはやそこにいないタイルに静かに飲み込まれないことを保証します。