Agent Object

 

AIS Definition of an Agent

For our definition of a Software Agent we aspire to the weak notion of agency plus we even reach further and aspire to the strong notion of agency; however, we accept the point of view of the agent-oriented detractors: that a software agent is just like any other computer program. In our case we would even go further (than the agent-oriented detractors) and claim that, for our purposes, a software agent is a restricted version of a general computer program. The restrictions being namely those restrictions which would allow the computer program to be stored in an agent-oriented database as a piece of data, and the restrictions which would allow the computer program to be passed around the Internet as a piece of data.

Our strategy is to first define a small insignificant executable software object which will storable as a fundamental unit of data in an AIS repository and will be mobile between copies of Agent Information Server across the Internet. We will name this clearly defined and concretely instantiated insignificant software object, an Agent. In an of itself, our agent will in no way be intelligent; however, each of our executable objects (agents) will the following rudamentary abilities.

From here forward, these concrete AIS executable objects will be called Software Agents. We make no claim that these agents are intelligent or are in any way better than other computer programs.

The second part of our strategy is to build and evolve large numbers of software agents, which operate together in agent communities to perform increasingly complex tasks. In these development activities we aspire to the the weak notion of agency and we even reach further and aspire to the strong notion of agency. However, we still make no claims about our executable objects (agents) being in any way better than other computer programs. We simply present the interested observer with the fruits of our development efforts: agent communities of ever increasing complexity. We let the interested observers determine, from their own point of view, which (if any) of these increasingly complex communities of agents exhibit behavior which might have some of the emerging properties of intelligence.

Executable Objects

An AIS agent is a concrete executable software object building block that is a fundamental unit of data stored in an AIS repository, and is mobile between copies of Agent Information Server across the Internet. We make no a priori claims about the eventual capability of these agent objects; instead, we let any positive properties emerge naturally as the communities of these interacting agents become more complex. In this manner of thinking, intelligence is not really a property of any one software agent object; instead, intelligence is an emerging property of a whole complex community of executable agent objects. For instance, it is very difficult to isolate any one human neural cell and make the claim that this particular cell is intelligent. However, one can grow billions of human neural cells in a complex interacting community (the human brain) under such conditions that most interested observers would consider the whole community of neural cells intelligent.

AIS agents are concrete executable software objects with the following rudimentary capabilities. Agents are designed to work together in communities of other agents forming complex adaptive applications. Agents can communicate with other agents in the system, sharing information.  An Agent can reconfigure itself. If a situation arises that requires an agent to perform a new action, the agent can reproduce another agent and direct that agent to perform a different set of tasks. An agent has the rudimentary capability being goal-oriented, and may collaborate with other agents to accomplish its goals. Agents have the ability to learn. Agents can be written in multiple computer languages, and can be executed under the control of multiple virtual machines. Agents can personalize the presentation of information. Agents can be asked to automatically perform small or tedious tasks such as locating a specific piece of information, or filtering through a large database looking for a set of conditions. Agents have the ability to execute at microchip-level speeds.

The ability of agents to modify themselves as they learn and to interact with communities of other agents, sharing knowledge and goals, presents opportunities for the development of powerful, adaptive data analysis solutions. Agent data analysis applications may have adaptive user interfaces which learn the needs of different users and which adjust to changing data conditions.

Multiple Computer Languages

Each AIS agent is a concrete executable software object building block that is a fundamental unit of data stored in an AIS repository. Multiple computer languages can be expressed as executable agent objects. Agent Information Server currently comes with a built-in Lisp compiler, a JavaScript compiler, an XML compiler, a natural language chatbot compiler, various agent query language compilers, and there is even an agent community which acts as a feature-based compiler compiler. It is certainly possible, and is currently often the practice to have communities of agents which are not all produced by the same compiler. For instance, there are examples of parent agents written in Lisp which have child agents written in JavaScript and vice versa.

