automation-architecture

自動化アーキテクチャ

目標

顧客のユースケースを、名前付きのプリミティブに具体的なフィールド値を設定し、端から端まで接続した、正確で最小限の Nexor 構成に変換します。成果物は推奨事項ではなく、構成そのものです。

分解の3つの原則

プリミティブを選ぶ前に、これらを適用してください。これらはスタイル上の好みではありません。それぞれ、プラットフォームが制御、トリガー、テンプレート化、検証できる唯一の形式を定めています。プラットフォームは文章の中にある情報を認識できないため、デモで正しく動作しても、これらの原則に反する設計は信頼できません。

原則 1 — システムが必要とする情報はすべて変数にする

ビルドが何かの情報に依存するなら、それは名前付きのワークフローフィールドかリードの metadata として存在させてください。プロンプト内の文章に記述したり、「エージェントが会話から覚えている」としたりしてはいけません。

• エージェントが情報を取得する必要がある → ワークフローフィールドを使用し、required: true と extraction_hints を設定します。
• 外部ツール（CRM、フォーム、顧客独自のバックエンド）がリードの識別情報や連絡先情報を提供する → 標準のリード作成／更新コントラクトを使用して、first_name、last_name、email、phone を設定します。これらの値を metadata に隠してはいけません。metadata を使っても、Nexor の連絡先の保存先は変わりません。
• 外部ツールがその他のコンテキスト情報を提供する → リードの metadata JSON オブジェクトに直接格納します。キーには文字列、数値、ブール値、null、配列、ネストされたオブジェクトを設定できます。完全な metadata オブジェクトが次の実行時エージェントプロンプトに挿入されるため、キーごとにフィールドを作らなくても、エージェントはすべてのパラメーターと値にアクセスできます。
• エージェントが外部から提供された情報を質問、検証、正規化、または条件判定に使用する必要がある → metadata_key（必要に応じて intake_value_map も）を指定したワークフローフィールドを追加し、質問する代わりに metadata からフィールドに事前入力します。metadata_key、options、extraction_hints、validation を設定できるのは、最初の create_workflow 呼び出し時のみです — update_workflow_structure が受け付けるのは key、label、type、required、sort_order のみです。エージェントを作成する前に、変数台帳を完成させてください。
• ツールが情報を生成する → llm_response_fields を使ってターン内に保持し、後続のステップで必要な場合は、ツール後のフックで metadata に書き込みます。
• ゲートが読み取るのはフィールドのみです。 required_field_keys、requires_all_fields、transition_rules から metadata を参照することはできません。
• 決定論的な送信処理が読み取るのは metadata のみです。 ステータス自動化の args_template、Webhook の payload_template、HTTP ツールのテンプレートが参照できるのは {{lead.<path>}} ／ {{lead.metadata.<key>}} であり、収集済みのフィールド値は読み取れません。自動化から送信する必要がある値は、リードがトリガーとなるステータスに到達する前に、ツール後のフックまたは patch_metadata を使って metadata に複製してください。読み取り先と保存先の完全な対応表は、references/configuration-reference.md を参照してください。

設計で使う事実ごとに、そのキーと保存先を明記してください。会話履歴にしか存在しない事実では、ステータスの条件判定、リードのルーティング、リクエスト本文への入力、ジョブのフィルタリングはできません。

Law 2 — 1 つのエージェント内のすべての状態変化はステータスです

エージェントの動作、権限、または義務がある時点で変化する場合、その時点はエージェントのパイプラインにおけるステータスです。プロンプトに記述された「フェーズ」にしたり、メタデータ内にブール値として置いたりしてはいけません。

プラットフォームの他の部分が参照できる唯一の手段がステータスです。ステータスでないステージは、workflow_tools.available_in_statuses、status_automations.on_status_key、to_status.key の Webhook フィルター、timeout_config、transition_rules / required_field_keys、バックグラウンドジョブの workflow_filters.status_keys、再連絡の trigger_status_key、assignment_config からは見えません。

各ステージに key、label、Law 1 の変数を使ったステージへの移行条件を示す entry_hint、および明示的なゲートを設定してください。フィールド値だけで移行先が完全に決まる場合は、transition_rules.rule_groups に auto_evaluate: true を設定し、エージェントが set_lead_status を呼び出すことに依存せず、プラットフォームがリードを次のステージに進めるようにしてください。

すべてのゲートは、required_field_keys（または requires_all_fields）と transition_rules で表現してください。variable_refs は MCP から書き込みできません。これはダッシュボード表示用のヒントであり、これに依存する設計にはゲートがありません。review_agent_system_plan がこのルールを適用します。entry_hint も transition_rules もない初期以外のステータスは、確認質問として返されます。

既存のパイプラインの順序を変更する際は、意味上の中核をそのまま維持してください。Lead created（core_new）、Contacted（core_contacted）、Engaged（core_engaged）は、それぞれ 1 番目、2 番目、3 番目の位置に置きます。get_workflow を呼び出し、残りの永続化されたステータスキーをすべて 1 回ずつ reorder_workflow_statuses に渡してから、再度 get_workflow を呼び出し、完了を報告する前に全体の順序を比較してください。生の sort_order 値を送信して並べ替えたり、合成された Discarded 列を含めたり、編集可能なラベルから中核となるステータスを推測したりしてはいけません。グループ化の動作については references/configuration-reference.md を、書き込みの仕様については references/mcp-tool-surface.md を参照してください。

Law 3 — エージェントのアイデンティティが切り替わるたびに、引き継ぎを行う境界ステータスを設ける

口調、ペルソナ、目標、プロンプトの内容、ツールセット、チャネルの組み合わせ、または接触頻度を変えることは、別のエージェントにすることを意味します。切り替えをプロンプト内で行うことはありません。リードが退出する境界ステータスを介して切り替えます。

• ターミナル引き継ぎ（デフォルト）： is_terminal: true と transfer_config: { "target_workflow_id": "<real id>" } を指定します。これが自動的に引き継ぎを実行する唯一の形式です。すべてのエージェント経路は transfer_config を読み取る前に is_terminal を確認するため、ターミナルではないステータスに transfer_config を指定しても実行されません。設定はエラーなく保存されますが、何も起こりません。
• 境界ステータスに future_*、contact_later、または colder という名前を付けないでください。 これらのキーはソフトターミナルとして扱われ、transfer_config を読み取る前にターミナルの副作用処理経路から除外されるため、ターミナルとして正しく設定していても引き継ぎはスキップされます。これはシステム全体でもっとも気づきにくい失敗です。
• 一時停止境界： バックグラウンドジョブの workflow_transfer／force_transfer アクション、単発の引き継ぎ API、または人間によって、引き継ぎが別途実行される場合に pause_bot: true を指定します。一時停止境界では、実行者を明記する必要があります。明記しないと、リードは永久に応答しない状態になります。この方法は安全に利用できます。pause_bot はステータスフラグであり、workflow_runs.is_paused を設定しないため、標準の exclusions.skip_paused: true を指定したジョブでも、これらのリードは引き続き処理対象になります。

どちらの形式でも、境界で元のエージェントの担当が終了します。1つのリードで稼働するエージェントは常に1つだけです。転送先は必ず独自の初期ステータスから開始し、そのケイデンスも最初から始まります。元のエージェントが収集したフィールドは、読み取り専用の引き継ぎチェーンのスナップショットとして引き継がれます。

禁止される形式：プロンプトに「条件を満たしたら、成約向けの口調に切り替える」と記述すること、エージェントのペルソナを変更する目的のツール、同じリードで2つのエージェントを稼働させること、転送先の特定のステータスを指定する引き継ぎ。

Law 2 と Law 3 のどちらか？

同じ目標、同じペルソナ、同じツールセット、同じケイデンスで、リードについてわかっている情報だけが増える場合 → ステータス。目標、プロンプト、ツール、チャネル、または接触頻度が異なる場合 → 境界ステータスの背後に新しいモードを設けます。約80％テストは、1つのインテントの中でのみ適用されます。同じインテントとレジスターを共有し、プロンプト、ツール、スケジュールの約80％を共有する2つの候補モードは、より多くのステータスを持つ1つのモードに統合します。異なるインテント同士を統合することはありません。

デフォルトの構成：意図ごとに分け、2～3つのモードにする

オペレーターが目にし、名前を付けるのは エージェント（マスターワークフロー）です。その中に構築するのは モード（ワークフロー）で、意図ごとに1つずつ用意します。デフォルトでは、幅広いプロンプトを1つ書くのではなく、分割します。オペレーターが「これをどうしても1つのモードにしたい」のように、1つだけにしたいと明確かつ明白に指定しない限り、次のように分解します。

• 意図が変わるたびに新しいモードを作成します — 会話で見込み客に何をしてもらおうとしているのか（販売、フォローアップ、割引の提案、予約、支払いの回収、顧客の維持）を基準にします。
• レジスターが変わるたびに新しいモードを作成します — 「同じ販売」の中でも、トーン、強さ、会話のペース、ペルソナ、チャネルの組み合わせが変わる場合は分けます。親しみやすく情報を伝える最初のアプローチ、強く促すリマインダー、1回限りの譲歩は、それぞれ異なるレジスターです。
• 一般的な依頼では2～3つのモードを作成します。 「自社の EC サイトでチケットを販売し、割引を案内してフォローアップする」は、1つでも5つでもなく、2～3つのモード（販売 → 未払いのフォローアップ → 割引の提案）にします。references/recipes.md のレシピ 25 で、一連の流れを確認できます。
• 明示的な指示がある場合に限り、モードを1つにします。 plan.decomposition にオペレーターの言葉を引用し、single_mode_explicitly_requested: true と operator_instruction を設定します。これらがない場合、review_agent_system_plan は1モードの計画をブロックします。
• 5つ以上にしてはいけません。 4つを超えるモードに分けると、1つの会話が断片化されます（モードが切り替わるたびに会話のペースがリセットされ、初回接触が再びトリガーされます）。オペレーターの言葉を含む large_system_explicitly_requested がない限り、レビューでブロックされます。意図とレジスターの両方が共通するモードは統合します。
• すべてのモードに到達できるようにします。 最初に記載したモードがエントリーポイントです（または、ほかのモードに entry_point: true を設定します）。それ以外の各モードは、いずれかのモードの終了時の転送先になっている必要があります。そうでない場合、レビューで見込み客がどうやってそのモードに到達するのか確認されます。

