Main Workflow

02/07/2026

GraphRAG version 1.2.0

The Main workflow is used as an orchestrator. This workflow receives the actual request for an answer, along with all required information, and orchestrates all the business logic to answer the question. The following shows the main workflow:

Pre-processing:
1. Input Guardrails
Data Gathering
1. Short-term memory
2. Parallel Steps
Main Answer
Post-answer processing
1. Parallel steps

To avoid having a large single workflow, we separate different business logic into different sub-workflows. From the main workflow, we call the sub-orchestrator for each stage.

In this workflow you can also see the approach used to send SSE messages. Typically, this involves a pair of Build and Send nodes accompanied by a colored sticky note and a description, as shown in the example below:

Input guardrails are the most important pre-processing step. They check for input such as prompt injection attempts (for example, "ignore instructions" or "forget rules"), malicious content such as hate speech or encouragement of illegal activity, and requests for unrelated external advice such as medical advice unrelated to system scope. The input guardrails sub-workflow also forward data to use as explainability messages for use as needed.

The Main workflow invokes input guardrails and then branches execution based on the result: proceed to data gathering or reject the question.

The logic is split across two workflows:

Step - Input Guardrails - Main: Orchestrator: Processes the LLM result, calculates token usage, and handles errors.

The sticky note description of Input Guardrail tests in workflow shows how a normal query will be approved and sent along in the workflow and inappropriate queries such as those containing prompt injection or personally identifiable information will be rejected.

The workflow nodes will check whether the input passed the guardrail tests. If it did, the workflow builds explainability messages to pass along to further steps; if not, it creates messages about the failure for further steps to use. The workflow also has a loop to keep checking for input until a timeout threshold is reached.

Step - Input Guardrails - Sync: Contains the actual guardrails rule logic. The list on the screenshot shows several of the data fields that are stored and passed along such as whether the guardrails passed or not, the level of risk, and a human-readable summary of why the guardrails were triggered.

This step is responsible for preparing the short-term memory, i.e., the context of the current conversation. It is not part of the data gathering stage, because some of those steps require short-term memory as input.

Below you can see its invocation from the main workflow. It shows how the workflow uses both local data for context and, if available, context data from the LLM. It also creates explainability messages to pass along if requested by the user.

Implementation is in Step - Short-term memory - Sync. It collects all Q&A pairs from the current conversation and then either uses them as-is or applies compression.

Default behavior: LLM compression is applied if the total size exceeds the shortMemoryMaxUncompressedSizeInTokens threshold. The token count is estimated as string length ÷ 3.

Alternatives: Sliding window or other custom approaches can replace the default.

This stage collects all required data as fast as possible by running steps in parallel.

Below you can see the invocation from the main workflow:

The orchestrator is Parallel - Main, which has two phases.

Phase 1 — Start steps asynchronously: A sequence of similar blocks, each checking an activation flag and starting a step. To disable a step, turn its flag OFF in the corresponding Activate [Step Name] code node.
Phase 2 — Collect results (sync): A loop checking the PARALLEL_SYNC_DATA data table for completed steps. If the configured timeout expires before all steps finish, processing continues with whatever data was gathered.

Results are batched via Parallel - Steps Batching and SSE messages sent via Parallel - Steps Messaging, which encapsulates step-specific message formatting logic.

Phase 1 is comprised of the following five sub-workflows:

Concept Expansion, also known as inference tagging, enables augmentation of the list of originally extracted concepts based on an expansion query. It goes beyond explicit concepts by using existing datasets and specified rules to derive new information from implicit document concepts. It also leverages ontologies and rules to reveal hidden relationships, enabling interpretation, conclusions and predictions.

First, set the flag to indicate whether this step should be active. Then, increment the counter for the starting steps and begin the actual step.If any steps are not required, simply turn the flag OFF in the corresponding “Activate [Step Name]” code node.

Set the flag to indicate whether this step should be active; then, increment the counter for the starting steps and begin the actual step.

Should any steps be not required, simply turn the flag OFF in the corresponding Activate [Step Name] code node.

Phase 2, which involves collecting all results, appears as follows:

The main body of the workflow is a loop that checks the PARALLEL_SYNC_DATA data table for completed steps. The beginning of the loop checks whether all the data has been collected and, if so, passes control to the end of the phase where the data is collected and passed along. If it has not all been collected, the workflow uses Check timeout and Is timeouted nodes to check whether the predefined time period has elapsed. If not, the lower part of the workflow shows how the workflow prepares table results and performs other cleanup duties before looping back to once more Check all data is collected and continues with the loop.

When all steps are completed, the gathered data is returned to the main workflow.

In this loop we call another workflow: Parallel - Steps Batching. This workflow is responsible for taking the collected data and orchestrating the sending of the corresponding SSE messages.

It loops over an array of steps and calls the Parallel - Steps Messaging workflow to send the corresponding SSE message. It encapsulates the per-step specific logic of what and how to send. The screenshot below only shows a few of the steps that might be run in parallel (Query Understanding, Concept Enrichment, and Concept Expansion); other choices that will appear below those in the GraphRAG interface are Short-term Memory, Vector Retrieval, and the GraphDB MCP Tool.

It encapsulates the per-step specific logic of what and how to send. As you can see from the screenshot above, different steps might generate different messages.

Adding a New Parallel Step

All parallel steps share common characteristics:

Naming convention: Step - [short desc] - Async
Trigger: webhook with Respond = "Immediately" and Path = "internal/[desc]" ("internal" prefix required)
First node after webhook: "prepare input data" code node (used by error handling to extract input data)
Check the stepTag JSON property in "prepare input data"; this drives SSE message generation
Third node (optional but typical): call Configuration workflow for connection configs
End with two paths (success / failure), each writing results to the PARALLEL_DATA_SYNC data table

The fourth and final stage is orchestrated by Parallel Post Final Answer - Main, which follows the same pattern as the data-gathering parallel framework.

The main orchestrator of this stage is the Parallel Post Final Answer - Main workflow.

It should already look familiar because it is based on the same concept as the Parallel - Main workflow.

We can again separate it into four phases:

Start all post-answer steps (answer concept enrichment, follow-up generation, output guardrails).
Collect results from PARALLEL_SYNC_DATA.
Check output guardrails – if failed, abort; if passed, continue.
Send all remaining SSE messages (answer, sources, concepts, follow-ups, token usage).

This is the first phase – starting the steps. Output Guardrails checks that the output doesn't break any rules, Answer Concept Details uses the Concept Enricher to identify extracted and extended concepts that will make the text input richer, and Follow up performs any activated follow up steps and merges the results.

Note

Optional Guardrails is not optional, it does not have an activate/deactivate option.

Note

The Output Guardrails step is mandatory and cannot be disabled.

This is the second phase - collecting data:

It is basically a loop over the PARALLEL_SYNC_DATA data table.

Here we have an additional phase - checking output guardrails:

The main task of this phase is to verify that the generated answer is a good answer, does not contain any hallucinations, and can be presented to the end user.

The last phase is to send all corresponding SSE messages. This workflow loops through the explainability messages and final answer messages that are delivered to it and prepares explainability and follow-up messages for delivery. Processing of explainability messages also includes the generation and delivery of concept messages:

Again, the “per-type” approach is used here.

In this section: