Pitfalls of Agent Projects Borrowed from Nick Jennings University of Southampton, UK

Pragmatics of Agent-Oriented Developments  Lots of (single and multi-) agent projects But pragmatics of agent-oriented development received little attention.  Here identify number of key pitfalls. political; management; conceptual; analysis and design; micro (agent) level; macro (society) level; Jennings and Wooldridge

You Oversell Agents  Agents are not magic If you can’t do it with ordinary software, probably can’t do it with agents. No evidence that any system developed using agent technology could not have been built using non-agent techniques.  Agents may make it easier to solve certain classes of problem but they do not make the impossible possible.  Agents are not AI by a back door. Agents have not solved all the problems that have dogged AI since its inception Political Pitfalls

Get Dogmatic about Agents  Agents used in wide range of applications, but they are not a universal solution. For many applications, conventional software paradigms (e.g., OO) are more appropriate. Given a problem for which an agent and a non-agent approach appear equally good, prefer non-agent solution!  Other form of dogma believing in your agent definition and shoe-horning solution to fit this

Management Pitfalls Don’t Know Why You Want Agents  Agents = new technology = lots of hype! “Agents will generate US$2.6 billion in revenue by the year 2000”  Managerial reaction: “we can get 10% of that”  Managers propose agent projects without having clear idea idea about what “having agents” will buy them.  No business plan for the project: pure research? technology vendor? solutions vendor?  Often, projects appear to be going well. (“We have agents!”) But no vision about where to go with them. understand your reasons for attempting agent development project, and what you expect to gain from it

Management Pitfalls Want Generic Solutions to 1-Off Problems  Devising a “generic” architecture/testbed, when really need a bespoke system. Re-use is difficult to attain unless development is undertaken for a close knit range of problems with similar characteristics.  General solutions are more difficult and more costly to develop often need extensive tailoring to target application

Conceptual Pitfalls Believe Agents = Silver Bullet  Holy grail of software engineering is a “silver bullet”: order of magnitude improvement in software development.  Many technologies promoted as silver bullet: COBOL automatic programming expert systems graphical programming  Agent technology is not a silver bullet. Good reasons to believe that agents are a useful way of tackling some problems. But these arguments largely untested in practice.

Conceptual Pitfalls Forget Agents are Software  Agent system development is essentially experimentation No tried and trusted techniques (at present)  Encourages developers to forget developing software Project plans focus on the agenty bits. Mundane software engineering (requirements analysis, specification, design, verification, testing) is forgotten.  Result a foregone conclusion: project flounders, not because agent problems, but because basic software engineering ignored. any principled software development technique is better than none.

Conceptual Pitfalls Forget Agents are Multi-Threaded Software  Multi-threaded software: one of most complex classes of computer system to design and implement. Significant background experience in distributed and concurrent computing areas  Multi-agent system tend to be multi-threaded both within and between agents need to recognise and plan for things such as:  synchronisation  mutual exclusion for shared resources  deadlock

Analysis and Design Pitfalls Don’t Ignore Related Technology  Percentage of system that is agent-specific is comparatively small. “intelligent agents are 99% computer science and 1% AI” (Etzioni,96)  Important conventional technologies and techniques are exploited wherever possible. Don’t reinvent the wheel.  CORBA  Database technology  Expert system shells

Analysis and Design Pitfalls Don’t Exploit Concurrency  One of most obvious features of a poor multi-agent design is that amount of concurrent problem solving is small. Serial processing in distributed system Only ever a single thread of control:  concurrency, one of the most important potential advantages of multi-agent solutions not exploited.

Analysis and Design Pitfalls You ignore legacy  When building systems using new technology, often an assumption that it is necessary to start from a “blank slate”. However in many cases, most important components of a software system will be legacy:  functionally essential, but technologically obsolete software components, which cannot readily be rebuilt.  When proposing a new software solution, essential to work with such components. They need to be incorporated into an agent layer.

