The Agent Grid

The Agent Grid:
A Software Framework for Building Massively
Distributed Autonomous Systems
Larry Suarez
Grid Research Group
Agent Net, Inc.

Abstract

Software solutions that deal with highly distributed artifacts1 have traditionally been very
difficult to construct. Naturally distributed domains include air traffic control,
transportation, military battlespaces, supply chains, and massively multiplayer online
games (MMOG). But with the ubiquitousness of computing today, even traditionally
localized domains are becoming distributed. For example, tracking and reacting in real-
time to national product usage or national consumer product preferences. Solutions
need to manage and control thousands of artifacts and require a myriad of technology.
And these domains are constantly changing while rapidly outdating static solutions.
There are no available frameworks for building massively distributed autonomous
systems. And there are no frameworks that support solutions that socialize and evolve
with the domain. The Agent Grid represents an attempt at creating a software
framework for quickly building massively distributed autonomous systems.

This paper will present a cursory description of the Agent Grid software framework. The
framework has been implemented and deployed in a number of test environments.
Although the basis for the Agent Grid is not new to researchers, the technology will be
new to most software developers. The Agent Grid is meant to be used as a valid
framework for commercial solutions but also as a tool to foster further discussions on
frameworks for massively distributed computing.

There were three driving goals for the Agent Grid beyond providing a framework for
constructing distributed solutions:

1. Constructing Agents must be easy, quick, and rapidly deployed. No deployment
XMLs, location requirements (special file directories), or any required ancillary
processes.
2. Software behaviors (contents of an Agent) must be easily constructed and
deployed by developers with only basic skills. Skills in robotics, artificial
intelligence, agent-based systems, or massively distributed processing are not
required.

1
Vehicles, hand-held devices, military hardware, aircraft, workers, sensors.

The Agent Grid 2

3. The construction and augmentation of Agents through the process of cobbling is
the primary goal of the framework. Cobbling is defined as the building of Agents
through the use of existing behaviors. Cobbling may be a human effort (end-user
or software developer) or it may be automated as defined in this paper.
The Agent Grid is a software framework designed to allow software developers to easily
construct massively distribute autonomous systems. The Agent Grid is viewed simply as
a collection of software constructs called “Agents” which are autonomous, evolve, and
work together to form solutions. Solutions built on the Agent Grid typically model one
Agent per artifact where the Agent manages, controls, and augments the artifact. For
example, an Agent may represent an aircraft. The Agent would maintain information
about the aircraft (fuel, passengers, armament) and be able to change the behavior of
the aircraft (turn left 30 degrees). Agents essentially create a virtual world where they
live and communicate on behalf of their real-world counterparts. Realize the Agent Grid
does not mandate that an Agent have a corresponding artifact in the real world. Agents
may represent logical entities such as an algorithm or processing step.

There are many aspects of massively distributed domains that make solutions difficult to
construct:

 Decentralized information, data, and artifacts. This includes data which cannot be
relocated or collected into one central location because of data size, data
ownership, or data security. Domains also typically include hundreds if not
thousands of artifacts that must be managed and controlled.
 Involving numerous, disparate 3rd party systems. These systems contribute to
the domain and must be integrated into the overall solution.
 Dynamic, changing environments. Includes environments where new artifacts are
being added or removed from the environment. For example, a testing laboratory
where test machines go down or machine operators become sick. Or
transportation which is effected by weather systems, traffic congestion, and traffic
accidents.
Agent technology, the core of the Agent Grid, has been researched for well over 30
years and currently drives a number of advanced real-world solutions such as air traffic
control, autonomous vehicles (space, marine, and air), and transportation. As shown in
Figure 1: Agent Grids and Existing Technology, the Agent Grid brings together a number
of technologies into one consistent model to solve these types of problems. In most
software frameworks today, each of the technologies is a distinct feature set added to
the solution resulting in a hodgepodge of terminology, tools, and staffing requirements.

Agent Net, Inc. 3/7/2010

The Agent Grid 3

Figure 1: Agent Grids and Existing Technology

Agent Grids are not meant to be a replacement for technologies such as web servers,
application servers, or other frameworks such as Apache Hadoop, Sun JXTA or the
Globus Toolkit. Agent Grids are merely part of the evolution of software solutions. Many
types of solutions will co-exist. Certainly customers will make decisions as to whether to
use an Agent Grid as oppose to a traditional n-tier solution. Agent Grids were designed
to be incorporated into existing environments. And customers can view Agents merely
as software services if they find that more convenient. Customers require that new
technologies such as the Agent Grid be able to leverage off their existing expenditures
including software developer skills, computer hardware, and computer software.

Advantages

Research into agent-based systems encompasses advanced areas such as robotics,
artificial life, and complex systems. The aspects of Agents that have attracted
researchers for years are just as attractive to business solutions and include:

 Natural way to model solutions. Solutions are modeled based on the
environment or organization as oppose to programming-based modeling
(objects).
 Agents are very flexible. They can change capabilities in real-time, can adapt,
and have learning capabilities. This is a tremendous benefit towards supporting
automation or what we term Agent Oriented Social Computing.
 Provides a new paradigm for developing solutions. Developers today
predominately write software code to be placed into application servers. They
may have choices as to how to deliver the code (Java Beans, Java Servlets,
.Net) but the paradigm remains the same. Agents introduce new ways to design
code solutions which allow more creativity and novel solutions. We have just
scratched the surface on how to construct agent-based solutions.
 Autonomous management of services. Agents can be placed in front of
services (such as a software service or even physical device) to provide service-
related features and autonomous management.
 Agent-based Workflows. Agents can participate in business processes as
“workers”. Agent-based autonomous workflow is a major area of research.


The Agent Grid 4

 Social. Agents can be organized into different control structures where needed.
The architectures are based on the environment not the type of computing
solution available. A traditional client-server solution has only one control
structure: client-server. The different architectures allow us to distribute the
specific control behaviors out to the individual Agents where they belong as
oppose to composing all the behaviors into one local server.
 Multiple solution views. Agents can model the environment in a number of
ways. Processes within the environment can be decomposed into functional units
where an Agent is assigned to each functional unit. For example, an Agent could
be responsible for populating a SAP database for billing purposes. Processes
within the environment could also be broken down into physical units where an
Agent is assigned to each physical unit. For example, an Agent could be
responsible for all software access to a person or test workstation.

The Agent + Grid

The Agent Grid consists of two major concepts: Agents and Grids. The Grid represents
the software infrastructure used to allow Agents to communicate with one another and
maintain their world models. The Grid is known in the industry as middleware. Agents
are the “services” that execute on the Grid. Separating the two concepts allows software
developers to concentrate on the design of their Agents while letting the framework
handle the distributed aspects. This “separation of concerns” is required to ensure the
acceptability of the framework by developers. The separation also allows replacing the
Grid infrastructure with other 3rd party solutions such as the Globus Toolkit without
reducing the effectiveness of the framework.

