polyflow

エージェントはすでに停止中の実行を再開できます。しかし、再開された実行が何を許可されているかをエージェントに伝えることはできません。

polyflow は AI エージェント向けのワークフローエンジンです。エージェントは 次のツール呼び出し ではなく ワークフロー を推論します。polyflow は、そのワークフローがモデルチェックに合格した場合のみ受理し、永続的に実行して、エージェントに一度に1つの作業指示を渡します。

MCP サーバーとして提供されるため、OpenWorker、Claude Code、Cursor など、MCP 対応のエージェントであれば、そのエージェントのコアを変更することなく利用できます。

実験的、未検証、査読なし。このチェックは証明ではなく整合性チェックであり、「網羅的」とは常に、契約が宣言する有限ドメインに対する網羅を意味します。すべての発見は結果ではなく手がかりです。

ループ

tools → observe → reason → WORKFLOW ──▶ polyflow admits it (or refuses)
                                            │
                        ┌───────────────────┘
                        ▼
        one work order  →  the agent runs the tool, through its own
                           permission gates, with its own credentials
                        →  workflow_report
                        →  next work order … until terminal

エージェントは次に何が起こるかを決めることはありません。エージェントは、1つの指示をどのように果たすか（モデルが実際に得意とする部分）を推論し、結果を報告します。シーケンス、リトライ、タイマー、重複抑制、終了条件は機械に属します。

Related MCP server: nano-vm-mcp

なぜこれなのか、常時許可ではないのか

今日、無人自動化は 動詞 によって承認されます。「slack_send を #cs に許可」— 永遠に、モデルがそれで何をするかを問わず。これは、プランが散文の指示文字列であり、実行のたびに再計画される場合の上限です。

polyflow は プラン を承認します。workflows/customer-brief/effect-invariants.mjs には、ユーザーが実際に同意できる文が含まれています。

{ name: 'no-post-without-prior-approval',
  pred: (path) => path.emitted.every((e, i) =>
    e.kind !== 'post_brief' || path.actionBefore('APPROVED', i)) }

起動時には、契約が宣言するドメイン上の到達可能なすべての出力パスを列挙し、チェックします。失敗したワークフローは登録されません — フラグが立てられるだけでなく、実行不可能です。

[polyflow] admitted: customer-brief — paths explored: 5 · states seen: 10 · exhaustive within declared domains
[polyflow] REFUSED: unsafe-brief
[polyflow]   no-post-without-prior-approval

test/fixtures/unsafe-brief は意図的に壊れた双子です。レビューに入るときに、人間が答える前に投稿します。それでも ask_user を呼び出し、同じチャネルをターゲットにし、常時許可を満たします。差分を読むレビューアは簡単に見逃すかもしれません。ゲートは見逃しません。

クイックスタート

npm install                    # pulls polygraph (polyrun) as a dependency
npm test                       # 14 tests, no API key, deterministic
node bin/polyflow-mcp.mjs      # MCP stdio server

OpenWorker と一緒に実行する

前提条件: Node 22+（polyflow は node:sqlite を使用）、および OpenWorker がインストールされていること。polyflow は独自の API キーを必要としません — モデルを呼び出すことはありません。

1. 登録します。 polyflow ディレクトリから:

node bin/polyflow-install.mjs --agent openworker/cowork --workspace acme
# --print shows the entry and the target path without writing anything

これにより、polyflow エントリが OpenWorker のグローバル mcpServers ファイルにマージされます — Connectors ページが編集するのと同じファイルです（Windows では %APPDATA%\coworker\mcp.json、それ以外では ~/.config/coworker/mcp.json、$COWORKER_STATE_DIR が両方を上書きします）。置き換えではなくマージであり、解析できないファイルには触れません。

2. OpenWorker を再起動します。 起動または監視する polyflow デーモンはありません。OpenWorker はセッションが開かれると bin/polyflow-mcp.mjs を stdio 経由で起動し、セッションとともに終了します。実行状態は POLYFLOW_DB の SQLite ファイルに保存されるため、両方の再起動後も存続します。

