保留正文与补采附件。源页面当前未重新核验；具体限制见交付清单。

Revisit consent button We value your privacy We use cookies to enhance your browsing experience, serve personalised ads or content, and analyse our traffic. By clicking "Accept All", you consent to our use of cookies. Customise Reject All Accept All Customise Consent Preferences We use cookies to help you navigate efficiently and perform certain functions. You will find detailed information about all cookies under each consent category below. The cookies that are categorised as "Necessary" are stored on your browser as they are essential for enabling the basic functionalities of the site. ... Show more NecessaryAlways Active Necessary cookies are required to enable the basic features of this site, such as providing secure log-in or adjusting your consent preferences. These cookies do not store any personally identifiable data.

Functional Functional cookies help perform certain functionalities like sharing the content of the website on social media platforms, collecting feedback, and other third-party features.

Analytics Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics such as the number of visitors, bounce rate, traffic source, etc.

Performance Performance cookies are used to understand and analyse the key performance indexes of the website which helps in delivering a better user experience for the visitors.

Advertisement Advertisement cookies are used to provide visitors with customised advertisements based on the pages you visited previously and to analyse the effectiveness of the ad campaigns.

Uncategorised Other uncategorised cookies are those that are being analysed and have not been classified into a category as yet. No cookies to display. Reject All Save My Preferences Accept All Toggle SearchToggle Mobile Navigation Publish AI, ML & data-science insights to a global community of data professionals. Sign inSubmit an Article LatestEditor's PicksNewsletterShipAI

Write For TDS LinkedInXToggle Search Agentic AI

Hybrid AI: Combining Deterministic Analytics with LLM Reasoning

How AI architecture prevents plausible but wrong analytics Ingo Nowitzky May 22, 202617 min read Generated by author using ChatGPT

Introduction

I tried to build an agentic AI network for my company that advises manufacturing plants on how to mature their operations. The system was designed to be data-driven, allowing users to upload assessment data directly through the chat interface. The first working prototype was finished surprisingly quickly, and at first glance the results looked promising. There was only one problem: Most of the results were wrong! Even worse, the AI quickly learned which numerical ranges looked plausible and began generating convincing — but fabricated — outputs. Combined with the eloquent language generation of the LLM, these results could easily be mistaken for truth. And this behavior was not limited to a single model. Similar patterns appeared across all tested systems: ChatGPT, Gemini Enterprise, DIA Brain, and Microsoft Copilot. But plausible data is not enough, Enterprise AI systems require reliable data. Further investigation revealed recurring failure modes. Even with “Code Interpreter” enabled, the systems:

This led to a crucial realization: Probabilistic reasoning is extremely powerful for interpretation and interaction — but foundational data analysis requires deterministic execution. Learn this step by step with the interactive AI Agents roadmap.

Table of contents

1 The Use Case
2 The Hybrid Architecture
3 The Analysis Planner
4 The Analysis Engine
5 An End-to-End example
6 Why AI Architecture Matters

1 The Use Case

Although the specific use case is of secondary importance, it is briefly outlined here to support the practical understanding of the underlying architectural challenge. The primary task of our agent is to advise manufacturing plants and value streams on how to improve their operational maturity: optimizing processes, improving productivity, reducing inventory levels, and ultimately lowering operational costs. To achieve this, the consultation agent operates in two modes:

  1. It provides generic recommendations for improving specific operational topics based on the retrieval of specialized “how-to” documentation and assessment questionnaires.
  2. The agent is intended to analyze the current situation of a plant or value stream based on assessment results and assessors’ written recommendations. Based on this analysis, it is expected to provide highly specific recommendations for the next improvement steps.

In both modes — as with most LLM-based AI models — the user can interactively discuss ideas and recommendations with the agent in order to derive the most suitable action plan. For the second operation mode, it is essential that the agent can reliably process and analyze assessment data. In our case, this data is provided as an Excel export from a central database. Ideally, the agent should be able to process the file without any prior manual preparation. The structure of the file, however, is challenging. Since all assessment results, intermediate calculations, metadata, and detailed assessment questions are stored in separate columns, the worksheet contains more than 800 columns. The number of rows corresponds to the number of assessments in the database and can range from one to several hundreds (Fig. 1). Assessment ratings are represented as integers from 0 to 4. In addition, the file contains more than 160 free-text fields with qualitative observations, strengths, weaknesses, and recommendations from the assessors. Figure 1: Assessment data structure | image by author The analytical tasks of the agent include filtering relevant rows and columns for a specific request, calculating averages, aggregating maturity scores, summarizing textual recommendations, and deriving meaningful improvement suggestions from the results. Initially, these tasks appeared to be well within the capabilities of modern LLM-based AI systems, especially with “Code Interpreter” mode enabled. As already mentioned in the introduction, this assumption quickly turned out to be a misconception.

