Patterns

Keep workflows close to the process they coordinate.

For a real application, create a Workflows folder and put each deterministic execution path in its own file. Agents stay in Agents/. Tools stay in Tools/. Program.cs registers them.

Recommended project layout

MyApp/
  Program.cs
  Agents/
    TriageAgent.cs
    PolicyCheckAgent.cs
    ResponseWriterAgent.cs
  Tools/
    CustomerLookupTool.cs
    CreateTicketTool.cs
  Workflows/
    SupportResolutionWorkflow.cs

For the travel sample:

Runiq.WorkflowTravelPlanner/
  Agents/
    WeatherAgent.cs
    PlacesAgent.cs
    PlannerAgent.cs
  Tools/
    WeatherTool.cs
    PlacesTool.cs
    MealSuggestionTool.cs
  Workflows/
    TravelPlanningWorkflow.cs

Travel is only the sample domain. The pattern is deterministic orchestration of specialized agents. A company can keep its existing .NET services, repositories, and policies where they already live, then expose selected capabilities through tools and route them through workflow steps.

Keep Program.cs small

builder.Services.AddRuniqServer(options =>
{
    options.AddAgent(WeatherAgent.Create(openAiApiKey));
    options.AddAgent(PlacesAgent.Create(openAiApiKey));
    options.AddAgent(PlannerAgent.Create(openAiApiKey));
});

builder.Services.AddRuniqWorkflows(options =>
{
    options.AddWorkflow(TravelPlanningWorkflow.Create());
});

The agent files define behavior. The workflow file defines order. Program.cs only registers runtime components.

That separation is useful when AI is added to an existing application. The workflow does not need to become a new product layer; it can coordinate the application services the team already trusts, with each agent responsible for one stage of interpretation or synthesis.

Use workflows for product-owned order

Do not use a workflow just because multiple agents exist. Use it when your product needs a repeatable sequence.

Good workflow fits:

support triage -> policy check -> final response
document extraction -> risk review -> summary
expense lookup -> policy analysis -> approval recommendation
weather context -> place context -> itinerary planner

If the model should freely decide the whole approach, a single agent with tools may be enough. If the application owns the order, use a workflow.

In the travel sample, the order is weather, places, then planner. In a real product, the order might be customer lookup, entitlement check, policy review, and response writer. The key is that the framework lets the product keep that order explicit while still using agents where natural language reasoning adds value.

Keep steps focused

Each step should have a clear output that helps the next step.

Weather Agent should not create the final itinerary. Places Agent should not own meal planning. Planner Agent should synthesize prior context into the final answer.

The same applies to other domains. A policy-check agent should produce policy findings. A response-writer agent should write the final customer-safe message.

Common mistakes

Putting workflow definitions inline in Program.cs makes startup code hard to read. Put workflow definitions in Workflows/*.cs.

Using one large agent instead of a workflow makes repeatability harder when the product needs known stages.

Using workflows for every request can add unnecessary structure. Keep simple tasks as single-agent runs.

Forgetting to register the agent types referenced by workflow steps causes runtime resolution failures.

Ignoring failure behavior makes product behavior unclear. Decide which steps are required and which steps can be skipped or routed to fallback.