Hybrid AI: Combining Deterministic Analytics with LLM Reasoning

Introduction

an agentic AI community for my firm that advises manufacturing crops on how you can mature their operations. The system was designed to be data-driven, permitting customers to add evaluation information straight by the chat interface. The primary working prototype was completed surprisingly rapidly, and at first look the outcomes appeared promising.

There was just one downside: A lot of the outcomes had been flawed!

Even worse, the AI rapidly discovered which numerical ranges appeared believable and started producing convincing — however fabricated — outputs. Mixed with the eloquent language era of the LLM, these outcomes might simply be mistaken for fact. And this habits was not restricted to a single mannequin. Comparable patterns appeared throughout all examined techniques: ChatGPT, Gemini Enterprise, DIA Mind, and Microsoft Copilot.

However, believable information will not be sufficient, Enterprise AI techniques require dependable information!

Additional investigation revealed recurring failure modes. Even with “Code Interpreter” enabled, the techniques:

• skipped rows or columns,
• utilized incorrect filters,
• returned an identical outcomes for various inputs,
• silently combined components of the dataset,
• or just collapsed below extra advanced analytical duties.

This led to an important realization:

Probabilistic reasoning is extraordinarily highly effective for interpretation and interplay — however foundational information evaluation requires deterministic execution.

Desk of contents

1 The Use Case
2 The Hybrid Structure
3 The Evaluation Planner
4 The Evaluation Engine
5 An Finish-to-Finish instance
6 Why AI Structure Issues

1 The Use Case

Though the precise use case is of secondary significance, it’s briefly outlined right here to assist the sensible understanding of the underlying architectural problem.

The first job of our agent is to advise manufacturing crops and worth streams on how you can enhance their operational maturity: optimizing processes, enhancing productiveness, lowering stock ranges, and in the end reducing operational prices. To realize this, the session agent operates in two modes:

1. It gives generic suggestions for enhancing particular operational matters based mostly on the retrieval of specialised “how-to” documentation and evaluation questionnaires.
2. The agent is meant to research the present scenario of a plant or worth stream based mostly on evaluation outcomes and assessors’ written suggestions. Primarily based on this evaluation, it’s anticipated to offer extremely particular suggestions for the subsequent enchancment steps.

In each modes — as with most LLM-based AI fashions — the consumer can interactively talk about concepts and suggestions with the agent with a purpose to derive essentially the most appropriate motion plan.

For the second operation mode, it’s important that the agent can reliably course of and analyze evaluation information. In our case, this information is supplied as an Excel export from a central database. Ideally, the agent ought to have the ability to course of the file with none prior handbook preparation.

The construction of the file, nevertheless, is difficult. Since all evaluation outcomes, intermediate calculations, metadata, and detailed evaluation questions are saved in separate columns, the worksheet accommodates greater than 800 columns. The variety of rows corresponds to the variety of assessments within the database and may vary from one to a number of a whole lot (Fig. 1). Evaluation rankings are represented as integers from 0 to 4. As well as, the file accommodates greater than 160 free-text fields with qualitative observations, strengths, weaknesses, and suggestions from the assessors.

The analytical duties of the agent embody filtering related rows and columns for a selected request, calculating averages, aggregating maturity scores, summarizing textual suggestions, and deriving significant enchancment recommendations from the outcomes.

Initially, these duties gave the impression to be nicely inside the capabilities of recent LLM-based AI techniques, particularly with “Code interpreter” mode enabled. As already talked about within the introduction, this assumption rapidly turned out to be a false impression.

2 The Hybrid Structure

The core concept for overcoming the analytical problem was to obviously separate deterministic information evaluation from LLM-based reasoning and interpretation. Fig. 2 exhibits the chosen system structure after a number of enchancment iterations. The system was applied in Microsoft Copilot Studio as a result of the platform permits deterministic workflow parts, equivalent to matters and flows, to be mixed with LLM-based reasoning elements.

The dad or mum agent handles all communication with the consumer. It orchestrates the sub brokers and the analytics module, delegates duties to them, receives their responses, and composes the ultimate reply.

The sub brokers are specialised LLM-based modules with entry to particular information sources. These embody descriptions of maturity-level expectations for the worth streams, questionnaires with detailed evaluation questions, and extra normal pointers for operational excellence. The sub brokers are referred to as by the dad or mum agent in line with their particular capabilities and reply to the dad or mum agent slightly than on to the consumer.