The Grid

A grid is a distributed software solution focusing on the integration, virtualization, and
management of services. Grids tend to differ from conventional distributed computing by
concentrating on issues that involve:

 Crossing institutional boundaries. In other words, solutions requiring multiple
institutions, organizations, or business units.
 Sharing and management of resources such as software applications, physical
devices, or employees.
 Virtualization of resources so participants are unaware of the physical aspects of
a resource which includes its location, size, and protocols.
The peer-to-peer architecture has gained a deal of notoriety in the past ten years. A
peer-to-peer architecture is one in which there are no specific servers servicing the
participants on the network. Grids are naturally peer-to-peer solutions. Participants are
not required to visit a particular server on the grid to access services. This is in contrast
to architectures such as client-server where there exists a server that must be visited to
acquire a service. Web Servers are an example of a client-server solution. Peer-to-peer
architectures are typically used when the services or data tend to be naturally distributed
and coalescing the services or data onto one host system would be impractical and often
impossible. This will be the case when the participants are distinct organizations often
representing different vendors. Requiring vendors to move their data, processes, and


The Agent Grid 5

software to a central location would be very difficult. A point to remember when reading
the material in this paper is that the Agent Grid is a distributed software system
employing the peer-to-peer architecture. Each Agent on the Agent Grid can
communicate with any other Agent on the Grid without having to go through a central
server.

Agents

So what is an Agent? Agent technology had its start in the studies of Artificial
intelligence. Research into how the human mind functions led to computing research in
modeling some of the basic tenets of the mind. An initial definition is that an Agent is
simply a software container of behaviors much like our minds are a container of
behaviors. The goal of Agent technology research is geared towards mimicking the way
the human mind manages its behaviors. This includes defining how behaviors move
from the subconscious (non-executing) to consciousness (executing). Figure 2: Agent
Reacting to its Environment (Server Down) shows the basic principle of Agent execution.
In the figure, an Agent maintains a pool of behaviors which are not executing. This is
much like our subconscious. If a change occurs within the world of the Agent, such as a
server going down, the Agent determines if the change causes a reaction. In this case it
does and the behavior “Alert IT” moves out of the behavior pool into the execution pool.
It’s interesting that humans are not necessarily aware of what changes trigger a reaction
(behavior execution) which leads to surprising behaviors within ourselves (i.e. “...I did not
know I would react like that.”).

Figure 2: Agent Reacting to its Environment (Server Down)

Notice that this mechanism is different from the current programming world where
software is “invoked” and there is a tight coupling between the request and the software
being invoked. If either changes, the coupling fails and a service cannot be provided. In
Agent technology, behaviors are not invoked. There is a loose coupling between the
change in the environment and the reaction. And the coupling can be manipulated at any
time and the Agent will still function. For example, with a little training a human could be
taught to change the stimulus of a “flee-danger” behavior so that they can function in dire
situations such as would be the case for firemen or policemen. A fireman never loses


The Agent Grid 6

that “flee-danger” behavior but rather another competing behavior such as “save life” is
brought into consciousness in its place.

Behaviors are the basic building blocks of Agent actions. Behaviors are small, succinct
pieces of software code which contribute to a task or goal. They are inherently modular
to allow behaviors to be added, subtracted, or shared from an Agent at any time. For
example, an Agent may represent a forklift and has behaviors such as “turn left”, “turn
right”, and “move forward”. There are a number of differences between a traditional
software server executing chucks of code and an Agent. Agents are designed to mimic
the human mind and how it functions. This includes how the human mind “executes”
human behaviors such as opening a door, taking a step, and fleeing danger. The human
mind does not execute behaviors in the same fashion as an Application Server would
execute services.

The Service Oriented Architecture Computing Model

A major area of interest in the computing arena is distributed applications based on the
computing model called Service Oriented Architecture (SOA). An SOA views all
resources on the network (CPU, storage, applications, etc.) as services which are
available for use. A service provider makes the services available for access over the
network. The idea is to provide a loose coupling between the services so that callers are
only concerned with the functionality of the service and not the details of how the service
is constructed. SOA systems are still based on the communication style of request-
response where a request to a service should involve a response from that service given
that the caller uses the correct protocol. There is a consensus among the computing
establishment that the SOA computing model is the future for building distributed
applications.

The SOA computing model is a one dimensional system. It merely defines the protocols
that are used to communicate with individual services. The model does not support any
relationships or dependencies between services which the model defines as its strength.
Services are viewed as distinct and disjoint. However, this simplicity is forcing vendors
and solution providers to build additional capabilities on top of SOA systems to truly
solve industry problems. For example, event-based systems and workflow systems are
added to allow designers to create business processes that are reactive to the events
that occur within an organization. There is no doubt that the SOA computing model will
be expanded to encompass these features since all solutions will need some form of
those capabilities. But currently the additional capabilities are being added outside the
scope of the computing model and hence users and developers have to digest a number
of computing models within a single business solution.

The basic premise of the SOA computing model is to provide services that are available
for re-use and for the ability to replace like-services on the basis of constraints such as
cost. Hence, a vendor will provide services that are available for use on the network in
exchange for some nominal fee.

The Agent Oriented Architecture Computing Model

The Agent Oriented Architecture (AOA) computing model shares many of the
capabilities of SOA. In AOA, Agents provide goals derived from their many behaviors. In


The Agent Grid 7

SOA, a user requests a service from a service provider. In AOA, a user requests a goal
to be achieved from the Agent. There is no guarantee that the Agent will accomplish the
goal or even respond. This is the case even when the Agent advertises the goals it is
able to accomplish. The reason for this style of computing is that an Agent is designed to
be autonomous and to maintain some form of decision processing. An Agent may
acquire additional goals over time. A human may be asked to run up a hill (service) but
would not do so if a hungry lion happens to be sitting on top of that hill. SOA systems do
not use decision processing in providing their services. They merely provide a set of
services. So Agents provide the ability to define some form of coupling between
“services” ranging from no coupling to very tight coupling.

Whereas SOA services do not share data, Agents can share a world model. A world
model is a description of the world as it is known to the Agents on the grid. A world
model may describe a room, an organization, a city. This is a natural reflection on how
humans are able to function together. An individual may provide distinct “services” but all
humans share a world framework otherwise it would be impossible for humans to
construct societies and civilizations. Finally, AOA is designed to be peer-to-peer systems
as oppose to client-server systems which is the case with SOA.

Agents

There are many industry definitions of an Agent. The definitions are usually dependant
on the system supporting the Agent. Standard bodies have provided some clarity to the
definition of Agents but primarily in Agent communication only. Our discussion of Agents
is based on the Agent Grid as defined in this paper.

