Just how different - or the same - are objects and agents? Some developers consider agents to be objects, except with more bells and whistles. Then, there are those who see agents and objects as different even though they share many things in common. Both approaches, however, envision using objects and agents together in the development of software systems. In other words, objects and agents are two distinct notions - each having its own particular place in software development. The important point here is that the agent-based way of thinking brings a useful and important perspective for system development, which is different from - while similar to - the object-oriented way. This paper discusses some of the differences and similarities between agents and objects and lets you decide which viewpoint you want to choose.
EVOLUTION OF PROGRAMMING APPROACHES
Figure 1 illustrates one way of thinking about the evolution of programming languages. Originally, the basic unit of software was the complete program where the programmer had full control. The program's state was the responsibility of the programmer and its invocation determined by the system operator. The term modular did not apply because the behavior could not be invoked as a reusable unit in a variety of circumstances.
As programs became more complex and memory space became larger, programmers needed to introduce some degree of organization to their code. The modular programming approach employed smaller units of code that could be reused under a variety of situations. Here, structured loops and subroutines were designed to have a high degree of local integrity. While each subroutine's code was encapsulated, its state was determined by externally supplied arguments and it gained control only when invoked externally by a CALL statement. This was the era of procedures as the primary unit of decomposition.
In contrast, object orientation added to the modular approach by maintaining its segments of code (or methods) as well as by gaining local control over the variables manipulated by its methods. However in traditional OO, objects are considered passive because their methods are invoked only when some external entity sends them a message.
Software agents have their own thread of control, localizing not only code and state but their invocation as well. Such agents can also have individual rules and goals, making them appear like "active objects with initiative". In other words, when and how an agent acts is determined by the agent.
Agents are commonly regarded as autonomous entities, because they can watch out for their own set of internal responsibilities. Furthermore, agents are interactive entities that are capable of using rich forms of messages. These messages can support method invocation - as well as informing the agents of particular events, asking something of the agent, or receiving a response to an earlier query. Lastly, because agents are autonomous they can initiate interaction and respond to a message in any way they choose. In other words, agents can be thought of as objects that can say "No" - as well as "Go". Due to the interactive and autonomous nature of agents, little or no interation is required to physically launch an application. Van Parunak summarizes it well: "In the ultimate agent vision, the application developer simply identifies the agents desired in the final application, and the agents organize themselves to perform the required functionality."  No centralized thread or top-down organization is necessary since agent systems can organize themselves.
Since a key feature of agents is their autonomy, agents are capable of initiating action independent of any other entity. However, such autonomy is best characterized in degrees, rather than simply being present or not. To some degree, agents can operate without direct external invocation or intervention.
Autonomy has two independent aspects: dynamic autonomy and nondeterministic autonomy. Agents are dynamic because they can exercise some degree of activity. As illustrated in Fig. 2, an agent can have some degree of behavior from being simply passive to entirely proactive.
For example, paint booths were experimentally treated as agents at GM. Here, information about an unpainted car or truck coming down the line is posted in an automated form that is accessible to all paint booths. When a paint booth nears completion of it current job, it basically says, "Hmmm, I'm running out on work, I'll look over at the jobs posted." If the booth is currently applying the color of paint required by an upcoming job, it will bid more for the job than a booth having a different color. Other bidding criteria could include how easy or important the job is. In a top-down planned "push-through" world, if one booth malfunctions the plan would require immediate recomputing; with bottom-up "pull-through" paint booth agents, there are other booths to pick up the bidding slack at a moment's notice. 
Figure 2 Two aspects of autonomy (based on collaborative work with Van Parunak).
Agents can react not only to specific method invocations but to observable events within the environment, as well. Proactive agents will actually poll the environment for events and other messages to determine what action they should take. To compound this, in multiagent systems agents can be engaged in multiple parallel interactions with other agents - magnifying the dynamic nature of agents. In short, an agent can decide when to say "go."
Objects, on the other hand, are conventionally passive - with their methods being invoked under a caller's thread of control. The term autonomy barely applies to an entity whose invocation depends solely on other components in the system. However, UML and Java have recently introduced event-listener frameworks and other mechanisms for allowing objects to be more active. In other words, objects are now capable of some of the dynamic capability of agents.
Agents may also employ some degree of unpredictable (or nondeterministic) behavior. When observed from the environment, an agent can range from being totally predictable to completely unpredictable (Fig. 2). For example, an ant that is wandering around looking for food can appear to be taking a random walk. However, once pheromones or food are detected, its behavior becomes reasonably predictable. In contrast, it is difficult to predict which GM paint station will paint which vehicle. The behavior of a shopping agent might be highly unpredictable. Giving it criteria for a gift, will not predict exactly which gift it will choose. In fact, the agent might return empty handed because it did not find any gifts that match the criteria. In other words, the agent can also say "no".1
Conventional objects do not have to be completely predictable. However, the typical usage and direct support with OO languages tends toward a more predictable approach. For instance, when a message is sent to an object, the method is predictably invoked. Yes, an object may determine whether or not to process the message and how to respond if it does. However, in common practice if an object says no, it is considered an error situation; with agents, this is not the case.
Usually, object classes are designed to be predictable in order to facilitate buying and selling reusable components. Agents are commonly designed to determine their behavior based on individual goals and states, as well as the states of ongoing conversations with other agents. While OO implementations can be developed to include nondeterministic behavior, this is common in agent-based thinking.
Agent behavior can also be unpredictable because the agent-based approach has a more "opaque" notion of encapsulation. First, the requested behaviors that an agent performs may not even be known within an active system. This is a clear distinction from object systems, because current OO languages only let you ask an object what interfaces it supports. Since the programmer needs to have some idea what interface to ask for, this makes coding difficult. In OO, there is no provision in current languages for an object to "advertise" its interfaces. In contrast, an agent can employ other mechanisms, such as publish/subscribe, protocol registration, "yellow page", "green page", and "white page" directories. Another common mechanism provides specialized broker agents to which other agents can make themselves known for various purposes but are otherwise unlisted to the rest of the agent population.
Second, the underlying agent communication model is usually asynchronous. This means that there is no predefined flow of control from one agent to another. An agent may autonomously initiate internal or external behavior at anytime, not just when it is sent a message . Asynchronous messaging and event notification are part of agent-based messaging systems, and agent languages need to support parallel processing. These are not part of the run-of-the-mill OO language. Those that require such functionality in an OO system typically layer these features on top of the object model and OO environment. Here, the agent model explicitly ties together the objects (data and functionality) with the parallelism (execution autonomy, thread per agent, etc.). According to Geoff Arnold of Sun Microsystems, "Just as the object paradigm forced us to rethink our ideas about the proper forms of interaction (access methods vs. direct manipulation, introspection, etc.), so agents force us to confront the temporal implications of interaction (messages rather than RMI, for instance)".
AGENTS ARE INTERACTIVE
Interaction implies the ability to communicate with the environment and other entities. As illustrated in Fig. 3, interaction can also be expressed in degrees. On one end of the scale, object messages (method invocation) can be seen as the most basic form of interaction. A more complex degree of interaction would include those agents that can react to observable events within the environment. For example, food-gathering ants don't invoke methods on each other; their interaction is indirect, through direct physical effects on the environment. And finally in multiagent systems, agents can be engaged in multiple, parallel interactions with other agents. Here, agents can act as a society.
One method per message
An object's message may request only one operation, and that operation may only be requested via a message formatted in a very exacting way. The OO message broker has the job of matching each message to exactly one method invocation for exactly one object.
Agent-based communication can also use the method invocation of OO. However, the demands that many agent applications place on message content are richer than those commonly used by object technology. While agent communication languages (ACL) are formal and unambiguous, their format and content vary greatly. In short, an agent message could consist of a character string whose form can vary yet obeys a formal syntax, while the conventional OO method must contain parameters whose number and sequence are fixed. Theoretically, this could be handled with objects by splitting the world into two portions: one including messages for which we have conventional methods, another including messages that we send as strings.
To support string-based messages in an OO language, you could either anticipate every possible variation by supplying a specialized method for each or use a general utility AcceptCommunicativeString method. The AcceptCommunicativeString method, then, could cover the multitude of services that an object might handle. However, with just a single method, the underlying services would not be part of the published interface. In the traditional OO environment, such an environment would be both boring and not very forthcoming. In agent-based environments, agent public services and policies can be made explicit through a variety of techniques (described earlier).
Agent communicative languages
Since we may wish to send a message to any (and every) agent, we need the expressive power to cover all desired situations - including method invocation. Therefore, an agent communication language is necessary for expressing communications among agents - and even objects. The ACL syntax could be specially crafted for each application. However, the lack of standardization would quickly result in a tower of Babel. Here, two applications could have difficulty interacting with one another; for an entire organization, it would be totally impractical. Standard ACL formats, then, would be desirable. Two of the most popular general purpose ACLs are KQML and the FIPA ACL. These ACLs communicate agent speech acts, specify ontologies, and participate in discussion patterns called protocols.
Conversations and long-term associations
Another way in which agent interaction can be more than just method invocation is that agents can be involved in long-term conversations and associations. Agents may engage in multiple transactions concurrently, through the use of multiple threads or similar mechanisms. In an agent-messaging environment, each conversation can be assigned a separate identity. Additionally, either a unique message destination or a unique identifier can be used to sort out the threads of discourse. Conventional OO languages and environments have difficulty supporting such a requirement, directly or indirectly. It should be mentioned that objects could be used for the elements of agent conversation - including the conversation itself. In other words, agents can employ objects for those situations requiring entities with little autonomous or interactive ability.
Geoff Arnold has considered the question of third party interactions which are very hard for strongly typed object systems to handle. Here, two patterns come to mind. The first involves a broker that accepts a request and delegates it to a particular service provider based on some algorithm that is independent of the type of service interface (e.g., cost, reachability). The second involves an anonymizer that hides the identity of a requester from a service provider. Models based on strong typing, such as CORBA, RMI, and Jini, cannot easily support these patterns.
Two key areas that can differentiate the agent-based approach from traditional OO are autonomy and interaction. However, there are other ways in which agents may seem to differ from objects. The list below describes some underlying concepts that agent-based systems can employ. None are universally used by agents: active object systems may use them as well. Furthermore, no agent system is required to use any of them.
Agents can exhibit properties of parasitism, symbiosis, and mimicry. They can participate in "arms races" where agents can learn and outdo other agents. Agents can participate in sexual (and asexual) reproduction that can incorporate principles from Darwinian and Lamarckian evolution. Agent societies can exhibit political and organizational properties - whether they are organized, anarchic, or democratic. In short, nature can provide a rich trove of ideas for multiagent system design.
It is tempting to assert: "An agent is an object that...." - completing the phrase in a variety of ways. Jeff Bradshaw  refers to agents as "objects with an attitude" in the sense of being objects with some additional behavior added, for instance, mobility, inference, etc. Here, we are using objects as a generic modeling or abstraction mechanism, independently of whether agents are implemented as objects (using object-oriented programming techniques).
The viewpoint might help resolve the problem of multiple kinds of agents. In a sense, we could view the maximal agent as potentially having all behaviors found in the agent attributes list, and that degenerate forms of agents are those containing fewer than all properties. In this view, objects are agents without these extra agent attributes. This helps explain how agents might literally be "objects with an attitude." Taking this view, considering agents that use agent communication languages as having the ability to "just say no" to message requests, we can view objects as degenerate agents that always do as they are told.
One can now simultaneously argue that agents are objects and that agents are different from objects. These extra agent capabilities could be added to objects but then they would become agents. The nice thing, then, is we have a path for treating agents and objects the same in models and both as first class model elements. For example, we could distinguish agents that communicate natively as agent-oriented and objects that encapsulate and simulate native agent capabilities as agent-based, in comparison to the traditional, similar distinction between object-oriented and object-based.
However are some of the challenges that confront us in the area of trying to understand the relationship of objects to agents :
In some sense, the burden of getting along with other technologies is a problem for the agent camp - the sooner we provide migration strategies, the sooner agent technology can become more widely available and useful. A way to put the problem in perspective is, pretend you give some application developer an agent toolkit and also conventional tools like scripting languages. At what point will solutions commonly be developed using many of the tools from the agent toolkit? Will they just be used when they are useful, like other tools. For instance, inference might just be used occasionally (perhaps rarely); trading more often; mobility in certain families of situation; and so on.
Agents are autonomous entities that can interact with their environments. But, are they just objects with extra attributes or are they really an entirely different approach? And, just how important is it to answer this question? What is important is that objects and agents are distinct enough to treat them differently. When we design systems, we can choose a well thought-out mixture from both approaches. In some sense, the burden of getting along with other technologies is a problem for both the agent and object camps.
The sooner we provide migration strategies, the sooner agent technology can become more widely available and useful. Some software developers strongly advocate composing agents from objectsbuilding the infrastructure for agent-based systems on top of the kind of support systems used for OO software systems. For example, many structures and parts of agents can be reasonably expressed as objects. These might include agent names, agent communication handles, agent communication language components (including encodings, ontologies, and vocabulary elements), and conversation policies.
In multiagent systems, an additional layer of software components may be naturally expressed as objects and collections of objects. This is the underlying infrastructure that embodies the support for agents composed of object parts. For example, this might include communication factories, transport references, transport policies, directory elements, and agent factories.
In short, when we design systems, we can choose a well thought-out mixture from both approaches. We can even build aggregates where agents consist of both objects and other agents, and vice-versa. For Grady Booch, employing agents with object systems is useful because the agent-based approach:
a) provides a way to reason about the flow of control in a highly distributed system,
1) [Parunak, Van Dyke 1997] Parunak, H. Van Dyke, "Go to the Ant": Engineering Principles from Natural Agent Systems, Annals of Operations Research, 75, 1997, pp. 69-101.
2) [Morley 1998] Morley, Dick, Cases in Chaos: Complexity-Based Approaches to Manufacturing, Embracing Complexity, Ernst & Young Center for Business Innovation, Boston, MA, August, 1998, pp. 97-102.
3) [Wooldridge et al 2000] Wooldridge, Michael, Nicholas R. Jennings, and David Kinny, The Gaia Methodology for Agent-Oriented Analysis and Design, Autonomous Agents and Multi-Agent Systems, forthcoming, 2000.
4) [Bradshaw 1997] Bradshaw, J. (ed.), Software Agents, MIT Press, Cambridge, MA, 1997.
5) [Odell 2000] Odell, James (ed.), Agent Technology, green paper, OMG Agent Special Interest Group, OMG document agent/00-09-01, 2000.
6) Booch, Grady, private communication, 2000.
About the author
Cite this column as follows: James J. Odell: "Objects and Agents Compared", in Journal of Object Technology, vol. 1, no. 1, May-June 2002, pp. 41-53. http://www.jot.fm/issues/issue_2002_05/column4