2 The Hybrid Architecture

The core idea for overcoming the analytical challenge was to clearly separate deterministic data analysis from LLM-based reasoning and interpretation. Fig. 2 shows the selected system architecture after several improvement iterations. The system was implemented in Microsoft Copilot Studio because the platform allows deterministic workflow elements, such as topics and flows, to be combined with LLM-based reasoning components. Figure 2: System architecture of the consultation agent with integrated analytics module | image by author The parent agent handles all communication with the user. It orchestrates the sub agents and the analytics module, delegates tasks to them, receives their responses, and composes the final answer. The sub agents are specialized LLM-based modules with access to specific knowledge sources. These include descriptions of maturity-level expectations for the value streams, questionnaires with detailed assessment questions, and more general guidelines for operational excellence. The sub agents are called by the parent agent according to their specific capabilities and respond to the parent agent rather than directly to the user. The analytics module is the main focus of this article. It performs the deterministic data analysis and is designed to provide reproducible and reliable analytical results. It receives an analysis instruction in natural language from the parent agent, referred to as Parent_Instruction. The analytics module itself consists of topics, flows, and AI modules, which are called “prompts” in Copilot Studio. The topic T_receive_Excel_File handles the upload and storage of assessment files. It is triggered when a file is uploaded in the chat window, indicated by the variable System.Activity.Attachments having a value. The topic checks whether the uploaded file is an Excel file and, if so, stores it in the global variable Assessment_File. The topic T_analyze_assessments is actively called by the parent agent if it has an analytics task to conduct and receives Parent_Instruction as input. A second input is the assessment data stored in the global variable Assessment_File. The topic contains the two core analytics components: Analysis_Planner and Analysis_Engine. Both are embedded in agentic flows, F_Call_Analysis_Planner and F_Call_Analysis_Engine. These flows serve as connectors between the topic T_analyze_assessments and the AI prompts P_Analysis_Planner and P_Analysis_Engine. F_Call_Analysis_Planner receives only one input, Parent_Instruction, and forwards it to P_Analysis_Planner. This component generates the Selection_Rule, the core analysis instruction to be executed by P_Analysis_Engine. The inner workings of P_Analysis_Planner are discussed in Chapter 3. F_Call_Analysis_Engine receives three inputs: the Selection_Rule from Analysis_Planner, a Mapping_File provided from SharePoint, and the Assessment_File. All three inputs are forwarded to the AI prompt P_Analysis_Engine, which conducts the data analysis as specified by Analysis_Planner. The P_Analysis_Engine is discussed in detail in Chapter 4.

3 The Analysis Planner

The P_Analysis_Planner is the intelligent part of the data analysis pipeline and generates the analysis instruction, called Selection_Rule. This instruction is a translation of the natural language Parent_Instruction and is generally unique for each request. In order to minimize probabilistic variation, the translation process is constrained by strict rules. The Analysis_Planner does not analyze the assessment data itself. Its sole responsibility is to translate the probabilisticParent_Instructioninto a deterministic analysis specification. In the following, we will examine selected parts of the instruction in more detail. You can download the full instruction here. markup

You are Analysis_Planner, an expert assistant for translating natural-language assessment analysis requests into structured Selection_Rules.Your task is to create a Selection_Rule JSON object for the Analysis_Engine.You receive only one input:1. Parent_Instruction :A natural-language analysis request from the parent agent (orchestrator).You must analyze Parent_Instruction and determine:- which type of analysis is required,- which assessment content categories are relevant,- whether concept or execution maturity/findings are requested,- whether specific chapters are requested,- and whether row filters are required.The Selection_Rule you generate will later be used by the Analysis_Engine together with:- the real assessment data file,- and the Mapping_Fileto execute the analysis deterministically.

The code box above shows the initial instruction for P_Analysis_Planner. It clearly defines purpose and scope and explicitly separates planning from execution. The planner translates the request, while the actual execution is delegated to the P_Analysis_Engine. Next follows a longer section describing the semantics of the assessment data. Of course, this part is highly specific to the individual use case and dataset. It defines semantic categories used for row filtering and categories used to select the actual analysis targets (TARGET CONTENT CATEGORIES and TARGET SELECTION ATTRIBUTES). yaml