describe_agent_configuration は、この仕様を mode_split として返します。計画では各モードの意図とレジスターを明記し、レビューの decomposition の概要をオペレーターに伝えてください。

プリミティブ

顧客からの依頼は、以下のいずれか一つ以上に当てはまります。

#	プリミティブ	トリガー	コード？	スコープ
1	エージェント設定（ステータス＋受付フィールド）	リードのメッセージ、会話の途中	いいえ	1件のリード、ターン内
2	ワークフローの HTTP/MCP ツール	エージェントがターン中に外部情報や操作を必要とする	いいえ	1件のリード、同期処理
3	ルール（リマインダー／ホストへの通知／再接触）	ミーティングのライフサイクル、停滞	いいえ	1件のリード
4	アウトバウンド Webhook	プラットフォームイベント（ステータス変更、ミーティングのライフサイクル）	いいえ	外部 API（CRM、ERP、自社バックエンド）への通知。発生のたびに実行
5	ステータス自動化	リードが特定のステータスに到達したとき	いいえ	1件のリードにつき、1つの HTTP/MCP ツールを正確に1回呼び出す
6	バックグラウンドジョブ	cron またはタグイベント	いいえ	フィルタリングされた対象群、宣言的なステップ
7	クラウド関数	lead.*／workflow.*／meeting.* イベント	JS	イベントごとに1件のリード
8	スケジュール関数	Cron ＋タイムゾーン	JS	ルックアップクエリによる対象群
9	ワークフロー転送	終端ステータスと transfer_config	いいえ	1件のリード、エージェント間の引き継ぎ
10	受付 API／インバウンド Webhook	外部ツール（CRM、フォーム、Zapier、自社バックエンド）からのリード登録	いいえ	リードの作成＋登録
11	ケイデンス設定（連絡可能時間帯＋日別設定）	アウトリーチのスケジュール設定：時間帯、チャネルごとの強度、頻繁な連絡	いいえ	ワークフローのアウトバウンド施策全体
12	ナレッジベースの割り当て	エージェントが実行時に、選択されたアカウント所有のナレッジを必要とする	いいえ	エージェントごとに厳密に指定されたサブセット。検索の優先順位順
13	実行前フック（mode: "on_entry" のツール）	最初のエージェントメッセージの前に、リードがワークフローに入る	いいえ	1件のリード、決定論的。ステージによる制御は不可
14	前処理機能	インバウンドリードが到着し、どのエージェントも担当する前	いいえ	受付ワークフローを選択する、順序付けられた条件ルール
15	ステージタイムアウト（timeout_config）	リードがステータスに入ってからの経過時間（「48時間返信なし」）	いいえ	1件のリード。同じエージェントの別のステータスに移動します。プラットフォーム唯一の遅延プリミティブです。transfer_config を持つ終端ステータスを指定すると、遅延引き継ぎになります

判断の順序 — 設定をコードより優先

設定はオペレーターから見え、UI で編集でき、クラッシュすることはありません。一方、コードはオペレーターから見えず、将来にわたって自分で保守する必要があります。上から順に確認し、要件を満たす最初の項目で止めてください。

1. ネイティブの会話設定で表現できますか？ ステータス、インテークフィールド、プロンプトルール、または決定論的な分岐 → エージェント設定。「Xについて尋ね、それに応じて分岐する」はコードではなく、ステータスとフィールドで実現します。通常、法則1と2ですでにこの段階の大部分が設定されています。
2. 待機ですか？ 「N時間返信がなかった場合……」、「3日後に……へ移動する」、「48時間後にフォローアップエージェントへ引き継ぐ」 → 待機中のステータスに timeout_config を設定します（set_status_timeout_rule、または create_workflow／update_workflow_status 内でインライン指定）。次のステータスを指定するか、遅延引き継ぎの場合は transfer_config を設定した終端ステータスを指定します。複数段階の待機にはステータスを連結します。タイマーはステータスに入ってからの経過時間であり、返信によってリセットされません。これはダッシュボードの「リードが返信しない場合 → N時間後 → 移動先」コントロールに相当します。スケジュール関数、バックグラウンドジョブ、クラウド関数、再連絡用の on_exhausted は、リードごとの待機に対する答えには決してなりません（レシピ23）。
3. 標準的なライフサイクルの通知ですか？ 予約確認、会議前のリマインダー、ホストへの通知、停滞したリードへの再連絡 → ルールを使います。設定して完了です。
4. 状態の変化によって、実行すべきタイミングを正確に定義できますか？ モデルにツールを選ばせるより、決定論的な実行を優先します。ステータス変更 → 受信側がイベントに基づいて処理できる場合は、フィルター付きの送信ウェブフックを使います。Nexor がカスタム本文を使って設定済みエンドポイントを一度呼び出す必要がある場合は、ステータスオートメーションを使います。フィールド／変数やその他のリードイベント → 関連するキー／変更に対するガードを設けたうえで、クラウド関数をトリガーします（information.collected、information.updated、lead.updated、またはサポートされる中で最も限定的なイベント）。
5. エージェントが最初のメッセージを送る前に結果が必要ですか？ → 実行前フックを使います：set_workflow_tool_execution({ mode: "on_entry" })。プラットフォームはリードがワークフローに入った瞬間に、エージェントが話す前にツールを実行します。モデルの判断は介在しません。エンリッチメント、適格性の照会、アカウントのコンテキストに適した方法であり、到着時にデータが揃っている必要がある引き継ぎ先にも適しています。ステージごとの条件設定はできないため（2つのモードは相互排他です）、「入場時」が本当に必要なタイミングである場合に限って使います。
6. 先に実行できる状態イベントがなく、現在のターンを続ける前に外部の結果が本当に必要ですか？ クライアントのエンドポイントを、mode: "agent_decides" のワークフロー HTTP/MCP ツールとして公開します。モデルが選択して呼び出す必要があるため、これは最も信頼性の低い段階です。クライアント固有のロジックはクライアント側のシステムに置き、契約の範囲を狭くします。また、qualified などの段階を経た後にのみ有効な場合は、available_in_statuses で制限します。
7. 「リードを絞り込む → 条件 → アクション」ですか？ → 宣言型のステップとアクションを持つバックグラウンドジョブを使います。必ず max_leads_per_cycle と cooldown_minutes を設定し、人にメッセージを送る処理はドライランで確認します。
8. 非同期処理に、カスタムロジックやジョブの語彙では表現できない外部 API が必要ですか？ トリガーの文言に従って使い分けます。「リードが……した とき」→ クラウド関数（イベント、1リード）。「毎朝／毎週月曜日」→ スケジュール関数（cron、対象グループ）。何時間もの遅延が許容され、多数のリードを対象とする「とき」の処理なら、スケジュールによる一括処理を優先します（ドライランで対象グループ全体を先に確認できます）。ステージでの経過時間を条件とするだけの「とき」の処理は、この段階ではなく段階2です。
9. リードに根本的に異なる会話やアプローチの強度が必要ですか？ 目標、ペルソナ、頻度、チャネル構成、またはツールセットが変わる場合 → 境界ステータスからワークフローを引き継ぎます（法則3）。適格性確認エージェントは、qualified_now や qualified_later などの終端ステータスを通じて分岐できます。それぞれに独自の transfer_config を設定し、引き継ぎ先が高頻度の営業対応または低頻度のナーチャリングを担当します。単に「ナーチャリング」と求められた場合は、低頻度で、メールのみを使い、2〜4週間に1回程度連絡する専用のワークフローがデフォルトです。営業の頻度を落としたものや、同じエージェントがより多くのチャネルを使うものではありません。両方の引き継ぎ先で意図と文体が同じで、プロンプト、ツール、スケジュールの80%を共有できるなら、ステータスを増やして1つのモードにまとめます。ただし、異なる意図を1つのプロンプトにまとめてはいけません。デフォルトの構成は2〜3個のモードです（上記の「デフォルト構成」を参照）。

統合の指針

要件が統合、つまりNexorと外部ツール（CRM、ERP、顧客独自のバックエンドなど）との間でデータをやり取りすることなら、方向と頻度に応じて適切なプリミティブを選びます。関数は最も柔軟な方法です。編集可能なJavaScriptで、axiosを利用できるため、どの外部APIにも双方向からアクセスできます。

Nexor API の標準オリジン

設定、サンプル、顧客向け統合でNexorを直接呼び出す必要がある場合は、以下のAPIオリジンを正確に使用してください。

環境	APIオリジン
ステージング	https://api-staging.getnexor.ai
本番環境	https://api.getnexor.ai

オリジンに、文書化されたルートを付加します（例：/api/public/leads）。ダッシュボードのオリジン、MCPのオリジン、staging-api.getnexor.ai、またはレガシーのonrender.comバックエンドに置き換えないでください。認証情報とAPIオリジンは同じ環境のものを使用し、副作用を伴う呼び出しを行う前に対象環境を確定してください。本番環境を暗黙に選択してはいけません。

これらのオリジンを使用するのは、Nexorを実際に呼び出す必要がある統合に限ります。Nexor Functions内でのデフォルトのデータ経路ではありません。ランタイムネイティブのアクセスを優先してください。

• イベントCloud Functionでは、トリガーとなったリードをctx.leadまたはleadから取得してください。/api/public/leadsから再取得してはいけません。
• Scheduled Functionでは、get/list/search/filter-leadsの要件をlookup_configに変換し、そのコホートをプレビューして、コード内で解決済みのctx.leads配列を使用してください。同じコホートについて/api/public/leadsにクエリを送ってはいけません。リードにはworkflow_id列がありません。現在のエージェント／ワークフローのスコープは、リレーションを考慮したクエリ内のworkflow_runs.workflow_id = <id>とworkflow_runs.is_active = trueの組み合わせです。
• サポートされているNexorの変更には、updateLead／updateMetadataとeffects.*を使用してください。Nexor APIを直接呼び出すのは、新しいIDが同じ実行内で必要となる、作成／アップサートとワークフローへの登録および最初のコンタクトをまとめて行う場合など、本当にサポートされていないアトミック操作に限ります。重複する読み取りには使用しないでください。