It is well known among researchers that real-world complex systems exist which are
constructed from simple entities using a very limited number of skills or capabilities (for
example, ant colonies). Agent-based solutions are based on that premise. Those core
capabilities which are found in an Agent include:

 Adaptable. Ability of the Agent to change over time to match its environment.
Without adaptability, the Agent would soon become useless in a dynamic
environment. Agents can change their behaviors and world models to fit their
environment.
 Reactive. Ability of the Agent to react to changes in its environment. Reaction is
the core capability that enables an Agent to change over time. And its ability to
service other Agents.
 Social. Ability of the Agent to engage with other Agents to form structures such
as processes, societies, and organizations with the purpose of solving problems.
 Deliberative. Ability of the Agent to construct sequences of behaviors (plans) to
execute complex tasks. In addition, the ability to manipulate the sequences (add
and remove behaviors) during execution.
 Autonomous. Ability of the Agent to execute without control or direction simply by
using its environment (stigmergy).
Another powerful aspect of Agents is that they are small, succinct entities that can be
constructed by anyone participating in the environment. Hence, a third party vendor,


The Agent Grid 8

system integrator or channel partner can construct, deploy, and manage their own
Agents while participating in an overall business solution.

Just as the case with human behavior, Agent behaviors are not directly visible to the
outside world. In humans we only see the results of our behaviors. When we throw a
ball, we are only seeing the results of the behaviors which control our arms, legs and
hands. To get another individual to answer a question on fishing, we pose the question
and wait for a response. A response indicates that either the individual does have
“fishing” knowledge or that the individual needs further instructions (“what kind of
fishing?”). There is a loose coupling between goals required by a client (e.g. questions
on fishing) and the actual behaviors of an individual. Human’s react to events: a question
being asked, a car honks its horn, a closed door blocking our way. These events change
our view of the world. Change an individual’s view of the world and a behavior is elicited
as a result. How do you elicit a “salute” behavior from a soldier? Merely change their
world by standing in front of them wearing a type of military uniform. It was the task of
the soldier’s Drill Sergeant to “develop” the salute behavior in the soldier’s mind and
adding the trigger that stipulates when it should be executed. From this discussion, we
can see that a behavior needs a model of the world, a trigger to bring the behavior into
consciousness, and a definition of what the behavior is to accomplish (its intention).

An Agent has the following major components:

 Behaviors.
 Sequences
 A world model.
 Triggers which elicit a behavior.
Figure 3: Agent Components shows the relationship between the Agent components for
an Agent representing a forklift operating on a shop floor.

Figure 3: Agent Components


The Agent Grid 9

World Model

Each of us maintains a model in our mind of the world we live in. The model describes
the world as it is known to us, filtered by biases, experiences, and culture. Sometimes
the model becomes distorted or skewed. This model drives every behavior that we
maintain and exhibit. Two individuals may have the same world model but each reacts
differently by exhibiting different behaviors. Or they may have the same behaviors but
different world models which also affect which behaviors are exhibited. This is what
makes us unique. Without this world model, humans would not be able to function since
the model drives our behaviors. An Agent also maintains a model of its world. It is the
responsibility of the Agent designer to define the world model of an Agent. Agents have
the ability to augment or restrict their own world model at any point in time. And Agents
have the power to augment or restrict the world model of each other. This is part of the
learning capabilities of an Agent. Figure 4: Robotic Vacuum's World Model shows an
example world model (room) for an Agent controlling a robotic vacuum cleaner.
Interestingly, some commercial robotic vacuum cleaners do not maintain a world model.

Figure 4: Robotic Vacuum's World Model

World Model Conflicts

It cannot be expected that every human or Agent has the exact same world model.
Humans are able to function very well even when their world model is incomplete. For
example, suppose that I understand that a soccer ball has shape, size, and texture. But I
don’t know that a soccer ball has a color. Now someone comes to me and asks if I have
a green soccer ball. I could either not respond or utter a phrase such as “Do soccer balls
come in colors?” A conversation would ensue in which my world model of a soccer ball
would probably change to include color. This is part of learning. Now suppose that I
understand about color and I am asked if I have a soccer ball (no specified color). I could
either respond with “yes” or I could utter the response “will a green soccer ball suffice?”
These interactions are part of the Agent fabric which separates Agents from other
modeling facilities. World models may differ on two levels:


The Agent Grid 10

 Syntax. This implies that two models differ syntactically. This may be merely a
versioning issue or similar Agent models defined by different individuals. In our
example of soccer balls, our worlds match except one model defines “color” and
the other define “ballColor”.
 Semantic. This implies that two models differ on how they are semantically
modeling their world. In our example of soccer balls, one model may be
describing color on a number of levels in which they are including shading and
luminosity.
The resolution of differences between models of the two participating Agents is done at
interaction time. In other words, the Agent Grid will try very hard to ensure that two
Agents can affect work but it must ensure that both Agents should in fact be interacting.
The Agent Grid does not want to force two Agents to interact that should not be
interacting. From the resolution, the world model of both Agents may be affected.

Agent World Model

Within an Agent, the world model is represented as facts. For example, facts for an
airport include:

 Aircraft 591 taxiing on runway 51.
 Aircraft 100 requesting permission to land.
 Fire truck 111 at terminal 41.
Changes in the real world cause events that update an Agent’s world model. The facts
may also represent the state of the Agent itself. For example, an Agent may represent
an aircraft hence information about the aircraft (number of passengers, airspeed, and
fuel level) is maintained in the Agent’s world model.

The actual representation of the world model is in the form of XML. For example, a fact
about an aircraft would look as follows:

<aircraft><id>591</id><status>inFlight</status><fuel>20</fuel></aircraft>

An Agent designer would define the format of an aircraft fact as part of designing the
Agent. The format is in the form of an XML schema. Clients who wish to update the
world model of an Agent should use the XML schema of the Agent to submit facts.
However, Agents are intelligent enough to discern minor differences and resolve issues
concerning the format of facts when submitted by outside participants. The assumption
is that some outside organizations will define the XML schemas so that all Agents will
support well-known standard definitions of facts.

Behavior World Model

Behaviors can maintain their own world models. This allows a behavior to migrate from
one Agent to another and still be able to function. In essence, each behavior is able to
migrate and bring its own baggage. If this was not the case, a behavior would only be
able to execute within the confines of one Agent and the Agent Grid would not be able to


The Agent Grid 11

support reusability. When an Agent starts execution, the world model of each of its
behaviors is added to the Agent’s world model to create a single composite world model.

Stigmergic System

