Guidelines for Project Implementation Preparation

The following checklist guides you through building a new AI Fusion framework implementation from scratch. Use it to ensure that components are properly configured.

The implementation phase can be done on top of the setup phase.

Data Product Setup — AI-Ready

Add Schema Description

Schema descriptions help the LLM understand your data model and generate accurate SQL queries. Verify that schema descriptions exist; add them if they do not.

Option A: Generated by the Catalog Discovery (Recommended)

• [ ] Run Catalog discovery on your source database
• [ ] Use the LLM plugin to generate descriptions
• [ ] Build the LU from Catalog discovery results

Option B: Added Manually in Fabric Studio

• [ ] Open each table in the LU schema
• [ ] Add table-level descriptions
• [ ] Add column descriptions including:
  • Purpose of the column
  • Valid values (for enums/codes)
  • Relationships to other tables
  • Business context

For either option, also add the overall LU schema description using the Schema Properties pane.

Note: Even if Option A is used, you can modify and fine-tune it directly in the LU, as described in Option B.

Configure Domain Data

You can organize a data product into domains, where each domain represents a logical group of tables.

This structure is especially useful for AI agents that dynamically generate SQL. When AI agents are intended to generate SQL dynamically, it is important to limit the scope to only the tables relevant to the user’s request. Domain-based separation enables this intention by allowing the agent to operate on a focused subset of the data product rather than the entire schema.

For example, a banking data product (customer_bank) might be divided into domains such as DDA (Demand Deposit Accounts), LOAN (Loans and Mortgages), and CC (Credit Card Management). If a user asks a question related to credit cards, only the tables in the CC domain are included in the LLM invocation context.

A good practice is to provision and maintain a domain list by creating an MTable in the data product LU, including the following recommended columns:

• Domain
• Description
• Rules
• Tables
• Goal_Description

According to this list, during an agentic flow, you can use an MTable actor to look up a specific domain and its content, and thus augment the AI context. In case you are running an external agent, this information can be exposed as a tool via API or MCP.

Here is an example:

Create Sample Questions and SQL Queries

Sample questions help the LLM generate accurate SQL queries for data retrieval.

In addition to prompt context scoping defined by the domain list, it is important to provide, for each domain, a set of example user questions along with the corresponding SQL queries that can answer them.

• [ ] Create questions.json in customer_bank/Java/resources/

• Use UserCode loadResource method for consuming it.
• As an alternative, you can have it is a const actor in a Broadway flow.
• [ ] Add question-SQL pairs for each domain. For example:

```json
[
  {
    "domain": "POLICY",
    "question": "What insurance policies do I have?",
    "sql": "SELECT policy_number, policy_type, status, premium FROM     Policies_Master"
  },
  {
    "domain": "POLICY",
    "question": "What is my coverage amount?",
    "sql": "SELECT coverage_type, coverage_amount, deductible FROM Policy_Coverage"
  },
  {
    "domain": "CLAIMS",
    "question": "Show me my recent claims",
    "sql": "SELECT claim_number, claim_date, status, amount FROM Claims_History ORDER BY claim_date DESC"
  }
]
```

Tool Configuration

Create Core Tools

Create the following standard tools for your implementation:

Domain Description Tool

• [ ] Create a <describeDomain>.flow or update an existing one.
• [ ] Input: Use the domain as input parameter
• [ ] Output includes:
  • [ ] The specific domain's information from the domain's MTable (name, description, rules, tables, goals)
  • [ ] Schema description (you can use the LLMSchema actor)
  • [ ] Sample Questions and SQL Queries

Vector Database Tools

• [ ] When using vector database, create a tool for searching it.

• [ ] In case the vector database is self-hosted with Fabric (SQLite or Postgres), implement an additional tool for loading the data.

Consider whether to run the vector load process in QA and production deployments as well. You may prefer to take action during implementation: Store the content in a CSV file that is already vectorized, and then use that file in non-Studio deployments (as an SQLite vector database). This approach is beneficial as it allows you to track changes in GIT and well as perform testing before using it.