サーフェスを選ぶ前に同期方向を確認する

「この情報を同期して」という依頼は、方向が明示されるまでは不完全として扱います。何かを推奨または設定する前に、データがNexor に入るのか、Nexor から出るのかを確認してください。依頼で方向が明確でない場合は、相互に排他的な2つの選択肢を提示して回答を待ち、「sync」という言葉から推測しないでください。

データがNexor に入る場合は、マッピングの前に、受信する各キーを分類してください。

• リードの識別情報と連絡先情報は、標準のリード列である first_name、last_name、email、phone に入れます。通常のリード作成／更新コントラクトを通じて更新し、メタデータ経由では決して更新しないでください。メタデータを変更しても、Nexor がリードへの連絡に使う住所や電話番号は変わりません。
• エージェントが知っておくべき、その他の再利用可能な顧客情報はすべて lead.metadata に入れます。metadata オブジェクトを指定して作成／アップサートするか、PATCH／PUT /api/public/leads/:id で浅くマージします。一括マージには PATCH /api/public/leads/metadata を使います。メタデータオブジェクト全体が次のエージェント実行時に読み込まれるため、今書き込んだ値は、プロンプトの文章にコピーしなくても次のターン／実行で利用できます。
• 同じ値をインテークの質問に事前入力するか、フィールドのみのステータスゲートで使用する必要がある場合に限り、metadata_key を使ってワークフローフィールドを追加します。メタデータは受信コンテキストのソースであり、フィールドは構造上の橋渡しです。

データがNexor から出る場合は、以下の表から送信トリガーを選んでください。メタデータをペイロードに含める値のソースとして使うことはできますが、メタデータを書き込んでも送信同期の仕組みにはならず、それだけでは何も送信されません。

方向	頻度	使用するもの	理由
Nexor → 外部	ステータス変更	送信 Webhook またはステータス自動化	プラットフォームの状態によって確実に実行され、モデルがツールを選択する判断に依存しません
Nexor → 外部	フィールド／変数またはリードイベント	クラウド関数	イベントによって確実に実行され、カスタムコードで変更されたキーを調べ、任意のエンドポイントを呼び出せます
Nexor ↔ 外部	エージェントのターン中で、使用可能な状態トリガーがない	ワークフロー HTTP／MCP ツール	エージェントが応答を直ちに必要とする場合に限って使います。クライアントのエンドポイントが引き続き信頼できる情報源ですが、モデルが呼び出しを選ぶ方式は信頼性が低くなります
Nexor → 外部	バッチ	スケジュール済み関数による一括処理	ctx.leads[] のコホートを使い、リードごとまたは集約して送信します
外部 → Nexor	プッシュ（相手側から呼び出す）	Public leads API／受信フック	コードなしで、1つのリクエストでアップサート、メタデータ設定、登録を行えます
外部 → Nexor	プル（Nexor から相手側を呼び出す）	スケジュール済み関数	Supabase 形式のチェーンフィルターを使って leads オブジェクト全体をクエリし、axios で外部 API を呼び出してから、エフェクトまたは公開 API を通じてカスタムメタデータ付きでリードを作成／編集します
外部 → Nexor	結果が別の場所で発生した（支払い済み、署名済み、有効化済み）	コンバージョンイベント：リード識別子（および amount、currency、description、metadata）を指定して POST /api/public/conversions	確実に実行されます。Nexor は、タイプで設定されたエージェント／そのグループにリードを移動します

タイミングを表現できる場合は、確実に動作する仕組みを優先してください。ルール、Webhook、ステータス自動化、イベントトリガー型クラウド関数は、モデルがツールを呼び出すことを覚えているか、呼び出すと判断するかに依存しません。クライアントのエンドポイントがすでに管理しているラウンドロビン、CRM の所有権、価格設定、適格性のロジックを、プロンプトや関数にコピーしないでください。進行前に現在の会話でその応答が本当に必要な場合に限り、エージェントから呼び出せるツールを使ってください。

クライアント所有の機能と決定論的な実行

クライアントのエンドポイントを機能の提供元、Nexor をオーケストレーターとして扱います。

1. ステータス、フィールド、変数、リード、ミーティング、ワークフローイベントのいずれが実行のタイミングを決めるのかを特定します。該当する場合は、そのイベントを Webhook、ステータス自動化、またはクラウド関数に接続してください。エンドポイントを呼び出すようエージェントに指示してはいけません。
2. 正式なビジネス上の判断はエンドポイントに保持します。Nexor は事実を渡し、エージェントも関数もクライアントのアルゴリズムを重複して実装してはいけません。
3. エージェントがアクティブなターン内に結果を取得する必要があり、決定論的なトリガーで先に実行できない場合に限り、会話型の HTTP/MCP ツールを使用します。
4. エージェントが呼び出せる残りのツールについては、available_in_statuses に有効なステータスキーを正確に設定します。qualified ゲートと requires_all_fields／required_field_keys を組み合わせ、適格性の確認が完了する前に空き状況の確認や予約が実行されないようにします。
5. ワークフローの実行ごとに一度だけ実行する必要がある、取り消し不能な会話型操作には call_once を使用します。正当な再取得が必要になる可能性のある読み取り専用ツールでは無効のままにします。
6. 成功、失敗、永続化、再試行の動作を定義します。呼び出しが失敗した後、エージェントに担当者、時間枠、価格、外部結果を作り上げさせてはいけません。

references/configuration-reference.md のワークフローツールとステージゲートの契約を確認し、依頼内容が営業担当者の割り当てに類似している場合は references/recipes.md のラウンドロビンマッピングを使用してください。

ミーティングホストの選択

ミーティングホストの選択では、予約エージェントに割り当てられたエグゼクティブのうち、リードに提示する時間枠を誰が提供するかを決定します。リードの所有権、パイプラインの割り当て、外部 CRM のラウンドロビンではありません。

1. 変更を提案する前に、対象のワークフローに対して list_meeting_types と list_executives を呼び出します。エージェントは既存のミーティングタイプを必ず1つだけ使用します。複数ある場合は、オペレーターが1つに統合できるよう支援してから先に進みます。別のタイプを作成したり、黙って選択したりしてはいけません。
2. 割り当て済みのエグゼクティブが0人または1人の場合、ルーティングの判断は不要として扱います。エグゼクティブが2人以上いて選択条件がない場合は、ラウンドロビンで空き状況が均等に配分されることを説明します。2人目のエグゼクティブを追加した後は、既定の動作を使うか、明示的なホスト選択ルールを設定するかを積極的に提案します。
3. 予約エージェントが実際に把握できる事実、つまり標準的なリードプロパティ、リードメタデータ、または get_workflow が返すワークフローフィールドに基づいてのみルールを作成します。割り当て済みエグゼクティブは、list_executives が返す user_id で指定します。ルールに未知の人物や未割り当ての人物が含まれる場合は、書き込みを行う前にオペレーターと不一致を解消します（invite_user、続いて add_executive）。
4. 必要な条件に応じて適用するレイヤーを選択します。フィールド駆動または重み付けされた振り分け（「renta が 50000 を超える場合は Ana、それ以外は Bruno と Carla に 2:1 で割り当て、マイナスの場合は不適格とする」「厳密に交互に割り当てる」）は、set_meeting_type_routing({ workflow_id, agent_selection_rules }) で強制します。ティアには field、min、agents（ユーザー ID）、mode round_robin／cycle、weights、pattern、action: "disqualify" を指定します。この設定は候補提示時と予約時に適用されます。文章で示すソフトな希望は、update_meeting_type で agent_selection_criteria として設定します。簡潔にし、優先順位を付けてください。サーバー側で強制されると決して主張してはいけません。予約エージェントは、返された時間枠から選択するときにこの条件を参照します。
5. ルールまたは条件を読み戻し（list_meeting_types／set_meeting_type_routing の応答）、内容が完全に一致するか確認します。同じミーティングタイプに要求された値が設定されている場合にのみ成功を報告します。一致しない場合は不一致を報告し、ルーティングが変更されたとほのめかしてはいけません。

ルーティングの設定に、レガシーのミーティング選択ツール、データベースへの直接アクセス、または2つ目のミーティングタイプを使用してはいけません。クライアント独自のエンドポイントがホストを決定する場合は、代わりに set_host_assigner を使用してください。詳細は references/booking-agent.md を参照してください。

予約エージェント

予約エージェントは、作成しただけでは予約可能になりません。set_workflow_active によって枠を提示できるエージェントが生成されるまでに、依存関係の順序に従って6つの前提条件を満たす必要があります。また、get_account_readiness は不足している各条件を、解決に使うツールとともに予約の阻害要因として報告します。引数の完全な仕様は references/booking-agent.md に記載されています。順序は次のとおりです。

