Run Multiple Workflows

Run Multiple Workflows

Feluda can run more than one workflow at the same time.

Each run has its own status and output stream, so you can start several workflows and switch between them while they are active.

This can be useful when:

• different tasks are independent;
• several long-running workflows need to process at once;
• you want to compare results;
• one flow uses a local model while another uses a cloud model; or
• you need to continue working while another run finishes.

Running several workflows also creates more to review.

Begin with one active flow while learning RunFlows, then add more only when you can clearly identify each run and its result.

How simultaneous runs work

Every workflow execution is treated as a separate run.

Each run has:

• its own workflow name;
• its own input;
• its own status;
• its own output stream;
• its own warnings and errors; and
• its own completion result.

Starting the same workflow twice creates two separate runs.

The runs do not automatically share their input or output unless the workflow itself uses a shared file, Journal entry, account, or connected destination.

When running several workflows is useful

Multiple runs can save time when the tasks do not depend on each other.

Examples include:

• summarising several separate documents;
• running different reports;
• comparing the same input across different models;
• generating an image while a document workflow runs;
• processing several independent customer messages; or
• testing different workflow versions.

Run tasks together only when you can review each one separately.

When to run one workflow at a time

Use one active run when:

• you are learning the workflow;
• the task performs an important write action;
• two workflows use the same destination;
• your computer has limited memory;
• several flows use large local models;
• the source information is sensitive;
• the workflow is being tested; or
• the result needs careful human approval.

Simpler execution makes troubleshooting easier.

Start the first workflow

In RunFlows:

1. find the workflow;
2. select its card;
3. review its description and requirements;
4. choose Run Flow;
5. provide the requested input; and
6. start the run.

Confirm that the workflow appears in the active-runs area before starting another one.

Start another workflow

Return to the workflow list while the first run is active.

Then:

1. select the next workflow;
2. confirm that it is the correct flow;
3. provide its own input;
4. review any tool or provider requirements; and
5. start the run.

The second workflow receives its own status and output stream.

Do not reuse input accidentally when the workflows expect different information.

Switch between active runs

Use the active-run list or sidebar to move between workflow executions.

When you select a run, confirm:

• the workflow name;
• the run status;
• the starting input;
• the latest visible output; and
• whether it has completed.

Similar workflow names can make active runs difficult to distinguish.

Clear saved-flow names are especially important when several runs are open.

Pin an important run

Pin a run when you want to keep it easy to find.

This can help when:

• the workflow takes a long time;
• the result needs review;
• several other runs are active;
• you are comparing outputs; or
• an error requires investigation.

Pinning keeps the run visible.

It does not change how the workflow executes.

Unpin runs that no longer need special attention.

Give each run clear input

Before starting several workflows, prepare the input for each one.

For example:

Workflow	Input
Summarise Meeting Notes	Monday team meeting notes
Extract Contract Dates	Supplier agreement
Draft Customer Reply	Customer support message

Keep source information separate.

Copying the wrong input into the wrong workflow can produce a convincing but irrelevant result.

Check the workflow name before every run

Similar names can cause mistakes.

For example:

• Summarise Meeting Notes;
• Summarise Research Notes;
• Summarise Meeting Notes — Local Model Test.

Read the full name and description before starting.

Rename unclear or outdated workflows in Studio.

Monitor each status separately

One run may complete while another is still active.

Review each status independently.

Common states may include:

• Running;
• Completed;
• Failed; and
• Stopped.

Do not assume that all active workflows finished because one result appeared.

Switch through the active-run list and review each status.

Review each output separately

Every output belongs to a specific run.

Before accepting a result, confirm:

• which workflow produced it;
• which input was used;
• which path ran;
• whether warnings appeared;
• whether tools completed; and
• whether the result matches the source.

Do not copy output between runs until you have confirmed its source.

Compare results from different workflows

Multiple runs can help you compare:

• two models;
• two instructions;
• two versions of a workflow;
• local and cloud processing; or
• different output formats.

For a fair comparison:

1. use the same source input;
2. change only the item being tested;
3. keep the review criteria the same;
4. identify each run clearly; and
5. compare the final outputs side by side.

Avoid changing the model, instruction, input, and tools at the same time.

Compare models with separate runs

You can run similar workflows that use different models.

Compare:

• accuracy;
• instruction following;
• output structure;
• speed;
• tool behaviour;
• handling of missing information; and
• unsupported claims.

Use non-sensitive sample data during comparison.

The strongest result is the one that best meets the task, not necessarily the longest or fastest answer.

Understand shared computer resources

Several active workflows may compete for the same computer resources.

This matters especially when they use:

• local AI models;
• large models;
• image generation;
• long documents;
• several AI blocks; or
• memory-heavy applications.

You may notice:

• slower responses;
• higher memory use;
• delayed model loading;
• timeouts; or
• local model failures.

Reduce the number of simultaneous runs when your computer becomes slow or unstable.

Run multiple local-model workflows carefully

