diff --git a/doc/MCP/README.md b/doc/MCP/README.md index 0f107c7..68bc042 100644 --- a/doc/MCP/README.md +++ b/doc/MCP/README.md @@ -91,14 +91,14 @@ The architecture consists of five core components: **Components** -| Component | Description | -| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| **AI Orchestrator** | Central coordinator. Receives user requests, interacts with the LLM to create execution plans, and initiates the approval workflow. | -| **Tool Registry** | Maintains a catalog of all available tools – both internal Imixs services and external tools discovered from MCP servers. Provides tool definitions to the LLM for function calling. | -| **LLM Client** | Connects to the local LLM (llama.cpp via OpenAI API). Sends prompts with tool definitions and receives structured execution plans. | -| **MCP Client** | Discovers and invokes tools from external MCP servers (e.g., SAP, Salesforce). Translates MCP protocol calls into the Tool Registry format. | -| **MCP Server Endpoint** | Exposes Imixs workflow capabilities to external AI systems. Allows tools like Claude Desktop or third-party orchestrators to start processes or query tasks. | -| **AI Execution Process** | A BPMN process that handles human review and approval. Stores the execution plan, presents it to the user, and executes approved actions through the workflow engine. | +| Component | Description | +| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| **AI Orchestrator** | Central coordinator. Receives user requests, interacts with the LLM to create execution plans, and initiates the approval workflow. | +| **Tool Registry** | Maintains a catalog of all available tools – both internal Dynamixs.AI services and external tools discovered from MCP servers. Provides tool definitions to the LLM for function calling. | +| **LLM Client** | Connects to the local LLM (llama.cpp via OpenAI API). Sends prompts with tool definitions and receives structured execution plans. | +| **MCP Client** | Discovers and invokes tools from external MCP servers (e.g., SAP, Salesforce). Translates MCP protocol calls into the Tool Registry format. | +| **MCP Server Endpoint** | Exposes Dynamixs.AI workflow capabilities to external AI systems. Allows tools like Claude Desktop or third-party orchestrators to start processes or query tasks. | +| **AI Execution Process** | A BPMN process that handles human review and approval. Stores the execution plan, presents it to the user, and executes approved actions through the workflow engine. | ### 2.2 Request Flow @@ -155,9 +155,9 @@ Dynamixs.AI already provides powerful LLM integration within BPMN processes. Pro This approach works well for **predefined workflows**. The process designer knows in advance which LLM calls are needed and where. The prompts are fixed, the integration points are explicit, and the sequence flow controls everything. -But what happens when the user's intent is not predefined? When a user types _"Create a customer in SAP and start an invoice process"_, there is no existing BPMN model for that specific request. The system would need a process for every possible combination of actions – which is impossible. +But what happens when the user's intent is not predefined? When a user types _"Create a customer in SAP and start an invoice process"_, there is no existing BPMN model for such kind of ad-hoc request. The system would need a process for every possible combination of actions – which is impossible. -This is where the AI Orchestrator comes in. Instead of embedding AI into fixed workflows, the Orchestrator inverts the relationship: The AI creates the workflow. The user expresses intent in natural language, the LLM selects the appropriate tools and assembles an execution plan, and the result flows into a BPMN process for human approval and execution. +This is where the Dynamixs.AI Orchestrator comes in. Instead of embedding AI into fixed workflows, the Orchestrator inverts the relationship: **Dynamixs.AI creates the workflow**. The user expresses intent in natural language, the LLM selects the appropriate tools and assembles an execution plan, and the result flows into a BPMN process for human approval and execution. The two approaches complement each other: @@ -166,7 +166,7 @@ Key Design Decisions: | Approach | Use Case | | --------------------- | ------------------------------------------------------------------------------------------------------- | | BPMN with embedded AI | Predefined processes where AI enhances specific steps (classification, summarization, decision support) | -| AI Orchestrator | Ad-hoc requests where the user defines the goal and AI determines the steps | +| Ad-hoc AI Workflows | Ad-hoc requests where the user defines the goal and Dynamixs.AI determines the steps | The AI Orchestrator does not replace the existing LLM integration. It adds a new capability: Letting users initiate complex, cross-system actions through natural language – with full BPMN-based control over execution. @@ -228,7 +228,7 @@ public class AiOrchestrator { When a request arrives, the Orchestrator follows a strict sequence: -**Step 1: Collect available tools.** The Orchestrator asks the Tool Registry for all tools the current user is allowed to use. This includes internal Imixs services and external MCP tools. The result is a list of tool definitions with names, descriptions, and parameter schemas. +**Step 1: Collect available tools.** The Orchestrator asks the Tool Registry for all tools the current user is allowed to use. This includes internal Dynamix.AI services and external MCP tools. The result is a list of tool definitions with names, descriptions, and parameter schemas. **Step 2: Build the LLM prompt.** The Orchestrator constructs a prompt that contains the user's request, the available tools, and any relevant context (e.g., current user, business domain). The prompt instructs the LLM to analyze the request and return a structured execution plan.