This commit is contained in:
Ralph Soika 2025-12-05 23:56:54 +01:00
parent 7aacc62e73
commit 79f42ec989

View file

@ -91,14 +91,14 @@ The architecture consists of five core components:
**Components** **Components**
| Component | Description | | Component | Description |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **AI Orchestrator** | Central coordinator. Receives user requests, interacts with the LLM to create execution plans, and initiates the approval workflow. | | **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. | | **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. | | **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 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. | | **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. | | **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 ### 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. 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: The two approaches complement each other:
@ -166,7 +166,7 @@ Key Design Decisions:
| Approach | Use Case | | Approach | Use Case |
| --------------------- | ------------------------------------------------------------------------------------------------------- | | --------------------- | ------------------------------------------------------------------------------------------------------- |
| BPMN with embedded AI | Predefined processes where AI enhances specific steps (classification, summarization, decision support) | | 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. 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: 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. **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.