Understand Workflow Results
A workflow result is more than the final answer shown at the end of a run.
In RunFlows, you may also see progress updates, intermediate output, warnings, tool activity, errors, and a completion state.
Reviewing these parts helps you understand:
- what the workflow did;
- which path it followed;
- where information changed;
- whether a tool or model failed;
- whether the final result is complete; and
- whether the result is ready to use.
A workflow can complete successfully and still produce an answer that needs correction.
The main parts of a workflow result
A completed or failed run may include several types of information.
| Result part | What it tells you |
|---|---|
| Status | Whether the run is active, completed, failed, or stopped |
| Intermediate output | What an earlier step produced before the workflow ended |
| Final output | The result returned by the workflow's final path |
| Warnings | Issues that deserve attention but may not have stopped the run |
| Errors | Problems that prevented a step from completing normally |
| Tool activity | What a tool received, returned, created, or changed |
Not every workflow shows every type of result.
A simple flow may show only a final output and completion state.
Read the status first
The run status gives you a quick view of what happened.
Common states may include:
| Status | Meaning |
|---|---|
| Running | The workflow is still processing |
| Completed | The workflow reached an intended endpoint |
| Failed | A step could not complete |
| Stopped | The run ended before normal completion |
The exact wording may vary.
A completed status does not mean that every fact is correct.
It only means that the workflow reached an expected endpoint without a blocking failure.
Understand final output
Final output is the result returned at the end of the workflow path.
It may be:
- a summary;
- a table;
- a classification;
- extracted details;
- a draft;
- a generated image;
- a review message;
- a warning; or
- another structured result.
Compare the final output with the workflow's stated purpose.
A workflow named Extract Invoice Details should return invoice details, not a general summary.
Compare the result with the input
Review the output against the information you provided.
Check:
- names;
- dates;
- amounts;
- deadlines;
- decisions;
- categories;
- source references; and
- any required fields.
Look for details that were:
- changed;
- omitted;
- invented;
- repeated;
- placed in the wrong field; or
- presented more confidently than the source supports.
AI-generated output should not be accepted only because it sounds clear.
Check the expected format
A workflow may be designed to return a specific structure.
For example:
Summary
Decisions
Action Items
Unanswered Questions
Or:
| Owner | Action | Deadline |
|---|
Confirm that the result follows the expected structure.
An incorrect format can affect a later workflow step or make the output harder to review.
Understand intermediate output
Intermediate output is information shown before the final result is ready.
It may come from an Emit block or another visible step.
For example:
Input
→ Extract Details
→ Emit Extracted Details
→ Prepare Report
→ Output
In this case, RunFlows may show the extracted details before the final report.
Intermediate output can help you:
- confirm that an early step worked;
- understand how the input changed;
- see which branch was selected;
- identify missing information;
- find the first incorrect result; and
- monitor progress in a longer flow.
Do not confuse intermediate output with the final answer
Intermediate output may be incomplete.
It may contain:
- raw extracted fields;
- an early classification;
- source information;
- a temporary draft;
- progress details; or
- a result intended for the next block.
Look for the final output before deciding that the workflow is complete.
A workflow may show several useful messages during one run.
Use intermediate output for troubleshooting
When the final result is wrong, review earlier output in order.
Ask:
- Did the workflow receive the correct input?
- Did the first step return the expected result?
- Did classification or extraction work?
- Did the correct path run?
- Did the next block receive useful information?
- Where did the first unexpected result appear?
The first incorrect result is usually the best place to begin troubleshooting.
Understand warnings
A warning means the run may have completed, but something deserves review.
A warning may indicate that:
- required information was missing;
- part of the source was unclear;
- a fallback path was used;
- a tool returned incomplete information;
- an optional step failed;
- the output needs human review; or
- the workflow used a different result than expected.
Read the full warning.
Do not remove or ignore it until you understand the cause.
Understand errors
An error means a step could not complete normally.
Common causes include:
- an unavailable AI provider;
- a model that cannot be reached;
- a local model service that is not running;
- a missing Gene or tool setting;
- an invalid connection;
- unsupported input;
- missing required information;
- a timeout;
- a permission restriction; or
- an unavailable external service.
The error message may identify the block or action that failed.
Review the complete message before changing the workflow.
Find the first failure
A visible error near the end of the flow may have been caused earlier.
For example:
Input
→ Extract Details
→ Prepare Report
→ Output Error
The Output block may fail because the report step returned no result.
The report step may have failed because the extraction step returned empty fields.
Trace the flow from the beginning and identify the first unexpected result.
Fixing the earliest failure prevents later steps from receiving incorrect information.
Review tool activity
A workflow may use tools to retrieve, create, update, or save information.
RunFlows output may show:
- the tool that was used;
- the information passed to it;
- the data it returned;
- a success confirmation;
- a warning; or
- an error.
Review whether the correct tool was used for the task.
A tool can complete successfully while receiving the wrong input.
Review tool input
Check the information sent to the tool.
Depending on the action, this may include:
- a search query;
- a title;
- source text;
- a file location;
- a destination;
- an identifier;
- a date; or
- structured fields.
Confirm that the tool received only the information required for the task.
Incorrect tool input can produce an incorrect result even when the tool itself works normally.
Review tool output
Tool output may include:
- retrieved data;
- a created item;
- an updated record;
- a file path;
- a returned identifier;
- a confirmation;
- a warning; or
- an error.
Read the returned information before relying on the model's summary of it.
The model may misunderstand or omit part of a tool result.
Confirm write actions at their destination
A write action creates or changes something.
Examples include:
- creating a Journal entry;
- writing a file;
- updating a connected record;
- saving a result; or
- sending information to another service.
Confirm the outcome in its destination.
For example:
- open the Journal;
- open the saved file;
- inspect the connected service;
- check the correct record; or
- review the final saved content.
A success message is not a substitute for checking the actual result.
Avoid duplicate actions
A write action may complete even when its confirmation is delayed.
If the workflow reports a timeout or unclear failure:
- check the result destination;
- review the visible tool output;
- confirm whether the action completed; and
- retry only when you know it did not.
Repeating the run too quickly could create duplicates.
Understand branch results
A workflow may have several possible paths.
For example:
Customer Message
→ Question → Draft Answer
→ Complaint → Draft Apology
→ Other → Human Review
The output should show which path was followed through the result it returned.
Confirm that the selected path matches the input.
If the wrong result appears, review:
- the LLM Label block;
- the Expression rule;
- the category definitions;
- the branch connections; and
- any fallback route.
Review classification results
A classification result should use one of the expected labels.
Check whether:
- the label exists in the workflow;
- the input clearly fits the label;
- two labels overlap;
- an Other or Human Review path was needed; and
- the next step matches the label.
A confident label can still be wrong.
Compare it with the category definitions.
Review extracted fields
Structured extraction can look reliable because it uses named fields.
Check each field against the source.
For example:
| Field | Value |
|---|---|
| Customer Name | Alex Morgan |
| Order Number | 48321 |
| Deadline | Not provided |
Confirm that:
- every value appears in the source;
- missing fields are marked clearly;
- values were not placed in the wrong field;
- dates and amounts were preserved; and
- no missing value was guessed.
Review generated text
A draft, summary, or report should be checked for:
- factual accuracy;
- missing information;
- unsupported claims;
- tone;
- clarity;
- length;
- audience suitability; and
- requested structure.
Separate source facts from AI suggestions when both appear.
A well-written result is not automatically a verified result.
Review generated images
A workflow may return an image from a Generate Image block.
Review whether the image matches:
- the requested subject;
- the intended style;
- the composition;
- important objects;
- brand or project requirements; and
- any limits in the instruction.
Generated images can contain incorrect text, distorted details, or unexpected elements.
Review them before publishing or sharing.
Understand empty output
An empty final result can mean that:
- the Input block received no usable information;
- an earlier step returned an empty value;
- the wrong branch was followed;
- no Output block was reached;
- a tool returned no data;
- a model response was missing; or
- the workflow failed without a useful error path.
Review intermediate output and trace the flow from the beginning.
Understand partial output
A partial result may appear when one part of the workflow completed and another did not.
For example, the workflow may return a summary but fail to save it.
Or it may extract some fields but miss others.
Treat partial output as incomplete.
Confirm which steps completed and which did not.
Understand stopped runs
A stopped run ended before normal completion.
This may happen because:
- the user stopped it;
- the application closed;
- a provider became unavailable;
- a local model stopped;
- a step could not continue; or
- another interruption occurred.
Review the last visible result and determine whether any write action may already have completed.
Start a new run only after checking the earlier outcome.
Review results from cloud models
For a cloud-model step, confirm that:
- the intended provider and model were used;
- the provider returned a complete answer;
- the output follows the instruction;
- the account had access to the selected model; and
- the result is appropriate for the information sent.
If the provider returns an error, test the same model in Workbench.
This helps separate provider problems from workflow problems.
Review results from local models
Local model output depends on the selected model and available hardware.
Check whether the model:
- followed the instruction;
- handled the complete input;
- returned the expected structure;
- used tool results correctly; and
- avoided unsupported details.
Smaller local models may need:
- shorter input;
- clearer instructions;
- fewer tasks in one block; or
- a simpler output format.
Decide whether the result is ready
Before using the result, ask:
- Is it accurate?
- Is it complete?
- Does it match the source?
- Is the format correct?
- Did the correct path run?
- Did all required tools complete?
- Were warnings resolved?
- Were write actions confirmed?
- Does a person need to approve it?
If any answer is unclear, keep the result in review.
Keep human review where it matters
Human review is especially important when a workflow affects:
- customers;
- employees;
- money;
- contracts;
- legal rights;
- health;
- safety;
- security; or
- access to important services.
A workflow can prepare a result.
A person should remain responsible for important decisions and approvals.
Compare two workflow runs
Repeating the same workflow with different input can reveal whether the process is consistent.
Compare:
- the selected path;
- output structure;
- handling of missing information;
- tool behaviour;
- warnings;
- response time; and
- final quality.
Similar input should normally produce results that follow the same rules.
Unexpected variation may indicate that the instruction, label, or model needs improvement.
Record recurring problems
When the same issue appears more than once, note it.
Examples include:
- missing deadlines;
- incorrect labels;
- inconsistent tables;
- empty tool results;
- unclear warnings;
- repeated timeouts; or
- unsupported information.
Use these findings to improve the workflow in Studio.
Return to Studio when needed
Return to Studio when you need to:
- change an instruction;
- choose another model;
- change labels;
- adjust extraction fields;
- repair a connection;
- add an error route;
- improve an output format; or
- make warnings clearer.
Save and test the updated workflow before relying on it again.
A practical result-review routine
Use this routine after an important workflow run:
- Read the run status.
- Review intermediate output.
- Check which branch ran.
- Read warnings and errors.
- Review tool input and output.
- Confirm write actions at their destination.
- Compare the final output with the source.
- Check required fields and formatting.
- Decide whether human approval is needed.
- Return to Studio when the process needs improvement.
This gives you a complete view of what happened during the run.