The Agent Grid is a stigmergic system. Stigmergic systems are self-organizing systems
where the participants use their environment for management and control with limited
interaction between the participants. Agents do not communicate directly with one
another; they merely affect each other’s world model. Stigmergic systems are very adept
at self-organization, self-tasking, and learning. When groups of fish school together it is
a result of stigmergic communication as oppose to having one “managing” fish that
instructs the other fish. Stigmergic systems do not have managing entities to control the
organization. Ants are another great example of a stigmergic system where large
colonies can organize without “managers” and with a very small set of behaviors. Figure
5: Stigmergic Forklift System shows two forklifts that are executing behaviors based on
their environment and not by instructing each other. In other words, forklift B has run out
of fuel but it does not broadcast a message to all other forklifts to stop their motors. In
addition, neither Forklift A or B needs to understand the entire world around them (i.e.
the entire shop floor). At minimum, they only understand the immediate area around
them. This is a subtle difference from standard software systems and has a great impact
in massively distributed systems where central control is impossible as well as complete
knowledge about the entire world.

Figure 5: Stigmergic Forklift System

Agents request goals from other Agents by affecting the world model of the destination
Agent. Figure 6: A Speech act results in an intention (start motor) shows the situation for
our stigmergic forklift system. Forklift A does not instruct Forklift B to start its motor. It
merely tells Forklift B that it needs its space on the shop floor. The intent is to have
Forklift B start its motor and move but Forklift A does not express that explicitly. Forklift B
is free to respond to the goal request in any way it finds feasible including not moving at
all. As another example, a person may tell their roommate that “The Trash is piling up in
the Kitchen” with the intention that the roommate should throw out the trash without
actually requesting the roommate to throw out the trash. There are in fact numerous
ways in which intent can be conveyed to an Agent.


The Agent Grid 12

Figure 6: A Speech act results in an intention (start motor)

Behaviors

Behaviors are software “chunks” of fairly succinct work. A behavior can be written in a
number of programming languages including Java, Pearl, and C++. The Agent Grid
supports two kinds of behaviors:

 Reactor – models behaviors within the human body which do not require
conscious thought such as reflexes (involuntary reactions to stimulus). Reactor
behaviors react to events within the environment. For example, “stop the car
when an object is 5 feet away” or “start ceiling sprinklers when heat exceeds x
degrees”.
 Procedure – Behaviors which react to goal requests. For example, “stop forklift
engine” or “open door”.
Future releases may see additional types of behaviors. Supporting behavior types
provides designers with greater latitude in designing software solutions. A designer can
create a reactor behavior to service a critical event and let the system control the
execution without having to define any further criteria. Behaviors are discussed in detail
later in this document.

Sequences

A sequence is a description of behaviors and Agents which are executed in a pre-
defined order. Sequences are also known as Agent-based workflows. Sequences allow
an Agent to construct complex actions from simple behaviors. In the human mind,
complex actions include “throwing a ball”, “exiting a room”. In the Agent world, complex
actions include “find recharging station”, “load delivery vehicle”. In the Artificial
Intelligence world, sequences are analogous to “plans” and “planning”. Sequences are
the predominant construct for solving goals within an Agent.


The Agent Grid 13

Triggers

A trigger is essentially a description of what the real world must look like if a particular
behavior is to be executed. For example, a trigger could be “rainfall of 4 inches” or “room
temperature of 100 degrees”. The trigger describes the future state of the world as it is
known by the Agent. Let’s take the airport example and assume that we have a world
model fact as follows:

<aircraft><id>591</id><status>inFlight</status><fuel>20</fuel></aircraft>

As fuel is consumed, the aircraft sends an electronic message containing the current
status of the aircraft. The values are extracted from the message received at a ground
station, and the fact within the world model of the aircraft’s Agent is updated. There is a
trigger defined in the Agent as follows:

(aircraft (id 591) (fuel <= 2))

The trigger says that when the fuel of the aircraft is less than 2, then trigger the
corresponding behavior. The behavior would undoubtedly generate the necessary
events to ensure that the aircraft is properly warned and all the necessary arrangements
are done to service the aircraft as soon as possible.

Designing an Agent

Designing an Agent involves four main steps:

 Creating the Agent.
 Defining the Agent’s world model format. This is accomplished using XML which
describes the world model in the form of a schema.
 Creating an initial real world model. These are the facts about the real world. For
example, there is a chair, table, and picture in a room. An initial world model is
not required in the design of an Agent. Other Agents on the grid as well as
behaviors added to the Agent will contribute to the world model of your Agent.
 Designing the behaviors and specifying the triggers for each individual behavior.
Behaviors, schemas, and world model facts can be added at any time during the
existence of an Agent.

Agent Life Cycle

Once designed, an Agent must be revealed to be used. Revealing an Agent makes the
Agent alive and makes the Agent’s behaviors available for execution. A revealed Agent
can be later hidden which causes the Agent to cease living. Enhancements to the
Agent’s pool of behaviors will persist once the Agent is hidden. However, changes to the
Agent’s world model will not persist unless requested. An Agent is revealed when it is
asked to achieve a goal or when the Agent is recruited for work. An Agent may be
identified by either it’s grid-wide numeric identifier, its name-version-status string
identifier, or via its classification (e.g. give me an Agent that adds two integer numbers).


The Agent Grid 14

Conversing with an Agent

So how does one communicate with an Agent and affect their world model? Messages
are sent to the Agent via a number of protocols. Messages can be sent from software
applications, from within Agent behaviors, from web browsers using URLs, or even
emailed to an Agent. The messages contain speech acts. Agent communication is
patterned off the theory of speech acts. Speech act theory provides a new dimension to
how objects communicate on the Grid. Speech act theory tells us that communication is
much more than mere request-responses. A request to a “service” in SOA is a pure
pattern match between the request and the service provider’s interfaces. In Speech act,
a request has more of an intention on the receiver (Agent). Communicating with an
Agent involves a performative. This is a keyword recognized by an Agent to indicate an
illocutionary act (the intentions of the speaker on behalf of the addressee). The following
are some of the performatives recognized by an Agent:

 Tell - indicates that the requester wants to add a fact to the world model of the
receiving Agent.
 UnTell - indicates that the requester wants to remove a fact from the world model
of the receiving Agent.
 Achieve - indicates that the requester wants the receiving Agent to achieve a
goal.
 Ask-Health - indicates that the requester wants to know the health of another
Agent.
 Reveal - indicates that the requester wants an Agent to start living.
Messages to an Agent consist of a performative followed by data relating to the
performative. For example, to indicate to an Agent that you wish to add a fact to their
world model, the message would look roughly as follows:

TELL “<aircraft><id>591</id><status>inFlight</status><fuel>20</fuel></aircraft>”

If the message does not fit the Agent’s world model, the Agent merely ignores it.

As mentioned, the Agent Grid supports conversing with Agents using a web browser.
The URL supports the expression of performatives, identification of the receiving Agent,
and parameters that are part of the performative. Figure 7: URL Access to an Agent
shows an example request to an Agent via a URL.


The Agent Grid 15

Figure 7: URL Access to an Agent

The “HomePage” goal is a well-known goal that is supported by all Agents. This paper
will not detail the well-known goals of every Agent but suffice it to say that the
“HomePage” goal generates a web page which describes all the goals of an Agent and
the necessary web page forms to converse with that Agent. It is a very handy means of
communicating with an Agent via a web browser.