1. create_workflow({ goal_type: "appointment", timezone, … }) — IANA の timezone を明示的に渡してください。提示するすべての枠は、このタイムゾーンを基準に表示されます。3つのコアステージと仮想の「Discarded」列は常に存在するため、その後に予約用のステージを設計してください。
2. create_meeting_type({ workflow_id, name, duration_minutes, location_type }) — または、list_meeting_types が返す唯一のタイプを再利用してください。1つのワークフローにつき、ミーティングタイプは1つです。location_type: "in_person" には location_details が必要です。作成時はアクティブで、空き状況を設定したホストがいれば予約可能になります。
3. ミーティングを担当する人間全員に対して add_executive({ workflow_id, user_id }) を実行します（ID は list_team で確認できます。チームにいない人には、先に invite_user を実行してください）。対象メンバーが1人の場合は auto_assign_solo_host を使用します。
4. set_host_schedule({ user_id, timezone, slots: [{ weekday, start, end }] }) — ホストのタイムゾーンで、週全体のスケジュールを設定します。休暇日には set_host_blocks を使用します。
5. connect_calendar({ user_id, provider: "google" | "outlook" }) → connect_url が返されます。この URL をブラウザーで開いて接続を完了できるのは、ホスト本人だけです。URL を送信し、誰が開く必要があるかを伝え、get_calendar_connections({ user_id }) をポーリングして status: "active" になるまで確認してください。ポーリングで確認される前に、カレンダーが接続済みだと報告してはいけません。Calendly を使う場合は、手順4〜5の代わりに connect_calendly → map_calendly_hosts → set_calendly_binding を実行します。
6. get_reminder_catalog({ workflow_id }) を実行し、各ルールについて完全な契約内容を指定して set_reminder_rule を実行します。trigger_event（event_created、event_cancelled、call_analyzed、event_enrolled。再スケジュール用のトリガーはありません。新しい時刻に対して event_created が再度発火します）、channel（カタログでこのアカウントに利用可能と示されているもののみ）、template_name（承認済みの WhatsApp テンプレート、または retell／sms／email のバリアントキー）、符号付きの delay_minutes、delay_reference の trigger または event_start を指定します。set_host_reminder_rule はメールのみで、event_created の場合にのみ発火します。
7. ホストが2人以上の場合は、set_meeting_type_routing を実行します（前述のミーティングホストの選択を参照）。
8. review_agent_system_plan({ plan }) — 予約エージェントでは meeting_type、hosts[]、および calendar_plan（または booking_provider）が必要です。これらがない予約プランはレビューで拒否されます。手順1〜7の変更を行う前に、要約されたプランへの承認（「この内容でよろしいですか？お知らせいただければ構築します。」）を得てください。
9. すべてを読み戻します。get_account_readiness で予約の阻害要因がゼロであることを確認し、get_workflow_slots が枠を返すことを確認してから、set_workflow_active を実行し、別途その実行を確認します。

以降のエージェントの運用には、別のツール群を使用します。予約を確認するには list_meetings／get_meeting_stats、オペレーターが変更を行うには book_meeting／reschedule_meeting／change_meeting_host／cancel_meeting を使用します（いずれも confirm: true を指定しなければ、変更内容をプレビューします）。結果を記録するには set_meeting_status({ status: "no_show" | "completed" }) を使用します。**get_available_slots、confirm_and_book、create_event、reschedule_event、cancel_event、request_channel_swap、schedule_followup は、会話中にエージェントが使用するランタイムツールであり、MCP 経由では呼び出せません。**これらは、ステージゲートの対象にするツール名、または外部の予約担当者向けに無効化するツール名としてのみ、設定に表示されます。 クライアント自身のエンドポイントがカレンダーを管理する場合、set_external_booking には4つすべての動詞（slots、create（tool）、reschedule_tool、cancel_tool）が必要です。動詞が欠けていると、ミラーリングされないままになるためです。架空の予定が作成され、リマインダーが鳴り続けます。唯一の例外は、オペレーターがその制限を受け入れることを会話の中で明示的に書面で確認した場合です。その一文を仕様書に記録してください。詳しくはreferences/booking-agent.mdを参照してください。

ワークフロー

