Principle:Microsoft Semantic kernel Process Execution
| Knowledge Sources | |
|---|---|
| Domains | Process_Orchestration, Runtime_Lifecycle |
| Last Updated | 2026-02-11 19:00 GMT |
Overview
Process execution is the two-phase lifecycle of materializing a process definition into an executable object and then launching it with a kernel and an initial event.
Description
Process Execution is the principle that governs how a declaratively defined process is transformed into a running workflow. The lifecycle follows a strict two-phase pattern:
Phase 1 -- Build: The ProcessBuilder.Build() method compiles the builder's accumulated step definitions and event routes into a KernelProcess object. This phase resolves all edges in the process graph, builds each step's metadata, creates the state objects, and produces an immutable process definition. After this phase, the process graph is frozen: no steps can be added and no routes can be modified.
Phase 2 -- Start: The KernelProcess.StartAsync(kernel, initialEvent) method launches the process. It accepts a Kernel instance (which provides AI services, plugins, and the dependency injection container) and a KernelProcessEvent that triggers the process entry point. The method returns a LocalKernelProcessContext that represents the running process and provides access to process state.
The separation of build and start is deliberate. It means:
- The same process definition can be started multiple times with different kernels or different initial events, enabling reuse and parameterization.
- The process graph is validated at build time, catching configuration errors before any execution begins.
- The running process context is disposable, following the .NET IAsyncDisposable pattern to ensure proper cleanup of resources when the process completes.
The running process context supports await using syntax, which means the process execution is bounded by a lifetime scope. When the scope ends (either through natural process completion via StopProcess() or through disposal), the runtime cleans up all step resources.
Usage
Use Build() after completing the process definition to produce the executable KernelProcess object. Then call StartAsync with a configured kernel and the initial triggering event. Always wrap the running process in an await using block to ensure proper resource cleanup.
Theoretical Basis
Process execution in Semantic Kernel follows the Factory Method pattern combined with the Disposable Resource pattern.
Two-Phase Object Creation: The build-then-start lifecycle separates what the process is from how it runs:
Phase 1 (Build): ProcessBuilder → KernelProcess
- Resolves graph topology
- Validates routes
- Creates immutable state
- No side effects, no I/O
Phase 2 (Start): KernelProcess × Kernel × Event → RunningProcess
- Allocates runtime resources
- Dispatches initial event
- Begins event processing loop
- Returns disposable context
Immutability After Build: The KernelProcess produced by Build() is an immutable snapshot. Multiple concurrent executions can share the same process definition without interference:
KernelProcess p = builder.Build();
// Multiple concurrent executions of the same process definition
Task run1 = p.StartAsync(kernel1, event1);
Task run2 = p.StartAsync(kernel2, event2);
Task run3 = p.StartAsync(kernel3, event3);
Resource Lifecycle: The LocalKernelProcessContext returned by StartAsync implements IAsyncDisposable. This follows the resource acquisition pattern:
acquire: context = await process.StartAsync(kernel, event)
use: // process executes, steps fire, events route
release: await context.DisposeAsync() // cleanup
Syntactic sugar via await using:
await using var ctx = await process.StartAsync(kernel, event);
// process runs within this scope
// DisposeAsync called automatically at scope exit
Kernel as Execution Environment: The Kernel parameter to StartAsync provides the execution environment for the process. Steps can access AI services, plugins, and other dependencies through the kernel's service provider. Different kernels can provide different service configurations, allowing the same process definition to run in different environments (development, testing, production).