The Agent Grid provides a Software Development Kit (SDK) to support developers who
wish to converse with Agents via programming languages. The Agent Grid currently
supports Java, C++, and Pearl. Figure 8: C++ Access to an Agent shows sample C++
code to request an Agent to achieve a goal.

Figure 8: C++ Access to an Agent

Behaviors

Behaviors serve as the basic building blocks of Agent. An Agent consists of a collection
or pool of behaviors which execute in reaction to changes in their world model. For
example, if a sensor for a robot detects heat, a behavior would execute to reduce any
immediate damage to the robot. Or if a temperature sensor within a room indicates a
potential fire, a behavior would execute to cause the overhead sprinklers to activate.
Unlike static software systems where code is designed, implemented, and deployed,
behaviors of an Agent may be added or removed or altered at any time. In addition, the
triggers which determine when behavior executes can be manipulated at any time as
well.


The Agent Grid 16

For those knowledgeable about object-oriented systems, behaviors may be thought of
as methods while an Agent may be thought of as an object. However, their relationship
stops there. Behaviors are much more powerful than methods and may migrate from
Agent to Agent. Methods of objects are tied to the object to which they were designed
because of their reliance on the state of the object. This does not hold for behaviors.
This section will introduce the concept of behaviors and their construction.

Behavior Types

The Agent Grid supports two types of behaviors. Other types are expected in future
revisions:

 Reactor – models behaviors within the human body which do not require
conscious thought such as reflexes (involuntary reactions to stimulus). Reactor
behaviors react to events within the environment. For example, “stop the car
when an object is 5 feet away” or “start ceiling sprinklers when heat exceeds x
degrees”.
 Procedure – Behaviors which react to goal requests. For example, “stop forklift
engine” or “open door”.

Reactor Behaviors

Reactor behaviors are always active during the life of an Agent. They react to changes in
the world model of the Agent. Reactor behaviors are designed to maintain constant
vigilance over the Agent. Reactor behaviors correspond to reflexes within a human. A
human reflex action bypasses all processing in the mind and responds directly to
stimulus. Agent reactor behaviors are intended to bypass all “execution flow” processing
in the Agent and execute immediately if triggered.

Designers constructing reactor behaviors should adhere to the following guidelines:

 May not assume the existence of another specific behavior.
 May not assume the order in which the behavior will be executed.
 During execution of the behavior, the behavior may not wait for a response from
another Agent. In other words, the behavior may not block waiting for a
response. If the behavior must request work from another Agent, the behavior
will submit the request and another behavior will be responsible for processing
the response.

Procedure Behaviors

Procedure behaviors correspond to complex behaviors in humans. Complex behaviors
in humans include sequenced actions such as saluting an officer, exiting a room, and
throwing a ball. These behaviors in humans are not reflexes. They are behaviors
specifically called upon when the world model in a human reaches a certain state. For
example, the “exit the room” behavior would occur when a business meeting ends.
Procedure behaviors in Agents are the same way. The behaviors may be a single
behavior or a sequence of behaviors (workflow). A procedure behavior is said to provide


The Agent Grid 17

a goal. For example, a goal called “exit-the-room”. To initiate the behavior, a client would
request that an Agent achieve a particular goal such as “I need to exit the room”. The
relationship between the client request and the corresponding procedure behavior in an
Agent is said to be loosely coupled. In other words, it should not be viewed as a service
invocation where the service names are well-known and the service parameters of the
behavior are well-known. However, the assumption is that the individual vertical
industries (e.g. manufacturing, medical, etc.) will define strict naming for goals as they
relate to their industry. It is up to the Agent designer to map well known goal invocations
to the triggering of procedure behaviors. At times, it may be one-to-one. At other times, it
may be quite complex. For example, a goal request of “Request an Ambulance” may
result in the triggering of a procedure behavior call “dispatch Ambulance” for an Agent
called “Jon’s Friendly Ambulance, Inc.”.

Default Execution Flow

When an Agent is first revealed (started), the behaviors of the Agent are placed in a
pool. The behaviors are then ordered by priority, criteria, and any other characteristics
defined by the Agent Grid system. Once complete, the behaviors are tested one at a
time. If the current state of the Agent’s world model triggers a behavior, that behavior is
executed to completion. The Agent then moves to the next behavior until all behaviors
have had an opportunity to execute. The process is repeated continuously to include
newly added behaviors and any changes to behavior priorities, criteria, or
characteristics. The general execution flow is defined by the designer of the Agent
Virtual Machine (AVM). The AVM is a software service that is responsible for defining
the execution flow of the Agent. Other forms of execution flow are possible merely by
providing a new AVM. AVMs will be introduced later in this paper.

Components of a Behavior

A behavior consists of the following components:

 Body – behavior code executed by the Agent (default in Java but other
programming languages such as Pearl and C++ are supported). Future versions
will allow web services to act as behavior bodies.
 Triggering or activation – world model event that will cause the behavior to come
into consciousness. The event could be either real-world driven or created by
another behavior (e.g. when dreams trigger behaviors such as running).
Activation only applies to reactive behaviors.
 Taxonomy / Classification – every trigger is defined within the context of a
taxonomy. Unless two Agents agree on a taxonomy, they cannot communicate
effectively. For example, two individuals who come from different cultures will find
it difficult to elicit specific behaviors from one another. In addition, a classification
can be added to the behavior to ensure competition only among behaviors with
the same classification. Sample classifications include “protective”, “exploration”,
“foraging”, “walking”).
 Coupler – descriptions that allow two behaviors to be coupled for the creation of
explicit behavior (deliberations). Couplers could be explicit specifications for a
behavior or it could be part of the triggering or activation.


The Agent Grid 18

 Goal – these are the changes made by the behavior to the external world or
internal world. The modifiers are used to trigger or activate other behaviors and
are used by the couplers. The behavior is not complete until its goals are
accomplished. These are essentially the “services” they provide. If a goal is to
“authorize an inpatient treatment” then any other Agent requesting that goal from
the Agent will recruit the Agent.
 Long Term Memory – represent the beliefs of an Agent containing the behavior.
The content of long-term memory changes depending on the Agent to which the
behavior belongs.
 Short Term Memory – Short-term memory contains local or global variables for a
behavior. The assumption is that the behavior is well aware of the well-known
names associated with short-term memory. Short-term memory is used to
support the execution of a particular behavior and is not intended to persist
longer that the life of a particular behavior.
 Context or World Model – Agents have a defined world model but so do
behaviors. The context or world model of a behavior defines a model specific to
the behavior regardless of the bounding Agent. This allows the behavior to be
shared among Agents. The behavior’s context is added to the Agent’s world
model when the behavior is attached to the Agent.
Figure 9: Behavior Components shows the components of a behavior.

