Workflow:Microsoft Semantic kernel Process Orchestration
| Knowledge Sources | |
|---|---|
| Domains | Workflow_Orchestration, Event_Driven_Architecture, AI_Orchestration |
| Last Updated | 2026-02-11 18:00 GMT |
Overview
End-to-end process for building event-driven, stateful business workflows using the Semantic Kernel Process Framework, including step definition, event routing, subprocess composition, control flow patterns, and agent integration.
Description
This workflow covers the Semantic Kernel Process Framework, an experimental feature for defining multi-step business processes as event-driven workflows. A process is composed of typed steps connected by events. Each step is a class that processes input events and emits output events, forming a directed graph of operations. The framework supports sequential execution, loops with conditional exits, fan-in/fan-out patterns, subprocess composition (processes as steps), stateful steps with persistent state, map-reduce patterns, and integration with the Agent Framework. Processes can run locally or distributed via Dapr, with optional real-time visualization through SignalR or gRPC.
Usage
Execute this workflow when you need to model a multi-step business process that combines AI operations with deterministic logic. Examples include account opening workflows (form filling, credit check, fraud detection, approval), document generation and review pipelines, order processing with conditional routing, and any scenario where multiple steps must execute in a defined sequence with branching and state management.
Execution Steps
Step 1: Define Process Steps
Create C# classes that extend KernelProcessStep to define the individual operations in the workflow. Each step class contains methods decorated with the KernelFunction attribute that process incoming events and optionally emit output events.
Key considerations:
- Each step is a class extending KernelProcessStep (or KernelProcessStep<TState> for stateful steps)
- Step methods receive event data as parameters
- Steps emit events using context.EmitEvent() to trigger downstream steps
- Steps can maintain internal state that persists across invocations
Step 2: Create a Process Builder
Instantiate a ProcessBuilder with a process name. The builder provides a fluent API for adding steps and wiring events between them. Steps are added by type reference and return a handle for event configuration.
Pseudocode:
processBuilder = new ProcessBuilder("MyProcess")
stepA = processBuilder.AddStepFromType<StepA>()
stepB = processBuilder.AddStepFromType<StepB>()
Key considerations:
- ProcessBuilder is the entry point for process definition
- AddStepFromType<T>() registers a step and returns a reference for wiring
- Steps can also be added from agent definitions using AddStepFromAgent()
Step 3: Wire Event Routing
Connect steps by defining how events flow between them. Use OnInputEvent to handle the initial process trigger, OnFunctionResult to route a step's output, and SendEventTo to direct events to downstream steps. Use StopProcess to define terminal conditions.
Key considerations:
- OnInputEvent(eventId) handles the initial event that starts the process
- OnFunctionResult() captures the output of a step's KernelFunction
- OnFunctionError() handles step failures
- SendEventTo(new ProcessFunctionTargetBuilder(step)) routes to a target step
- StopProcess() marks a step as the terminal point
Step 4: Implement Control Flow Patterns
Add conditional logic, loops, and parallel branches to the process. Steps can emit different events based on their internal logic, routing to different downstream steps. Loops are implemented by routing a step's output back to an earlier step with an exit condition.
Patterns available:
- Sequential: Step A output routes to Step B input
- Conditional: Step emits different events based on logic, each routed to different targets
- Loop: Step output routes back to an earlier step; exit condition emits a different event
- Fan-out/Fan-in: Multiple parallel steps receive the same event; a collecting step waits for all
- Map-Reduce: Map step processes items in parallel; reduce step aggregates results
Step 5: Compose Subprocesses (Optional)
For complex workflows, define smaller processes and embed them as steps within a parent process. This enables modular, reusable process definitions. A subprocess is itself a KernelProcess that can be added as a step to a parent ProcessBuilder.
Key considerations:
- Subprocesses are added via AddStepFromProcess(childProcess)
- Subprocesses can have their own internal event routing
- Parent and child processes communicate via events at the boundary
- This pattern improves readability and reusability for large workflows
Step 6: Build and Execute the Process
Compile the process definition into a KernelProcess object and start it with an initial event. The process runs on a local runtime by default, executing steps as events flow through the defined graph.
Pseudocode:
kernelProcess = processBuilder.Build() context = await kernelProcess.StartAsync(kernel, initialEvent)
Key considerations:
- Build() validates the process graph and produces an executable KernelProcess
- StartAsync() requires a Kernel and an initial KernelProcessEvent
- The process runs asynchronously until it reaches a StopProcess terminal
- Process state can be retrieved via context.GetStateAsync()
Step 7: Integrate Agents Into Process Steps (Optional)
Add AI agents as process steps using AddStepFromAgent(). This enables processes that combine deterministic business logic steps with AI-powered agent steps. Agent steps maintain their own chat history and can use plugins for tool calling.
Key considerations:
- Agent steps wrap ChatCompletionAgent or OpenAI Assistant agents
- Agent steps maintain independent conversation history within the process
- Agents can be equipped with plugins for domain-specific tool access
- Process events carry data between agent and non-agent steps