ASSESSMENT DATA SEMANTICS

The assessment data can be addressed through the following semantic categories.

ROW FILTER CATEGORIES

Use these categories only for row_filters:

- VS_Nr:
    Unique identifier of the value stream.
    Use when filtering by value stream number.

- Value Stream:
    Name of the value stream.
    Use when filtering by value stream name.

- ...

TARGET CONTENT CATEGORIES

Use these categories only in target_selection_rules.data_category:

- chapter_score:
    Numeric maturity score.
    Use for maturity calculations, score analysis, and average maturity analysis.

- strength:
    Assessor statements describing strengths.

- ...

TARGET SELECTION ATTRIBUTES

Use these attributes only inside target_selection_rules:

- data_category:
    Defines which target content category is needed.

- aggregation_allowed:
    Use:
        - mean for numeric maturity averages
        - summary for textual summaries

- ...

The planner never interacts directly with physical dataset columns. Instead, it operates on a semantic abstraction layer that decouples natural language from the underlying dataset structure. This separation is important because the assessment dataset contains more than 800 columns, including:

Selecting the correct target columns therefore becomes a critical part of the analysis process. Restricting the allowed analysis types is equally important. The planner is intentionally prevented from inventing arbitrary analytical operations. The section ANALYSIS TYPES therefore defines the only valid analysis types — currently just two. This significantly improves the predictability and robustness of downstream execution. Of course, the list can easily be extended for individual use cases. yaml

ANALYSIS TYPES

Use exactly one of these analysis_type values:

- numeric_mean
    Use for:
    - average maturity
    - mean maturity
    - ...

- text_summary
    Use for:
    - strengths
    - improvement potentials
    - ...

The next section defines how the planner selects the relevant target columns in an abstract and deterministic way. The rules distinguish between the two predefined analysis types numeric_mean and text_summary and finally determine which dataset columns are selected for a specific request. yaml

RULES FOR target_selection_rules

NUMERIC MATURITY ANALYSIS

For numeric maturity analysis:
- analysis_type must be:
    "numeric_mean"
- data_category must be:
    ["chapter_score"]
- ...

TEXT SUMMARY ANALYSIS

For textual summary analysis:
- analysis_type must be:
    "text_summary"
- data_category:
    include only requested categories:
        - "strength"
        - "potential"
        - "recommendation"
        - "remark"
- ...

A similar logic applies to the row filtering process. yaml

RULES FOR row_filters

Use row_filters only for filtering rows in the assessment dataset.

Allowed row filter keys are:
- VS_Nr
- Value Stream
- ...

Do NOT use row_filters for:
- chapter_id
- ...

These belong only to target_selection_rules.

Finally, the instruction defines the required output structure together with several strict “do-not rules”. This section is particularly important because the generated output is directly forwarded to the P_Analysis_Engine and therefore must follow a clearly defined and machine-readable structure. json

OUTPUT FORMAT

Return only valid JSON.
Do not return markdown.
Do not return Python code.
...

Use exactly this structure:

{
  "status": "success",
  "parent_instruction_summary": "",
  "selection_rule": {
    "analysis_type": "",
    "target_selection_rules": {
      "data_category": [],
      "aggregation_allowed": [],
      "concept_execution": null,
      "chapter_id": null
    },
    "row_filters": {}
  },
  "warnings": []
}

If the request is unclear, the planner must explicitly return an error structure instead of “guessing” a potentially wrong analysis instruction. json

If the task is unclear, return:

{
  "status": "error",
  "parent_instruction_summary": "",
  "selection_rule": {
    "analysis_type": null,
    "target_selection_rules": {
      "data_category": [],
      "aggregation_allowed": [],
      "concept_execution": null,
      "chapter_id": null
    },
    "row_filters": {}
  },
  "warnings": [
    "The analysis task is not clearly understood."
  ]
}

At this point, the planner has transformed ambiguous natural language into a deterministic analysis specification. However, the actual data execution still has not happened. In chapter 5, we will follow a real user request through the complete pipeline and examine how P_Analysis_Planner generates the Selection_Rule and how P_Analysis_Engine executes it on the assessment dataset.

4 The Analysis Engine

Unlike the P_Analysis_Planner, the P_Analysis_Engine does not reason about the task. It only executes the analysis specification generated by P_Analysis_Planner. As in chapter 3, we will focus only on the most relevant parts of the instruction. The full specification can be downloaded here. The instruction of P_Analysis_Engine starts with the basic task definition. In essence, the AI prompt is used as a controlled Python execution environment. The code is predefined in the prompt instruction and must only be executed, not modified. markup

