Claudeはワークフローを発見したが、Charlieはそこから始めた

Anthropicは最近、Claude Codeに動的ワークフローを導入しました。これはコーディングエージェントが単一のプロンプトからオーケストレーションへと移行していることを示す重要なシグナルです。しかし、Charlie Labsの創設者は、より効果的なアーキテクチャはセッションではなくタスクとタスクツリーに基づくものだと主張します。

ワークフローの真価は、複雑なソフトウェア開発が線形ではないことを認める点にあります。優秀なエンジニアは調査し、オプションを比較し、エッジケースを確認し、レビューを依頼し、テストを実行し、証拠が計画と矛盾する場合は方向転換します。エージェントも同じ形状を必要とします。あるワーカーがデータベース層を調査し、別のワーカーがAPI境界を読み、検証者がパッチを破壊しようと試み、最終的な回答がすべての証拠を統合して一つにまとめることができます。

ここで重要なのは、アーキテクチャがプロンプトの巧妙さよりも重要になることです。複数のワーカーには、ライフサイクル状態、スコープ付きコンテキスト、ハンドオフ、権限、キャンセル、リトライ、検証、および記録が必要です。これらがなければ、燃費の悪い印象的なグループチャットにすぎません。

Charlieはセッションではなくタスクから始めます。ローカルチャットやIDEセッションは密なループに便利ですが、作業を共有、再開、レビュー、またはツール間で調整する必要がある場合、セッションは扱いにくくなります。セッションは一人のユーザー、一つのタイムライン、一つのトランスクリプトに属し、調整の痕跡はオプトインです。

代わりに、Charlieはリクエスト自体を永続的なオブジェクトとして扱います。Slackスレッド、GitHubコメント、Linearイシュー、スケジュールされたウェイク、レビューリクエストがタスクになります。そのタスクは子タスクを生成でき、各子タスクは限定されたロールで実行され、構造化されたハンドオフを返します。ブランチ、コミット、PR、テスト出力、コメント、フォローアップ質問は、チームがすでに作業しているシステムに直接反映されます。

違いは些細に見えますが、何か問題が起きた時にその真価を発揮します。ユーザーが実行中にフォローアップした場合、タスクは適応できます。検証が失敗した場合、その失敗はハンドオフの一部になります。ワーカーが完了した場合、曖昧な要約ではなく、永続的な識別子を返します。セッションは深くなったのではなく、作業がセッションを離れたのです。

一般的な反論として、タスクツリーは重すぎるというものがあります。ワーカー、ハンドオフ、検証、永続状態——これらは大規模な移行のためだけのものに思えます。しかし、その逆です。重いワークフローモードの反対はおもちゃモードではありません。それは、同じシステムで爆発半径を小さくしたものです。

例えば、Slackでタイポ修正を依頼した場合、Charlieは狭いタスクを実行し、ブランチを作成し、該当ファイルをフォーマットし、PRを開き、結果を報告します。GitHubレビューコメントに回答するよう依頼した場合、ターゲットを保持し、コードをパッチし、関連するチェックを実行し、その場で返信できます。同じ基盤、より小さなタスク、より速い完了。

これが「ワークフローモード」が誤ったメンタルモデルである理由です。チームはリクエストがオーケストレーションに値するかどうかを判断すべきではありません。すべてのリクエストは、安全に完了するために必要な最小限のオーケストレーションに値します。時には一つのワーカーと一つのコマンド、時にはワーカーのツリーと検証パス。

オーケストレーションは基盤であるべきであり、アップグレードボタンではありません。Claudeの動的ワークフローは市場にとって良い兆候であり、真剣なエージェント作業には分解、並列化、検証、永続性が必要であることを明確に示しています。しかし、議論はもう一層低いレベルで行われるべきです。問題は、エージェントがセッション内でワークフローを作成できるかどうかではなく、製品が永続的な作業を中心に構築されているかどうかです。

Charlieはそのように構築されました。リクエストはタスクになり、タスクはツリーを形成し、ワーカーは境界のあるジョブを実行し、ハンドオフは状態を保持し、証拠はレビュー可能な成果物に格納され、フォローアップは作業の実行中でも到着可能で、デーモンは不滅のバックグラウンドプロセスを装うのではなく、境界のあるアクティベーションとして起動します。大きな作業も小さな作業も同じメカニズムを使用します。

ワークフローは機能ではありません。ランタイムこそが機能なのです。