Figure 9: Behavior Components


The Agent Grid 19

Behavior Body

The body of a behavior is implemented using the Java programming language. Any
industry Java IDE can be used to design a behavior. All behaviors consist of a class
definition with a public static void method called Behavior. The class name is the name
of the behavior merely by convention. The method name “Behavior” must remain
constant but all other parts of the Java class may be changed. For example, new
methods and attributes may be added. In addition, new import declarations may be
added. The following shows the basic behavior class definition for the behavior
“SampleBehavior”:

import com.Agentnet.system.*;
import com.Agentnet.daplet.*;
import java.io.IOException;
import com.Agentnet.clips.*;
import java.io.*;
import java.util.*;

public class SampleBehavior {

public static void Behavior (int AgentId,
int callerHdl,
int behaviorId,
byte[] converseOid,
int context) {
}
}

The static method Behavior contains 5 parameters. The parameter list cannot be
changed by the designer however the parameter names may be changed to suit the
designer.

 AgentId - handle (identifier) of the Agent containing this behavior. Behaviors may
execute under a number of different Agents during its life. The parameter
indicates the Agent under which this behavior is executing.
 callerHdl - handle (identifier) of the Agent which caused the invocation of this
behavior. This handle can be used to respond to the initiating Agent.
 behaviorId - handle (identifier) of this behavior. At times, the designer may wish
to retrieve further details of this behavior from the grid or may wish to change
aspects of the behavior such as the behavior context.
 converseOid - XML document containing any additional information required by
the behavior.
 context - identifier used to get access to the world model of the Agent containing
this behavior. Allows the designer to interrogate and manipulate the contents of
the Agent’s world model.
After designing the behavior, the behavior must be compiled. The generated byte stream
is then stored within one of the Grid’s Directory Services. Unlike traditional Java
systems, the compiled class is not stored on disk. When needed by an Agent, the


The Agent Grid 20

behavior byte contents are retrieved from the database and executed like any other Java
class.

Agent-Oriented Social Computing

The Agent Oriented Architecture (AOA) promotes a basic tenet that there will be
software entities out in the world that will provide capabilities but, most important, will
socialize to accomplish work. The social aspect will remain as the most fundamental and
important component of AOA systems. Within the context of the Agent Grid, this is
known as Agent-oriented social computing. Cobbling or assembling are other terms
used to describe the requirement that these entities must communicate to accomplish
work. However, we use the term social computing because the future entails more than
the mere assembling of entities as would be found in workflows or business processes.
The autonomous construction of software solution will be the holy grail of AOA systems.
These solutions will be cobbled from existing Agents and behaviors without human
intervention. The solutions may form and then disband after completion. Complete
autonomous software construction will only come about by using complex modeling
structures beyond workflows. Workflows and process flows are very limited forms of
social computing. True solution creation will come about using social structures such as
organizations and societies which allow Agents to form complete relationships with other
Agents. Whereas design patterns are used in the manual construction of object-based
software systems today, the Agent Grid uses social patterns and Organization Theory in
the automated construction and management of Agent Grid solutions. Social computing
will be used in four important aspects in Agent Grid solution automation:

 Self-generation. The ability for solutions to form based on a change in the
environment such as a new business need.
 Self-organization. The ability for solutions to change structure because of a
change in its environment.
 Self-optimization. The ability for solutions to change because of a reduction in
performance or diversion from best practices.
 Self-healing. The ability to resolve issues dealing with the health of the solution
such as an unavailable or misbehaving Agent.
In general, a social pattern is a defined set of relationships, behaviors, and structures
between participants. The pattern defines how the participants are organized and what
they can expect from each other under specific circumstances. Organization Theory
studies how participants are structured and how they interact based on their
environment. For example, a small company with few employees will support much
different organizations than a large company with many employees. Given the state of
the environment, Organization Theory can indicate the types of structures that will
appear under specific circumstances such as during the development of a software
product. Both social patterns and Organization theory can be applied to Agents to dictate
how they autonomously form relationships.

Let’s take an example. If two companies are to merge resources (employees, computer
systems, software), the process of automating the merge would be as follows:


The Agent Grid 21

 Describe the environment of both companies (employees, organizational charts,
computer networks) and allow an Agent Grid solution to form autonomously for
each company. The grids will form based on Organization Theory and social
patterns. Figure 10: Automatic Grid Generation shows an example Agent Grid
solution generation driven by an organizational chart and the computer network.
 Define the type of environment envisioned when two companies merge. For
example, the organization charts, the divisions, the tasks, etc. Then let the two
grids self-organize to the new environment. Figure 11: Agent Grid Self-
Organization shows a simple example of two company grids self-organizing. The
process would be monitored, tracked, evaluated, and optimized based on best
practices.
Figure 10: Automatic Grid Generation

Figure 11: Agent Grid Self-Organization


The Agent Grid 22

Societies

A society is the most basic social structure in the Agent Grid. Social patterns are evident
within the confines of a society. Every “cobbling” capability in the Agent Grid must occur
within the confines of a society. In fact, the society paradigm is the glue that ties all
existing and future cobbling capabilities. The concept of a society is defined by two
major aspects:

 Shared behaviors and Rules. These are the behaviors that bind the participants
of the society. They are shared by the participants and the participants are
expected to hold such behaviors. This would include basic tenets such as
obeying the law, speaking the same language (protocol) and paying local taxes.
 Defined Roles and Relationships. Participants are expected to fulfill certain roles
and relationships within the society. These may be well-known roles such as a
machine operator, a mechanic, a teacher, or a pupil.
Societies work or function because each individual member of that society plays
particular roles and each role carries a status and norms which are formed by the values
and beliefs of the culture of that society. The process of learning these roles and values
is called socialization.

In contrast, a society within the Agent Grid is defined by three major components:

 The Society behaviors.
 The Society relationships.
 Supported social patterns.
These components define how the society should form and the types of agents expected
in the society.

There are two aspects to social computing for Agent Grids:

 Social skills of each Agent. In humans and Agents, these skills overlap and
include listening, respecting distance, recognizing the feelings of others, taking
turns.
 Social Patterns. In human terms, these are technology tools that allow us to
socialize such as email, blogs, and chat rooms. In Agent Grids, these are
workflows, process flows, and organizational structures.
Social Skills are commonly defined as those specific behavioral strategies that allow one
to initiate and maintain positive social interactions with others. The intent is to embed
these skills within Agents in the form of behaviors. The behaviors will be used during
socialization processes. These social skills are the same skills adults and children use in
constructing new friendships, forming groups, or solving tasks. Some of the envisioned
skills include:

 Sharing. Agents will offer their behaviors to other Agents dependent on policies
and security.
 Compromising.


The Agent Grid 23

 Survival. There will be behaviors in an Agent that ensure their internal goals
