As explained in an earlier section, Swarm is designed for hierarchical creation of computer objects. The observer swarm object is created first, and it creates a user interface and it also instantiates the model swarm, and the model swarm then creates levels below and schedules their activities.
One of the original intentions of the Swarm project was to give users the ability to create high quality code with a minimum of fuss. The Swarm library creates a sequence of classes that accumulate and refine the ability to create simulation objects, manage memory for them, and schedule their activities.
Terminology can cause confusion because computer programmers may use the term "agent" in a way that befuddles scientists. To the scientist, the term agent refers to a theoretically important entity that is modeled by a simulation. To a programmer, the term agent is usually broader, something like object. As a result, there is sometimes slippage in a discussion of "agent-based modeling" because an understanding of the term agent is not shared.
We intend to finesse this (big surprise!) by creating terminology for two kinds of agents. This separation of agents into primary and auxiliary groups is created solely for discussion in this manual. The idea is that primary agents are the ones that the research sets out to model in the first place. They are described in a theory, they have substantive importance. Usually in this sense we have representations of important "actors" and one or more objects to represent the world in which they interact.
To the surprise of most new users, it is often also necessary to create auxiliary agents that facilitate the work of the primary agents. For example, in a model of majority rule voting, one can have primary agents like voters and candidates. There may be a need for an auxiliary class called Counter, a class that can spawn objects that can be used to tally the votes that are cast.
In most cases, when we talk about multi-agent systems, we are referring to the primary agents.