i've found that different semantics of RFGs (RuleFlowGroups) and AGs (AgendaGroups) to confuse people, especially because they can be used together. If you remember the idea was that an RFG was a staging ground for rules, when activated it would place all it's rules into the AG it was associated with, and trace those, when all it's rules had fired, it would de-activate. If you used both RFGS and different AGs, the combinations could result in RFGs never returning. Multiple process instances on the same ksession can also interact with the same RFG, at different points of it's initial activation and end deactivation. The concept of groups makes you think there is a some degree of isolation in the inferencing of rules within that group. Only for them to be "merged' into one single AG, either from an 'and' split or different executing process instances. This behaviour makes using RFG's potentially non deterministic, and certainly not deterministic from looking at the rules in the one RFG alone. Recently people wanted to be able to test RFGs without having to call the process, for testing purposes. So I think we need to rethinking how we do this. My first initially step is to remove the ambiguities of the RFG and AG interaction, and merge them. So the rule has only one potently group name, and it's semantics are that of an AG, with the additional rule flow tracking call back. Now when an rule flow reaches an RFG it simply call setFocus(), and adds the tracking callback. So when the group pops the rule flow is notified, and allowed to continue. So while i feel unifying the concepts is a step in the right direction, it does not solve everything, and I don't have all the answers yet…. so if anyone has thoughts on this, please share them :) Mark