override all others. This may includes requirements to prevent sensitive company
data from being released from the Agent. Or requests for services that are
considered detrimental to the Agent such as removing a fact from the Agent’s
world model.
 Friendship. An Agent will form a special bond with other Agents to support the
direct sharing of behaviors. For example, suppose that an Agent needs help in
supporting a goal and it determines that one specific Agent is always able to
respond. That Agent may be given preferential treatment.
 Knowing rules. This is the support of policies that define the overall behavior of
the Agent and any societies that it participants in.
 Flexibility. Allowing behaviors to be added or removed from the Agent.
 Winning and losing. This is about competition. We will add certain criteria that an
Agent must strive to achieve. For example, responding to requests within a
certain time frame. Or ensuring that all requests are answered (no missing
behaviors). If an Agent loses (does not fulfill a criteria), then it will try to find ways
of achieving that criteria such as collaborating with other Agents to achieve its
goals.

Design and Implementation

This section will discuss the design and implementation of the Agent Grid. Specifically,
the software services (components) that are required to run the Agent Grid. These
services can be categorized as follows:

 Grid Services. These are services that support the grid technology itself as
oppose to the Agent features.
 Agent Services. These are services designed to support Agent technology.
 Vertical Market Services. These are services designed to support a specific
vertical market. These services will not be discussed in this paper.

The Grid Router Service

The Grid Router service is a grid service that provides a key role in the Agent Grid. The
Grid Router can be viewed in the same context as physical network routers found on
LANs. Unlike network routers, Grid Routers do not have a defined area of responsibility
so a Grid Router is not guaranteed to see every message that passes through the grid.
However, if there is only one Grid Router servicing a small local grid then that router will
in fact see all messages traveling through the grid. The basic rule of the Agent Grid and
of Grid Routers is that a message between participants on the grid must travel through
at least one router. The Grid Router provides a number of important features for the
Agent Grid including:

 Agent Discovery and Message Routing. All messages that travel through the grid
must pass through at least one grid router. Since Agents are identified with a
logical identifier, the Grid Router is responsible for translating the logical identifier
into a physical identifier (i.e. IP Address). The Grid Router may use other grid


The Agent Grid 24

services to do the actual translation (e.g. Discovery Service) however the Grid
Router is responsible for initiating and terminating the discovery process. Once
the Agent is discovered, the Grid Router is then responsible for determining
where the Agent is to execute (see discussion in section “Agent Discovery”).
 Protocol Translation. The Grid Router accepts network messages in a number of
protocols including the default Agent Grid message protocol (called “Daplets”).
The Grid Router may receive Agent messages in the form of HTTP requests,
Web SOAP calls, and any other protocol that the Agent Grid defines acceptable.
In addition, the Grid Router will return messages to a caller in the protocol in
which the message was first received. Hence, a Web Browser would submit an
Agent message in the form of HTTP and would get a response from an Agent in
HTTP format for display as shown in Figure 12: Grid Router Protocol Translation
(From HTTP to Agent Grid).
 Service Launching. The Grid Router has the ability to launch software services
upon request or when required by the Grid. The Agent Grid Directory Service
maintains information about software services such as the host location, the
location on disk, and any required parameters. The Grid Router has the ability to
communicate with any launched software service.

Figure 12: Grid Router Protocol Translation (From HTTP to Agent Grid)

The Grid Router supports any application that uses TCP/IP as its communication
protocol. However, the application must be using an application protocol that the Grid
Router understands. The Grid Router listens on a number of ports. These ports are
either defined by the Agent Grid or by industry standards (ICANN) such as the SNMP
ports.

The Global Directory Service

The Agent Grid Directory Service is a database that provides metadata for the grid. The
Agent Grid supports any number of Directory Services. These databases provide
information on how to locate an Agent/service (White Pages), how to locate a class of


The Agent Grid 25

Agents/services (Yellow Pages), or how to locate descriptive information about an
Agent/service such as on which host to execute an Agent. Directory Services are
typically distributed throughout the infrastructure. Agent metadata may be partitioned
among several Directory Services in order to reduce contention. There is no requirement
that each Grid Router be given its own Directory Service. Directory Services will be
deployed depending on issues such as the organization it is servicing or the amount of
visibility required. Figure 13: Grid Routers and Directory Services shows an Agent Grid
with Grid Routers and the Directory Services. Retrieving the metadata of an Agent may
require the request to meander through the network until it finally finds a Grid Router that
has access to the Directory Service containing the metadata. In massively distributed
solutions, the Agents are typically partitioned/regionalized along with their metadata.
Hence, only Agents within a region compete for a particular Directory Service.

Figure 13: Grid Routers and Directory Services

The Grid Infrastructure

The Agent Grid can be configured in a number of ways to accommodate the size of the
solution. The Agent Grid is a peer-to-peer solution. When we refer to a grid infrastructure
we are implying a network where Agents will be executing on multiple hosts. This is
typically the case when multiple vendors are part of a business solution and the vendors
will be executing their Agents on their side of the firewall. The connection points within
the Agent Grid are represented by Grid Routers as discussed in section “The Grid
Router Service”. To extend the Grid, Grid Routers are added to key host computers. The
Agent Grid Directory Service maintains information about the available Grid Routers that


The Agent Grid 26

it knows about. This information is loaded into a Grid Router’s memory on startup. Grid
Routers also update their in-memory tables during quiet points in their execution. A Grid
Router should be installed on any machine that needs to execute an Agent. This is
needed if the Router is to launch an Agent Virtual Machine application whose task is to
execute Agents.

There are two key concepts that are involved when executing distributed infrastructures
such as the Agent Grid:

 Object Discovery - process of locating an object via a Global Directory Service.
 Object Metadata - maintaining descriptive information about an object. This
would include all the data related to the design of the Agent (for example, its
behaviors).
Object Discovery is provided by the Agent Grid Directory Services. At this time, object
metadata is also provided by the Directory Services. Future releases will certainly see
this change with the separation of data to two distinct databases.

If a request arrives to a Grid Router to access a particular Agent, the Grid Router
executes the following steps:

 Requests Agent Discovery via the Directory Services service. The Router needs
to locate the description of the Agent (see Chapter “Agent Discovery” for a
description of the process).
 If the Agent description is found, the contents are examined to determine if the
Agent needs to execute on a particular host.
 If an Agent does not specify a host or if the Grid Router has access to the host,
then launch a special software service called the Agent Virtual Machine (AVM)
on that host and submit the request to the AVM. The AVM is responsible for
executing the Agent.
 If an Agent does specify a host and the Router does not have access to that
host, locate the Grid Router that has access to that host and pass on the request
to that Router.

Agent Discovery