The analytics module is the principle focus of this text. It performs the deterministic information evaluation and is designed to offer reproducible and dependable analytical outcomes. It receives an evaluation instruction in pure language from the dad or mum agent, known as Parent_Instruction. The analytics module itself consists of matters, flows, and AI modules, that are referred to as “prompts” in Copilot Studio.

The subject T_receive_Excel_File handles the add and storage of evaluation recordsdata. It’s triggered when a file is uploaded within the chat window, indicated by the variable System.Exercise.Attachments having a price. The subject checks whether or not the uploaded file is an Excel file and, if that’s the case, shops it within the international variable Assessment_File.

The subject T_analyze_assessments is actively referred to as by the dad or mum agent if it has an analytics job to conduct and receives Parent_Instruction as enter. A second enter is the evaluation information saved within the international variable Assessment_File. The subject accommodates the 2 core analytics elements: Analysis_Planner and Analysis_Engine. Each are embedded in agentic flows, F_Call_Analysis_Planner and F_Call_Analysis_Engine. These flows function connectors between the subject T_analyze_assessments and the AI prompts P_Analysis_Planner and P_Analysis_Engine.

F_Call_Analysis_Planner receives just one enter, Parent_Instruction, and forwards it to P_Analysis_Planner. This element generates the Selection_Rule, the core evaluation instruction to be executed by P_Analysis_Engine. The internal workings of P_Analysis_Planner are mentioned in Chapter 3.

F_Call_Analysis_Engine receives three inputs: the Selection_Rule from Analysis_Planner, a Mapping_File supplied from SharePoint, and the Assessment_File. All three inputs are forwarded to the AI immediate P_Analysis_Engine, which conducts the info evaluation as specified by Analysis_Planner. The P_Analysis_Engine is mentioned intimately in Chapter 4.

3 The Evaluation Planner

The P_Analysis_Planner is the clever a part of the info evaluation pipeline and generates the evaluation instruction, referred to as Selection_Rule. This instruction is a translation of the pure language Parent_Instruction and is mostly distinctive for every request. To be able to reduce probabilistic variation, the interpretation course of is constrained by strict guidelines.

The Analysis_Planner doesn’t analyze the evaluation information itself. Its sole accountability is to translate the probabilistic Parent_Instruction right into a deterministic evaluation specification.

Within the following, we are going to study chosen components of the instruction in additional element. You may obtain the total instruction right here.

You might be Analysis_Planner, an skilled assistant for translating natural-language evaluation evaluation requests into structured Selection_Rules.
Your job is to create a Selection_Rule JSON object for the Analysis_Engine.

You obtain just one enter:

1. Parent_Instruction :
A natural-language evaluation request from the dad or mum agent (orchestrator).

It's essential to analyze Parent_Instruction and decide:
- which sort of study is required,
- which evaluation content material classes are related,
- whether or not idea or execution maturity/findings are requested,
- whether or not particular chapters are requested,
- and whether or not row filters are required.

The Selection_Rule you generate will later be utilized by the Analysis_Engine along with:
- the actual evaluation information file,
- and the Mapping_File
to execute the evaluation deterministically.

The code field above exhibits the preliminary instruction for P_Analysis_Planner. It clearly defines goal and scope and explicitly separates planning from execution. The planner interprets the request, whereas the precise execution is delegated to the P_Analysis_Engine.

Subsequent follows an extended part describing the semantics of the evaluation information. In fact, this half is extremely particular to the person use case and dataset. It defines semantic classes used for row filtering and classes used to pick out the precise evaluation targets (TARGET CONTENT CATEGORIES and TARGET SELECTION ATTRIBUTES).

ASSESSMENT DATA SEMANTICS

The evaluation information could be addressed by the next semantic classes.

ROW FILTER CATEGORIES

Use these classes just for row_filters:

- VS_Nr:
    Distinctive identifier of the worth stream.
    Use when filtering by worth stream quantity.

- Worth Stream:
    Identify of the worth stream.
    Use when filtering by worth stream title.

- ...

TARGET CONTENT CATEGORIES

Use these classes solely in target_selection_rules.data_category:

- chapter_score:
    Numeric maturity rating.
    Use for maturity calculations, rating evaluation, and common maturity evaluation.

- energy:
    Assessor statements describing strengths.

- ...

TARGET SELECTION ATTRIBUTES

Use these attributes solely inside target_selection_rules:

- data_category:
    Defines which goal content material class is required.

