Host application execution

The main purpose of Runiq workflows is to add agent and workflow capability to an existing .NET application.

The dashboard helps developers inspect and debug registered workflows, but production behavior should usually be driven by your application code: an API endpoint, background job, controller action, queue consumer, or internal service can execute a workflow through the Runiq workflow runtime.

Register the workflow

Define the workflow in C# and register it with the host application:

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

The agents used by workflow steps must also be registered in the same application host:

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

This keeps the workflow definition, agent registrations, tools, configuration, and dependency injection graph inside the product that owns the behavior.

Execute from an endpoint

Application code can resolve the registered workflow and execute it with IWorkflowExecutionRuntime.

using Runiq.Workflows;

app.MapPost("/travel-plan", async (
    TravelPlanRequest request,
    WorkflowRegistry registry,
    IWorkflowExecutionRuntime runtime,
    CancellationToken cancellationToken) =>
{
    var workflow = registry.FindById("travel-planning-workflow");

    if (workflow is null)
    {
        return Results.NotFound();
    }

    var result = await runtime.ExecuteAsync(
        workflow,
        request.Message,
        cancellationToken);

    return Results.Ok(new
    {
        status = result.Status.ToString(),
        finalOutput = result.FinalOutput,
        errorMessage = result.ErrorMessage
    });
});

public sealed record TravelPlanRequest(string Message);

In this example, /travel-plan is your application endpoint. Runiq executes the registered workflow behind that endpoint, but the route, request shape, response shape, authentication, persistence, and product behavior remain under your control.

Use the result in your application

Workflow execution returns a structured result. Your application can decide what to do with it:

• return the final output to an API caller,
• store the final output in your database,
• persist step results for audit or debugging,
• trigger a follow-up workflow or background process,
• show the result in your own product UI.

Each workflow step can produce an intermediate output. A later step receives the previous step output as input, so the application can model multi-stage behavior without putting the whole process into a single prompt.

Where this fits

Use host application execution when the workflow is part of your product.

For example:

• a support endpoint can run triage, policy lookup, and response drafting,
• an expense endpoint can run receipt extraction, policy review, and approval recommendation,
• an operations job can run incident analysis, remediation planning, and summary generation,
• a travel feature can run weather, places, and planning steps before returning a final itinerary.

The dashboard is useful for development-time inspection. The application runtime is where the workflow becomes a real product capability.