チームが初めて導入するとき、どんな Agent を作ればいいか、どう分担すればいいかが分かりません。最も怖いのは、いきなり使いこなせない「おもちゃ」を大量に作ってしまうことです。
先に Agent を作らず、まず案内役の Agent 1 体に業務を把握させます。ポジションをどう分けるか、どの工程が最も人手を食うか、データがどのシステムにあるか。把握したうえで、それが「人 + Agent のハイブリッド組織」の設計案を提示し、人が判断を下してから承認フローを通して新しい Agent を 1 体ずつ作成し、既存の Agent が新しい Agent に「オンボーディング研修」を行います。
業務の細部を掘り下げ、実際のファイルを読み解き、ネットで業界のやり方を調べ、組織構成の提案を出し、新しい Agent の承認カードとワークフロー説明を起草します。
ユーザープロフィール、レビュー、注文シグナルのデータベースを棚卸しし、どの市場データの経路が欠けているかを指摘します。
新規作成されたサポート Agent。着任前に @案内役 が研修し、境界を長期記憶に書き込みます。
新規作成されたリサーチ Agent。@ユーザー洞察 とその場でデータ分担を取り決めてから着手します。
運用担当が実際の業務ファイルを #onboard に置き、@案内役 が読み解いて「最も詰まる工程は何か」を掘り下げます。
@ユーザー洞察 が内部データベースを棚卸しし、各市場のデータ像とギャップを示します。
@案内役 がネットで業界のやり方を調べ、自社の現状と 1 条ずつ照らしてギャップ分析を出します。
2 体の Agent がそれぞれ運用視点・ユーザー視点で組織の提案を出し、人がどちらかを指定して最終版を作らせます。
案に沿って承認カードを起草し、人が承認して作成します。既存の Agent が新しい Agent にオンボーディング研修を行います。
新しい Agent はそれぞれ着任前に、関連する Agent がデータインターフェースと業務テンプレートを引き継ぎます。
どの Agent がどのデータツールを備えているか、誰が代理検索を要するかを、定期的にはっきりさせます。
パイロットサイトをしばらく回したあと、あらためて組織構成の提案を改訂します。
1 つのサイト、1 つの単品で 2〜3 週間のパイロットを、検収指標付きで行い、そのうえで他のサイトへ横展開する。
把握の中で見つかったデータ経路の欠落（一部の市場ではユーザーデータがほぼない）を、専任の補完項目として挙げる。
Agent にあなたへ反対させる。良い組織提案には「あえて勧めない設計」も含まれるべきで、たとえば国ごとにまったく同じ Agent を N セット複製するような案です。