A critical part of the BOD methodology is the set of rules for revising the specifications. The fundamental design principle is when in doubt, favor simplicity. A primitive is preferred to an action sequence, a sequence to a competence. Similarly, control state is preferred to learned state, specialized learning to general purpose learning or planning. Given this bias, heuristics are then used to indicate when a simple element should be exchanged for a more complex one.
A guiding principle in all software engineering is to reduce redundancy. If a particular plan or behavior can be reused, it should be. As in OOD, if only part of a plan or a primitive action can be used, then a change in decomposition is called for. In the case of the action primitive, the primitive should be decomposed into two or more primitives, and the original action replaced by a plan element, probably an action pattern. The new plan element should have the same name and functionality as the original action. This allows established plans to continue operating with only minimal change.
If a sequence sometimes needs to contain a cycle, or often does not need some of its elements to fire, then it is really a competence, not an action pattern. If a competence is actually deterministic, if it nearly always actually executes a fixed path through its elements, then it should be simplified into a sequence.
Competences are really the basic level of operation for reactive plans, and learning to write and debug them may take time. Here are two indications provided by competences that the specification of an agent needs to be redesigned:
Effectively every step of the competence but the highest priority one is a subgoal. If there is more than one way to achieve that subgoal, trying to express both of them in the same competence can split attention resources and lead to dithering or `trigger-flipping' (where two plan elements serve only to activate each other's precondition). The purpose of a competence is to focus attention on one solution at a time.
The heart of the BOD strategy is rapid prototyping. If one approach is too much trouble or is giving debugging problems, try another. It is important to remember that programmers' experiences are the key selective pressures in BOD for keeping the agent simple. BOD provides at least two paths to simplicity and clarity: modularity and hierarchical reactive plans. Using cyclic development and some trial and error, the programmer should determine which path is best for a particular problem (5,30). This is also why modularity and maintainability are key to BOD: programmers are to be encouraged to change the architecture of an agent when they find a better solution. Such changes should be easy to make. Further, they should be transparent, or at least easy to follow and understand, if another programmer encounters them.
Further heuristics, particularly with respect to prioritization and scheduling in drive collections can be found elsewhere (8). In the next section, I will instead give an example of the most fundamental revision, trading off complexity in plans for that in behaviors.