A better question should be why doesn't jbpm leverage rules :) jBPM does many things we don't do, it's transactional and persistable, it has a number of services configured for nodes (tasks etc) and is generally better aimed at long lived orchestration and choreography and of course it is aimed at various workflow/bpm standards support. Firstly the GUI side was donated and already partially integrated, it was a few days work to get that fully integrated or weeks of work (maybe more) to refactor much of jBPM designer to allow us to integrate and then ofcourse the further work to better supported our "tooled" environment. Our GUI side offers a far more integrated approach for rules, where as jBPM has more pojo focused, still leaving the author to implement interfaces and then specify the class as a callback within the configuration on that node - so it's far more low level. Secondly if we where to leverage jBPM to do the state management of the executions we would end up with two engines running which would need to be bridged, contexts would have to be mapped and the tooling is not aimed at ruleflow but more orchestration of services - over all there is an impedenance mismatch which would actually make this more complex, the implementation slower and generally it would take longer to do. RuleFlow is a natural extension of the approached use by agenda groups and its hooked tightly into the engine to get the best performance. Mark Ming Fang wrote: