Engineering & roadmap
AI integration decisions
A new name. The same foundation. KratosForge is the upcoming name for Fabric Desktop by KratosBI. These guides preserve the app’s current labels and paths.
Decisions made while building the AI integration program, with the reason for each. Architecture: ai-integration.md.
| # | Decision | Why | Alternatives considered |
|---|---|---|---|
| AI-D1 | No AI inside the app: no model, chat, provider SDK or AI key. The app exposes capabilities; people bring their own AI tool. | Chris's principle: AI-ready, not AI-dependent. | — |
| AI-D2 | MCP server and local API run as separate engine processes (fabric-desktop mcp, fabric-desktop integrations serve), not inside the app's engine. |
The app's engine is owned by the shell over stdio and runs the person's kernel; an external caller there would share it and could block the UI. Separate processes share the code, data folder and sign-in. | A bridge through the Tauri shell into the app's engine (needs Rust changes, shares the kernel). |
| AI-D3 | Official MCP Python SDK (mcp), low-level Server. |
The engine is Python; the SDK tracks the spec and handles negotiation and both protocol eras. The low-level server lets the tool list come from the registry at run time. | Hand-written JSON-RPC (more to maintain, easy to drift from the spec); the decorator-based MCPServer (static tools). |
| AI-D4 | stdio first; HTTP only when the person switches it on, on 127.0.0.1 with a per-client token. |
stdio is reachable only by the tool that started it and every current client supports it. HTTP is for tools that can't start a process. | HTTP on by default (opens a port nobody asked for). |
| AI-D5 | One invoke() below every transport; authorization and approval there. |
Approval can't be bypassed by choosing another interface, and behaviour is identical across MCP and REST. | Checks in each transport (drift between them). |
| AI-D6 | Approvals are decided only in the app, never through MCP elicitation or an API call. | A client that could answer its own approval prompt, or be told to by injected text, makes the approval meaningless. | MCP elicitation (the AI client renders and answers the prompt). |
| AI-D7 | Approvals are single-use and bound to a hash of the exact arguments. | Stops a client getting approval for one thing and running another. | Time-window approvals for any arguments. |
| AI-D8 | External SQL is read-only and sandboxed (DuckDB enable_external_access = false, configuration locked). |
DuckDB can otherwise read and write local files, attach databases and load extensions, which would bypass the file and data permissions. Lakehouse tables are registered as Arrow datasets and keep working. | Treat SQL as code execution (needs approval for every read). |
| AI-D9 | External Python always runs in a process kernel, never inside the server process. | Stop can end it without ending the server, and it is the engine's existing execution control. | In-process kernel (a runaway cell takes the server down). |
| AI-D10 | First release offers no OneLake writes, Fabric item changes, deployments or Fabric runs to external tools. Those categories exist and show as unavailable. | Writes to OneLake and Fabric deserve their own preview, confirmation and audit design; reads, local execution and notebook authoring cover the first workflows. | Exposing publish and promote now. |
| AI-D11 | The registry precedes the MCP server in the build order. | The server lists tools from the registry; building it first avoids a static list that is later thrown away. | The requested order (002 before 003). |
| AI-D12 | Integration settings live in their own SQLite file; IT controls are two new keys in the existing policy file (integrations, integrations_max_permissions). |
Clients, approvals and activity are written by several processes at once, which SQLite handles. Using the existing policy file keeps one place for IT. | JSON files (unsafe across processes); a second policy file. |
| AI-D13 | Each pull request targets main and builds on the previous one; merge in order. |
Chris merges by hand; stacked bases on feature branches are easy to merge into the wrong place. | Stacked bases. |
Need a hand?
Find a fix in troubleshooting, or share a reproducible issue with the community.
Get support ↗Improve this guide on GitHub ↗