2つのモード
FIM Oneのすべてのチャットリクエストは1つの質問から始まります：エージェントが選択されているか？ この答えによって、リソース（コネクタ、ナレッジベース、スキル、MCPサーバー）がどのように検出され、LLMが使用できるツールセットに組み立てられるかが決まります。 エージェント制約モードは、ユーザーが特定のエージェントを選択したときに有効になります。システムは、そのエージェントが明示的に設定されたリソースのみをロードします：- コネクタ：エージェントにバインドされた
connector_idsのみがツールとしてロードされます。 - ナレッジベース：エージェントにバインドされた
kb_idsのみが取得ツールとして注入されます。 - スキル：グローバルに利用可能 — ユーザーに表示されるすべてのアクティブなスキルが注入されます。スキルはエージェント固有の知識ではなく、組織のSOP（標準業務手順）だからです。（下記のグローバルSOPとしてのスキルを参照してください。）
- MCPサーバー：常にユーザースコープ — ユーザーに表示されるすべてのアクティブなMCPサーバーが両方のモードでロードされます。
- インストラクション：エージェントの
instructionsフィールドは、システムプロンプトに注入されるペルソナと行動ガイドラインを定義します。
- コネクタ：ユーザーに表示されるすべてのコネクタ（自分のもの + 組織共有 + マーケット購読）がロードされます。
- ナレッジベース：アクセス可能なすべてのKBが
kb_retrieve経由で取得可能です。 - スキル：ユーザーに表示されるすべてのアクティブなスキルがSOPスタブとして注入されます。
- MCPサーバー：エージェント制約モードと同じ — ユーザーに表示されるすべてのアクティブなサーバー。
- インストラクション：汎用アシスタントペルソナが使用されます。
_resolve_tools()内で発生し、これはすべてのチャットリクエストで呼び出されます：
実際の効果：ユーザーはエージェントを設定することなく、すぐにチャットを開始できます。システムは利用可能なリソースを検出し、それらをツールとして公開します。エージェントを選択すると、スコープが絞られます — 新しい機能のロックを解除するのではなく、既存の機能に焦点を当てます。
各モードが検出するもの
2つのモードはスコープが異なり、種類は同じです。どちらもToolRegistry を生成しますが、異なる方法で入力されます。
自動検出モード（エージェント未選択）:
エージェント制約モード（エージェント選択済み）:
重要な非対称性：コネクタとナレッジベースはエージェントでスコープされていますが、スキルとMCPサーバーは両方のモードでグローバルなままです。
CallAgentTool（エージェント委任）は自動検出モードでのみ利用可能です — 特定のエージェントが選択されている場合は登録されません。これはセキュリティ対策です。マーケットプレイスエージェントは call_agent を使用して他のエージェントを呼び出し、プライベートプロンプトにアクセスする可能性があるからです。スキルは組織的ルール（すべてのユーザーが同じSOPに従う）ですが、コネクタとKBは機能バインディング（異なるエージェントが異なるシステムに接続）です。
すべてはツールである
LLMレベルでは、すべてのリソースタイプは呼び出し可能なツールのフラットリストに収束します。LLMは、コネクタ、MCPサーバー、またはナレッジベースを呼び出しているかどうかについての構造的な認識を持ちません。ToolRegistryを見ます — 名前、説明、パラメータスキーマを持つ関数のセットです。
重要な洞察: エージェントはツールではなく、ツールを使用するエンティティです。 エージェントはその指示をシステムプロンプトに寄与し、どのツールが利用可能かを決定します。しかし、LLMの観点からは、「エージェント」という概念は存在しません — システムプロンプトと呼び出し可能な関数のセットのみです。
この均一性がシステムを拡張可能にするものです。新しいリソースタイプを追加することは、
Toolプロトコル（name、description、parameters_schema、run()）を実装することを意味します。実行エンジン、コンテキスト管理、およびLLM相互作用レイヤーは変わりません。
スキルをグローバルSOPとして
スキルはエージェントの上位レイヤーに位置します。これらは組織のポリシーと手順であり、選択されたエージェントに関係なく、すべてのエージェントが従う必要があります。スキルがエージェントにバインドされない理由
「顧客苦情処理 SOP」のようなスキルは、顧客と対話するすべてのエージェントに適用されます。スキルをエージェントにバインドすると、双方向の所有権の問題が生じます。スキルがエージェントをオーケストレーションし、エージェントがスキルを所有する場合、誰が誰を制御するのでしょうか。 スキルはグローバル設計です。これらはエージェント固有の知識ではなく、会社のルールです。_resolve_tools() 関数は、エージェント選択に関係なく、ユーザーに表示されるすべてのアクティブなスキルを読み込みます。これは他のリソースに使用されるのと同じ resolve_visibility() フィルタを使用します。
2つのインジェクションモード
スキルは2つのインジェクションモードをサポートしています — progressive（デフォルト）とinline — これらはSKILL_TOOL_MODEまたはエージェントのmodel_config_json.skill_tool_modeで制御されます。プログレッシブモードでは、コンパクトなスタブのみがシステムプロンプトに表示され、LLMは必要に応じてread_skill(name)を呼び出して完全なコンテンツを読み込みます。これはFIM Oneの広範なProgressive Disclosureアーキテクチャの一部であり、すべてのリソースタイプ全体でコンテキスト消費を最小化します。
エージェントをコンテナではなくペルソナとして
FIM Oneのアーキテクチャは、エージェント中心モデルからリソース中心モデルへの意図的なシフトを反映しています。 前のモデル: エージェントはすべてのリソースへのアクセスをゲートする容器でした。エージェントが選択されないということは、コネクタ、スキル、特殊なKBがないということでした。エージェントは任意の機能への必須のエントリーポイントでした。 現在のモデル: エージェントはペルソナです — 一連の指示と動作ガイドラインと、オプションのリソース制約の組み合わせです。リソースはエージェントとは独立して存在します。エージェントを選択するとスコープが狭まり、選択しないと完全に開きます。 これは以下を意味します：- ユーザーはエージェントを設定することなく、すぐにチャットを開始できます。
- システムは利用可能なリソースを自動検出し、ツールとして公開します。
- エージェントは軽量なペルソナになります — 指示を書き、オプションで特定のコネクタとKBをバインドするだけで、すぐに作成できます。
- リソース管理はエージェント管理から分離されます。組織にコネクタを公開すると、自動検出モード、エージェントバインディングドロップダウン、およびエージェント委譲解決のすべての場所で利用可能になります。
エージェント委譲
FIM One はCallAgentTool を介して専門エージェントにタスクを委譲することをサポートしていますが、自動モード（エージェント未選択）でのみ可能です。ユーザーが特定のエージェントを選択すると、委譲は無効になり、そのエージェントは自身のツールのみに集中します。
2つのモード: 自動 vs エージェント選択
エージェント選択モードで委譲が無効な理由: セキュリティ。マーケットプレイスエージェントは
call_agentを使用して他のエージェントを呼び出し、その非公開システムプロンプトを読み取る可能性があります。委譲を自動モード（個別エージェントのプロンプトではなくシステムLLMがフローを制御する）に制限することで、信頼できないエージェント構成に対して非公開エージェントプロンプトが決して公開されません。
オーケストレーションレイヤーとしてのオートモード
オートモードはUIの第一級の概念です。エージェントセレクターは「Auto」をデフォルトオプションとして表示します。オートモードがアクティブな場合、システムLLMはオーケストレーターとして機能します。つまり、表示されているすべてのエージェントの完全なカタログを確認し、各イテレーションで最適なスペシャリストにタスクを委譲できます。これにより、専用の「親エージェント」の必要性が排除されます。システム自体がオーケストレーターとなります。エージェント カタログ
実行時に、ユーザーに表示されるすべてのアクティブな非ビルダー エージェントがカタログに集約されます。各エージェントの名前と説明はcall_agent ツールのパラメータ スキーマにリストされており、LLM が意味的に適切なスペシャリストを選択できます。ハードコードされたルーティングは不要です。
完全なツール継承
委譲されたエージェントがcall_agent(agent_id, task) 経由で呼び出されると、独自の設定から構築された完全な ToolRegistry を受け取ります。これには、バインドされたコネクタ、KB、および組み込みツールが含まれます。委譲されたエージェントは、テキストのみのアドバイザーではなく、完全な実行ユニットです。
ワンレベルの委譲
無限再帰を防ぐため、委譲されたエージェントはcall_agent ツールを受け取りません。委譲は常に1レベル深くなります：オートモードがスペシャリストを呼び出し、スペシャリストが実行して結果を返します。システムは複数の委譲されたエージェントからの結果を統合します。
並列実行
ネイティブ関数呼び出しモードでは、LLMは単一のターンで複数のcall_agent呼び出しを実行できます。これらはasyncio.gatherを介して同時に実行され、「3つのソースを同時に検索する」などのパターンを可能にします。
可視性モデル
両方のモード内のすべてのリソース検出は、3つのティアを持つ統一された可視性モデルによって管理されます：web/visibility.pyのresolve_visibility()関数は、3つのティアすべてを単一のクエリに含むSQLフィルタを構築します：
- エージェントなしモードでのコネクタの自動検出
CallAgentToolのエージェントカタログの構築- システムプロンプトインジェクション用の表示可能なスキルの読み込み
- MCPサーバーの解決
- エージェント設定の検索（ユーザーが表示可能なエージェントのみを選択できることを保証）
関係図
FIM Oneには2つの並列実行パラダイムがあります — チャット（エージェント駆動）とワークフロー（DAG駆動） — これらは同じ基盤となるリソースを共有していますが、異なる方法でそれらをオーケストレーションします。 図からの主要なポイント：- エージェントとワークフローは並列パラダイムです。 どちらもコネクタ、ナレッジベース、MCP サーバーを使用できます — ただし異なるメカニズムを通じてです。エージェントはそれらを
ToolRegistry内のツールとして使用します。ワークフローはそれらを型付きDAGノードとして使用します。 - ワークフローはエージェントをオーケストレーションできます —
AGENTノード経由で、ワークフローステップは独自のReAct/DAGループを持つ完全なエージェントを呼び出すことができます。逆は真ではありません。エージェントはワークフローを直接呼び出すことはできません（API/webhookトリガー経由の間接的な方法のみ）。 - スキルはエージェントにのみ注入されます。 スキルはシステムプロンプトテキストです — これらはエージェントの動作をガイドします。ワークフローはスキルを消費しません。ワークフローノードは決定論的ロジックを実行し、LLMガイドの推論ではないためです。
- 共有リソース、異なるアクセスパターン。 コネクタはエージェント（
ConnectorToolAdapter経由）、ワークフロー（CONNECTORノード経由）、または同じビジネスプロセス内の両方によって呼び出すことができます — 例えば、ワークフローがエージェントをトリガーし、そのエージェントがワークフローが後のステップでも使用する同じコネクタをクエリします。
ワークフローエンジン — もう1つの実行パラダイム
このドキュメントはエージェント駆動のチャット実行に焦点を当てていますが、FIM Oneには完全なワークフローエンジンが含まれています — 固定プロセス自動化のための26のノードタイプを備えたビジュアルDAGエディタです。
2つのパラダイムは相補的です。タスクがオープンエンド (“この四半期の売上データを分析し、アクションを推奨してください”) の場合はエージェントを使用します。プロセスが既知の場合 (“毎週月曜日、ERPから新しい請求書を取得し、コンプライアンスチェックを実行し、例外を人間のレビュアーにルーティングする”) はワークフローを使用します。ワークフローは、固定パイプライン内で柔軟な推論が必要なステップについて、エージェントを呼び出すことができます。
エージェント実行モードとワークフローノードタイプの詳細については、実行モードを参照してください。