3. 起動を確認します。 6つのツールが mcp__polyflow__* として表示されます。エージェントに 「実行できるワークフローをリストアップして」 と依頼すると、customer-brief、その admitted: true、および承認された5つの保証が返ってくるはずです。返ってこない場合は、Connectors ページに常時エラーが表示され、サーバー自身の起動行（admitted: / REFUSED:）は stderr に出力されます。

4. 使用します。 特別なことはありません。ワークフローがカバーするタスクをエージェントに与えると、エージェントは自分でワークフローを選択します — それが FINDINGS-phase3.md が測定していることです。定期的なジョブを実行するには、タスクを説明する指示を持つ通常の OpenWorker オートメーションを作成します。ワークフローは毎回最初からやり直すのではなく、派生キーによって再アタッチされます。

エリア。 --agent はエージェントクラスエリア（この種類のエージェントが利用するワークフローライブラリ）で、--workspace はインスタンスエリア（これらの実行が属する場所）です。1つの polyflow インストールで複数のワークスペースを提供できます — ワークスペースごとに異なる --workspace で一度登録し、同じ POLYFLOW_DB を指してストアを共有するか、異なるファイルを指して分離します。

独自のワークフローを追加する。 workflows/customer-brief/ をコピーし、6つのファイルを編集します（下記の ワークフロー を参照）。サーバーを再起動します。出力チェックに失敗したワークフローは起動時に拒否され、まったく開始できないため、悪い編集は午前3時ではなく大きな音で失敗します。

権限。 インストールされたエントリは意図的に requires_approval: false を設定しています — polyflow ツールはマシンの外部に到達せず、実行の実際の副作用はエージェント自身のツールであり、それぞれ独自のゲートを保持します。workflow_report のたびにプロンプトを表示すると、エージェントと自身の記録管理の間にダイアログが入ります。エントリは読み取り専用ツールの tool_risk も宣言しており、upstream/0001-mcp-per-tool-risk-level.patch が適用されると尊重され、適用されなくても無害に無視されます。

polyrun の出所。 polyflow は polyrun をプロセス内に埋め込み、node_modules/polygraph から解決し、次に兄弟チェックアウトを使用します。POLYFLOW_POLYRUN は両方を上書きします。

他のエージェントホスト

polyflow はプレーンな MCP stdio サーバーであるため、MCP を話すものなら何でも使用できます。インストーラーは各ホストに適切なファイルを書き込みます。

node bin/polyflow-install.mjs --host kiro          # ~/.kiro/settings/mcp.json
node bin/polyflow-install.mjs --host kiro --scope workspace   # ./.kiro/settings/mcp.json
node bin/polyflow-install.mjs --host claude-code   # ./.mcp.json
node bin/polyflow-install.mjs --host generic       # prints the entry, writes nothing

2つのホストは異なる形状を取り、書き込むのではなく出力されます。

node bin/polyflow-install.mjs --host nemo      # YAML for a NeMo Agent Toolkit workflow
node bin/polyflow-install.mjs --host registry  # AWS CLI call to publish an Agent Registry record

• Kiro / Kiro Crew は mcpServers を ~/.kiro/settings/mcp.json（ユーザー）または .kiro/settings/mcp.json（ワークスペース、名前の競合ではワークスペースが優先）から読み取ります。Kiro Crew の定期的な無人ジョブは OpenWorker のスケジュールジョブと同じ形状であり、FINDINGS-phase3.md の結果が対象としているケースです。

• NVIDIA NeMo Agent Toolkit は mcp_client 関数グループ（nvidia-nat-mcp が必要）を介して接続します。出力されたブロックはグループを宣言し、ワークフローの tool_names に追加します。NeMo はそれ自体も MCP サーバーとして実行できるため、NeMo ワークフローは polyflow の作業指示が名前を挙げるツールの1つになります。

