My intent is that this page will eventually evolve into a full-blown Software Agent Manifesto, but for now it is simply the starting point(s) for such a "manifesto".
This web page details my current thinking about software agents. Some are rather clear and I have a high level of confidence in them. Others are murky and I have no real confidence. Over time I hope that all of my thoughts become quite clear. Or maybe the frontiers of my thoughts will just keep moving and I'll always still have just as many unclear thoughts.
The manifesto is designed to suggest a long-term (10-20 years) vision for software agents, not a short-term roadmap.
For the most part, the manifesto is a set of requirements that 'need' to be met to build a new software agent industry. Some requirements relate to encouraging additional research and others stem from the difficulties in moving software agent technologies from the research lab into industrial-grade real-world environments.
At present, there is no particular order to the points. They are merely ordered as a stream of consciousness.
Any definitions in the domain of software agents should be based first on standard English and then on established computer science, software art, and software practice. Then, we can start getting creative with additional terminology.
I have attempted to compile a lexicon of English words that might be relevant for discourse on software agents.
I need a little more time before I come up with a definitive definitions of "agent", "software agent", etc. First I want to elaborate a concept I have called "dimensions of agency" which will be a long shopping list of characteristics of agents. After I organize that shopping list I hope to come up with a fairly small number of broad categories of characteristics of agents and use that as the basis for defining a number of specialized categories of agents. Then I hope to generalize and finally come up with a simple definition of agent that takes on a variety of variations are adjectives are added.
Before even beginning that whole collection of tasks, I first want to summarize the variety of usages of the term "agent" that I have run across in my research.
For my current definition of the term 'software agent', click here.
My feeling is that agents are a new paradigm for software design that subsumes the existing software paradigms. First, a software agents is still a computer program. Some existing programs would be considered to be agents and the rest are "degenerate" cases of agents that would be recognized as agents if extended or "wrapped" with additional functionality. Not all agents are created equal and given the large number of possible characteristics of agents, it is possible that the overlap between two perfectly valid agents might be nil.
Much of the "work" in an agent should be pushed down into a common infrastructure so that agents will be as simple as possible and less error-prone.
Rather than the developer or user having to 'manage' each software agent, the infrastructure needs to have sufficient knowledge of the purpose, intent, and state of the agent so that the infrastructure can assure that the agent performs as expected. This includes performing activities automatically whenever possible and detecting fault conditions in the agent. A sufficiently robust, smart software agent infrastructure could be referred to as an Agent Operating System.
Well, technically yes, but not really. Typically a daemon performs a closely related set of tasks for more than one user (e.g., mail server, http server).
Yes and no, depending on how you wish to define intelligence. Certainly there are plenty of opportunities and benefits of 'intelligent software agents', but simply working towards an interesting goal without direct user supervision should be sufficient to classify a computer program as a software agent. There is also the issue of what level of sophisticated computing rises to the level of machine intelligence.
Certainly we want to enable software agents to exhibit levels of intelligence far beyond those exhibited by legacy software.
The need for autonomy by itself requires that a software agent be 'smart' enough to deal with dynamic contingencies that may not have been anticipated by the developer.
Finally, note that a significant amount of the 'intelligence' of a software agent will actually be embodied down in the smart infrastructure and the web services that the agent uses. And, a relatively 'dumb' agent could appear quite intelligent simply by utilizing the services of other, more intelligent software agents.
No. Back in the old days, mobility was a required characteristic to get around the lack of sufficient connectivity, but nowadays computer programs can frequently access resources directly across the net. There are still applications and devices that may exploit mobility, but for most applications it is not required.
Although a software agent tends to operate autonomously (without interaction with the user), it's quite acceptable for the software agent to have a user interface for initiation, reporting results, or even periodically interacting with the user to confirm decisions (e.g., "I found this great deal... Should we take it?"). Also, there should ALWAYS be a way for the user to be able to 'recall' the agent, either to stop it, modify its goal, or simply to query its status. The important thing is that the user does not have to feel 'tethered' to the software agent with an application window.
A robot requires two types of software: an interface to the real world and higher-level planning and control software. The latter can be quite similar to a software agent, so we can think of a robot's software as a software agents plus the real-world interface software. In addition, there is no reason why a software agent could not migrate across a communications link in much the same way a software agent could migrate across a network. In fact, a robot could have sufficient memory and compute power to simultaneously support a number of software agents in a single robot. They could all simultaneously process the robot's input, but obviously there would need to be some level of control (negotiation) if more than one software agent sought to control the output effect of the robot. Also, software agents running in different robots could coordinate their computing to coordinate the operation of the robots in the real world. Note that the software agents do not actually have to physically run inside the robot, but could run on the net and communicate with a 'stub' of the higher-level robot software which resided on the net. But if the robot was intended to operate disconnected from the net at times, then obviously the software agent code would have to migrate (or hopefully be automatically migrated) into the physical robot.
A robot could be micro-miniaturized, even down to the level of nanotechnology (presuming you design a nano-computer with sufficient nano-memory to run a reasonable amount of software), so the comments concerning the similarity of software and the higher-level software of a robot can be relevant to a nano-scale robot as well. Given very simple nano-robots, it might be that a software agent does not actually control or migrate into the nano-robot, but rather goes through a process that takes a statement of the desired behavior of the nano-robot and actually builds ('compiles') the detailed design of the nano-robot from the specification. Conceptually, there could also be 'helper nano-robots' that could 'communicate' between the fielded nano-robot and some 'home office'. That same 'helper' function could be used with macro-scale robots as well (i.e., a sophisticated version of a carrier pigeon).
In any case, there is tremendous potential for cross-fertilization between the field of software agents, robotics, and nanotechnology.
Software agents are an ideal mechanism for conceptualizing, designing and implementing distributed artificial intelligence applications.
Software agents are an ideal mechanism for conceptualizing, designing and implementing distributed computing applications. In fact, I would go so far as to say that software agents are the single best approach to distributed computing.
It would be very, very useful for agent servers to utilize the concepts of the old IBM VM operating system so that software agents (especially those with horrible bugs or even malicious viruses) could run in a 100% sand-boxed mode so that people don't have to worry about security and 'wild software agents'.
Part of the benefit of a true VM sand-box is that it provides a 'parallel universe' microcosm in which the software agent can think that it has access to real resources, but is in fact dealing with virtual resources. The same concept should be provided for the net so that software agents could be tested against the 'production' net without the virtually impossible task of replicating the entire net in a separate sand-box. The basic idea is that the agent can access the actual net resources as long as it is not modifying them, and any attempted modification (e.g., invoking a web service to perform an action or make a commitment) would perform a 'copy-on-write' operation which would copy the invoked service into a new sand-box so that the copy of the invoked service would now be running in the invoking agent's 'parallel universe'. Transitive closure would then keep pulling invoked agents into the parallel universe on an as-needed basis.
Ala the human body and IBM's Autonomic Computing Initiative, the underlying software agent infrastructure would have a variety of always-running monitoring and control mechanisms to facilitate operation of software agents and to allow developers and 'the software agent police' to suspend, interrogate, debug, restart, or shutdown an entire collection of software agents that are running as part of an application, as well as monitoring and controlling all applications that are using particular software agents.
I believe that software agents are the single best approach to implement parallel computing on the net.
The 'grid' is a great way for organizing compute resources on the net, but interacting software agents are the great way for organizing computations to run on the grid.
Actually, there is no technical difference at all! It's all a matter of intent, perception, and effect. They are both computer programs that run in a networked environment. The difference is that a software agent causes no 'harm' whereas a software virus does cause harm. But, if a software agent has bugs and does cause harm, should it not be thought of as a software virus? And if a software virus has bugs which prevent it from having its intended harmful effects, is it not then behaving merely as a benign software agent? The point is that the net's software and users may not be able to tell whether they are looking at a bad software agent or a benign software virus. The other point is that the software agent infrastructure should be designed so that the net and users have excellent 'defense mechanism' to protect against both software viruses and rogue software agents. Developing a much more robust net 'autonomic monitoring and control system' would be a single stone to kill two birds.
My simple definition of a software agent is that it is a computer program that exhibits the characteristics of software agency, with autonomy being the primary characteristic. Part of the reason for this definition is to allow for the possibility that legacy computer programs could be retrofitted to include at least some of the characteristics of software agency. A big old server-based app may not be mobile or very flexible, but it does have at least some sense of autonomy from 'the user'. It should be possible to embed intelligence modules and agent communications protocol modules in a legacy app so that the app can look and talk to software agents on the net as if the legacy app really was a newly designed software agent itself.
I myself am certainly not in a position to expound on beliefs about how the human brain works and is organized, but I do raise the question as to whether current approaches to interacting software agents represent a subset of what the human brain is capable of or are in fact a step or leap beyond the human brain. Are we mimicking or extending? Is each agent (or small clusters of agents) simply an element of 'thought'? Is a web full of software agents still far short of 'intelligence' or is it a new 'collective, shared brain' that allows us to each act as if we had a bigger and better brain?
Somehow, it seems that even a single software agent has the potential to be an extension of a human brain, assuming that the software agent has sufficient machine intelligence and that the communications interface is sufficiently compatible with human thought and discourse.
Could we back a bunch of software agents in a PDA such that 'we' (us and our PDA working seamlessly together) are more intelligent? Maybe 'PDA' should be conceptually changed to 'PBE' for 'Personal Brain Extension' or is it 'PIE' for 'Personal Intelligence Extension'. The terminology for brain, intelligence, knowledge, self, presence, and personality gets rather fuzzy. The point is not how to discuss the human brain itself, but the combination of a human and one or more software agents and the hardware devices needed to support those software agents.
Whether by design, intent, or merely bugs, a software agent may be perceived as being a rogue software agent. The goal is that the autonomous smart agent infrastructure should have enough defensive capabilities to detect and deal with rogue software agents and prevent harm to the net and communities of software agents, service providers, and users.
Despite the current plague of email-based software viruses, in principle there is no good reason not to use a mechanism similar to email to transport agents and to provide a platform for their execution. A common use would be to send a smart survey to a user which would be a software agent that would then run in the user's environment and then communicate back to the sender. Obviously there need to be defense mechanisms and a flexible permissions system so that users could decline such software agents, possibly by listing out the kinds of tasks or questions that will be entertained.
In addition to interacting with web services and other software agents, a software agent could also initiate communications with real-world users, such as in my email survey example, or via instant messages. Obviously such a capability could be abused by the computing equivalent of telemarketers, but within companies, organizations, or limited communities, the capability could be extremely beneficial.
A robust set of defense mechanisms will be needed to protect user privacy any time a software agent is attempting to interact with a real-world user. An entire hierarchy of capabilities, by domain, will be needed so that the user can optimize the benefits of gaining services from inbound software agents while protecting their own privacy and the value of their time.
The idea that the average software agent will go around visiting host computers on the net is absurd. For a small network that might make sense, but in a web of thousands, millions, and even billions of host computers that makes little sense. The goal is that the software agent is interested in making contact with one or more services, resources, or users.
In some cases the software agent simply wishes to "select one" out of the many possibilities, so it wants to call upon the services of a broker who then consults a distributed registry of services.
In other cases, the software agent does want to interact with all (or a designated portion) of the population that match a set of criteria. Once again, a matching broker service seems more appropriate rather than each agent laboriously traipsing around the net knocking on every door like a cold-caller.
If a number of hosts match the request, then the theory should be to broadcast a request (or the agent "code" itself) to the sub-population of matches and exploit the parallel execution of the various hosts.
Many real-world problems can be tackled more effectively if pursued in parallel rather than sequentially.
A restatement of the merits of pursuing parallel execution of software agents. The goal is to get as much code as possible running in parallel so that more useful work can be accomplished per unit of time. In this sense, software agents can be a "time machine" enabling us to travel into the future faster than at the snail's pace of traditional programming paradigms..
This is the focus on goals rather than tasks. Declare the overall requirements for the solution and let the smart agent infrastructure analyze and decompose the requirements and repackage for more efficient execution.
Much of the work of a software developer is spent taking a conceptual design and packaging it in terms of lines of code, functions, modules, and programs and deciding how those programs will be deployed on various host computers. All of this packaging is essential for execution, but actually interferes with the ability of a smart infrastructure to analyze the design and dynamically package elements of the design to execute the overall design more effectively on a network and to do so in a way that exploits redundancy and massive parallelism.
Methods and tools are needed to permit software developers to focus more attention on the design of computations and less attention on packaging decisions that should be left to the smart infrastructure.
We could also refer to the smart infrastructure as the Computation Operating System.
The idea is that you "code" declarations (equations) and the "compiler" generates sub-agents, tables, and code that monitor the dependencies and update variables or trigger code (or software agents) based on changes in the environment. Most of the processing to achieve constraint management should reside down in the smart software agent infrastructure.
Programs should declare (register) to the smart software agent infrastructure what data and events are of interest so that the program can go into idle mode while awaiting the conditions of interest. In many cases, the smart infrastructure can perform responses automatically as directed by the declarations without requiring the program to gain direct control. Polling can be error-prone and consume far too much resources when the dependencies are great.
Software agents can automate the process of seeking and accessing resources on the net. The user may not know where to look or how to behave when resources are located.
Manually and consciously exploiting parallelism is difficult and interferes with the user's though processes. Software agents and the smart infrastructure can automate and otherwise facilitate the process.
Information overload is all about giving the user both more than they want and more than they can handle. Software agents have the potential to trim away the excess and reformulate what remains so that a much smaller fraction of the user's time and cognitive capacity is needed.
Program languages, communications protocols, database systems, and the smart infrastructure should allow the programmer and user alike to manipulate knowledge, ideas, concepts, and wisdom to be manipulated and accessed as easily as numbers and strings are today.
The idea is no to do the things we do today faster (or even "better"), but to eliminate the tasks we do today and to open up whole new worlds of discourse that enrich our lives.
First, stop thinking about programs that run on the PC or a server and think of the PC as a Personal Computing Access Device (PCAD) which is a combination of a window into all of the personal computations that are running on the user's behalf (either locally or out on the net) combined with some amount of local storage and compute power needed for interactive tasks and when temporarily disconnected from the net.
The user should be able to run a program on another PC or server as easily and transparently as locally. Software agents can run locally or elsewhere on the net. Most importantly, the smart infrastructure can morph a single agent (or collection of agents) so that some parts will run locally or on the net as seems optimal to the infrastructure. The user and the software agents should see one seamless computing environment whether running or accessing resources locally or on the net. Code and intermediate results could be cached on the local PCAD so that net disconnection merely degrades performance, but does not impede the correct function of the users personal computations.
The user and software agents should not have to worry about how, when, and where to cache code, data, and code execution to optimize the performance of individual personal computations. Caching should be a robust, transparent, and automatic function of the smart agent infrastructure.
Software agent code and execution can be pushed out towards the resources that they need more efficient access to. Also, if many more than one computation on the net requires execution of the same agent (or requirements common to different agents), the common computation could be pushed to a more efficient host and then intermediate results broadcast to interested parties.
Similarly, the repository for a data item could be migrated to be closer to its users rather than be forced to live near the host where it is generated. Once again, the code that may generate the data item should not care or be dependent on where the data-item officially resides.
The nice thing about a language like LISP is that the code and data format is identical. Programs should be able to easily query, generate, and modify code stored not as ASCII text, but in its abstract semantic form. Conversely, programs can be written to execute or interpret information stored in abstract semantic form.
There should be a bias towards programming in the form of requirements and declarations which can be both directly manipulated as if they were data, and processed and optimized on a more global level by the smart agent infrastructure.
The single most important test of whether the concepts related to software agents are ready for prime time is whether they can be applied usefully to all forms of software, including interactive applications, operating systems, device drivers, BIOS code, PDAs, cell phones, embedded systems, compilers and other software development tools, etc.
Software Agents are not just for AI applications.
Software agent technology is not even yet really in its infancy. The next 2-3 years will be the time when people begin to grasp the vision for software agents, but research efforts are still too tentative to be the basis for the true flowering of the potential for software agents. As such, we should all be very prepared for an extended period of waves of irrational exuberance and dashed hopes. But, out of each stage of failure will come knowledge and conviction that the subsequent stages will be better and more successful.
Software agents are computer programs. Java may be in vogue right now, but LISP or C++ may be 'better' for any number of reasons. The software agent infrastructure should not bias itself to one programming language.
There should be a machine-independent intermediate language (whether it is similar to the Java Virtual Machine (JVM), the Intel x86, or something new). The idea is that the developer can code in whatever programming language fits the application and then compile the source code into the Software Agent Intermediate Language (SAIL). An agent server may choose to either directly execute SAIL (ala the JVM), or further compile it into a machine-dependent binary code.
Since the local host may have special security requirements or limitations or privacy concerns, it may request that one or more standard code filters be applied to the SAIL code to verify that the code for the software agent will be 'safe' on the host computer. The SACS would only need to run the filters once for each compilation of the SAIL code.
Marketers and software developers spend inordinate amounts of time and resources designing the packaging of code into computer software applications. That's fine if your needs approximately match the packaged software's functions, but frequently (or usually) they do not.
What we need are better methods and tools so that the underlying software design can be represented in a form that can be dynamically reconfigured to meet the specific needs of subgroups or even specific users. A typical user or class of user at a large organization may only need 15% of the functions of the so-called application, but may also need those functions to be customized to more dramatically improve the productivity and effectiveness of the users.
The actual application packaging should be more in the way of hints on how the software should be presented. System integrators could then be able to easily modify or extend those hints to cause the software to be morphed into a form that more closely approximates the end-user and organizational needs.
System integrators should be able to fix and match subsets of the overall application computation to meet specific needs.
The application packaging decisions made by the vender's marketing and software developers should be the starting point, rather than the end point of the packaging.
It is difficult and indeed counterproductive to attempt radical innovation by merely incrementally extending an existing technology ad infinitum. The burden of 100% backward compatibility simply stifles creative thinking and creative energy.
It is better to focus on leapfrog advances that are completely unconstrained by current technology and market 'needs'. Only by passing into such brave new worlds can we truly comprehend the power and potential of the new technology.
Then, and only then, can we begin to contemplate how to backfill subsets of the new technology into legacy platforms and applications.
We can then ping-pong between the old and the new worlds, allowing each to guide the other.
At some stage, the gap between the two can become conceptually small enough that legacy uses can be shifted to the new world.
In short, backfilling is important, but is still secondary to the leapfrog advances.
It should be possible for a pool of software agents to share and jointly manipulate a pool of knowledge without the need for explicit communications (such as using an agent communication language or protocol). The details of how to update and control the knowledgebase would be done autonomously by the smart infrastructure. Developers should be able to think about a collection of software agents as simply as they currently think about a collection of functions.
Even will the adoption of software agent technology, the needs, methodologies, and tools of software engineering are still as important as ever. Although software agents may provide a somewhat higher-level abstraction for design, there is still a need for software engineering to focus on user requirements and the process of mapping user requirements to software features.
One change would be to put a higher emphasis on matching the goals of software agents with the requirements of users and the fact than many of the 'details' of software development (and even software engineering) would be automated and autonomously implemented by the smart software agent infrastructure rather than laboriously massaged by the software 'engineer'.
Software agents work towards goals by manipulating raw data or information and knowledge 'snippets' in various stages of refinement. We could view the work of a software agent as simply knowledge refinement. A side effect of the processing of one or more software agents is the production of software agent artifacts. These might be intermediate results, a detailed knowledgebase, or final results ready to be presented to a user. Some will be of direct interest to the user and some will be only of interest to software agent developers. But they will all be of interest to someone. The smart infrastructure should treat all of them as interesting and provide tools for cataloging, accessing, and manipulating them. They should not simply be treated as bits in a communications stream that are used once and discarded. In fact, the bits in a communication stream will tend to merely be summaries of the software agent artifacts as they exist in their 'proper' repositories.
Although software agents can undoubtedly be used to optimize and enhance existing tasks, their real promise is to act as an enabling technology to permit people to pursue goals that might have been even unimaginable with pre-agent legacy technology. Instead of building a better mousetrap, why not build a device that can harness the best abilities of the mouse and extend and exploit them in a socially beneficial manner (and hopefully enhance the mouse's quality of life at the same time).
It is absolutely critical that as much of the technical innovation as possible be free and openly available to stimulate the vast amount of development that will be needed simply just to get the software agent 'movement' moving. That is not to say that for-profit venders can't retain ownership of their products, but the extent to which key technologies are kept proprietary will hinder development of the industry.
Venders should think very carefully about the extent to which their business models are based on licensing products at high fees versus open source products and earning income from providing services.
The extent to which basic software agent technologies are patented and require payments of fees is the extent to which development of the industry will be impeded.
That said, there is no reason why any particular implementation of software agent technologies can't be patented or provided under proprietary license fees. In other words, as long as there are a wide variety of free implementations of each type of black box, there is no reason why some implementations of each type of black box cannot be proprietary.
In general, protocols and reference implementations of the handlers for those protocols should be free and open source.
But proprietary implementations that add significant value (e.g., higher performance or scalability and capacity) for high-end industrial-grade systems should certainly be encouraged. But adding features which would tend to cause 'lock-in' to a vender are to be highly discouraged.
Larger software agents, analogous to current personal computing applications, tend to work on goals that have apparent meaning to the user or the organization. These are macroscopic software agents.
Smaller software agents, more analogous to individual functions or objects, and sometimes referred to as sub-agents or fractional agents, tend to work on portions or fractions of goals or sub-goals that might not even be recognizable at the user or organization level. These are microscopic software agents.
Of course, there is no reason that a user-level or organization-level goal can't be pursued by a very small agent or why a sub-goal can't have a very large, even multi-agent, manifestation.
A macroscopic software agent may frequently have a user interface for occasionally interacting with a user to collaboratively work towards a goal, but it is far less likely that a microscopic agent would ever interact with a user.
For a historical version of my original (dated) thinking about software agents, click here.
Please contact us with any questions or comments.
Updated: November 04, 2005 05:08:09 PM -0500
Copyright © 2003 John W. Krupansky d/b/a Base Technology