スケジューラーの修正を引き継ぐとき、こんな記録が残るかもしれない。
目標：新規タスクの受け入れを一時停止し、実行中のデータ取り込みは完了させる。
成果物：中心部分のパッチは保存済み。コマンドライン入口は未接続。
矛盾：現在のパッチは実行中のタスクをキャンセルする。テストもその古い動作を検証している。
次の行動：一時停止の意味を修正してから接続を続ける。
実行者：現在なし。
Agent が動いていなくても、仕事には明確な状態がある。引き継ぐ人は前の会話を全部読む前に、最重要の欠陥に気づける。中心コードが現在の目標と一致せず、そのまま接続すれば誤った動作を利用者へ届けてしまう。
これは説明用の記録だ。公開コミット c9d6abe の Flowness が提案する Work 設計を示している。この版では Agent をまたぐ完全な継続経路はまだ設計段階であり、この例を実行済みの結果とは扱わない。設計と証拠の状態
住所から根拠へ戻れること
Work は継続する仕事に安定した問い合わせ入口を与える。しかし番号は仕事を見つける助けにはなっても、開いた先が現在の事実であることまでは保証しない。
Flowness は Work を下層の記録の投影として設計している。コードはリポジトリに置き、テスト結果は対応する版を指し、判断と変更はイベント記録に残す。仕事のビューはそれらを集める。パッチの版が変わったなら、単に緑の「合格」を出すだけでなく、どの版をテストしたか示せる必要がある。
ビューは時間上の位置も持つ。たとえば as_of_seq は、どのイベントまで集約済みかを表す。ビューがイベント 147 で止まり、責任者が 148 で一時停止要件を変えたなら、そのビューが新しい決定を含んでいないと識別できる。WorkView の設計
こうした入口は引き継ぎ要約より確かに後続の行動を支えられる。要約は当時の考えを説明する。現在のビューは、どの解釈が後に変わったかも知る必要がある。
実行者が中断したとき、最初にするのは残されたものの照合だ。元の実行は本当に止まったか、パッチはコミットされたか、どのファイルが一時作業区にあり、どの結果が検査されたか。復旧は実状態から決める。前の Agent の「ほぼ完成」という見積もりをそのまま使えない。
次に次の行動用の文脈を準備する。Flowness はこれを Context Capsule と呼ぶ。明確な事実の切断点から、現在目標、関連版、有効な制約、成果物、未解決問題を選ぶ。スケジューラー例では、引き継ぎ側はまず一時停止の意味の矛盾を解く必要がある。全会話履歴を渡すと、次の判断を決める数点の資料が埋もれるかもしれない。実行状態の照合と文脈の編成
新しい Agent は自身の実行を始め、同じ Work を進める。その結果は検査後、次の問い合わせの根拠になる。
前提が変わると、完了記録の意味も変わる
一時停止要件は当初「すべてのタスクを止める」と理解されていたかもしれない。その後責任者が、実行中の取り込みは完了させると確認した。この変化はタスク説明だけに影響するものではない。
古いテストは合格していても、検証したのはキャンセルだ。中心コード、テストのアサーション、コマンドのヘルプは同じ古い前提に依存しているかもしれない。一時停止と無関係なログ形式までやり直す必要はないかもしれない。
この判断には二種類の依存関係が必要だ。タスクが実行順にどうつながるかと、成果物がどの版の解釈に基づくかである。前者だけなら接続がテストの後だと分かる。後者があって初めて、テストの前提となる要件が古くなったと分かる。
Flowness は後続の仕事を変える観察を Finding と呼び、Reflow が影響する前提と依存関係を特定して次の仕事を組み立てる。ここでは「中心実装は実行中の取り込みをキャンセルし、現在の要件と矛盾する」と直接書ける。計画はまず中心動作へ戻り、進行中タスクが完了することを確かめ、その後コマンド入口を接続する。Finding と Reflow の設計上の関係
既存成果物は残る。変わるのは、それが今も支えられる判断だ。古いテスト結果は歴史を説明できるが、新要件を満たした根拠には使い続けられない。
局所的なやり直しが省力になるかは、依存記録の正確さ次第だ。抜けた関係は調査が必要で、範囲が不明なら精細な分類より広く検証するほうが安いこともある。この設計は実際の修正課題で、引き継ぎ側の誤った進路をどれだけ減らし、記録費用をどれだけ増やすか試す必要がある。
実行の永続化には成熟した道具がある。Temporal はイベント履歴からワークフロー状態を復元し、Signal や Update などの新入力を受け取れる。LangGraph はチェックポイントと永続ストアでグラフ状態やスレッド間データを保存できる。Temporal ワークフロー、メッセージ伝達、LangGraph の永続化
Work が扱うのは、保存した状態の解釈だ。目標の版、置き換えられた判断、影響を受ける成果物、引き継ぎ側が今得るべき資料を整理する。既存実行エンジン上に構築できる規則である。チケット、リポジトリ、ワークフローが関係を十分に保存しているなら、並行するデータベースを増やすと同期負担が増えるだけだ。
「完了」の後にも住所は役立つ
中心ロジックを直しても、後続の仕事がすべてなくなるわけではない。Flowness は、異なる継続行動に対応する四状態を区別する。
| 状態 | スケジューラー例での意味 |
|---|---|
| 構築済み（built） | 検査可能な一時停止機能の成果物がある。 |
| 統合済み（integrated） | コマンド入口と実際の呼び出し経路が接続されている。 |
| 実利用済み（activated） | 対象環境での自然な利用がこの機能を実際に呼び出した。 |
| 受け入れ済み（accepted） | 検収責任者が需要を満たすと確認した。 |
実利用の定義は、テスト、デモ、演習、単なる配備完了を除く。責任者の受け入れも対象を明確にし、どの版を認めたか示せる必要がある。実利用と受け入れの定義
これで待機が具体的になる。接続は済んだが実際の一時停止需要がまだない場合も、実利用したが責任者の検収待ちの場合もある。Agent を動かし続ける必要はなく、待つイベント、責任者、再確認の条件を残せばよい。
条件がそろったら同じ Work を開き、現在の版を確かめて次の行動を始める。公開の引き継ぎデモ仕様も、この経路を検証するために用意されている。実行者の中断後、旧 Agent の一時的な記憶に頼らず、永続状態から新しい実行者が続けられるかを試す。引き継ぎデモ仕様
保守する人にとって、その住所が最終的に答えるべきなのは実用的な一問だ。今日またスケジューラーを扱うなら、どこから手を付けるべきか。答え続けられて初めて、仕事は会話の終了、人の交代、要件の変化を越えられる。