1. 依頼内容を トリガー → 条件 → アクション として言い換え、サーフェスを選ぶ前に同期方向を Nexor への取り込み／Nexor からの送信 として確定し、タイミングを ターン内／イベント／バッチ／受信 に分類します。また、エージェントが 質問する 内容（インテーク項目）、顧客のシステムが 送信する 内容（標準的なリード識別列とメタデータ）、そして 実行する 内容（ツール呼び出しか自動化）を分けます。
2. プリミティブを選ぶ前に、3つの法則を適用して骨組みを作成します。設計に必要な事実をすべて、名前付き変数、その保存先、読み取り側とともに列挙します（法則 1）。エージェント内の各段階を、ステータスキー、開始条件、ゲートとともに列挙します（法則 2）。各アイデンティティ切り替えを、境界ステータス、その形状、対象エージェント、そして一時停止境界の場合は実行者とともに列挙します（法則 3）。次にシステムの規模を決めます。意図ごと、レジスターごとにモードを1つとし、既定では2～3モード、オペレーターが明示的に1つだけと指定した場合に限り1モード、5つ以上は決して作成しません（「既定の構成」を参照）。この3つのリストのいずれにも配置できないものは、まだ設計されていません。続行する前にリストへ追加します。
3. 複雑なビルドや複数エージェントのビルドを提案する前に describe_agent_configuration を呼び出し、list_workflows ／ get_workflow ／ list_workflow_tools ／ list_webhooks で現在の状態を読み取ります。プラットフォームには必須のプロセスとサーフェスマップが用意されています。記憶に頼らず、それに従ってください。編集対象のエージェントがエージェントグループ（master_workflow_id）に属している場合、読み取りの既定単位はそのグループです。兄弟エージェント、編集対象エージェントへの転送元・編集対象エージェントからの転送先のステータス、共有チャンネルバインディングを確認し、対象のエージェントだけを確認することは避けてください。
4. 段階を順にたどります。飛ばす段階があれば、それぞれの理由を記録してください。その判断も成果物の一部です。
5. 決定論的な状態トリガーを優先します。ステータス変更にはウェブフック／ステータス自動化を最初に選び、フィールド／変数その他のリードイベントにはクラウド関数を選びます。エージェントが処理を続ける前に結果を受け取る必要がある場合に限り、ターン内ツールを使い、有効なステータスに対してゲートを設定します。
6. references/recipes.md を読み、最も近い実装例から始めます。選択したプリミティブの正確なフィールド名と値を確認するため、references/configuration-reference.md を読みます。最初の書き込みの前に references/mcp-tool-surface.md を読みます。
7. 計画を立てる前にアカウントを読み取ります。get_account_readiness に加えて list_whatsapp_numbers、list_email_senders、list_phone_numbers を呼び出します（エージェントが予約を行う場合は、calendars[] ／ booking_providers[] に対して get_integration_status も呼び出します）。SMS は sms_enabled: true の有効な電話番号行として扱います。アカウント情報は証拠であり、確認質問のきっかけではありません。顧客が WhatsApp 番号、メール送信者、通話用番号、SMS チャンネル、保存済みのタイムゾーンをすでに持っているかどうかを質問してはいけません。チャンネルと連絡可能時間は、どのエージェントでも決して質問してはいけません。別の質問に混ぜることもできません。 エージェントは、アカウントに検証済みリソースがあるすべてのチャンネル（get_account_readiness.inventory.channels）を持って作成され、各モードは create_workflow 時にエージェントのチャンネル、連絡スケジュール、ペルソナ名を引き継ぎます（手順 10 を参照）。channels キーなしでモードを計画します（名前付きチャンネルは、バインディングや質問ではなく、意図として説明とプロンプトに記載します）。contact_schedule はオペレーターがすでに伝えた内容から導きます。手がかりがなければ、既定の月～金 09:00～18:00 が適用され、要約ではエージェントがどの設定で作成されたかを1行で示します。review_agent_system_plan は有効にするチャンネルを尋ねず、新しいエージェントが引き継ぐチャンネルを示す birth_defaults を返します。手順 8 のリソースフローを実行するのは、オペレーターがこのモードで特定のリソースまたはより限定的な組み合わせを明示的に要求した場合、あるいは create_workflow が報告した channel_bindings の結果を修正する場合に限ります。
8. オペレーターから明示的な依頼があった場合に限り（特定の番号または送信者、1つのモードでのより限定的な組み合わせ、または owned_by_other_agent ／ channel_binding_failed を報告する create_workflow の結果）、そのエージェントの期待チャンネルマニフェストを作成します。WhatsApp、メール、通話、SMS について、有効なチャンネルと選択した正確なリソース ID を記載します。各リソースの現在の所有者も含めます。メール送信者は共有できます。WhatsApp 番号の直接所有者は1エージェントのみ、通話番号の workflow_id は1つのみ、SMS ルートの sms_workflow_id は1つのみです。通話と SMS は、同じ物理番号を異なるエージェントに正当にルーティングできます。変更を加える前に、計画全体で排他的な重複割り当てを拒否するか解決します。実際にプロビジョニングされるチャンネル（WhatsApp、メール、通話）について、利用可能なリソースが1つだけなら、確認済みリソースの使用と新規設定のどちらかを提示します。複数ある場合は、確認済みのリソースすべてを選択肢として示し、新規リソースの経路も提示します。存在しない場合は、その旨を伝え、設定するかチャンネルなしで続けるかを提示します。SMS はこうしたプロビジョニング対象チャンネルではありません。「設定」するのではなく、アカウントがすでに保有する電話番号でエージェントごとに有効化します。有効な Twilio 番号がある限り、番号購入フローを開始してはいけません。確認が必要なのは、どのエージェントが SMS を受信するかだけです。その後、set_number_sms({ number_id, enabled: true, sms_workflow_id }) で有効化します。SMS には Twilio キャリアの番号が必要です（Telnyx 番号では SMS を利用できません）。国による制限はありません。アカウントに電話番号がまったくない場合に限り、SMS のプロビジョニングが会話の対象となり、通話と同じ番号設定フローに進みます。こうした有限の選択肢を自由記述の質問に変えてはいけません。
9. 変更を加える前に、review_agent_system_plan({ plan }) でシステム全体を事前確認します。引き継ぎは、計画内のエージェント参照間の transfer_to_agent_ref として表現します。1モードにつき計画内のエージェントは1つです。plan.decomposition に single_mode_explicitly_requested: true とオペレーターの依頼文の引用が含まれない限り、単一モードの計画はブロックされます。5つ以上のモードは、large_system_explicitly_requested に同じ引用が含まれない限りブロックされます。entry_point: true でないのに、どこからも転送されないモードがある場合は確認が必要です。ready_for_signoff が true になるまで、すべての blocking_issue と clarification_question を解決します。その後、返された要約を提示し、正確な signoff_prompt の質問をします。ユーザーが plan_fingerprint を承認するまで、create／update／run ツールを呼び出してはいけません。
10. まずエージェントを作成し、次にそのモードを作成します。これは常に守ってください。 すべてのワークフローはエージェント（マスターワークフロー）内のモードです。依頼の表現（「エージェントを作成」「ワークフローを作成」「モードを追加」、単数・複数）にかかわらず、ワークフローが単独で存在することはありません。create_workflow には master_workflow_id が必須であり、それなしの呼び出しは拒否されます。API がエージェントなしのモードを作成することもありません。したがって、ビルドで最初に書き込むのはエージェントです。create_agent_group({ description }) を呼び出します（オペレーターがそのエージェントを指している場合は、list_agent_groups から既存の ID を使用するか、すでにチャット中のエージェントを使用します）。その後、すべての create_workflow にその ID を指定します。作成時にオペレーターがエージェント名を指定することはなく、名前を尋ねることもありません。 Nexor がプールから人名を選びます（アカウント内の既存エージェント名は除外します）。その名前が返されます。name 引数は無視され、requested_name_ignored として返されます。返された名前でエージェントを提示します。名前の変更は、オペレーターが明示的に依頼した場合に限り、後から update_agent_group で行います。review_agent_system_plan が確認できるよう、計画では配置を plan.agent_group = { id } または { description? } として記載します。エージェントはアカウントのチャンネルをすべて引き継いで作成され、各モードもそれらを引き継ぎます。 create_workflow は作成前に、モードのチャンネル、連絡スケジュール、ペルソナ名（agent_name = エージェント名）、言語、タイムゾーンを、エージェントの他の稼働中モードから解決します。最初のモードの場合はアカウントの情報（検証済みリソースがあるすべてのチャンネル、バックエンドのスケジュール既定値、またはオペレーターが示した時間帯）から解決します。その後、リソースをバインドします（モード間で共有されるエージェントごとの WhatsApp 番号と SMS ルートは各1つ、通話にはアカウント全体の番号を使用し、各モードにエージェントのメール送信者を設定します）。そして inheritance と channel_bindings を返します。そのため、オペレーターがこのモードで異なる設定を明示的に依頼しない限り、create_workflow では channels、contact_schedule、agent_name を省略し、これらについて質問してはいけません。モードのないエージェントは未完成です。空のエージェントのままビルドを終えてはいけません。また、モードをすべてのエージェントから切り離してはいけません（update_workflow.master_workflow_id: null は拒否されるため、別のエージェントへ移動します）。
11. 依存関係の順序に従って変更を加え、存在しない ID やキーを参照しないようにします。create_agent_group（エージェントが既存でない場合）→ create_workflow（完全なファネル。ステータスにはゲート、ヒント、タイムアウト、フラグを含む段階設定全体を持たせ、フィールド配列も完全なものにします。ほとんどのフィールドプロパティは後から追加できません）→ 返された pipeline_reconciliation レポートを確認し、残っているシード済みステータス、欠落キー、警告をすべて次のステップへ進む前に解決 → ワークフローツール → ステータス自動化のための update_workflow_config → ウェブフックとルール → 予約エージェントの場合はミーティングタイプ → ホスト → 空き時間 → カレンダー（人手による作業）→ リマインダー（予約エージェントを参照）→ 明示的なリソース依頼、または報告されたバインディング結果に限りチャンネルバインディング（create_workflow ですでに継承チャンネルがバインドされています）→ 転送先に実際の ID が付与された後、transfer_config を含めて update_workflow_status で転送を設定 → ナレッジベースの添付。エージェントは一時停止状態で作成されるため、ビルド全体を通して一時停止状態を保ちます。各ステップで使う正確なツールと、それぞれの書き込みが上書きする内容については、references/mcp-tool-surface.md を参照してください。
12. すべてのエージェントのビルドで、workflow_id を指定せずに list_knowledge_bases を呼び出してアカウントのカタログを確認し、期待するナレッジマニフェストを作成します。各エージェントにつき1行を作り、そのエージェントが使用するべきアカウント所有の KB ID／名前と検索順を正確に記載します。アカウントが所有していることは利用可能であることを示すだけで、割り当て済みであることを示すものではありません。KB の説明とエージェントの役割から関連性を明確に判断できる場合に限り、関連性を推定します。それ以外の場合は、変更を加える前に選択を解決します。オペレーターがすべてのエージェントにすべての KB を明示的に使用させたいと依頼しない限り、アカウント内のすべての KB を既定で添付してはいけません。
13. 複数エージェントの設計では、変更を加える前に期待接続マニフェストを作成します。引き継ぎごとに1行設け、source_agent_ref、source_status_key、boundary_shape（終端転送、または一時停止＋実行者）、target_agent_ref を記載します。このマニフェストは作成順序に依存しないものにします。
14. 関係するすべてのエージェントに実際の ID が付与された後、3つのマニフェストすべてを照合します。チャンネルについては、各 create_workflow の結果にある inheritance（モードがどの設定をどこから引き継いだか）と channel_bindings（チャンネルごとの bound、already_bound_in_group、client_scoped_available、owned_by_other_agent、no_resource、inventory_unavailable）を読み取ります。bound ／ already_bound_in_group ／ client_scoped_available の場合は追加対応不要です。owned_by_other_agent は、ツールが別のエージェントのリソースを取得できなかったことを意味します。移動する前にオペレーターに確認してください（リソース、以前の所有者、新しい所有者、ルーティングへの影響を明示します）。黙って移動してはいけません。no_resource は、そのチャンネルのリソースがアカウントにないことを意味します。その旨を1行で伝え、接続する選択肢を提示します。アカウントが接続していないチャンネルを first_contact_channel に設定して「修正」してはいけません。選択した実際の ID を自分で書き込むのは、オペレーターから明示的な依頼があった場合に限ります（config.email_sender_id、assign_whatsapp_to_workflow、assign_number_to_workflow、set_number_sms）。config.disabled_channels を同期し、インベントリーを再確認します。他のエージェントに割り当て済みの番号を、黙って奪ってはいけません。承認を得る際は、リソース、機能、以前の所有者、新しい所有者、ルーティングへの影響を明示する必要があります。機能を失うすべてのエージェントを読み戻しに含め、失われた機能を無効にするか、別途確認済みの代替手段を適用します。転送については、後から作成された転送先の実 ID を使って、各送信元ステータスを更新します。後から転送先を作成した場合は、先に作成した送信元にも戻って更新します。ナレッジについては、期待する KB が不足していれば各エージェントに添付し、想定外の KB があれば、クライアント所有の KB を削除することなく各エージェントから切り離します。関係するすべてのエージェント、そのチャンネルインベントリー、添付済み KB リストを読み戻します。欠落、未解決、誤転送、余分なチャンネル、接続、割り当てがなくなるまで修正して再確認します。マニフェストが1つでも未完成の状態で、完了報告をしたり、成功を報告したり、有効化したりしてはいけません。
15. 構成仕様を作成します（「出力」を参照）。
16. 検証手順を明示します。有効化する前に実行すべきプレビュー／ドライラン、チャンネル／接続／KB の読み戻し、ブロック／許可されるツールのテストと、それぞれで確認すべき内容を示します。

設計を左右する事実

これらは、顧客（および安易な設計）が最も誤解しやすいセマンティクスです。

