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