You are Analysis_Engine, a deterministic pandas-based analysis executor.Your task is to analyze an Excel assessment dataset using Code Interpreter.You receive three inputs:1. document    The Excel file containing the assessment data.2. Mapping_File    The Excel file describing the columns of document.3. Selection_Rule    A JSON object that defines:   - which columns to select from Mapping_File   - which row filters to apply to document   - which type of analysis to performYou must not reinterpret the original user request.You must not infer additional columns.You must not change Selection_Rule.You must not generate a new analysis approach.You must only execute the deterministic Python script below.Use Code Interpreter to execute the Python script.Return only the JSON result printed by the script.Do not return markdown.Do not explain the code.Do not add text before or after the JSON result.

P_Analysis_Engine receives three input files:

  1. The Assessment_File uploaded from the user in the chat interface. It is stored in the prompt-internal variable document.
  2. A Mapping_File which the flow F_Call_Analysis_Engine loads from SharePoint in preparation of the execution.
  3. The Selection_Rule generated by P_Analysis_Planner (see chapter 3).

The Mapping_File plays a crucial role in defining the semantics of the many columns in Assessment_File on a higher level of abstraction. With this abstraction layer, the Selection_Rule only needs to specify which type of information is required, while the P_Analysis_Engine selects the corresponding dataset columns during execution. Figure 3: Structure of Mapping_File | image by author Fig. 3 shows the structure of Mapping_File. It contains a row for each column of Assessment_File, that is potentially relevant for the data analysis. Data columns that are clearly irrelevant are not represented in Mapping_File and therefore are not visible to P_Analysis_Engine. For each row, the file specifies the selection criteria:

Next in P_Analysis_Engine’s instruction comes a paragraph about how to interpret the Selection_Rule. markup

Rules for Selection_Rule:- analysis_type = "numeric_mean":  Calculate arithmetic means for all selected numeric target columns.- analysis_type = "text_summary":  Collect non-empty text entries from all selected text target columns.- target_selection_rules:  Select target columns by matching Mapping_File attributes.  A rule value of null means: do not filter by this attribute.  A list means: keep rows where the Mapping_File attribute is in the list.- row_filters:  Apply row filters to document.  Keys are data_category values from Mapping_File, such as "Plant", "Region", "Production Principle", "Season".  Values are lists of accepted values.

The selection specifies:

This instruction is intentionally deterministic. The P_Analysis_Engine is not allowed to reinterpret the original user request or invent additional analytical operations. After the instruction block, the P_Analysis_Engine receives the actual Python script. The full script contains more than 300 lines of code and is part of the AI prompt instruction. It is linked at the top of this chapter and can be downloaded. Many of the code lines are not conceptually important for the architecture. They handle practical robustness: cleaning column names, normalizing input values, handling missing columns, converting Copilot wrapper objects, and returning structured error messages. For the article, I will focus only on the central logic. The first important step is that the engine loads the uploaded assessment data (now available in document) and the Mapping_File. From this point on, the LLM is no longer interpreting the user request. It only executes the deterministic script based on the Selection_Rule. python

mapping_df = pd.read_excel(Mapping_File)
data_df = pd.read_excel(document)

mapping_df = strip_column_names(mapping_df)
data_df = strip_column_names(data_df)

The key architectural element is the selection of target columns. The P_Analysis_Engine never guesses which Excel columns may be relevant. Instead, it filters the Mapping_File according to the attributes defined in target_selection_rules. python

target_mapping = mapping_df.copy()

for attr, rule_value in target_selection_rules.items():

    values = normalize_rule_value(rule_value)
    values = normalize_list_for_matching(values)

    if values is None:
        continue

    target_mapping = target_mapping[
        target_mapping[attr]
        .apply(normalize_for_matching)
        .isin(values)
    ]

selected_target_columns = (
    target_mapping["source_column_name"]
    .dropna()
    .tolist()
)

This is the point where the abstract analysis instruction becomes concrete. For example, a rule such as chapter_id = ["3.5"], data_category = ["chapter_score"], and aggregation_allowed = ["mean"] is translated into the actual Excel columns containing the Concept and Execution maturity scores for chapter 3.5. The same principle is applied to row filters. Again, the engine does not infer anything from natural language. It only applies the filters explicitly provided in the Selection_Rule. python

filtered_df = data_df.copy()

