While creating a workflow system with the Microsoft Agents SDK, I encountered the following error message when testing my workflow:
System.InvalidOperationException: Cannot use a Workflow that is already owned by another runner or parent workflow. at Microsoft.Agents.AI.Workflows.Workflow.TakeOwnership(...) at InProcessRunnerContext..ctor(...) at InProcessRunner.CreateTopLevelRunner(...)
It's cryptic if you haven't seen it before. But once you understand the ownership model, the fix is straightforward.
What's actually happening
.NET workflow runtimes treat workflow instances as stateful, non-reentrant objects. When a runner picks up a workflow, it takes exclusive ownership of that instance. No other runner — and no parent workflow — is allowed to touch it while that ownership is held.
This is by design. Workflows accumulate state as they execute, and allowing two runners to share that state simultaneously would corrupt it. The runtime enforces ownership as a hard constraint, not a soft lock.
The problem almost always has the same root cause: the workflow is registered as a singleton in the dependency injection container, and two requests arrive before the first one finishes. Both try to take ownership of the same instance — and one of them loses.
Why singletons cause this
When we call AddWorkflow<MyWorkflow>(key) without specifying a lifetime, the SDK often defaults to a keyed singleton. That feels sensible — why spin up a new object every time? But "singleton" means every call shares the same instance. Under any real load, concurrent requests will collide.
The stack trace in our exception confirms this: InProcessRunner.CreateTopLevelRunner calls TakeOwnership, which checks whether the instance is already claimed. It is, so it throws.
Three ways to fix it
1. Create a new instance per run (the simplest fix)
The most direct solution is to stop reusing a single instance. Instead, resolve or construct a fresh workflow object each time a run begins.
Before — singleton:
After — transient:
2. Use a factory pattern
If your workflow needs runtime parameters or non-trivial construction logic, a factory keeps things clean:
3. Check ownership timeouts for persisted workflows
If you're using durable/persisted workflows (backed by a database or checkpoint store), the ownership model extends across process boundaries. A previous run may have claimed ownership and crashed without releasing it — leaving the instance locked until the ownership lease expires.
In that case, check two things: whether another process is still actively holding the workflow, and whether your ownership timeout is long enough for your longest-running step. If timeouts are too short, a slow step will lose its lease mid-execution, and the next runner will see the same collision.
Quick checklist
- Change singleton registrations to transient for workflows that run concurrently
- Never share a workflow instance across requests — one instance, one run
- For persisted workflows, check that no other process holds ownership before retrying
- Tune ownership lease duration to exceed your longest step's expected runtime
- If sub-workflows are involved, ensure the parent passes the correct ownership signoff token
The ownership model isn't a bug — it's the runtime protecting you from state corruption under concurrency. Once you stop treating workflows like stateless services and give each run its own instance, the exception goes away and everything works as intended.