- aggregation_allowed:
    Use:
        - imply for numeric maturity averages
        - abstract for textual summaries

- ...

The planner by no means interacts straight with bodily dataset columns. As a substitute, it operates on a semantic abstraction layer that decouples pure language from the underlying dataset construction.

This separation is vital as a result of the evaluation dataset accommodates greater than 800 columns, together with:

• maturity rankings,
• textual assessor findings,
• metadata,
• organizational mappings,
• questionnaire variants,
• and idea/execution distinctions.

Deciding on the proper goal columns due to this fact turns into a essential a part of the evaluation course of.

Proscribing the allowed evaluation varieties is equally vital. The planner is deliberately prevented from inventing arbitrary analytical operations. The part ANALYSIS TYPES due to this fact defines the one legitimate evaluation varieties — presently simply two. This considerably improves the predictability and robustness of downstream execution. In fact, the listing can simply be prolonged for particular person use circumstances.

ANALYSIS TYPES

Use precisely one in every of these analysis_type values:

- numeric_mean
    Use for:
    - common maturity
    - imply maturity
    - ...

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

The following part defines how the planner selects the related goal columns in an summary and deterministic method. The principles distinguish between the 2 predefined evaluation varieties numeric_mean and text_summary and at last decide which dataset columns are chosen for a selected request.

RULES FOR target_selection_rules

NUMERIC MATURITY ANALYSIS

For numeric maturity evaluation:
- analysis_type have to be:
    "numeric_mean"
- data_category have to be:
    ["chapter_score"]
- ...

TEXT SUMMARY ANALYSIS

For textual abstract evaluation:
- analysis_type have to be:
    "text_summary"
- data_category:
    embody solely requested classes:
        - "energy"
        - "potential"
        - "advice"
        - "comment"
- ...

An identical logic applies to the row filtering course of.

RULES FOR row_filters

Use row_filters just for filtering rows within the evaluation dataset.

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

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

These belong solely to target_selection_rules.

Lastly, the instruction defines the required output construction along with a number of strict “do-not guidelines”. This part is especially vital as a result of the generated output is straight forwarded to the P_Analysis_Engine and due to this fact should comply with a clearly outlined and machine-readable construction.

OUTPUT FORMAT

Return solely legitimate JSON.
Don't return markdown.
Don't return Python code.
...

Use precisely this construction:

{
  "standing": "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 should explicitly return an error construction as a substitute of “guessing” a probably flawed evaluation instruction.

If the duty is unclear, return:

{
  "standing": "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 level, the planner has reworked ambiguous pure language right into a deterministic evaluation specification. Nevertheless, the precise information execution nonetheless has not occurred.

In chapter 5, we are going to comply with an actual consumer request by the entire pipeline and study how P_Analysis_Planner generates the Selection_Rule and the way P_Analysis_Engine executes it on the evaluation dataset.

4 The Evaluation Engine

Not like the P_Analysis_Planner, the P_Analysis_Engine doesn’t purpose in regards to the job. It solely executes the evaluation specification generated by P_Analysis_Planner.

As in chapter 3, we are going to focus solely on essentially the most related components of the instruction. The complete specification could be downloaded right here.

The instruction of P_Analysis_Engine begins with the essential job definition. In essence, the AI immediate is used as a managed Python execution atmosphere. The code is predefined within the immediate instruction and should solely be executed, not modified.

You might be Analysis_Engine, a deterministic pandas-based evaluation executor.

Your job is to research an Excel evaluation dataset utilizing Code Interpreter.

You obtain three inputs:

1. doc 
   The Excel file containing the evaluation information.

2. Mapping_File 
   The Excel file describing the columns of doc.

3. Selection_Rule 
   A JSON object that defines:
   - which columns to pick out from Mapping_File
   - which row filters to use to doc
   - which sort of study to carry out

It's essential to not reinterpret the unique consumer request.
It's essential to not infer extra columns.
It's essential to not change Selection_Rule.
It's essential to not generate a brand new evaluation strategy.
It's essential to solely execute the deterministic Python script beneath.

Use Code Interpreter to execute the Python script.
Return solely the JSON end result printed by the script.
Don't return markdown.
Don't clarify the code.
Don't add textual content earlier than or after the JSON end result.

P_Analysis_Engine receives three enter recordsdata:

1. The Assessment_File uploaded from the consumer within the chat interface. It’s saved within the prompt-internal variable doc.
2. A Mapping_File which the movement F_Call_Analysis_Engine masses from SharePoint in preparation of the execution.
3. The Selection_Rule generated by P_Analysis_Planner (see chapter 3).

The Mapping_File performs an important function in defining the semantics of the numerous columns in Assessment_File on a better stage of abstraction. With this abstraction layer, the Selection_Rule solely must specify which sort of knowledge is required, whereas the P_Analysis_Engine selects the corresponding dataset columns throughout execution.

Fig. 3 exhibits the construction of Mapping_File. It accommodates a row for every column of Assessment_File, that’s probably related for the info evaluation. Knowledge columns which might be clearly irrelevant should not represented in Mapping_File and due to this fact should not seen to P_Analysis_Engine. For every row the file specifies the choice standards:

• data_category: 
  Practical that means of the column, e.g. maturity rating, energy, plant title, area, or season.
• chapter_id:
  Distinctive identifier of the evaluation chapter.
• chapter_name:
  Human-readable title of the evaluation chapter.
• concept_execution:
  Signifies whether or not the column belongs to idea or execution maturity.
• aggregation_allowed:
  Defines which sort of aggregation is legitimate for the column, e.g. imply for numeric maturity scores or abstract for textual findings.

Subsequent in P_Analysis_Engine’s instruction comes a paragraph about how you can interpret the Selection_Rule.

Guidelines for Selection_Rule:

- analysis_type = "numeric_mean":
  Calculate arithmetic means for all chosen numeric goal columns.

- analysis_type = "text_summary":
  Acquire non-empty textual content entries from all chosen textual content goal columns.

- target_selection_rules:
  Choose goal columns by matching Mapping_File attributes.
  A rule worth of null means: don't filter by this attribute.
  A listing means: preserve rows the place the Mapping_File attribute is within the listing.

- row_filters:
  Apply row filters to doc.
  Keys are data_category values from Mapping_File, equivalent to "Plant", "Area", "Manufacturing Precept", "Season".
  Values are lists of accepted values.

The choice specifies:

• which evaluation operation have to be executed (analysis_type),
• how related goal columns are chosen from the Mapping_File (target_selection_rules),
• and the way the evaluation dataset is filtered earlier than the evaluation is carried out (row_filters).

This instruction is deliberately deterministic. The P_Analysis_Engine will not be allowed to reinterpret the unique consumer request or invent extra analytical operations.

After the instruction block, the P_Analysis_Engine receives the precise Python script. The complete script accommodates greater than 300 traces of code and is a part of the AI immediate instruction. It’s linked on the high of this chapter and could be downloaded. Most of the code traces should not conceptually vital for the structure. They deal with sensible robustness: cleansing column names, normalizing enter values, dealing with lacking columns, changing Copilot wrapper objects, and returning structured error messages.

For the article, I’ll focus solely on the central logic.

The primary vital step is that the engine masses the uploaded evaluation information (now obtainable in doc) and the Mapping_File. From this level on, the LLM is not deciphering the consumer request. It solely executes the deterministic script based mostly on the Selection_Rule.

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

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

The important thing architectural ingredient is the choice of goal columns. The P_Analysis_Engine by no means guesses which Excel columns could also be related. As a substitute, it filters the Mapping_File in line with the attributes outlined in target_selection_rules.

target_mapping = mapping_df.copy()

for attr, rule_value in target_selection_rules.gadgets():

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

    if values is None:
        proceed

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

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

That is the purpose the place the summary evaluation instruction turns into concrete. For instance, a rule equivalent to chapter_id = ["3.5"], data_category = ["chapter_score"], and aggregation_allowed = ["mean"] is translated into the precise Excel columns containing the Idea and Execution maturity scores for chapter 3.5.

The identical precept is utilized to row filters. Once more, the engine doesn’t infer something from pure language. It solely applies the filters explicitly supplied within the Selection_Rule.

filtered_df = data_df.copy()

for filter_category, filter_values in row_filters.gadgets():

    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 choice and row filtering, the precise evaluation logic turns into deliberately simple. For numeric maturity evaluation, the engine calculates arithmetic means for all chosen numeric goal columns.

if analysis_type == "numeric_mean":

    numeric_result = {}

    for col in available_target_columns:

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

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

    end result["result"] = numeric_result

For textual evaluation, the engine collects non-empty assessor statements as a substitute of calculating values.

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)
        }

    end result["result"] = text_result