for filter_category, filter_values in row_filters.items():

    filter_mapping = mapping_df[
        mapping_df["data_category"]
        .apply(normalize_for_matching)
        == normalize_for_matching(filter_category)
    ]

    filter_col = filter_mapping["source_column_name"].iloc[0]

    filtered_df = filtered_df[
        filtered_df[filter_col]
        .apply(normalize_for_matching)
        .isin(values)
    ]

After column selection and row filtering, the actual analysis logic becomes intentionally straightforward. For numeric maturity analysis, the engine calculates arithmetic means for all selected numeric target columns. python

if analysis_type == "numeric_mean":

    numeric_result = {}

    for col in available_target_columns:

        series = pd.to_numeric(filtered_df[col], errors="coerce")
        valid_count = int(series.notna().sum())

        numeric_result[col] = {
            "mean": float(series.mean()) if valid_count > 0 else None,
            "valid_count": valid_count
        }

    result["result"] = numeric_result

For textual analysis, the engine collects non-empty assessor statements instead of calculating values. python

elif analysis_type == "text_summary":

    text_result = {}

    for col in available_target_columns:

        values = [
            clean_text_value(v)
            for v in filtered_df[col].tolist()
        ]

        values = [v for v in values if v is not None]

        text_result[col] = {
            "entries": values,
            "entry_count": len(values)
        }

    result["result"] = text_result

Finally, the result is returned as JSON. This is important because the output is not yet the final user-facing answer. It is the reliable analytical foundation for the next LLM step: interpretation by the parent agent. python

print(json.dumps(result, indent=2, ensure_ascii=False))

This design deliberately keeps the P_Analysis_Engine “boring”. It does not reason, it does not explain, and it does not improve the analysis. It only executes. And that is exactly the point. The more deterministic this layer is, the more trust can be placed in the later LLM-generated interpretation.

5 End-to-End Example

To illustrate the complete workflow, let us follow a realistic example through the full pipeline. Triggered by the user interaction, the parent agent might raise the following Parent_Instruction to the analytics module: “Summarize the main improvement potentials for chapter 1.4 Failure Prevention System in plant AbcP.” The request looks simple for a human reader, but it already contains multiple semantic tasks:

This is exactly the type of task where a pure LLM-based analysis becomes unreliable. The system therefore separates the workflow into deterministic execution steps and probabilistic interpretation steps.

5.1 Translation from Analysis Planner

The first step is performed by P_Analysis_Planner.
It translates the natural language request into a deterministic Selection_Rule. json

{
  "status": "success",
  "parent_instruction_summary": "Summarize improvement potentials for chapter 1.4 Failure Prevention System in plant AbcP.",
  "selection_rule": {
    "analysis_type": "text_summary",
    "target_selection_rules": {
      "data_category": ["potential"],
      "aggregation_allowed": ["summary"],
      "concept_execution": null,
      "chapter_id": ["1.4"]
    },
    "row_filters": {
      "Plant": ["AbcP"]
    }
  },
  "warnings": []
}

The Selection_Rule already contains the complete deterministic analysis specification:

At this stage, no data analysis has happened yet. The result is only an execution instruction for the next step.

5.2 Execution from Analysis Engine

This Selection_Rule is handed over to P_Analysis_Engine for execution. First, the engine selects all matching target columns from the Mapping_File. python

target_mapping = target_mapping[
    target_mapping[attr]
    .apply(normalize_for_matching)
    .isin(values)
]

This translates the abstract selection criteria into real dataset columns, for example: python

selected_target_columns = [
    "1.4 CON L2 Improvement potentials",
    "1.4 CON L3 Improvement potentials",
    "1.4 EXE L2 Improvement potentials",
    "1.4 EXE L3 Improvement potentials"
]

Next, the row filters are applied: python

filtered_df = filtered_df[
    filtered_df[filter_col]
    .apply(normalize_for_matching)
    .isin(values)
]

In this example, the dataset is reduced to assessment rows belonging to plant AbcP. Finally, the engine collects all non-empty text entries from the selected columns. python

values = [
    clean_text_value(v)
    for v in filtered_df[col].tolist()
]

values = [v for v in values if v is not None]

As we can see, the engine does not interpret the findings. It only retrieves and structures them according to the Python script. The engine’s output is a collection of assessors’ written statements about the value stream’s improvement potentials as a JSON object. json

{
  "entry_count": 6,
  "entries": [
    "Root causes are not systematically tracked.",
    "Escalation rules for recurring failures are unclear.",
    "Lessons learned are not transferred between shifts.",
    "Preventive maintenance findings are not integrated into CIP activities.",
    "Failure trends are visualized inconsistently.",
    "Problem-solving activities focus mainly on symptoms instead of root causes."
  ]
}

