# Slickflow: a .NET BPMN engine where LLM calls and business rules are diagram steps

> Slickflow is an MIT-licensed .NET 8 workflow engine that treats large language model calls, retrieval-augmented generation and autonomous agents as BPMN nodes alongside ordinary service tasks. It also ships a business rules engine attached to gateway transitions, and an MCP server that exposes 14 workflow tools to AI assistants.

**besley/Slickflow** — .NET Open Source Workflow Engine,  AI Empowerment

- Repository: https://github.com/besley/Slickflow
- Website: http://www.slickflow.net
- Stars: 923 · Forks: 265
- Language: C#
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/besley-slickflow

## A BPMN engine where the model call is a step in the diagram

Slickflow is described as a .NET open source workflow engine, and the current version line is NET8. Its distinguishing feature is that large language model calls are not bolted on from outside. The README describes Slickflow as integrating LLM nodes directly into BPMN workflows, giving conversational reasoning, retrieval-augmented generation, image understanding and other AI capabilities as first-class workflow steps. An LLM, RAG or agent node goes into the process diagram the way a traditional service task does, and a multi-step AI pipeline can orchestrate prompt construction, tool calls, knowledge base retrieval, post-processing, persistence and notification inside one process. The audience is a .NET development team with existing BPMN definitions who want to introduce a model into a controlled point in a business process rather than in the surrounding application code. The homepage is slickflow.net and the repository carries bpmn-files, database and source directories, so process definitions and the engine live side by side.

## Multiple model providers, with the architecture left open for more

Provider support is listed in two named forms with an extension path for the rest. The OpenAI API is called out with GPT-4, GPT-3.5 and beyond, and QianWen, described as Alibaba's large language model, is the second. The README states that the architecture is extensible for additional providers, naming DeepSeek and custom gateways as examples. Two of the AI capabilities are worth separating because they have different engineering implications. Image classification and analysis runs directly through LLM nodes, which is a prompt and response problem. RAG is different: it combines vector search or knowledge bases with model reasoning so the answers are grounded and current, which means the workflow now depends on retrieval behaving as expected, not just on the model. The README points to a separate article on Medium for the detail on the LLM integration, and includes a demonstration GIF of an AI image classification process.

## Business rules live in wf_rule_set and attach to gateway transitions

The business rules engine is the part of Slickflow that has nothing to do with AI, and it is the part most likely to be useful to an existing BPMN team. Rules are authored in the designer or through an API and stored in the wf_rule_set table, and each rule set contains one or more expressions evaluated against process variables at runtime. The evaluation call is short:

```csharp
// Evaluate a rule set by name against the current process variables
IWorkflowService wfService = new WorkflowService();
var ruleResult = wfService.EvaluateRuleSet("CreditCheckRules", variableDict);
```

The interesting part is where rules attach. They are bound to gateway transitions in the BPMN diagram, so when the engine reaches a split gateway it evaluates the expressions and takes the matching branch with no custom code required. The patterns given are amount threshold routing, where an order above 10,000 goes to a senior approval branch, status-based branching on an inventory check, and AI output routing where a model confidence score decides between acceptance and human review. That last pattern is where the two halves of the project meet.

## The rule and AI combination is the interesting three-step pattern

The README describes combining rules and AI nodes in a single process in three steps: an LLM node produces a structured output, a JSON document with a score field; a split gateway then evaluates a rule against that score variable; and the process routes to different downstream activities as a result. The reason this pattern is worth copying is the separation of concerns it enforces. The model produces an assessment, and a deterministic expression decides what to do with that assessment, and the decision is auditable in the diagram without reading the prompt. A workflow where the model directly chooses the next activity is harder to review, harder to test and harder to explain to an auditor, because the branch logic lives in a temperature-controlled response. Putting the score in a variable and branching on a rule in the wf_rule_set table means the routing policy is a database row you can read, change and test. It also means a model that returns an unexpected shape fails at the gateway rather than silently taking the wrong path.

## Agent nodes run a ReAct loop with a typed tool registry

Multi-agent orchestration inside one workflow is built on the ReAct pattern of Reason, Act, Observe. Each Agent node in the diagram runs an autonomous loop: the agent analyses the current task and the tools available to it, calls a registered tool such as an API, a sub-agent or a database query, receives the result, and decides the next step, repeating until it produces a final answer. The execution path goes through a multi-turn service that takes an activity configuration, the input variables and the conversation history:

```csharp
// Agent node execution (simplified internal flow)
var agentService = new AgentMultiTurnService();
var response = await agentService.InvokeWithHistoryAsync(axConfig, inputVariables, history);
```

Tools are registered per activity through AgentToolRegistry, and each one is a typed C# class implementing IAgentTool:

```csharp
AgentToolRegistry.Register("PriceQuery", activityId, new PriceQueryTool());
AgentToolRegistry.Register("InventoryCheck", activityId, new InventoryCheckTool());
```

Because the registry is keyed by activity, the set of tools an agent can reach is defined where the activity is defined, which is a containment boundary worth having. AgentConversationMemory keeps per-session dialogue history across agent turns so agents can refer back to earlier reasoning without recomputing it.

## A five agent procurement process shows how agents pass structured output onward