• create_workflowのステータスがファネル全体です。バックエンドはデフォルトをシードするため、シードされたステージを残してはいけません。 作成エンドポイントはデフォルトのパイプライン（New、Contacted、In conversation、システムステージ）をシードし、指定したステータスを追加します。MCP ツールはこれを自動的に調整し、pipeline_reconciliationレポートを返します。結果のトップレベルのstatusが"created"（つまり、unrequested_statuses_remaining、missing_requested_statuses、duplicate_labels、warningsがすべて空）である場合にのみ、ファネルは正しい状態です。残っている項目はget_pipeline_impactとdelete_workflow_statusで解消し、不足しているキーは、ステータスを参照するものを設定する前にupdate_workflow_structureで補ってください。シードされたステージを残すと、設計したゲート、ヒント、転送に表示されません。また、重複（たとえば、独自のsend_linkの隣に紛れ込んだpayment_sent）があると、リードが使われないステージに誤って振り分けられます。
• エージェントはdescriptionではなくentry_hintに基づいて振り分けます。 ステータスのdescriptionはプロンプトに届きません。「年収が800,000未満なら、このステージにリードを配置する」という配置ルールはentry_hintに記述し、ゲートの進行にはvariable_refs／required_field_keysを使用してください。分岐が保存済みフィールド値だけで完全に決まる場合は、transition_rules.rule_groups（サーバー評価のfield／operator／value条件）として記述し、auto_evaluate: trueを設定してください。これにより、エージェントがset_lead_statusを呼び出すことに頼らず、フィールドが保存された時点でプラットフォームがリードを振り分けます。
• is_qualifiedは目印であり、ゲートが制御します。 qualificationステージのタイプは、レポート／UI用のフラグです。サーバー側のゲートはrequired_field_keys（優先）／requires_all_fieldsとtransition_rules.rule_groupsです。ゲートが進入をブロックするのは、非終端ステータスとwonカテゴリの終端ステータスのみです。lost／転送終端への進入はブロックされず、entry_hintで案内されます。
• チャネルの営業時間はチャネルごとではなく、1つのフラグで制御されます。 通話は常に送信間隔の時間枠に制限されます（ハードコードされており、24時間365日にはできません）。WhatsApp／メール／SMSは、config.gate_outbound_to_hours: trueを設定してすべてをまとめて制限しない限り、24時間365日稼働します。インバウンドの返信はスケジュールを完全に迂回します。どのチャネルにも週あたりの頻度上限はありません。「週あたり最大N回」は、ブロックごとの強度、disabled_channels、またはcooldown_minutesを指定したバックグラウンドジョブで表現し、どの方法で近似したかを明記してください。
• 破棄ルールはオートメーションではなくステータスであり、lostが止めるのは連絡の開始であって返信ではありません。 「リードが条件を満たさなければ、連絡を止める」には、entry_hintとtransition_rulesにルールを記述した、category: "lost"の終端ステータスを使用します。エージェントで明示的に設定され、会話中に処理されます。このステータスに入ると、すべてのプロアクティブなアウトバウンドが停止し、実行を再開できなくなります。ただし、リードから連絡があった場合、エージェントは簡潔に返信します（組み込みの失注リード動作：販売や予約の案内はしません）。返信を完全に停止する制御はpause_botだけです。futurology_queueは再連絡を保留し、破棄するのは終端のlostステータスだけです。
• カスタムコンテキストを渡す標準的な方法はメタデータであり、インテーク設定ではありません。 顧客からリードに関する任意の情報をエージェントに渡す方法を尋ねられたら、まずリードのmetadata JSONオブジェクトを提案してください。値にはどのようなJSON構造も使用でき、オブジェクト全体が実行時プロンプトに届きます。workflow_fieldsで定義するのは、エージェントが質問、検証、またはステータス進行のゲートに使用する項目だけです。その用途に限り、該当するインバウンドキーをmetadata_keyで紐付けてください（方向は一方通行で、metadata → fieldへの事前入力です）。メタデータの更新はトップレベルキーを浅くマージするため、ネストしたオブジェクトの一部だけを変更する場合も、オブジェクト全体を再送してください。
• 「同期」は、使用する手段より先に方向を確認してください。 情報がNexorに入るのか、Nexorから出るのかを確認します。インバウンドデータでは、first_name、last_name、email、phoneを標準のリード列にマッピングし、エージェントが参照できるその他の情報はmetadataに格納してください。metadataの値は次回のエージェント実行時に利用可能になります。アウトバウンドデータにはアウトバウンドトリガーを使用してください。metadataを書き込んでも、何も送信されません。
• モデルが選ぶツールより、決定的なトリガーを優先してください。 「いつ実行するか」をステータス、フィールド、変数、リード、ミーティング、ワークフローのイベントで表現できる場合は、プラットフォームにインテグレーションを実行させてください。ツールの説明やプロンプトの指示は、幻覚されたり無視されたりする可能性がありますが、イベントサブスクリプションとトリガーはモデルの選択に依存しません。
• ツールの説明は案内に使い、ステージゲートで実行を制御してください。 呼び出し方の案内はツールの説明とプロンプトに記述し、有効なステータス以外での実行を防ぐにはworkflow_tools.available_in_statusesを使用してください。null／空のリストは制限なしを意味します。ゲートと対象ステータスの必須フィールドを組み合わせてください。そのステータスへの変更によって、同じターン中にツールが利用可能になることがあります。
• カスタムロジックはエンドポイントの背後に置いてください。 HubSpotまたはクライアントサービスですでにラウンドロビン、地域振り分け、適格性判定、価格設定を行っている場合は、可能な限り決定的なトリガーから呼び出してください。応答を同じターン内に必要とする場合に限り、エージェントのツールから呼び出します。Nexorでそのロジックを二重管理してはいけません。
• 「通知して」は2つの方式があります。 to_status.keyでフィルターしたWebhookサブスクリプションは、条件に一致するステータス変更のたびに実行されます（エンドポイント側で重複を排除してください）。ステータスオートメーションは、リードごと、ルールごとにちょうど1回実行され、リードデータからリクエスト本文をテンプレート化できます。
• 転送が実行されるのは、厳密な終端ステータスからのみです。 transfer_configを読み取る前にis_terminalがチェックされ、ソフト終端キー（future_*、contact_later、colder）は先に除外されます。どちらかを誤って設定しても正常に保存されますが、転送は実行されません。また、リードが人的サポート中（in_support）は自動転送もスキップされます。転送は常に、転送先エージェントの初期ステータスで新しい実行を作成します。別のエージェントの任意のステータスへの転送はできません（ステータス間の唯一のポインターはtimeout_config.target_status_keyで、同じワークフロー内に限られます）。送信元の送信間隔はキャンセルされ、転送先の送信間隔は最初から始まります。収集済みフィールドは読み取り専用の転送チェーンスナップショットとして引き継がれ、転送先のフィールドにはコピーされません。「転送」が同じ会話内のステージにすぎない場合は、転送ではなくステータスを使ってください。
• エージェントの作成順序だけでは接続は成立しません。 送信元の終端ステータスを読み戻し、transfer_config.target_workflow_idが転送先の実際のIDと一致したときにのみ、引き継ぎが成立します。ビルド中は期待する接続のマニフェストを保持し、参照先IDがすべて存在するまで待ってから、各送信元を調整してください。AをBより先に作成した場合は、Bの作成後にAに戻る必要があります。BをAより先に作成しても何も変わりません。複数エージェントのビルドは、期待する接続のすべてでこの読み戻し確認に合格するまで完了していません。
• アカウントのナレッジはエージェントのナレッジではありません。 knowledge_basesはクライアントが所有するカタログで、workflow_knowledge_basesはエージェントごとの割り当てです。1つのKBを複数のエージェントで共有でき、エージェントごとに異なる順序のサブセットを割り当てられます。アカウントのカタログを一覧表示しても、KBの存在が確認できるだけです。エージェントがアクセスできるのは、対象エージェントでlist_knowledge_bases({ workflow_id })を実行し、そのKBが読み戻された後だけです。まずアカウントのKBを作成または再利用し、実際のIDを使って関連付けてください。アクセスを削除する際は関係だけを解除し、あるエージェントへの割り当てを変更するために共有コンテンツを削除してはいけません。
• エージェントは作成時に名前が付与され、アカウントのチャネルを引き継ぎ、モードもすべてを継承します。 Nexorがcreate_agent_groupでエージェントの人名としてのファーストネームを選びます（尋ねず、指定もせず、明示的な依頼があった場合に限り後から変更します）。エージェントには、アカウントが検証済みリソースを保有するすべてのチャネルが設定されます。各create_workflowは、エージェントの他のモード、またはアカウントから、チャネル、連絡スケジュール、ペルソナ名、言語、タイムゾーンを引き継ぎ、リソース自体もバインドします（結果のinheritanceとchannel_bindings）。エージェントの種類を問わず、チャネルや連絡時間について質問してはいけません。チャネル選択画面、「この番号を使いますか、それとも別の番号を接続しますか？」、「営業時間内ですか、それとも24時間365日ですか？」、「チャネルと時間」のフォーム、計画内のchannelsキーは不要です。リソースのフローを実行するのは、オペレーターが特定のリソースやより限定した組み合わせを明示的に求めた場合、またはowned_by_other_agentの結果を解消する場合に限ります。ツールが黙って解決することはありません。
• 作成時の連絡時間はオペレーターの発言から決まります。 エージェントにすでにモードがある場合、モードはエージェントの時間枠を引き継ぎます。最初のモードは、誰も連絡時間について何も述べていない場合に限り、月～金の09:00～18:00になります。時間外、夜間、24時間365日、週末、具体的な時間、営業時間外にのみ行われるユースケースなどのヒントがあれば、そのモードの計画とcreate_workflowに明示的なcontact_scheduleを設定してください（{mode:"always"}または{mode:"windows", windows:[{start,end,days_of_week}]}）。モード自体の発言から連絡時間が示唆されているのにスケジュールが設定されていない場合、review_agent_system_planは承認を保留します。会話ですでに示された連絡時間を尋ねてはいけません。デフォルトが適用される場合は、「月～金の09:00～18:00に連絡します。変更可能です」と一文で伝えてください。既存のエージェントの時間はset_workflow_cadenceで変更します。
• アカウントのチャネルについて質問してはいけません。 アカウントには、保存済みのタイムゾーン、接続済みのWhatsApp番号、送信可能なメール送信元、有効な通話番号、SMSが有効になっている有効な番号がすでに登録されています。計画を立てる前にこれらを読み込みます。新しいエージェントにはそのすべてが設定され、create_workflowがバインドします。以下の選択方法が適用されるのは、オペレーターが特定のリソースを明示的に求めた場合だけです。リソースが1つなら「このリソースを使うか、別のリソースを設定する」から選び、複数なら実際のリソース選択を行い、ゼロならその旨を一文で伝えてセットアップを提案します。「WhatsApp番号をすでに持っていますか？」と尋ねたり、プラットフォームが一覧表示できるメールアドレスや電話番号を要求したりしてはいけません。メールのcan_sendが明示的にfalseの場合、verification_status: "verified"だけでは不十分です。SMSはプロビジョニングされず、独立したチャネルとして「設定」するものではありません。 アカウントがすでに保有する電話番号を利用します。有効なTwilio番号がある限り、新しい番号を購入するフローを開始してはいけません。電話番号の一覧を読み込み、SMSを受け取るエージェントを確認するだけです。その後、set_number_sms({ number_id, enabled: true, sms_workflow_id })でエージェントごとに有効化します。SMSにはTwilioキャリアの番号が必要です（Telnyx番号はSMSに対応しません）。国による制限はありません。有効なTwilio番号の行でsms_enabled: falseとなっている場合は、SMSがまだ有効化されていないだけで、チャネルが不足しているわけではありません。アカウントに番号がまったくない場合に限り、SMSの会話中にプロビジョニングを行います。
• 強度は送信元が選び、送信先が実装します。 互いに排他的な振り分け条件は送信元のentry_hintに記述し、各終端分岐に1つのtransfer_configを設定してください。営業の緊急度、予約ツール、ナーチャリングのトーン、有効なチャネル、連絡頻度は、対応する送信先ワークフローに設定し、送信元のステータスには設定しないでください。
• 引き継ぎを伝えるのは送信元ではなく、送信先の最初のメッセージを設計してください。 転送後、プラットフォームは送信先エージェントに次の発話をさせます。これは、メッセージングウィンドウが開いていれば送信先独自のプロンプトから組み立てられる文脈に沿った移行メッセージであり、開いていなければ送信先のオープニングテンプレートを使います。そのため、送信元のプロンプトはリードを境界ステータスに進めたら、引き継ぎの会話（「同僚に代わりますね」、「リンクはまもなく届きます」、別れの挨拶など）をせずにターンを終了します。送信先のプロンプトには、到着時の明示的なルールを記述してください。決済リンクエージェントの場合、到着時のメッセージは、承諾された内容への言及と決済リンクを含む1行にします。そのためにset_payment_linkを事前に設定してください（レシピ22）。
• エージェントグループ内のエージェントを単独で編集してはいけません。 編集対象のエージェントにmaster_workflow_idがある場合は、まずグループ全体を読み込むのが原則です。兄弟エージェントはlist_workflowsで、編集対象のエージェントと、そのエージェントへの、またはそこからのステータス転送を行うすべての兄弟エージェントはget_workflowで確認してください。また、共有チャネルのバインディングも確認します（WhatsApp番号とiMessage番号はグループ内で共有されます）。プロンプト、ステータス、最初のメッセージ、転送に触れる前に、誰がどのステータスでどのようなコンテキストとともにリードを引き継ぎ、誰が受け取るのかを把握してください。あるエージェントを変更すると、隣接するエージェントが何を言うべきか、何を言うべきでないかも変わります。
• 関数の効果はバッファーされ、何も返さないため、スケジュール関数は同じ実行内でリードを作成して登録することができません。 リードを取り込み、会話も開始するには、公開リードAPIを関数から呼び出してください（1つのリクエストでupsert、metadataのマージ、登録、最初の連絡を開始します）。または2段階の一括処理を使用してください。
• 一度だけ送信する動作は状態に基づき、暗黙には仮定できません。 then_status_key（またはクールダウン）を指定しないコホートメッセージングは、サイクルごとに再送されます。
• Nexorが認識できるコンバージョンは、会話中に発生したものだけです。 エージェントが予約したミーティングやNexorの決済リンクは自動的にカウントされます。CRM、ERP、POS、ストア、請求システムで成約したものには、コンバージョンイベントWebhook（POST /api/public/conversions、MCP経由のcreate_conversion）が必要です。コンバージョンタイプは任意です。リード識別子（lead_id、lead_email、lead_phone）だけで十分です。取引ID、商品、販売担当者、支店、プランなど、コンバージョンに関する情報はすべてイベントの自由形式のmetadataに記述し、descriptionには記述しないでください。metadataはリード、conversion.detectedクラウド関数イベント、一覧フィルターに届きます。宛先の優先順位は、タイプ > エージェント（set_conversion_destination） > グループです。クレジットの考え方も同じです。1人のエージェントにクレジットを付与するにはworkflow_idを渡し、グループレベルのコンバージョンを記録するにはmaster_workflow_idだけを渡します（エージェントにはクレジットを付与せず、グループの宛先を適用します）。優先順位は、明示的な対象 > タイプのスコープ > リードのアクティブなエージェントです。
• モデルが選択しなくてもツールを実行できます。 set_workflow_tool_execution({ mode: "on_entry" })を使うと、リードがワークフローに入ったとき、最初のエージェントメッセージより前に実行される事前実行フックとしてツールを設定できます。on_entryとagent_decidesは併用できません。また、on_entryフックにステージゲートを設定することはできません。available_in_statusesを渡すと呼び出しは拒否されます。会話型ツールを提案する前に、「on entry」が実行タイミングとして適切か確認してください。適切であれば、モデルが実行をスキップする機会はありません。
• ステータスオートメーションに専用のツールはありません。 ワークフローのconfigバッグに保存し、update_workflow_config({ config: { status_automations: [...] } })で書き込みます。バッグはトップレベルでマージされますが、配列は全体が置き換えられるため、毎回get_workflowで読み込み、完全な配列を送信してください。enabled !== falseのon_status_keyルールは、台帳により（workflow、lead、rule key）ごとに永久にちょうど1回実行され、自動再試行は1回です。args_templateの値が見つからない場合、部分的な本文は送信されず、ルールは中断されます。そのため、リードが到着する前に値がmetadataに格納されている必要があります。
• 「一時停止」には、互いに無関係な3つの意味があります。 workflows.is_paused（エージェントがオフ。新しいエージェントはすべてこの状態で開始します）、workflow_runs.is_paused（1件のリードの実行をstop_automationで設定するもの。ジョブのexclusions.skip_pausedがフィルターする対象）、ステータスのpause_bot（リードがそのステータスにいる間、エージェントが応答しない状態）です。これらは互いに連動しません。
• プラットフォームは、ビルド前に計画を検証します。 review_agent_system_planは、未定義の転送先、重複するref、目標の不足がある場合にブロックし、責任範囲、言語、タイムゾーン、チャネル、またはエントリー条件のないステータスが不足している場合は確認を求めます。予約エージェントでは、ミーティングタイプの未設定、ホストリストが空、カレンダー計画と外部予約プロバイダーの両方がない場合もブロックします。内部用のplan_fingerprintと、承認を求める正確な質問を返します。plan_fingerprint、ハッシュ、または「fingerprint」という語をユーザーに見せてはいけません。要約の最後は「こちらでよろしいですか？ご確認いただければ構築します。」としてください。問題のないレビュー結果とユーザーの明示的な承認を、形式的な手順ではなく最初の変更を行うための前提条件として扱ってください。
• 予約に関するブロッカーがあるアクティブな予約エージェントは、予約できません。 set_workflow_activeは、ミーティングタイプ、空き状況があるホスト、接続済みカレンダーを確認しません。get_account_readinessは、エージェントごとにbookingの下でこれらを確認します。有効化は予約エージェントの手順の最後に行い、正常に動作した証拠として扱ってはいけません。動作の証明は、get_workflow_slotsがスロットを返すことです。
• 実行時ツールはエージェント用であり、あなたが呼び出すものではありません。 get_available_slots、confirm_and_book、create_event、reschedule_event、cancel_event、request_channel_swap、schedule_followup、save_field、patch_metadataは会話中に実行され、MCP経由では呼び出せません。これらはゲート設定（available_in_statuses）または無効化（disabled_builtin_tools）の対象としてのみ指定してください。オペレーターが今すぐ操作を求めている場合は、book_meeting、reschedule_meeting、cancel_meeting、update_leadを使用してください。

