See also Adaptive Object Model, which seems to be the preferred term.
One of the things about OOPSLA'97 that impressed me the most was that half of the demos had an explicit representation of their object model that they would interpret. Each system used a different name for this idea, often including "meta" as part of the name. But the name that I liked best was Active Object Model.
[See Meta Data, Meta Level for more about "meta"]
You can easily get yourself in trouble with an Active Object Model. It can make your application more abstract and harder for newcomers to understand. However, it can also drastically simplify an application, can make programs become much more extensible without recompiling them, and can make an expert extremely productive.
A system with an Active Object Model has an explicit object model that it interprets at run-time. If you change the object model, the system changes its behavior. For example, a lot of workflow systems have an Active Object Model. Objects have states and respond to events by changing state. The Active Object Model defines the objects, their states, the events, and the conditions under which an object changes state. Suitably privileged people can change this object model "without programming". Or are they programming after all?
One of the systems at OOPSLA was used for defining potential products. The products were complex telecommunications equipment. Each product had hundreds of options, and only certainly combination of options were legal. The system had an object model that described the different components of a product and which configurations were legal. The whole system used only four or five classes, but these classes were things like Object and Relation. The thousands of kinds of products were all just instances of Object. They would configure a system for sale by making a clone of one of the existing Objects and customizing it. So, this system not only had an Active Object Model, it used the Prototype pattern. The authors claimed they could build a system in .01% of the time that others took to build it.
The Hartford has an Active Object Model for representing insurance policies. A policy is a tree of objects, each of which is an instance of Component. Each Component has a type, which is an instance of Component Type. Each instance of Component Type has a name and defines a set of attributes. For example, the Component Type named "Auto" defines attributes like "Make" and "Year", while the Component Type named "Property" defines attributes like "Address" and "Construction". The component representing the policy on a house has the type "Property", and gives values to all the attributes defined by the "Property" Component Type.
This is similar to Customization Via Programming.
Ralph, you mention attributes above, but what about methods? Moreover, is AOM really different from, say, a pure prototype system like Self?
It is very interesting to me that here the object model is made explicit and over in Multi Caster, the connection and notification models are made explicit. -- Michael Feathers
This seems a bit related to Business Rules, where the rules are made explicit.
I've seen systems that let you define rules and associate them with types. The Hartford system is one. But some of the systems don't do this, so it seems to be an optional part of the pattern.
Self is a language. These systems are not billed as languages, though of course you can think of them as languages. Self is prototype based, while these are based on the Type Object pattern. James Noble has apparently seen quite a few prototype-based systems that are similar to this. I haven't.
A lot of patterns make something explicit that is usually implicit. I think that is a common trick in OO design.
Good insight. See also Aspect Oriented Programming.
-- Dave Harris
I would have called it an Abstract Machine: you are building a custom set of entities and an instruction set to go along with it. All your domain problems are expressed as combinations of these things. I like these types of designs -- must be my Operating System bias. If you take this seriously, and take into account language-design issues like naming and scope and so on, the designs become super-flexible with little effort. A closely related idea is the Bell Labs' Little Language school of design. Although I think the labs people were mistaken to build so many little languages, a single common language like lisp or smalltalk is much better. (Yes, I know they were working on resource-starved machines). -- Aamod Sane
Manufacturing systems (MRP, ERP) usually have more than one level of active models: one level often called Masters, e.g. Product Master, Bill Of Material Master, Routing Master, defines products and their associated processes generally. The Master level sometimes also has something corresponding to a Type Object. In process industries, the Master level might be called Recipes or Formulas for products.
The next level is Planning or Specification, where people plan specific quantities of specific products to manufacture at specific times. This level is the Active Object Model for the real-time event level. --Bob Haugen
See these pattern languages:
Brian Foote and Joseph Yoder, Metadata and Active Object-Models,
www.joeyoder.com 
Martin Fowler, Dealing with Properties, Copyright year 1997 www.martinfowler.com
In my experience, there is one element that makes an Active Object Model work or break: If you can come up with a complete interpreter or not. The interpreter is actually the place where your domain knowledge goes in. It contains the invariants of the "Business Rules", the fundamental rules the system has to play by. The system can not operate outside this invariants (unless someone comes up with a hack here and there). The variant parts (Hot Spots) have been factored out to the object model it interprets.
It is interesting that the systems mentioned on this page are all dealing with a relative small and well defined Problem Domain (Configuration: Combination allowed or not. Insurance: Case Insured or not). All problem domains where it seems to be possible to come up with a closed Meta Model of what is going on in the real word. So one prerequisite for succesfull applying the pattern might be to have
a relative small, well defined problem domain,
where all principal interactions and relations in the problem domain are known,
and where these can be abstracted into some kind of interpreter,
forming a Frame Work on a Meta Level.
Regarding the last point: In my view, Active Object Model is about creating a Frame Work, which is based on a higher problem domain abstration than usual (on the Meta Level). Consequently, the flexible part of such a framework (the object model) operates on the problem domain level.
A note about the pattern's name. Active Object is a well known OO term, where it denotes that an object executes in its own thread of control. Maybe Active Object Model is a misleading name?
Seconded! --Paul Morrison
See also: www.adaptiveobjectmodel.com
See original on c2.com