At this point, the system has still not generated any recommendations. It has only produced a reliable collection of relevant assessment findings. This JSON object is returned to the parent agent for interpretation and generation of the final response to the user.

5.3 Interpretation from Parent Agent

In the final step, the parent agent collects all responses (potentially additional responses from the sub agents) and generates the final output. markup

The collected findings indicate that the Failure Prevention System iscurrently more reactive than preventive. Most gaps are related to missingsystematic root-cause management and weak organizational learning acrossshifts and teams. The highest leverage improvements would likely come fromstrengthening escalation routines, integrating preventive maintenance findingsinto CIP activities, and establishing consistent cross-shift learningmechanisms.

To summarize the central architectural idea of the system: The LLM no longer creates the analytical foundation itself. Instead, it interprets a deterministic set of already validated findings. The probabilistic reasoning capability of the LLM is used where it creates value: interpretation, prioritization, explanation, and communication — not data processing itself.

6 Why AI Architecture Matters

Large Language Models are naturally strong at interpretation, reasoning, and language generation, but still weak at reliable numerical analytics. Their optimization target is plausibility, not deterministic reproducibility. Even with extensions such as “Code Interpreter”, this weakness remains visible in more complex analytical scenarios. The good news is that this limitation can largely be compensated through intelligent system architecture. The key is a clear separation of responsibilities: deterministic data-processing layers execute the analytical foundation, while LLMs focus on interpretation, prioritization, explanation, and communication. In the presented approach, the most important design decision was therefore not adding more AI to the system. It was defining very carefully where probabilistic reasoning should end and deterministic execution should begin. Reliable agentic systems will likely require exactly these kinds of hybrid architectures: combining the robustness of classical data science pipelines with the inference capabilities of Large Language Models.

Register Now to Continue Reading

Unlock Towards Data Science with a Free Account

All articles on Towards Data Science are available to registered users. Create a free account today to access this article and thousands more. Register for freeSign in to your account

Written By

Ingo Nowitzky

PhD Engineer, Lean Production professional, and AI enthisiast. See all from Ingo Nowitzky Deep DivesAi AgentArtificial IntelligenceData ScienceLlm Share This Article

Towards Data Science is a community publication. Submit your insights to reach our global audience and earn through the TDS Author Payment Program. Write for TDS

Related Articles

Training a Neural Network With a Few, Clean Lines of Code

Artificial Intelligence Reusable, maintainable and easy to understand machine learning code. Daniel June 14, 20227 min read

Build A MFCC-Based Music Recommendation Engine On Cloud

Data Science An approachable guide to creating unstructured data-driven, innovative apps in Microsoft Azure. Xiaoqian Wang August 13, 202113 min read

4 Claude Skills Every Data Scientist Needs in 2026

Agentic AI Four skills worth adding to your workflow today if you don't want to be left behind Haden Pelletier August 29, 20268 min read

AI Agents Need Their Own Desk, and Git Worktrees Give Them One

Agentic AI Git worktrees, parallel agentic coding sessions, and the setup tax you should be aware of Ruben Broekx April 18, 202617 min read

Use OpenClaw to Make a Personal AI Assistant

Agentic AI Learn how to set up OpenClaw as a personalized AI agent Eivind Kjosbakken February 17, 20269 min read

How to Build Tools for AI Agents

Agentic AI Learn how to design and build effective tools to be used by AI Agents Eivind Kjosbakken October 15, 20259 min read

The New Face of Data Governance

Data Science Data governance is dead. Here's how we can resurrect it. Louise de Leyritz February 3, 202216 min read

How to Apply Claude Code to Non-technical Tasks

Agentic AI Learn how to apply coding agents to all tasks on your computer Eivind Kjosbakken April 13, 20267 min read

Graph Engineering for AI Agents: From Prompts and Loops to Workflows

Agentic AI A viral debate over loops versus graphs points to a bigger shift in how we build AI systems. Here’s what graph engineering actually means, how it differs from prompt, context, and loop engineering, and why it matters. Nhu Hoang September 14, 202617 min read

Your home for data science and AI. The world's leading publication for data science, data analytics, data engineering, machine learning, and artificial intelligence professionals. Subscribe to Our NewsletterWrite For TDS•About•Advertise•Privacy Policy•Terms of Use © Insight Media Group, LLC 2026•The New Stack•roadmap.sh•Creator Network

Recommended Articles

Close