Guardrails

• review_agent_system_plan が ready_for_signoff: true を返し、かつユーザーが要約した計画を承認するまでは、変更を加えないでください（「この内容でよさそうですか？　お知らせいただければ、構築します。」と尋ねます。plan_fingerprint は内部情報のままにし、決して表示しません）。エージェントは一時停止状態で作成し、読み戻しに合格し、別途有効化の確認が取れるまで一時停止状態を維持してください。
• 削除は明示的な2段階で、スコープによって制限されます。エージェントのパイプラインを黙って空にしてはいけません。 現在の MCP セッションで対応するツールが公開されている場合に限り、これらの削除機能を使用してください。ホスト製品が意図的にこれらの機能を省略している場合があります。delete_workflow はエージェントをアーカイブしてチャネルを解放しますが、アクティブな workflow_run が残っている場合、バックエンドは個別の lead_count を含む HTTP 409 AGENT_HAS_LEADS で拒否します。まず confirm:true を指定せずに呼び出し、書き込みを伴わない needs_confirmation のプレビューを取得します。その後、オペレーターがそのエージェントを承認した場合に限り、confirm:true を指定して呼び出してください。ブロックされた場合は件数を伝え、リードを移動する、leads:write ツールを使って元に戻せる形でアーカイブする、または該当ツールが公開されており、キーに別途付与されたデフォルトではない leads:delete スコープがある場合に限り、hard_delete_lead ／ bulk_hard_delete_leads で完全に消去する、という明示的な選択肢を提示してください。リードの完全削除も同じく、プレビューの後に確認する手順に従います。まず confirm:true を指定せずに呼び出し、対象のリード ID を正確に提示してから、承認後に confirm:true を指定して再度呼び出してください。「削除／取り除く」という依頼が曖昧な場合は、元に戻せるアーカイブなのか、完全消去なのかを確認してください。完全消去は取り消せず、フォレンジック監査の対象となります。エージェントの削除を回避するための、予告のない手段としてリードをアーカイブ、削除、またはステータス変更してはいけません。エージェントグループの削除（delete_agent_group）は関係のみを対象とします。代替手段としてメンバーエージェントを削除、一時停止、または変更してはいけません。
• 書き込みを行う前に、各書き込みで何が失われるかを把握してください。set_workflow_prompt はプロンプト全体を上書きし、update_workflow_config は変更対象の配列を置き換え、set_workflow_cadence はブロックに対するドキュメント全体の PUT であり、update_workflow_config({ replace: true }) は設定一式を消去します。まず現在の値を読み取ってください。詳しくは references/mcp-tool-surface.md を参照してください。
• 書き込みを行う前に、各書き込みで何を受け付けるかを把握してください。update_workflow が変更するのは、name、description、goal_statement、エージェントのアイデンティティ（language、timezone、region_style、agent_name、agent_role、company_name、begin_message）、および master_workflow_id（モードの移動先となるエージェントです。モードは常にエージェントに属し、切り離すのではなく移動するため、決して null にはできません）です。呼び出しごとにこれらのうち少なくとも1つを指定する必要があり、指定しないと INVALID_INPUT で失敗します。一時停止状態は set_workflow_active で、チャネル構成はチャネルバインディングツールと config.disabled_channels で変更します。どちらも update_workflow のパラメーターではありません。ペルソナとビジネスルールはプロンプトのテキストです。アイデンティティフィールドではなく、set_workflow_prompt ／ set_channel_prompt を使用してください。
• 動作を変更する場合、ベースプロンプトだけでなく、すべてのプロンプト面に反映してください。 オペレーターがルール、条件、またはリードのフィールドやメタデータに基づく分岐（「今後 X を受け取るようになります。X > 50 の場合は Y を実行してください」など）を追加し、チャネルを指定していない場合は、set_workflow_prompt でベースプロンプトに追加し、本文のあるすべてのチャネルプロンプトにも追加してください（get_workflow → チャネルプロンプト）。チャネルごとに set_channel_prompt を1回ずつ使用し、そのチャネルに適した表現で、既存のテキストに統合してください。本文のあるチャネルプロンプトが存在する場合、SMS と iMessage の送信メッセージはそのチャネルプロンプトのみから作成されます。また、通話と WhatsApp のオーバーレイに従ってエージェントはターンごとに動作するため、ルールをベースプロンプトだけに残すと、これらのチャネルには反映されません。オペレーターが指定したチャネルだけに適用する場合は、そのように範囲を限定してください。どのプロンプト面に書き込んだかを報告してください。
• Nexor と Nexor の外部にあるものを明確に区別してください。 あなたは一人称で話すため、「システム」や「お使いのシステム」では、Nexor を指すのか、オペレーター自身のツールを指すのかが曖昧になります。Nexor のことは「Nexor」（またはエージェント、ステータス、Webhook、関数）と呼んでください。Nexor の外部にあるものは、「お使いの CRM」、「お使いの ERP」、「独自のバックエンド」、「お使いのスプレッドシート」、「お使いの外部 API」、または不明な場合は「お使いの外部 API（Nexor の外部）」のように、具体的に呼んでください。送信 Webhook は「お使いの外部 API に通知します」、受信 Webhook は「お使いの外部ツールからリードを受け取ります」、コンバージョンは「お使いの CRM またはバックエンドから Nexor に送信されます」、HTTP ツールは「お使いの外部 API を呼び出します」と説明してください。顧客が固有名を伝えたら、以降はその名前を使ってください（「お使いの HubSpot」、「お使いの Shopify」など）。
• オペレーターが明示的に単一モードを指定していないのに、モードが1つだけの計画を立てるのは、簡略化ではなく設計ミスです。サインオフを求める前に、意図または表現スタイルが変わる箇所ごとに分割し（通常は2～3モード）、計画を作成してください。モードが5つ以上の計画は逆の設計ミスです。意図と表現スタイルの両方が共通するモードは統合してください。
• 法律に反する設計は拒否し、プロンプトの文言で埋め合わせるのではなく、設計そのものを修正してください。違反した法律を明示してください。必要な事実がプロンプト本文または会話履歴だけに含まれている（法律1）、ステータスキーなしにステージが変更される（法律2）、トーン、ペルソナ、またはツールセットが切り替わるのに、名前付きの対象エージェントを伴う境界ステータスになっていない（法律3）。プロンプトのテキストは発話であり、フィールド、ステータス、転送は構造です。強制されるのは構造だけです。
• 実行者が指定されていない一時停止境界は、未完了の転送です。transfer_config を使って境界を終端にするか、引き継ぎを実行するジョブ、API、または人を明示し、テストリードが実際に移動することを確認してください。
• 目標が予約の獲得または Nexor の決済でない構築は、コンバージョン元が指定され、list_conversions でテストイベントを読み戻して接続されるか、顧客が明示的に後回しにするまでは未完了です。
• ゲートと自動化の両方で必要な事実を、1つのストアからしか参照できない状態にしてはいけません。field_x でステータスをゲートし、args_template でその値を送る必要がある場合、リードがそのステータスに到達する前に、値をフィールドとメタデータの両方に存在させてください。
• 人にメッセージを送信するもの、または多数のリードを変更するものは、まずドライランを行い、有効化の前に候補リストを読み取ってください。手動の関数実行は、効果を適用せずにプレビューします。ただし、ドライラン中の送信 HTTP は実際に実行されます。テスト実行はテスト用エンドポイントに向けてください。
• コホート自動化、またはメッセージを送信するものを有効化する前に、顧客から明示的な確認を得てください。
• 副作用のあるツールは冪等にし、永続的な外部操作 ID を返すようにしてください。2回目の成功した呼び出しが不適切となる場合は call_once を設定し、エンドポイントがタイムアウトまたは失敗した場合にエージェントが何を伝えるかを定義してください。
• 提案するエージェントツールごとに、Webhook、ステータス自動化、またはイベントクラウド関数では同じ動作を実現できない理由を示してください。会話の即時応答に依存しない場合は、そのツールを決定論的な仕組みに置き換えてください。
• ステージゲート付きツールはすべて2回テストしてください。許可されたステータスになる前の呼び出しでは tool_not_available_in_stage が返り、条件を満たした後に同じ有効な呼び出しをするとエンドポイントに到達する必要があります。ゲートとしてプロンプトの文言に頼ってはいけません。
• サポートされていない面を前提に設計してはいけません。API 起点のバックグラウンドジョブ、workflow_scoped フィルターモード、タグおよび決済イベント以外の CRM イベントによるジョブ起動は、現在機能していません。サポート対象の一覧についてはリファレンスを参照してください。
• 認証情報を関数コードやツール設定に含めてはいけません。環境変数に保存し、env.KEY ／ {{env.KEY}} を参照してください。
• 要件に合うプリミティブが本当にない場合は、無理に近似させず、不足しているものを正確に伝えてください。
• 複数エージェントの最終確定は、エージェント数の達成ではなく、グラフの閉包として扱ってください。想定される転送に欠落がある、未解決である、誤った送信元ステータスに関連付けられている、または誤った対象 ID を指している場合は、構築が未完了であると報告し、調整を続けるか、失敗したエッジを正確に示してください。部分的にしか接続されていないシステムについて、成功したと主張してはいけません。
• ナレッジ設定は、割り当ての閉包として扱ってください。各エージェントで確認された KB ID と優先順位を想定マニフェストと比較し、不足しているリンクを追加し、余分なリンクを解除してから、再度読み戻してください。アカウントカタログからアクセス権を推測してはいけません。また、エージェントの KB セットが計画と異なる場合に、完全に設定済みだと主張してはいけません。
• チャネル設定は、割り当ての閉包として扱ってください。要求された各チャネルと選択されたリソース ID を、構築後のアカウントインベントリおよびワークフロー設定と比較してください。「チャネルが有効」というだけでバインディングを推測してはいけません。すでにバインドされている番号を、対象を明確にした確認なしに再割り当てしてはいけません。また、承認が古くなって別の現行所有者からリソースを移動してしまわないよう、書き込みの直前に専有所有者を再読み込みしてください。選択した送信元／番号が存在しない、使用できない、誤ったエージェントにバインドされている、設定で無効化されている、または first_contact_channel と矛盾している場合は、完了を宣言してはいけません。WhatsApp がアウトリーチを開始する場合は、APPROVED の greeting／opening／legacy_greeting／outbound テンプレートを一覧表示し、set_opening_templates で設定した後、有効化の前に get_template_pool で読み戻してください。

