Overview

Runiq Workflows give agent systems a deterministic execution path.

Single-agent systems are flexible, but many product features need more than flexibility. They need a known sequence, clear ownership of each step, repeatable behavior, failure rules, and output that can be inspected stage by stage. If you push all of that into one large prompt, the system becomes difficult to test and even harder to debug.

Workflows let .NET developers keep orchestration in application code. You can split a feature into focused agents, define the order in C#, decide what happens on success or failure, and inspect each step in Studio. The model still handles language and reasoning inside each agent, but the application owns the process.

Why workflows matter

Some AI features need a known order because the product behavior itself is ordered.

For example, a travel planner can run weather analysis, place research, and final itinerary planning as separate agent steps. This sample is not meant to be a travel product blueprint. It is a compact way to show what happens when application code owns a business process and agents fill in the reasoning-heavy parts. The workflow owns the order. Each agent owns one responsibility.

The same pattern applies outside travel:

Text

support triage -> policy check -> response writer
expense lookup -> policy review -> manager summary
incident timeline -> impact analysis -> follow-up plan
requirements intake -> risk review -> implementation brief

The framework feature is deterministic orchestration. Travel planning is only one sample domain. The same value shows up anywhere the business process matters as much as the final answer: support teams can preserve escalation rules, finance teams can preserve approval order, and developer platforms can expose existing .NET services through focused agent steps without turning the whole feature into one prompt.

Workflow vs agent

Use an agent when	Use a workflow when
One AI component can handle the task.	The app should control multiple steps.
The model should decide the approach.	The execution order must be repeatable.
The output can be produced in one run.	Intermediate outputs should feed later steps.
Tool use is enough structure.	Success and failure paths matter.

Runtime model

Part	Purpose
`Workflow`	Registered definition with id, name, and ordered steps.
`WorkflowStep`	A step that executes a registered agent type.
Success transition	The next step to run after success.
Failure behavior	Stop, continue, or go to a fallback step.
Workflow runtime	Validates and executes the workflow.
Dashboard metadata	Shows workflow id, name, start step, steps, and transitions.

Execution flow

Step	What happens
1	The application or dashboard starts a registered workflow with input.
2	Runiq validates the workflow structure.
3	The runtime resolves the first step's registered agent by type.
4	The agent runs through the normal Runiq agent runtime.
5	The step output becomes the input to the next successful step.
6	On failure, the workflow applies the step's configured failure behavior.
7	The final output is the output of the last completed step.

Workflows do not replace agents or tools. They coordinate them.

Dashboard example

The workflow detail view makes the application-owned execution path visible. In the sample, weather, places, and planner are domain examples; in a production system, these nodes would usually map to the stages your product already understands, such as triage, policy review, approval, or response generation.