• AWS Agent Registry はランタイムではなくカタログです。レコードを公開すると、組織内の他の人やエージェントが polyflow を発見できます。レコードは HTTPS エンドポイントから同期できますが、stdio サーバーにはそれを提供する方法がないため、出力されたコマンドは代わりに手動の MCP レコードを作成します。

OpenWorker パスのみがエンドツーエンドでテストされています（FINDINGS-phase2.md を参照）。他は各ホストの文書化された構成形式から構築されており、実行されていません。

どのホストを使用する場合でも、環境変数:

ツール

エリア

2つの層があり、OpenWorker に新しいフィールドは必要ありません。

• エージェントエリア — エージェントの クラス ごとに1つ（openworker/cowork）。ワークフローライブラリを所有します。この種類のエージェントが実行できること。ScheduledTask.agent にマップされます。

• インスタンスエリア — 実行中の コピー ごとに1つ（workspace）。ライブ実行とそのジャーナルを所有します。workspace にマップされ、これはすでに coworker.memory.Scope.WORKSPACE です。

インスタンス ID は agent | instance | workflow | key から派生するため、開始とアタッチは1つの呼び出しになります。

ワークフロー

ディレクトリ内の6つのファイル:

polyflow.workflow.json   name, area, tools{effect kind -> agent tool},
                         key{template,fields} — the run's identity, derived
contract.json            states, actions, finite data domain
machine.cjs              SAM v2 strict-profile module
effects.cjs              pure mapper: transition -> work orders
effects.manifest.json    completion actions + retry policy per kind
effect-invariants.mjs    what may be EMITTED, on every reachable path

エージェントに対してこれを機能させる逆転: polyrun ではランタイムがエフェクトを実行します。polyflow には資格情報、コネクタ、権限エンジンがありません — エージェントにはそのすべてがあります。したがって、エフェクトは手渡される作業指示です。ハンドラーは停止し、エージェントは指示を要求し、自身のゲートの下でツールを実行し、報告します。その後にのみ完了アクションがディスパッチされます。

耐久性はリース機構から生まれます。保留マップはメモリ内にあるため、クラッシュするとプロミスが失われ、リースが期限切れになり、エフェクトが再要求され、指示が再提供されます — 同じインテント ID、少なくとも1回、機械によって吸収されます。

テストが証明すること

✔ the admission gate certifies the demo workflow exhaustively
✔ workflow_list reports the guarantees the run was admitted under
✔ happy path: one order at a time, ending posted
✔ the run key is derived from input, not chosen by the caller
✔ an invalid key field is refused with an instruction, not honoured
✔ a finished run says so, and says not to start another
✔ start is idempotent: re-attaching returns the run in progress
✔ a denial is a result, not a fault — and no post is ever ordered
✔ zero tickets ends the run rather than posting an empty brief
✔ a duplicate report is refused, not double-executed
✔ an out-of-band action that does not apply is an observable reject
✔ a workflow that can post before approval is REFUSED and cannot be started
✔ a run outlives the process: restart re-offers the open work order
✔ initialize, tools/list, tools/call over stdio

再起動テストが重要です。セッション1は実行を承認ステップまで進めて終了します。セッション2は会話、トランスクリプト、リプレイのない別のプロセスです — 状態はそもそもメッセージに含まれていなかったためです。実行を正確にその場所から再開し、両方で正確に1つの投稿が発生します。

まだ構築されていないもの

• プロモーション。 ワークフローはここでは手書きです。計画は、ジャーナルから繰り返し発生する実行形状をマイニングし、レビュー用のマシンを提案することです — 先見ではなく履歴からの帰納。タスクごとにマシンを作成することは、再利用されない限り、置き換えるツール呼び出しよりもコストがかかります。

• バージョン管理。 polyvers は変更されたワークフローを進行中の実行に対してゲートします。まだ配線されていません。

• 監査。 ジャーナルはすでにトレースコーパスです。それに対する polyrun audit はまだ配線されていません。

• コアの変更が必要な OpenWorker のシーム: 停止中の指示をインボックスにルーティングすること、および ScheduledTask の workflow_ref。FINDINGS-phase0.md を参照してください。