Agent Information Server is agnostic in the choice of agent programming language. It is often the case that one computer language is preferable for certain data analysis applications while yet another computer language is preferable for other data analysis applications. AIS comes equipped with several agent compilers and rule-based tools for the easy creation of additional user-defined agent programming languages. The only caveat is that popular computer languages implemented in Agent Information Server must be tailored to produce our executable agent objects, and to operate within the AIS runtime environment. AIS compiler development tools are not designed to create compilers for execution outside Agent Information Server.

Multiple Virtual Machines

AIS Agents are designed to be write-once-run-anywhere executable objects. This is accomplished via the virtual machine concept of software agent execution. Agent virtual machines are designed to be mapped onto the actual host microchip at the server location, providing faithful agent execution wherever the agent may travel on the Internet. There are currently several virtual machines operating within Agent Information Server. The DRM virtual machine uses a Dynamically typed Register Machine model to provide portable agent execution from high level dynamically typed instructions all the way to super fast microchip-level register execution. The DRM virtual machine runs in emulation mode during the debug phase of agent development; while, during normal operation, the DRM virtual machine's just-in-time (JIT) compiler automatically converts Agents to run in the NATIVE code of the host machine. The NATIVE code is a faithful machine language translation of the execution rules in the DRM virtual machine onto the actual host microchip at the server location. DRM NATIVE virtual machine code always runs at microchip-level execution speeds.

Agent Information Server is agnostic in the choice of agent virtual machine. It is certainly possible, and is currently often the practice to have communities of agents which are not all running on the same virtual machine. It is often the case that one virtual machine model is preferable for certain data analysis applications while yet another virtual machine model is preferable for other data analysis applications. AIS comes equipped with several agent virtual machines and loadable library tools for the easy creation of additional user-defined agent virtual machines. The only caveat is that popular virtual machines (such as the Python, Java, or Smalltalk virtual machines) implemented in Agent Information Server must be tailored to execute our executable agent objects, and to operate within the AIS runtime environment. AIS virtual machine development tools are not designed to create virtual machines for execution outside Agent Information Server.

Microchip-level Execution Speeds

Agent Information Server is primarily concerned with software agents which perform high volume data analysis. Super fast execution speed is essential in such application domains. There are several levels of general computer program execution speeds. Disk based operations, such as those performed by SQL and other database system languages, are among the slowest executing animals in the program zoo. The next level of faster execution speed is achieved by programs performing memory to memory operations, such as those performed by COBOL and many other business languages. The fastest possible level of program execution is achieved by programs performing register to register operations on the microchip, such as those performed by assembler language.

The AIS DRM virtual machine provides very fast native execution of agents performing disk based operations, memory to memory operations, and microchip-level register to register operations. Regardless of the data analysis domain, AIS allows the development of write-once-run-anywhere agents which execute at the fastest possible speeds.

Multiple Programming Paradigms

AIS Agents are designed to operate in many different programming paradigms. Agent Information Server is agnostic in the choice of agent programming paradigm. It is often the case that one programming paradigm is preferable for certain data analysis applications while yet another programming paradigm is preferable for other data analysis applications. AIS provides basic services and tools for: register to register programming; functional programming; object oriented programming; agent oriented programming; rule based programming; evolutionary programming; and natural language programming paradigms.

AIS comes equipped with basic services and tools for the easy creation of additional user-defined agent programming paradigms. The only caveat is that popular programming paradigms (such as the object oriented, evolutionary, or register to register) implemented in Agent Information Server must be tailored to execute our executable agent objects, and to operate within the AIS runtime environment. AIS programming paradigm development tools are not designed to create programming paradigms for execution outside Agent Information Server.

Agent Properties

The Agent object stores agent behavior and knowledge in a standard building block format (regardless of the original source language). The Agent Information Server Agent object contains the following properties:

 