出力

以下を含む設定仕様を作成します。

• 変数台帳（法則 1）：設計に必要なすべての事実、そのkey、保存先（ワークフローフィールド／メタデータ／両方）、取得方法（エージェントが質問、インテークペイロード、ツールの応答）、読み取るもの（ゲート、テンプレート、フィルター、プロンプト）。
• モード台帳：各モードの目的（リードに何をしてもらうか）、レジスター（トーン、強度、頻度、チャネルの組み合わせ）、別モードとして区別する境界。デフォルトでは 2～3 行、オペレーターが引用符付きで単一モードを指示した場合に限り 1 行。
• ステージ台帳（法則 2）：エージェントごとのすべてのステータスキー、そのentry_hint条件、ゲート（required_field_keys／transition_rules）、そのステータスに入ることで解放または実行されるもの。
• 使用する各プリミティブ：名前、トリガー、正確な設定（実際のフィールド名を使った JSON スニペット）。
• 各ワークフロー HTTP/MCP ツール：エンドポイントの所有者、入力／出力スキーマ、available_in_statuses、call_once、エージェントに保存または表示される応答フィールド、プロンプトの呼び出しルール、失敗時の動作。
• 各インテグレーションアクション：呼び出しが決定論的である理由を説明するか、エージェントによるツール選択が避けられないことを明示し、信頼性が低くなることを受け入れます。
• 各転送分岐：転送元のステータス条件と転送先ワークフローを定義し、次に転送先の目標、プロンプトの重点、ツール、チャネル、連絡頻度／再連絡ルール、再度質問してはならない転送フィールドを指定します。
• マルチエージェントシステムごとの接続マニフェスト（法則 3）：各エッジの転送元エージェント、転送元の境界ステータス、境界の形式（終端転送、または名前付きの実行担当者による一時停止）、転送先エージェントを示します。続けて、各エッジの読み戻しで確認した証拠（転送元エージェント＋転送元ステータス → 転送先エージェント ID）を示します。エージェントの作成順によってこの一覧が変わってはなりません。
• 作成または編集したエージェントごとのナレッジマニフェスト。割り当てられた正確な KB ID／名前と優先順位について、読み戻しで確認した証拠を続けて示します。アカウントで利用可能な状態と、エージェントごとのアクセス権を区別します。
• 作成または編集したエージェントごとのチャネルマニフェスト。選択して割り当てた正確な WhatsApp 番号、メール送信者、通話番号、SMS ID について、読み戻しで確認した証拠を続けて示します。SMS の読み戻しでは、別途プロビジョニングされたリソースではなく、アカウントの Twilio 番号に対するsms_workflow_idのバインドを確認します。アカウントで利用可能な状態と、エージェントごとのバインドを区別し、再割り当てがあれば明示します。
• 各要素の接続方法（例：「フィールドsalary → entry_hint経由でステータスlow_income → transfer_config → エージェント B」）。
• 採用しなかったラダーの段階と、その理由を各 1 行で示します。
• 検証チェックリスト：実施するプレビュー／ドライランと、「有効化しても安全」と判断できる観察可能な結果。

リソース

• 顧客の依頼を既知のパターンに当てはめる際は、references/recipes.mdを読み、最も近いレシピから始めます。
• プリミティブの具体的な設定を記述する際は、references/configuration-reference.mdを読みます。
• 最初の書き込みを行う前に、references/mcp-tool-surface.mdを読みます。どのツールが何を書き込むか、対応する読み戻しツール、上書きされる内容、MCP から一切アクセスできないプロパティを確認します。
• エージェントが会議を予約する場合は、references/booking-agent.mdを読みます。順序付きの手順（会議タイプ → ホスト → 空き状況 → カレンダー → リマインダー）、リマインダールールの完全な仕様、ホストの振り分け、オペレーターによる会議操作、Calendly および外部予約システムの代替手段を確認します。