.NET: [Bug]: AddWorkflow uses AddKeyedSingleton for Workflow instances, causing TakeOwnership conflicts for parallel runs

[nC-LBR8]

Description

When using AddWorkflow from Microsoft.Agents.AI.Hosting.HostApplicationBuilderWorkflowExtensions, the framework registers workflows via AddKeyedSingleton. This causes fundamental issues when running multiple workflow executions in parallel for the same workflow key.

The core problem is that Workflow is a stateful, non-reentrant runtime object, but is treated as a singleton definition in DI. This leads to ownership conflicts at runtime.

Observed Behavior

When multiple requests (e.g. in an ASP.NET Core application) attempt to start the same workflow key concurrently, the following exception is thrown:

InvalidOperationException:
Cannot use a Workflow that is already owned by another runner or parent workflow.

This happens because:

• AddKeyedSingleton guarantees only one Workflow instance per key
• Workflow contains mutable runtime state (checkpoints, execution position, ownership)
• TakeOwnership explicitly forbids concurrent usage of the same instance

This makes it impossible to safely run the same workflow definition multiple times in parallel.

Expected Behavior

It should be possible to:

• run multiple concurrent workflow executions
• based on the same workflow definition / key
• without ownership conflicts

This requires one Workflow instance per run, not per key.

Root Cause Analysis

• Workflow currently combines:
  • workflow definition (graph, nodes, edges)
  • runtime state (execution position, checkpoints, ownership)
• AddKeyedSingleton assumes the object is:
  • immutable
  • safe for concurrent reuse

These assumptions do not hold for Workflow.

Additionally:

• There is no Clone() method
• There is no WorkflowDefinition vs WorkflowInstance separation
• Samples implicitly assume only one active run per workflow key

As a result, users are forced to bypass AddWorkflow entirely for real-world ASP.NET / AG-UI / Human-in-the-loop scenarios.

Why this is a Framework Bug (not a Usage Error)

From a DI and runtime semantics perspective:

• A stateful, ownership-enforced object must not be registered as a singleton
• TakeOwnership explicitly enforces single-run semantics per instance
• Therefore, AddKeyedSingleton is incompatible with the runtime contract of Workflow

This creates a contradiction between:

• DI lifetime (singleton)
• runtime expectations (exclusive ownership)

Impact

This issue affects:

• ASP.NET Core Web Applications
• AG-UI / Human-in-the-loop workflows
• Multi-tenant and concurrent request scenarios

Currently, AddWorkflow cannot be safely used in these environments without running into ownership exceptions.

Code Sample

From AddWorkflow:

builder.Services.AddKeyedSingleton(name, (sp, key) =>
{
    var workflow = createWorkflowDelegate(sp, keyString);
    return workflow;
});

At runtime, the same Workflow instance is later passed into the workflow runner, where ownership is enforced via:

InProcessRunnerContext.TakeOwnership(workflow)

This fails when multiple runs attempt to use the same instance.

Error Messages / Stack Traces

"Cannot use a Workflow that is already owned by another runner or parent workflow."

Package Versions

Microsoft.Agents.AI.Workflows dotnet-1.0.0-preview.260128.1

.NET Version

.NET 10.0

Additional Context

No response