Main Workflow
29/04/2026
The Main workflow has four stages, some of which have subsections. Each flows into the next to add up to the complete workflow. These stages are described in more detail below after this brief overview.
Pre-processing:
Input Guardrails
Data Gathering
Short-term memory
Parallel Steps
Main Answer
Post-answer processing
Parallel steps
Business logic is separated into different sub-workflows to avoid having a very large single workflow. Each stage of the main workflow calls the sub-orchestrator.
In this workflow you can also see the approach used to send SSE messages. This typically involves a pair of Build and Send nodes accompanied by a colored sticky note and a description, as shown in the example below, where the sticky note is a purple rectangle labeled "Introspection message" :
 |
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: either proceed to data gathering or reject the question if the guardrails detected something inappropriate.
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. Once it gets additional question context by taking into account all previous questions and answers of the current conversation, it moves on to all the subsequent parallel steps.
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. The following three screenshots illustrate this workflow.
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_DATAdata 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.
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.
As you can see from the screenshot, 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
stepTagJSON property in "prepare input data"; this drives SSE message generationThird node (optional but typical): call Configuration workflow for connection configs
End with two paths (success / failure), each writing results to the
PARALLEL_DATA_SYNCdata table
This is the third pipeline stage. Step - Final Answer - Syn prepares input data from all gathered data context and calls the LLM to generate the final answer.
That is how the invocation looks in the Main workflow:
 |
The workflow itself -- Step - Final Answer - Sync is quite straightforward:
 |
It prepares the input data for the final answer and calls the LLM model.
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 followup steps and merges the results.
Note
The Output Guardrails step is mandatory and cannot be disabled.
This is the second phase — collecting data:
 |
Again, 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.