判断を伴うクロスシステムオーケストレーション
典型的な調達から支払いまでのワークフローは、十数のシステムに接触します。購買依頼は一つのプラットフォームで始まり、別のシステムの承認チェーンにルーティングされ、三番目でベンダー照会が起動し、四番目で発注書が作成され、五番目で受領プロセスが開始され、六番目で請求書照合が行われ、七番目で支払いがスケジュールされ、八番目にすべてが記録されます。各システムには独自の API、更新スケジュール、認証モデル、障害モードがあります。
従来の自動化は硬直したパイプラインでこれを処理します。ステップ 1 が API A を呼び出してレスポンスを解析し、フィールドをステップ 2 に渡して API B を呼び出す。うまく機能するのは機能している間だけです。ベンダーレコードのフォーマットが予期せず変わる。承認がパイプライン設計外のステータスコードで返ってくる。API 更新で新しい必須フィールドが追加される。一つのステップが壊れると連鎖全体が壊れ、数日後に下流プロセスが失敗するまで誰も気づきません。
より深い問題は技術的な脆弱性ではありません。実際のビジネスプロセスには判断が必要だということです。この請求書の差異はエスカレーションすべきか自動解決すべきか？このベンダーの納期遅延パターンは契約見直しを warrantsか？この承認依頼は標準ルーティングを省略するほど緊急か？これらの判断は現在、人の頭の中にあります。つまり自動化はハッピーパスしか処理できません。
Triggerfish の解決方法
Triggerfish のワークフローエンジンは、一つのパイプライン内で決定論的自動化と AI 推論を組み合わせた YAML ベースのワークフロー定義を実行します。ワークフローの各ステップは Triggerfish のすべての操作を統括する同一のセキュリティ適用層を通過するため、分類追跡と監査証跡は関わるシステムの数にかかわらず連鎖全体を通じて維持されます。
決定論的な作業は決定論的なステップで
ワークフローステップの入力と出力が既知の場合、標準的な HTTP 呼び出し、シェルコマンド、または MCP ツール呼び出しとして実行されます。LLM の関与なし、レイテンシーペナルティなし、推論コストなし。ワークフローエンジンは REST API 用の call: http、接続済み MCP サーバー用の call: triggerfish:mcp、コマンドラインツール用の run: shell をサポートします。予測可能な作業には従来の自動化が正しいアプローチであるため、これらのステップは従来の自動化と全く同じように実行されます。
判断が必要な場面での LLM サブエージェント
ワークフローステップが文脈的な推論を必要とする場合、エンジンは call: triggerfish:llm を使って実際の LLM サブエージェントセッションを生成します。これは単一のプロンプト/レスポンスではありません。サブエージェントは Triggerfish に登録されたすべてのツール——ウェブ検索、メモリ、ブラウザ自動化、すべての接続済み統合——にアクセスできます。文書を読み、データベースをクエリし、レコードを比較し、見つけたすべての情報に基づいて意思決定できます。
サブエージェントの出力は次のワークフローステップに直接フィードされます。推論中に機密データにアクセスした場合、セッションの taint は自動的にエスカレーションされ、親ワークフローに伝播します。ワークフローエンジンはこれを追跡します。PUBLIC で開始したワークフローが判断呼び出し中に CONFIDENTIAL データにアクセスした場合、その実行履歴全体が CONFIDENTIAL レベルで保存されます。より低い分類のセッションはそのワークフローが実行されたことさえ見ることができません。
実際のコンテキストに基づく条件分岐
ワークフロー DSL は条件ルーティング用の switch ブロック、バッチ処理用の for ループ、ワークフロー状態の更新用の set 操作をサポートします。複雑な条件を評価できる LLM サブエージェントステップと組み合わせることで、ワークフローは単なるフィールド値ではなく実際のビジネスコンテキストに基づいて分岐できます。
調達ワークフローはサブエージェントのベンダーリスク評価に基づいて異なるルーティングができます。オンボーディングワークフローは特定のロールに関係ないステップをスキップできます。インシデント対応ワークフローはサブエージェントの根本原因分析に基づいて異なるチームにエスカレーションできます。分岐ロジックはワークフロー定義に存在しますが、意思決定の入力は AI の推論から来ます。
システムが変化したときの自己修復
API がレスポンスフォーマットを変更したり、システムが予期しないエラーを返したりして決定論的ステップが失敗した場合、ワークフローは単に停止しません。エンジンは失敗したステップを LLM サブエージェントに委任し、エラーを読み取り、レスポンスを確認して、代替アプローチを試みることができます。新しい必須フィールドを追加した API は、エラーメッセージを読んでリクエストを調整するサブエージェントによって処理されます。認証フローを変更したシステムはブラウザ自動化ツールによってナビゲートされます。
これはすべての失敗が魔法のように解決されるという意味ではありません。しかし、ワークフローが無言で失敗する代わりに graceful に degradeすることを意味します。サブエージェントは前進する道を見つけるか、誰も確認しないログファイルに埋もれた不可解なエラーコードの代わりに、何が変わりなぜ手動介入が必要なのかを明確に説明します。
連鎖全体のセキュリティ
Triggerfish ワークフローの各ステップは、直接ツール呼び出しと同じポリシー適用フックを通過します。PRE_TOOL_CALL は実行前に権限を検証してレート制限を確認します。POST_TOOL_RESPONSE は返却データを分類してセッション taint を更新します。PRE_OUTPUT は分類レベルがターゲットの許可を超えるデータが系外に出ないことを確認します。
これにより、CRM（CONFIDENTIAL）から読み取り、LLM でデータを処理し、Slack にサマリーを送信するワークフローが、機密情報を公開チャネルに誤って漏洩させることがありません。書き下し防止ルールがデータが通過した中間ステップの数にかかわらず PRE_OUTPUT フックで検出します。分類はワークフロー全体を通じてデータと共に移動します。
ワークフロー定義自体に classification_ceiling を設定して、ワークフローが指定レベルを超えるデータに触れないようにすることができます。INTERNAL に分類された週次サマリーワークフローは、アクセス認証情報を持っていても CONFIDENTIAL データにアクセスできません。上限はコードで適用され、LLM がプロンプト指示を尊重することへの期待に依存しません。
Cron とWebhookトリガー
ワークフローは誰かが手動で開始することを必要としません。スケジューラーは定期ワークフロー用の cron ベーストリガーとイベント駆動実行用の webhook トリガーをサポートします。朝のブリーフィングワークフローは午前 7 時に実行されます。PR レビューワークフローは GitHub が webhook を送信したときに起動します。請求書処理ワークフローは共有ドライブに新しいファイルが現れたときにトリガーされます。
Webhook イベントには独自の分類レベルがあります。プライベートリポジトリ用の GitHub webhook は、セキュリティ設定のドメイン分類マッピングに基づいて自動的に CONFIDENTIAL に分類されます。ワークフローはその分類を継承し、すべての下流適用が適用されます。
実際の使用例
NetSuite、Coupa、DocuSign、Slack を横断して調達から支払いを運用する中堅企業が、フルサイクルを処理する Triggerfish ワークフローを定義します。決定論的ステップは発注書の作成、承認のルーティング、請求書照合の API 呼び出しを処理します。LLM サブエージェントのステップは例外を処理します：PO の行項目と一致しない請求書、予期しないフォーマットで文書を提出したベンダー、依頼者の履歴についてのコンテキストが必要な承認依頼。
ワークフローはセルフホスト Triggerfish インスタンス上で実行されます。データは会社のインフラ外に出ません。分類システムにより、NetSuite の財務データが CONFIDENTIAL に保たれ、INTERNAL に分類された Slack チャネルに送信できないことが保証されます。監査証跡は LLM サブエージェントが行ったすべての意思決定、呼び出したすべてのツール、アクセスしたすべてのデータを、コンプライアンスレビュー用の完全なリネージ追跡付きで捕捉します。
Coupa が API を更新してフィールド名を変更すると、ワークフローの決定論的 HTTP ステップが失敗します。エンジンはエラーを読んで変更されたフィールドを特定し、正しいパラメーターで再試行するサブエージェントに委任します。ワークフローは人の介入なしに完了し、インシデントは記録されてエンジニアが将来のフォーマットを処理するためにワークフロー定義を更新できます。