A major capability of the Agent Grid is Agent discovery. Agent discovery is defined as
that task which translates a logical Agent identifier to a physical definition of the Agent.
Participants on the Agent Grid will locate Agents via their logical identifier, name,
classification, criteria, etc. The component responsible for Agent discovery is the Grid
Router. That may change in future releases as the Agent discovery capability matures.
Object discovery is a large, complex research subject. Agent discovery in the Agent Grid
will undoubtedly change and evolve over time to include new technologies and the
support of industry standards such as LDAP.


The Agent Grid 27

Agent Services

Agent services are those services that directly support the execution of Agents. The full
set of Agent Services includes:

 Agent Virtual Machine (AVM) - responsible for providing the execution
environment for an Agent. Agents must execute within the confines of an AVM.
This is much like the case that a Java program must execute within the confines
of a Java Virtual Machine.
 Semantic (MatchMaker) Service - responsible for applying discovery services
involving more complex capabilities such as constraints and semantic data. The
Semantic Service will not be discussed in this paper.
 Conversation Service - responsible for controlling complex conversation styles
between Agents beyond those styles handled by the Grid Router and AVM. The
Conversation Service will not be discussed in this paper.
The Agent Virtual Machine (AVM) is the critical service required to support Agents. An
Agent is a collection of behaviors but has no capability to execute by itself. Given a set
of behaviors for an Agent, it’s the AVM that sets up the environment to allow behaviors
to execute. Figure 14: The Agent Virtual Machine shows the relationship between the
AVM and the other services on the grid. The AVM can support any number of Agents.
The Grid Router launches the AVM when it receives a message destined to the Agent.

Figure 14: The Agent Virtual Machine

The Agent Virtual Machine

Whereas the Agent represents a collection of behaviors, it’s the Agent Virtual Machine
(AVM) that represents the processing part of the human mind. The AVM is a software
server that can execute Agent definitions. The Agent definitions are stored in the Grid
Directory Services and extracted to the AVM and executed. Figure 15: Network
Execution Flow shows the execution flow of the AVM on the Grid. The Agent definition
includes the behaviors, knowledge (mental model & pre-defined knowledge base), and
run-time behavior description.


The Agent Grid 28

The Artificial Intelligence aspect of an Agent is embodied in the AVM. It’s envisioned that
the AVM will be the most redesigned component of the Agent Grid. There will be many
3rd party versions of the AVM and integrators will position for the best and most human-
like AVM. This was the intent of the design in which the behaviors and the engine that
executes the behaviors are separate. The AVM also incorporates all the social behaviors
attributed to the Agents. And we envision that any changes which relate to artificial life
are embedded with the AVM.

Figure 15: Network Execution Flow

The AVM is a software server. The AVM waits for requests from the participants on the
Grid. Typical requests include revealing an Agent, telling something to an Agent, hiding
an Agent, and asking an Agent about itself. The AVM routes a request in the form of a
performative to the correct controller. A controller is software code that manages either
one Agent or a society of Agents. The controller processes performatives destined to its
society/ Agent. Controllers do not directly communicate with its Agents. The controller is
primarily responsible for manipulating the world model for its society/Agent.

The most important responsibility of the AVM is the processing of Agent behaviors.
Agents consist of behavior pools. These behaviors are triggered into consciousness by
the state of the world model. However, this is a very simplistic view of how the human
mind works. Humans have many behaviors which conflict with each other. Most humans
would run when a building they are occupying catches fire. But this would not be an
admirable behavior for a fireman. Fireman still maintains behaviors which will cause
them to flee a building (for example, when the fire is out of control). However, their
behaviors to stay and fight a fire have a higher “priority” than their behaviors to flee.
Training ensures that their behaviors are prioritized appropriately. The AVM needs to be
able to model this type of prioritization. There are other aspects of human behavior
management that must be modeled within the AVM. The modeling capabilities of an
AVM must include:

 The ability to prioritize behaviors and the ability to manipulate the priorities in
real-time.


The Agent Grid 29

 The ability to disable behaviors. This implies that a disabled behavior will no
longer participate in behavior selection. The behavior may still exist but it won’t
be selected unless enabled.
 The ability to add behaviors to the behavior pool in real-time. This supports
learning capabilities.

AVM Architecture

An AVM is a software server designed to interpret and execute Agent definitions. The
Agent Grid does not enforce a specific architecture of an AVM. Vendors and developers
are free to define the architecture of their associated AVMs. The sample AVM allocates
a collection of software threads to handle an Agent or society definition. The threads are
defined as follows:

 Society/Agent Controller - this thread represents a society if executing a society
or an Agent if the execution consists of a solo Agent.
 Agent Coordinator - this thread represents a single Agent.
 Reactor - this thread handles the execution of an Agent’s reactive and procedural
behaviors.
 Coordinator - this thread handles situations where multiple Agents are
collaborating to solve a goal.
 Deliberator - this thread handles Agent sequences.

AVM Data Resources

The AVM data resources include the in-memory knowledge bases supporting each
Agent and the behavior pools. Each Agent has its own knowledge base structured
according to its mental model and populated by facts pre-defined for the Agent and
added to by other Agents on the grid. For the most part, the data resources are kept
distinct.

The Daplet

Agents and services communicate by exchanging messages called Daplets (short for
Data Applets). A daplet is a collection of datums in which each datum represents a piece
of data such as an integer, string, code. Datums can be constructed in many
configurations which allow a daplet to be as expressive as XML data, database records,
and any other structured data. Daplets also contain a number of innovations that
separate them from simple messages including:

 X400-like header which includes features such as security signatures, priority,
sensitivity level, and routing information (in-reply-to, reply-to).
 Ability to encrypt or compress at the datum level.
 Information on how to process the daplet for vendor specific formatting.
 Special hidden sections for system-only information.


The Agent Grid 30

 Ability to push portions of the message out to the network for performance
reasons before the entire message has been constructed.
 Ability to hold an unlimited amount of data for sending large data streams.
Datums are known as TNLVs (Type-Name-Length-Value). They consist of a type
indicator, a name value, a length value, and the actual data value itself. For example, a
datum containing an employee title would look as follows:

TYPE: string
NAME: employeeTitle
LENGTH: 6
VALUE: “execVP”

The corresponding record in XML would look as follows:

<TNLV>
<TYPE>string</TYPE>
<NAME>employeeTitle</NAME>
<LENGTH>6</LENGTH>
<VALUE>execVP</VALUE>
</TNLV>

Datums take up less space than their corresponding XML representation. Datums also
contain advance features such as:

 Ability to encrypt or compress the data contents (value).
 Ability to assign a conversation identifier to indicate datums relating to a
conversation stream between Agents.
 Ability to control the structure of the datum. For example, to remove any
indication of a name within the datum. This reduces the size of the datum and
increases the amount of information that can be sent on the network within a
single network packet.


The Agent Grid

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (19)

Semelhante a The Agent Grid

Semelhante a The Agent Grid (20)

Mais de Larry Suarez

Mais de Larry Suarez (9)

Último

Último (20)

The Agent Grid