Agent Level Pitfalls Want Your Own Architecture  Architecture: design for building agents. Many have been proposed over the years.  Great temptation to imagine you need your own “not designed here” mindset; intellectual property.  Problems: architecture development takes years; no clear payback.  Recommendation: buy one, take one off the shelf, or do without.

Agent Level Pitfalls Use Too Much AI  Temptation to focus on “intelligent” aspects of the application. an agent framework too overburdened with experimental AI techniques to be usable. fuelled by “feature envy”  Resist temptation to believe such features are essential in your system: build agents with a minimum of AI; success is obtained with such systems, progressively evolve them into richer systems.

Micro (Agent) Level Pitfalls No AI  Don’t call your on-off switch an agent!  Be realistic: find everyday distributed systems referred to as multi-agent systems. Web pages with any behind the scenes processing as “agents”.  Problems: lead to the term “agent” losing any meaning raises expectations of software recipients leads to cynicism on the part of software developers.

Macro (Society) Level Pitfalls See Agents Everywhere  “Pure” A-O system = everything is an agent! agents for addition, subtraction,…  Naively viewing everything as an agent is inappropriate. choose the right grain size. more than 10 agents = big system.

Macro (Society) Level Pitfalls Too Few Agents  While some designers imagine a separate agent for every possible task. Others don’t recognise value of a multi-agent approach at all. Create system with very small number of agents doing all the work  fails software engineering test of coherence.  result is like OO program with 1 class.

Macro (Society) Level Pitfalls Implementing Infrastructure  Presently, no widely-used software platforms for developing agents Such platforms provide basic infrastructure required to create a multi-agent system. The result: everyone builds their own.  By the time this is developed, project resources gone!  No effort devoted to agent-specifics.

Macro (Society) Level Pitfalls Agents Interact too Freely  Numerous systems interacting with one another can generate behaviour more complex than sum of parts good: exploit this emergent functionality to provide simple, robust cooperative behaviour bad: emergent behaviour akin to chaos  restrict way agents interact  simplest possible protocol for achieving set objective

Macro (Society) Level Pitfalls System Lacks Structure  Common misconception is that agent systems require no real structuring throw together agents and see what happens!  While this may be true in some cases, in majority of situations, considerable amount of system-level engineering takes place especially for large scale systems or where need some commonality of purpose structure helps:  reduce system’s complexity  increase efficiency  more accurately model problem at hand

Conclusions  Agent technology is immature and largely untested. Agent system developers often fall into the same traps. Described what we perceive to be most common and most serious of these pitfalls. Thereby shift attention to pragmatics of agent system engineering.

Further Reading  N. R. Jennings, P. Faratin, A. R. Lomuscio, S. Parsons, C. Sierra and M. Wooldridge (2001) “Automated negotiation: prospects, methods and challenges” Int. J. of Group Decision and Negotiation 10 (2).  F. Zambonelli, N. R. Jennings, and M. Wooldridge (2001) "Organisational rules as an abstraction for the analysis and design of multi-agent systems" Int J. of Software Engineering and Knowledge Engineering.  N. R. Jennings, P. Faratin, T. J. Norman, P. O'Brien and B. Odgers (2000) “Autonomous agents for business process management” Int. Journal of Applied Artificial Intelligence 14 (2)  N. R. Jennings, P. Faratin, T. J. Norman, P. O'Brien, B. Odgers and J. L. Alty (2000) “Implementing a business process management system using ADEPT: A Real-World Case Study” Int. Journal of Applied AI 14 (5)  N. Vulkan and N. R. Jennings (2000) “Efficient mechanisms for the supply of services in multi-agent environments” Int Journal of Decision Support Systems 28(1-2)  M. Wooldridge, N. R. Jennings, and D. Kinny (2000) “The Gaia methodology for agent-oriented analysis and design” Journal of Autonomous Agents and Multi-Agent Systems 3 (3)  M. J. Wooldridge and N. R. Jennings, (1999) “Software engineering with agents: pitfalls and pratfalls” IEEE Internet Computing 3 (3)