Agent は形式的に正しい応答を返しても依頼を完了していないことがある。有用な成果物を残して会話が終わる場合や、次の段階が未接続の場合もある。確かに続けるには、引き継ぎ側が成果物の用途、対応する依頼、現在それを支える前提を知る必要がある。
以下の三記事は違う箇所を扱う。設計ノートは同じ道具から作る製品を区別する。実際のバッチ処理障害は識別照合の後に成功を置く理由を示す。Flowness の Work 設計を読む記事は、その結果の状態を、一実行者の記憶を越えて問い合わせ可能に保つ方法を考える。
同じ三つの道具から、三つの製品が生まれる ↗
大気質の企画が最初に渡すべきものを、変換記録、調査できる比較、独立して読める説明から選ぶ。
成功の確定は識別情報の照合後に ↗
事例識別子が変わった項目を追い、新規呼び出しにも過去の成功記録にも同じ検収境界が要る理由を知る。
仕事に、会話の外でも開ける住所を持たせる ↗
古い要件に合格するテストが残ったスケジューラー引き継ぎを見て、現在の仕事のビューが保存すべきものを調べる。
既存ワークフローには、可逆なテストで意図的に中断する確認が使える。別の実行者は最新目標、実ファイルと結果、次の必須行動、実利用や受け入れ待ちの箇所を特定できるだろうか。節約した仕事と記録の維持にかかる労力を比べたい。