Handoff / ACK / Return

Contextの次に、受け渡しの問題が出てくる

Repository Contextは、目的、正本、現在地、判断、次アクションを会話の外へ置きます。 それだけでも長期作業はかなり再開しやすくなります。

しかし、仕事を専門ごとに分けたり、別のAIへ渡したりすると、次に「誰が、何を、どこまで引き受けたのか」という問題が出てきます。

最小形

Handoff
↓
ACK
↓
Work
↓
Return

Handoffは、会話全文のコピーではない

良いHandoffは巨大なContext Packではありません。正本がRepositoryにあるなら、Handoffは「どこを読めば現在地へ戻れるか」を短く示せば十分です。

# Handoff

from: website-planning
to: website-build
scope: Repository Context公開ページの実装

read_first:
- REPOSITORY_CONTEXT.md
- docs/SITE_V1_0_SCOPE.md
- docs/INFORMATION_ARCHITECTURE.md

required_result:
- 公開ページを実装する
- mobile / desktopを確認する
- 結果をACKまたはReturnで返す

boundaries:
- 公開方針を勝手に変更しない
- secretをRepositoryへ入れない

ファイル名やpathだけを人間が次のセッションへ渡し、受け手がRepositoryから文脈を復元する方法を、ここではPath-only Handoff と呼びます。

ACKは「了解」ではない

ACKの役割は、受領した内容の解釈が合っているかを、作業開始前に短く確認することです。 最低限、次が分かれば十分です。

• 何として受領したか
• 自分の担当Scope
• 担当外
• 着手できるか
• 止まる条件は何か
• 次に何をするか

# ACK

source_handoff: handoffs/example.md
status: accepted

role: Web implementation
scope:
- 指定ページの実装
- 表示確認

out_of_scope:
- IAそのものの変更
- production公開判断

stop_conditions:
- 正本間に矛盾がある
- 公開可否が不明

next_action:
- 正本を読んで実装を開始する

Returnは、成果と未解決を返す

作業が終わったら、長い作業実況を別チャットへ貼り直す必要はありません。 変更した正本と、残った判断だけをReturnします。

# Return

status: completed

result:
- 指定ページを実装
- build確認済み

changed_sources:
- site/src/pages/example/index.astro
- docs/INFORMATION_ARCHITECTURE.md

unresolved:
- production公開判断

next_owner:
- main session

人間を「伝書鳩」にしない

複数のAIセッションを使うと、人間が各チャットの内容をコピーして別チャットへ貼る作業が増えがちです。 RepositoryにHandoffとACKを置けば、人間が渡すものはpathだけにできます。

Human
  ↓ pathだけ渡す
Handoff in Repository
  ↓
Receiver reads sources
  ↓
ACK
  ↓
Work
  ↓
Return in Repository
  ↓
Main session reads result

ここで重要なのは、AI同士が自動で会話することではありません。受け渡しの意味が、特定のチャット画面に閉じずに残ることです。

最初は、この3つだけでいい

Routing Engine、Communication Bus、Agent Registryのような仕組みは、多数のAgentを扱う段階で必要になることがあります。 しかし、最初から必要ではありません。

まずRepository Contextで現在地を外部化し、必要になったときだけHandoff / ACK / Returnを足す。 これが受け渡しの最小形です。