Lastly, the result’s returned as JSON. That is vital as a result of the output will not be but the ultimate user-facing reply. It’s the dependable analytical basis for the subsequent LLM step: interpretation from dad or mum agent.

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

This design intentionally retains the P_Analysis_Engine “boring”. It doesn’t purpose, it doesn’t clarify, and it doesn’t enhance the evaluation. It solely executes. And that’s precisely the purpose. The extra deterministic this layer is, the extra belief could be positioned within the later LLM-generated interpretation.

5 Finish-to-Finish Instance

As an example the entire workflow, allow us to comply with a practical instance by the total pipeline.

Triggered by the consumer interplay, the dad or mum agent would possibly elevate the next Parent_Instruction to the analytics module:

“Summarize the principle enchancment potentials for chapter 1.4 Failure Prevention System in plant AbcP.”

The request seems easy for a human reader, however it already accommodates a number of semantic duties:

• establish the requested evaluation chapters,
• detect the requested content material sort,
• apply a row filter,
• retrieve the proper textual content columns,
• mixture textual findings,
• and at last generate a significant interpretation ( → dad or mum agent).

That is precisely the kind of job the place a pure LLM-based evaluation turns into unreliable. The system due to this fact separates the workflow into deterministic execution steps and probabilistic interpretation steps.

5.1 Translation from Evaluation Planner

Step one is carried out by P_Analysis_Planner.
 It interprets the pure language request right into a deterministic Selection_Rule.

{
  "standing": "success",
  "parent_instruction_summary": "Summarize enchancment 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 accommodates the entire deterministic evaluation specification:

• analysis_type = "text_summary"
  signifies that textual assessor findings have to be collected as a substitute of numeric calculations.
• data_category = ["potential"]
  restricts the evaluation to enchancment potentials.
• chapter_id = ["1.4"]
  limits the evaluation to the Failure Prevention System chapter.
• row_filters = {"Plant": ["AbcP"]}
  restricts the dataset to the requested plant.

At this stage, no information evaluation has occurred but. The result’s solely an execution instruction for the subsequent step.

5.2 Execution from Evaluation Engine

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

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

This interprets the summary choice standards into actual dataset columns, for instance:

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"
]

Subsequent, the row filters are utilized:

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

On this instance, the dataset is diminished to evaluation rows belonging to plant AbcP.

Lastly, the engine collects all non-empty textual content entries from the chosen columns.

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 will see, the engine doesn’t interpret the findings. It solely retrieves and constructions them in line with the Python script.

The engine’s output is a set of assessors’ written statements in regards to the values stream’s enchancment potentials as a JSON object.

{
  "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 level, the system has nonetheless not generated any suggestions. It has solely produced a dependable assortment of related evaluation findings. This JSON object is returned to the dad or mum agent for interpretation and era of the ultimate response to the consumer.

5.3 Interpretation from Dad or mum Agent

Within the ultimate step, the dad or mum agent collects all responses (probably extra responses from the sub brokers) and generates the ultimate output.

The collected findings point out that the Failure Prevention System is
presently extra reactive than preventive. Most gaps are associated to lacking
systematic root-cause administration and weak organizational studying throughout
shifts and groups. The very best leverage enhancements would doubtless come from
strengthening escalation routines, integrating preventive upkeep findings
into CIP actions, and establishing constant cross-shift studying
mechanisms.

To summarize the central architectural concept of the system:

The LLM not creates the analytical basis itself. As a substitute, it interprets a deterministic set of already validated findings.

The probabilistic reasoning functionality of the LLM is used the place it creates worth: interpretation, prioritization, clarification, and communication — not information processing itself.

6 Why AI Structure Issues

Massive Language Fashions are naturally robust at interpretation, reasoning, and language era, however nonetheless weak at dependable numerical analytics. Their optimization goal is plausibility, not deterministic reproducibility. Even with extensions equivalent to “Code Interpreter”, this weak point stays seen in additional advanced analytical situations.

The excellent news is that this limitation can largely be compensated by clever system structure. The secret’s a transparent separation of obligations: deterministic data-processing layers execute the analytical basis, whereas LLMs give attention to interpretation, prioritization, clarification, and communication.

Within the offered strategy, crucial design choice was due to this fact not including extra AI to the system. It was defining very fastidiously the place probabilistic reasoning ought to finish and deterministic execution ought to start.

Dependable agentic techniques will doubtless require precisely these sorts of hybrid architectures: combining the robustness of classical information science pipelines with the inference capabilities of Massive Language Fashions.