Customized Tools

As part of implementation, you might create and expose tools related to data products. See here for more information about tool objectives and concepts.

Tool Building

When building and maintaining a tool, it is recommended to follow this checklist:

• [ ] Create the tool flow
• [ ] Configure flow properties:
  • [ ] Add relevant tags
  • [ ] Write clear description
• [ ] Add parameter remarks to all inputs/outputs
• [ ] Implement validation logic
• [ ] Add error handling
• [ ] Test the tool independently

Tool Calling

The AI Fusion framework supports three types of tool calling, which you can choose from. When specifying their names, such as for a specialized sub-agent, ensure that you follow the naming conventions:

• <toolname> — calls a Broadway flow located in the aifusion LU.

• LU__<luName>__<toolName> — calls a Broadway flow (toolName) located in an LU (luName) rather than in the aifusion LU. As recommended, this tool calling type is usually built inside data products. Example: LU__customer_bank__getTransactionsByCategory

• MCP__<mcpInterfaceName>__<toolName> — calls a tool via the MCP protocol using an MCP connector. The interface (mcpInterfaceName), which is of MCP connector type, stores the MCP connection details, and toolName is the MCP tool name defined on that server.

Worker Sub-Agents

As explained in other articles (see here and here), it is highly recommended to create sub-agents focused on specific topics, usually aligned with to data product domains.

AI Applications

An organization might have several AI-based applications aimed at different purposes and/or audiences. For example, apps for CRM, for technician teams, and for end customers. Some apps may share LUs, sub-agents, and tools, while others may not.

The AI Data Fusion framework allows you to define multiple applications, enabling them to be managed and tested throughout their entire lifecycle, including their Chat flows and Evaluation.

App Flows

For each app, you should create the following flows. Their objectives and usage are described later in this article:

• [ ] The main entry-point flow (the chat flow)
• [ ] Customer Story flow
• [ ] Synopsis flow

Register Apps in the apps.csv File

The apps are managed in the Implementation/LogicalUnits/aifusion/Mtable/apps.csv file, where you should set the following parameters. This will enable the AI Fusion platform apps to use these parameters and operate accordingly:

Usage

The above table is used in several places:

• Chat — calls the default chat API; this information should be provided in order for the appropriate flows and tools to be used.

In the Chat Playground

• The client side uses the app-id as defined in the Apps JSON (see below) and sends it to the API.
• The app-id value also affects which Chat Playground customization files (CSS and text) are loaded. Read here for more information.

• Evaluation

  • When creating tests, the Evaluation Editor offers the user to create tests for apps that appear in the CSV file.
  • Evaluation analysis is performed on the specific app saved in the test case.
  • The auto-test creation capability uses the synopsis flow data to generate test case questions.

• Observation — information is collected with the app ID, allowing dashboard widgets and views to be separated for each app.

Configure the Apps JSON File

Configure the apps.json file used in your project. It is recommended to locate the apps JSON in the WS LU (Implementation/LogicalUnits/k2_ws/web/apps.json).

• The order of sub-apps — Chat playground, Observation and Evaluation
• The app and sub-apps names
• The active app-id of the Chat Playground — change the aifusionAppId according to the IDs that appear in the apps.csv file.

{
        "name": "AI Data Fusion",
        "appId": "aifusion",
        "apps": [
            { "displayName": "Chat", "pathName": "chat", "aifusionAppId": "banking" },
            { "displayName": "Evaluation", "pathName": "evaluation" },
            { "displayName": "Observation", "pathName": "observation" }
        ]
    }

• [ ] Verify that there is at least one app entry in the apps.csv file.

Best Practices

• Cache utilization — in the LLMConst actor, locate the dynamic system prompt information at the end. This allows LLM providers to use their cache mechanism for storing input tokens. This mechanism reuses the latest system prompts; however, any dynamic information will break it.