Pitfalls of Agent Projects

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

2. 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

3. Political Pitfalls 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

4. 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

5. 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

6. 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

7. 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.

8. 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.

9. 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

10. 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

11. 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.

12. 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.

13. 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.

14. 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.

15. 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.

16. 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.

17. 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.

18. 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.

19. 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

20. 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

21. 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.

22. 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) 145-189. • 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) 421-465. • 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) 5-19. • 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) 285-312. • M. J. Wooldridge and N. R. Jennings, (1999) “Software engineering with agents: pitfalls and pratfalls” IEEE Internet Computing 3 (3) 20-27.