Local models use your computer's memory and processing power.

Before starting several local workflows:

• confirm the model applications are running;
• check that the required models are loaded;
• close unnecessary memory-heavy applications;
• begin with smaller models;
• monitor response time; and
• reduce simultaneous runs when errors appear.

Two workflows using the same large local model may take longer than running them one after the other.

Run cloud and local workflows together

A local-model workflow and a cloud-model workflow may run at the same time.

The local flow mainly depends on your computer.

The cloud flow also depends on:

• the internet connection;
• the provider;
• account access; and
• the selected cloud model.

Review each workflow's privacy path separately.

A local model does not make another cloud workflow local.

Avoid conflicting write actions

Two workflows may try to change the same destination.

Examples include:

• writing to the same file;
• updating the same record;
• creating the same Journal entry;
• sending to the same recipient;
• changing the same connected item; or
• saving output under the same name.

This can cause:

• duplicates;
• overwritten information;
• conflicting updates;
• unclear final state; or
• lost work.

Run these workflows one at a time unless the process has been designed and tested for shared access.

Review destinations before starting

For every workflow with a write action, confirm:

• the destination;
• the item name;
• the file path;
• the account;
• the recipient;
• the identifier; and
• whether another active workflow uses the same destination.

Use unique names when several runs create files or Journal entries.

For example:

Weekly Report — 2026-06-08

is clearer than:

Weekly Report

when several versions may be created.

Avoid duplicate runs

Before selecting Run Flow again, check whether the workflow is already active.

Repeated clicking can start another independent execution.

This may create duplicate:

• outputs;
• files;
• Journal entries;
• messages;
• tool actions; or
• updates.

Check the active-run list before restarting a slow workflow.

Handle a timeout safely

A timeout does not always mean that every action failed.

When a run times out:

1. review its last output;
2. check any tool result;
3. inspect the destination of write actions;
4. confirm whether the workflow is still active; and
5. retry only when you know the earlier action did not complete.

This is especially important when several similar runs are active.

Stop an unnecessary run

Stop a workflow when:

• the wrong input was used;
• the wrong flow was selected;
• an important destination is incorrect;
• the same run was started twice;
• the result is no longer needed; or
• continuing could cause an unwanted action.

Review any steps that already completed.

Stopping the run does not necessarily reverse an earlier tool action.

Review stopped runs

After stopping a run, check:

• the last completed step;
• intermediate output;
• tool activity;
• files or records that may have changed; and
• whether another active run depends on the same destination.

Do not assume that nothing happened before the run stopped.

Keep sensitive information separated

When several runs are active, take extra care not to mix source information.

Confirm:

• which input belongs to each run;
• which provider receives it;
• whether the model is local or cloud-based;
• which tools have access;
• where the output is saved; and
• whether any result is copied into another workflow.

Use non-sensitive test data until you understand the process.

Review every run before closing Feluda

Before closing the application, check whether any workflow is still active.

Closing Feluda may stop an on-demand run before it finishes.

Review:

• active statuses;
• incomplete outputs;
• pending write actions;
• errors; and
• results that still need approval.

Allow important runs to finish or stop them intentionally.

Keep completed runs organised

Completed runs may remain visible for review.

Pin only the runs that still matter.

Use clear workflow names so completed results remain understandable.

When an output needs long-term storage, save it in the intended destination rather than relying only on the completed-run list.

Troubleshoot one run at a time

When several workflows fail, review them separately.

For each run:

1. confirm its input;
2. read its status;
3. inspect intermediate output;
4. find the first failing step;
5. review provider and tool errors;
6. correct one issue; and
7. retest with a small sample.

Do not apply the same correction to every workflow unless the cause is confirmed.

Know when to reduce concurrency

Run fewer workflows at the same time when:

• the computer becomes slow;
• local models fail to load;
• memory use becomes too high;
• tool destinations conflict;
• outputs become difficult to track;
• repeated timeouts appear;
• sensitive inputs may be mixed; or
• human review cannot keep up.

Running tasks one after another is often safer than running everything at once.

Run multiple workflows before scheduling

Simultaneous manual runs can help test how the computer and connections behave under load.

Before scheduling workflows that may overlap:

• test them together manually;
• review memory use;
• confirm provider availability;
• check shared destinations;
• prevent duplicate names;
• make errors visible; and
• decide who reviews each result.

Workflows that conflict during manual execution should not be scheduled to overlap.

A practical multiple-run routine

Use this process:

1. Choose independent workflows.
2. Review the requirements of each flow.
3. Prepare separate input for each run.
4. Start the first workflow.
5. Confirm it appears in the active-run list.
6. Start the next workflow.
7. Pin an important long-running execution when needed.
8. Switch between runs and review each status.
9. Confirm tool destinations.
10. Review every final output separately.
11. Stop duplicate or incorrect runs.
12. Reduce simultaneous execution when resources or review become difficult.

Multiple workflows can save time.

Clear identification and careful review keep the results manageable.