The multi-agent example in the documentation is a procurement workflow with five agent nodes, and the division of labour is worth reading closely because it is a pattern rather than a demo. NeedsAnalysisAgent analyses purchase requirements, SupplierQueryAgent queries the supplier catalogue and pricing, PriceNegotiationAgent negotiates terms with the selected supplier, RiskAssessmentAgent evaluates compliance and financial risk, and ApprovalDecisionAgent makes the final approval recommendation. Each agent passes its structured output onward as process variables to the next agent, which produces what the README calls a full collaborative reasoning chain within one BPMN process. The property that makes this a BPMN feature rather than a code pattern is that the chain is visible as a diagram. You can see where the risk assessment sits relative to the negotiation, and you can point at a step in a review meeting. The same visibility applies to failure: a chain that stalls in the middle is a stuck process instance you can find, which is what the MCP tools exist to help with.

## The sfmcp server exposes the engine as fourteen callable tools

Slickflow ships a Model Context Protocol server, the sfmcp project, which exposes the workflow engine as a set of callable tools for AI orchestration platforms such as Claude or GPT. The listed capabilities are creating and managing process definitions, starting process instances and running task steps, querying running instances and task lists, reading and writing process variables, and triggering AI node execution inside running workflows. The tools number fourteen and are grouped as GetProcessList, GetProcessDetail and CreateProcess for process definitions, StartProcess, RunProcess and GetProcessInstance for instance control, GetTaskList, GetTaskDetail and CompleteTask for task management, GetVariables and SetVariable for variables, and SearchDocuments, SaveDocument and GetDocuments for the knowledge base. Running it locally is one command sequence:

```bash
# Run the MCP server
cd source/sfmcp
dotnet run
```

You then point your AI platform at the MCP endpoint, and the server speaks the standard MCP protocol over stdio or HTTP transport. The use cases given are AI-driven process automation where an assistant starts and advances workflows from natural-language instructions, workflow introspection to query running instances and diagnose stuck processes by chat, and dynamic variable injection where an agent writes computed results back into a live instance. The third one is the capability that makes this worth evaluating, because it closes the loop between the assistant and the process state.

## MIT terms, a NET8 line, and a repository whose documentation stops mid-section

The licence field for the repository is MIT, which is permissive and carries no copyleft obligation for code that merely uses the engine. The release history shows the AI line moving quickly: Slickflow.AI 3.0.0 on 2025-02-28, 3.5.0 on 2026-01-03 and 5.0.0 on 2026-03-03, with the last push to the repository on 2026-06-24 and the project not archived. The version numbering, jumping from 3.5.0 to 5.0.0 across a few weeks, suggests the AI components are versioned on their own schedule rather than tracking the engine, so it is worth checking which package versions you are pinning together. One documentation gap is worth naming before you commit: the README in the repository ends in the middle of a section, at the heading for code-defined auto-execution, and the tree contains a slickflow-configuration.md file that the README does not describe. The installation story for the engine itself is also thin in what is available here, with a NuGet badge for Slickflow.Engine suggesting package distribution but no documented setup steps. If you need to evaluate this seriously, that configuration document and the package listing are where the missing detail lives.

## Conclusion

Slickflow suits a.NET team that already models processes in BPMN and wants to place a model call, a retrieval step or an autonomous agent inside an existing process definition rather than wrapping the workflow in bespoke orchestration code. It does not suit a team that wants the AI feature to be optional in the diagram, because the documentation presents LLM nodes as first-class steps with their own runtime behaviour, and the README leaves configuration details to a separate slickflow-configuration.md file it does not describe. Before you adopt it, run the sfmcp server locally with dotnet run to see the MCP surface your AI platform would drive, read slickflow-configuration.md for how the engine is configured, and check the wf_rule_set table design against how you expect to author rules, since the designer and API authoring routes are described but the storage details are not.

## FAQ

### What is Slickflow and what does it do?

Slickflow is a .NET 8 open source BPMN workflow engine. Alongside ordinary service tasks it supports LLM, RAG and agent nodes as first-class steps in a process diagram, a business rules engine, and an MCP server that exposes workflow operations as callable tools.

### How do I run the Slickflow MCP server?

Change into the source/sfmcp directory of the repository and run dotnet run, then point your AI platform at the MCP endpoint. The server communicates over the standard MCP protocol using stdio or HTTP transport.

### How are business rules stored and evaluated in Slickflow?

Rules are authored in the designer or through an API and stored in the wf_rule_set table. Each rule set holds expressions evaluated against process variables at runtime, and rules attach to gateway transitions so a split gateway follows the matching branch automatically.

### Which LLM providers does Slickflow support?

The README names the OpenAI API, covering GPT-4 and GPT-3.5 and beyond, and QianWen. The architecture is described as extensible for further providers, with DeepSeek and custom gateways given as examples.

## Sources

- [besley/Slickflow on GitHub](https://github.com/besley/Slickflow)
- [License: MIT](https://github.com/besley/Slickflow/blob/master/LICENSE)
- [Project website](http://www.slickflow.net)
- [README](https://github.com/besley/Slickflow/blob/master/README.md)
- [Releases](https://github.com/besley/Slickflow/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/besley-slickflow