Av: The arguments Structure object containing the Agent's arguments.
EvalWhenDoomed: The EvalWhenDoomed: property is set true iff the agent is to be evaluated, by the garbage collector, when it is doomed.
In: The faces: Structure object containing the Agent's published interface styles, current plans, goals, current capabilities, and any other information acquired during the learning stage.
Pc: The Pcode Vector object containing the Agent's virtual machine codes.
Pv: The pvars: Structure object containing the Agent's persistent variables.
Sv: The svars: Structure object containing the Agent's self object variables.
Cv: The cvars: Structure object containing the Agent's persistent class variables
Rv: The regs: Structure object containing the Agent's register variables
Nc: The Native Code Vector object containing the Agent's native machine code.
Sc: The Source Code Vector containing the original language source for debugger display and recreation of the original agent.
Tv: The vars: Structure object containing the Agent's temporary frame variables.
Vm: The Virtual Machine execution function (each Agent may run on a separate virtual machine).

 

An Agent is a First Class Object. A First Class object in Agent Information Server is any object that is fully exposed, i.e., all of the Structures are visible and modifiable by the other agents in the system. All Agents have the following data structure elements: source code (Sc), pseudo code instructions (Pc), argument variables (Av), self object variables (Sv), persistent variables (Pv), persistent class variables (Cv), register variables (Rv), temporary variables (Tv), interfaces (In), native code (Nc), and the virtual machine emulator (Vm). All Agent structures can viewed and modified by the programmer:

Dot Operator

Each property is represented internally as a Structure Object. Any of the Agent object properties can be displayed by referencing the Agent and the property name using the Lisp or JavaScript dot operator (see the ref function).

The Lisp lambda function always returns an Agent:

   (setq anAgent (lambda(x)

                                    faces:((english true))

                                    pvars:(p1)

                                    cvars:(c1)

                                    vars: (t1)

                                    regs: ((r1 Integer))

                                    (defun child(x) (/ x p1))

                                    (setq p1 100)))

Any of the Agent properties may be referenced with the Lisp or JavaScript dot operator:

anAgent.Pv Returns The Structure #{p1: #void   child: #<Agent 1234>}
anAgent.Cv Returns The Structure #{c1: #void}
anAgent.Tv Returns The Structure #{t1: #void}
anAgent.Rv Returns The Structure #{r1: Integer}
anAgent.In Returns The Structure #{ english: true }
anAgent.EvalWhenDoomed Returns false
anAgent.Cv.c1 Returns The value of the variable c1

 

Any of the persistent (Pv) attributes may be referenced directly with the dot operator:

anAgent.p1 Returns The singleton #void
anAgent.child Returns The Agent #<Agent 1234>

 

The special ref1 agent method may be used to set up an abstract Agent event handler, which captures all access attempts (somewhat like a cell membrane):

   (setq anAgent (lambda(x)

                                    faces:((english true))

                                    pvars:(p1)

                                    cvars:(c1)

                                    vars: (t1)

                                    (defun child(x) (/ x p1))

                                    (defun ref1(s) (writeln "Please do not touch my " s))

                                    (setq p1 100)))

 

Notes & Hints

The ref1 agent method captures all access attempts (somewhat like an abstract cell membrane). When any other agent in the system attempts the following access anAgent.child, the access attempt will be intercepted and the String "Please do not touch my child" will be returned.

Agent Event Handling

Agent Information Server Agents are not designed to be run alone. They are designed to be run in small, medium, or large communities of other agents. As the size of an agent community increases, its behavior can become increasingly complex, increasingly clever or intellgent. During the course of your contact with AIS, your will hear about many very complex agents (such as the Alice natural language chat robot, or the parseAgent compiler compiler agent). In actual fact, Alice and parseAgent are not single agents. They are large agent communities, working together to produce useful and complex results.

Any large community of agents must designate some agents to perform interface activities for the community. Agents in the community cannot all be equal. Many agents, inside the community, must specialize in specific behaviors for the good of entire community. Multiple internal areas of specialization is often the key to increasingly intelligent behavior.

In order for the terms inside and outside to make sense, when referring to an agent community, the community must designate one or more agents to perform all interface tasks with other "outside" agents. The designated interface agents create an application interface supporting access conventions, for the community as a whole. Among other tasks, these access conventions protect the community's internal agents from undesired access (analogous to the protections provided by a cell membrane or the skin of a biological community).

The simplest method for designating one or more agents to perform all interface tasks is by proclamation. The designated interface agents and the suported application interface and access conventions are published. Other external agents are expected to behave honorably and abide by the published conventions. In situations where the trust between agents is not absolute, Agent Information Server allows agents to inforce published access conventions, by making these reinforced agents aware of any access attempts by other external agents. Access attempts on any AIS agent are called events. Any AIS agent object may be made event aware. There are a number of designated events (which are described in the next section).

The following example shows how Agent Information Server supports event handling for all Agents (see the table of Reserved Agent Methods). Certain predefined events create conditions to which an Agent may respond (if the designer so chooses). An interesting example of Agent Information Server event handling support, is that an Agent may be made aware of any attempt to access it. For instance, in the following nearly identical Agents, one is access aware and the other is not.

The parent1 agent, shown below, is unaware of the access attempts from any other agents.

    (defun parent1(x)

          pvars:(p1)

          (setq p1 x))

The parent2 agent, shown below, is aware of all access attempts from any other agents and responds to the access attempt as programmed.

    (defun parent2(x)

          pvars:(p1)

          (defun ref1(member) (* (myself).Pv[member] (myself).Pv[member]))

          (defun set1(member) "Ouch! Please do not touch me.")

          (setq p1 x))

 

Notes & Hints

For example, we can set the persistent memory of the parent1 and the parent2 agents to see how an event unaware agent reponds versus how an event aware agent responds. The results are quite different depending upon whether the event unaware or the event aware agent is accessed.

(parent1 10) Returns 10
parent1.p1 Returns 10
(setq parent1.p1 5) Returns true
parent1.p1 Returns 5
(parent2 10) Returns 10
parent2.p1 Returns 100
(setq parent2.p1 5) Returns "Ouch! Please do not touch me."

Reserved Agent Methods

An agent community's designated interface agents and suported application interface and access conventions are published via proclamation in the Interfaces section of each agent, and other external agents are expected to behave honorably and abide by the published conventions. In situations where the trust between agents is not absolute, Agent Information Server allows agents to inforce published access conventions, by making these reinforced agents aware of any access attempts by other external agents. Access attempts on any AIS agent are called events. Any AIS agent object may be made event aware.

Agent Information Server supports reserved agent methods (child agents) each of which has a special access event which it captures and manages. The reserved agent methods (if present) monitor and control actions taken upon the agent in response to these special access events, and can enforce the published access conventions of the agent community. These reserved methods are:

Method Trigger Event Syntax Description of captured event
abortTrans (abortTransaction anAgent) Called when the abortTransaction built-in function attempts to abort a transaction with the agent.
beginTrans (beginTransaction anAgent) Called when the beginTransaction built-in function attempts to begin a transaction with the agent.
commitTrans (commitTransaction anAgent) Called when the commitTransaction built-in function attempts to close a transaction with the agent.
doClear (clear anAgent) Called when the clear built-in function attempts to clear the contents of the agent.
length (length anAgent) Called when the length built-in function requests the size of the agent.
new (copy anAgent)
(new anAgent)
Called when the copy or new built-in functions attempt to clone or copy the agent.
ref1 (ref anAgent x:)
anAgent.x
anAgent[0]
Called when the ref built-in function, the dot operator, or the bracket operator attempt to access the agent with a single index argument.
ref2 (ref anAgent 0 2)
anAgent[0 2]
Called when the ref built-in function or the bracket operator attempt to access the agent with two index arguments.
ref3 (ref anAgent 0 x: 5)
anAgent[0 x: 2]
Called when the ref built-in function or the bracket operator attempt to access the agent with three index arguments.
set1 (set anAgent x: newValue)
(setq anAgent.x newValue)
(setq anAgent[0] newValue)
Called when the set built-in function, the dot operator, or the bracket operator attempt to alter the agent with a single index argument.
set2 (set anAgent 0 2 newValue)
(setq anAgent[0 2] newValue)
Called when the set built-in function or the bracket operator attempt to alter the agent with two index arguments.
set3 (set anAgent 0 x: 5 newValue)
(setq anAgent[0 x: 2] newValue)
Called when the set built-in function or the bracket operator attempt to alter the agent with three index arguments.
refImport (importTab anAgent fileName) Called when the importTab built-in function attempts to import ascii tab delimited data directly into the agent.

 

Notes & Hints

The refImport agent method captures all give me your next import record container requests by the built-in importTab function as it imports the contents of an ascii tab delimited file, record by record, directly into the agent.

setImport (importTab anAgent fileName) Called when the importTab built-in function attempts to import ascii tab delimited data directly into the agent.

 

Notes & Hints

The setImport agent method captures all please take this filled import record container requests by the built-in importTab function as it imports the contents of an ascii tab delimited file, record by record, directly into the agent.

refExport (exportTab anAgent fileName) Called when the exportTab built-in function attempts to export ascii tab delimited data directly from the agent.

 

Notes & Hints

The refExport agent method captures all give me your next export record requests by the built-in exportTab function as it exports the contents of agent directly into an ascii tab delimited file, record by record.

Doomed Agents

One of the most important events occurs at the end of an agent's life span, just before the agent is destroyed. When an agent object is not longer referenced, the garbage collector may choose to destroy the agent. Before final destruction takes place, the agent will be sent a doomed message.

Each Agent's EvalWhenDoomed property is initially set to false. Normally, garbage collecting an Agent, causes nothing to happen (other than the destruction of the agent); however, if the Agent??s EvalWhenDoomed property is set to true, then the doomed agent is evaluated by the garbage collector BEFORE final destruction.

For instance, the following Agent community opens a file and performs operations to the open file during the life span of the agent. When the agent is destroyed, we do not wish the file to be left open. The closeLog child agent has the task of responding to the doomed event and closing the file before final destruction.

This example shows how several Agent's in a community can work together to open a file, keep it open during the life of the agent, and close the file before the agent is destroyed.

(defun fileLog()

          pvars:(logFileHandle)

          (defun closeLog() (setq logFileHandle (fileClose logFileHandle)))

          (defun openLog(fileName)

                 (setq logFileHandle (fileOpen fileName))

                 (setq closeLog.EvalWhenDoomed true))

          (defun writeLog(record) (fileWrite logFileHandle record))

          ;; Initialization

          (setq logFileHandle false)

          (setq closeLog.EvalWhenDoomed false)

          true)

Internet Security

Agent Information Server enforces strict Internet security as its default mode of operation. Obviously, for any agent database system, Internet security is a fundamental issue. Rather than suffer an unfortunate security breach, AIS enforces strict Internet security at all times.

Agent Information Server supports three Internet (TCP/IP) protocols: HTML, XML, and AMP (Agent Message Protocol) which is an XML extension protocol. Unless an agent declares itself as public (in the Interface section of the agent object), the agent remains unavailable to all Internet clients regardless of which protocol is being used by the client.

The AMP protocol allows individual agents to be accessed by Internet clients being served by Agent Information Server. The AMP protocol supports user security levels from 0 (lowest) to 7 (highest). In order to be available to an Internet client, using the AMP protocol, an agent object must publish its availability in its Interfaces section. The following example agent is accessable by AMP Internet clients with security levels of five or higher.

    (defun clientHelper(msg)

          faces:(;; This agent's interface proclamations

                       (public Amp:) ;; Is available to AIS clients using the AMP protocol

                       (security 5) ;; A client security level of five or higher is required

                       ) ; end of Interfaces proclmations

          pvars:(p1)

          (eval msg))

 

Notes & Hints

Further details on the AMP Internet protocol may be found in the Agent Message protocols reference guide.