Agent Infrastructure Michael Luck University of Southampton, UK

Agent Infrastructure

Michael LuckUniversity of Southampton, UK

Part I

The Case for Agent-Oriented Software Engineering

with slides borrowed from Nick Jennings

Remote Agent Experiment (RAX)

Deep Space One mission to validate technologies

AI software in primary command of a spacecraft

RAX

Comprises• planner/scheduler to

generate plans for general mission goals

• smart executive to execute plans

• Mode identification and recovery to detect failures

Goals not pre-planned so more flexible

Tests include simulated failures

Tests in May 1999

Agents

Relatively new field (10-15 years?) Dramatic growth Popularity Increasing numbers of applications Multi-disciplinary Problems:

• Agent backlash?• Sound conceptual foundation?

6

Agent-Based Computing: A New Synthesis for AI and CSIncreasing number of systems viewed in terms of agents:

• as a theoretical model of computation more closely reflects current computing reality than

Turing Machines

• as a model for engineering distributed software systems better suited than object-orientation, design patterns and

software architectures

• as a model for conceptualising and building intelligent entities framework for unifying piecemeal specialisations

Which Perspective?

Answer from many points of view from philosophical to pragmatic

Proceed from standpoint of using agent-based software to solve complex, real-world problems

8

Software Development is Difficult One of most complex construction task humans

undertake “Computer science is the first engineering discipline ever in which the complexity of the objects created is limited by the skill of the creator and not limited by the strength of the raw materials. If steel beams were infinitely strong and couldn’t ever bend no matter what you did, then skyscrapers could be as complicated as computers.” Brian K. Reid

True whatever models and techniques are applied “the essential complexity of software” Fred Brooks

Software engineering provides models & techniques that make it easier to handle this essential complexity

Software Development is Getting Harder Shorter development lifecycles More ambitious requirements Less certain requirements

• Greater scope for change More challenging environments

• Greater dynamism• Greater openness

• interacting agents

Software Engineering: Continually Playing Catch Up

Better Models• components• design patterns• software

architectures

Better Processes• light methods• heavier methods

“Our ability to imagine complex applications will always exceed our ability to develop them”

Grady Booch

The Adequacy Hypothesis

Agent-oriented approaches can enhance our ability to model,

design and build complex distributed software systems.

The Essence of Agent-Based Computing

13

“encapsulated computer system, situated in some environment, and capable of flexible autonomous action in that environment in order to meet its design objectives” (Wooldridge)

Agent

14

“encapsulated computer system, situated in some environment, and capable of flexible autonomousautonomous action in that environment in order

to meet its design objectives” (Wooldridge)

Agent

control over internal state and over own behaviour

15

“encapsulated computer system, situatedsituated in some environmentin some environment, and capable of flexible autonomous action in that environment in order


Agent


experiences environment through sensors and acts through effectors

16

“encapsulated computer system, situated in some environment, and capable of flexibleflexible autonomous action in that environment in order


Agent

reactive: respond in timely fashion to environmental change

proactive: act in anticipation of future goals


experiences environment through sensors and acts through effectors

Definitional Malaise

“My guess is that object-oriented programming will be what structured programming was in the 1970s. Everybody will be in favour of it. Every manufacturer will promote his product as supporting it. Every manager will pay lip service to it. Every programmer will practice it (differently). And no one will know just what it is.” (Rentsch, 82)

“My guess is that agent-based computing will be what object-oriented programming was in the 1980s. Everybody will be in favour of it. Every manufacturer will promote his product as supporting it. Every manager will pay lip service to it. Every programmer will practice it (differently). And no one will know just what it is.” (Jennings, 00)

18

Multiple Agents

In most cases, single agent is insufficient

• no such thing as a single agent system (!?)• multiple agents are the norm, to represent:

natural decentralisation multiple loci of control multiple perspectives competing interests

19

Agent Interactions

Interaction between agents is inevitable• to achieve individual objectives, to manage inter-

dependencies Conceptualised as taking place at knowledge-

level • which goals, at what time, by whom, what for

Flexible run-time initiation and responses• cf. design-time, hard-wired nature of extant

approaches paradigm shift from previous perceptions of

computational interaction

20

Agents act/interact to achieve objectives:• on behalf of individuals/companies• part of a wider problem solving

initiative

underlying organisational relationship between the agents

Organisations

21

Organisations

This organisational context:• influences agents’ behaviour

relationships need to be made explicit– peers – teams, coalitions– authority relationships

• is subject to ongoing change provide computational apparatus for creating,

maintaining and disbanding structures

A Canonical View

Environment

Agent

InteractionsOrganisationalrelationships

(see also: Castelfranchi, Ferber, Gasser, Lesser, …..)

Sphere of influence

Making the Case: Quantitatively

0

10

20

30

40

50

Productivity Reliability Maintainability

Software Metrics

Objects Agents

“There are 3 kinds of lies: lies, damned lies and statistics”Disraeli

Software techniques fortackling complexity

Making the Case: Qualitatively

Tackling Complexity

Decomposition

Abstraction

Organisation



Nature of complexsystems

Complex Systems

Complexity takes form of “hierarchy”• notnot a control hierarchy• collection of related sub-systems at different levels of

abstraction Can distinguish between interactions among sub-

systems and interactions within sub-systems• latter more frequent & predictable: “nearly decomposable

systems” Arbitrary choice about which components are

primitive Systems that support evolutionary growth develop

more quickly than those that do not: “stable intermediate forms”

(Herb Simon)

Agent-based computing





Agent-based computing

Degree ofMatch



The Match Process

1. Show agent-oriented decomposition is effective way of partitioning problem space of complex system

2. Show key abstractions of agent-oriented mindset arenatural means of modelling complex systems

The Match Process



Decomposition: Agents In terms of entities that have:

• own persistent thread of control (active: “say go”)

• control over their own destiny (autonomous: “say no”)

Makes engineering of complex systems easier:• natural representation of multiple loci of

control “real systems have no top” (Meyer)

• allows competing objectives to be represented and reconciled in context sensitive fashion

Decomposition: Interactions

Agents make decisions about nature & scope of interactions at run time

Makes engineering of complex systems easier:• unexpected interaction is expected

not all interactions need be set at design time

• simplified management of control relationships between components coordination occurs on as-needed basis

between continuously active entities

The Match Process



Suitability of Abstractions

Design is about having right models

In software, minimise gap between units of analysis and constructs of solution paradigm• OO techniques natural way of modelling world

Complex System Agent-Based System

Sub-systems

Sub-system components

Interactions between sub-systems and sub-system components

Relationships between sub-systems and sub-system components


Sub-systems Agent organisations

Sub-system components





Sub-system components Agents






Interactions between sub-systems and sub-system components:

“at any given level of abstraction, find meaningful collections of entities that collaborate to achieve some higher level view” (Booch)

“cooperating to achieve common objectives”

“coordinating their actions”

“negotiating to resolve conflicts”






“cooperating to achieve common objectives”

“coordinating their actions”

“negotiating to resolve conflicts”


- change over time

- treat collections as single coherent unit

Explicit mechanisms for representing & managing organisational relationships

Structures for modelling collectives

The Adequacy Hypothesis

Agent-oriented approaches can enhance our ability to model,

design and build complex distributed software systems.

The Establishment Hypothesis

As well as being suitable for designing and building complex systems,

agents will succeed as a software engineering paradigm

[NB: will be complementary to existing software models

like OO, patterns, components, …]

Agents Consistent with Trends in Software Engineering

Conceptual basis rooted in problem domain• world contains autonomous entities that

interact to get things done

Agents Consistent with Trends in Software Engineering Conceptual basis rooted in problem domain

Increasing localisation and encapsulation

• apply to control, as well as state and behaviour

Agents Consistent with Trends in Software Engineering

Conceptual basis rooted in problem domain Increasing localisation and encapsulation

Greater support for re-use of designs and programs• whole sub-system components (cf.

components, patterns) e.g. agent architectures, system structures

• flexible interactions (cf. patterns, architectures) e.g. contract net protocol, auction protocols

Agents Support System Development by SynthesisAn agent is a stable intermediate form

• able to operate to achieve its objectives and interact with others in flexible ways

construct “system” by bringing agents together and watching overall functionality emerge from their interplay

• well suited to developments in: open systems (e.g. Internet) e-commerce

Conclusions

Agents are a new model of computation Basic concepts are:

• Agents• Interactions• Organisations

Agents well suited to developing complex distributed applications

Further Reading

M. Luck, P. McBurney and C. Preist (2003) “Agent Technology: Enabling Next Generation Computing (A Roadmap for Agent Based Computing), AgentLink, 2003.

N. R. Jennings (2000) “On Agent-Based Software Engineering” Artificial Intelligence, 117 (2) 277-296.

H. S. Nwana (1996) “Software Agents: An Overview” The Knowledge Engineering Review, 11 (3).

M. Luck, R. Ashri, M. d’Inverno (2004) Agent-Based Software Development, Artech House, 2004.

Part II

Conceptual Infrastructure:The SMART Agent Framework

withMark d’Inverno, University of Westminster, UK

The SMART View: Objects

Agents

Autonomous Agents

Conceptual Infrastructure

Entities

Objects

Agents

AutonomousAgents

Entities have attributes

Objects are entities with capabilities

Agents are objects with goals

Autonomous agents are agents able to generate their own goals (based on motivations)

Structured, Modular Agent and Relationship Types (SMART)

Entities

Abstraction with • Actions• Attributes• Goals• Motivations

Objects, Agents, Autonomous Agents Objects are entities with non-

empty actions Agents are objects with non-empty

goals Autonomous Agents are agents

with non-empty motivations

Motivation

Motivations give rise to goals• Greed• Hunger• Etc

Robbing a bank – greed The why as opposed to the what

Engagement

One agent satisfies the goals of another

Can build up chains of engagements

Autonomous agent at head of chain Cooperation involves two

autonomous agents

Relationships

Ownership• When no others engage an agent

Direct ownership• When no chain is involved

Other categories are possible

Understanding Agent Systems

Part III

Technical Infrastructure:Agent Implementation through Jini

with Ronald Ashri, University of Southampton, UK

Overview

Goals and roadblocks Required solutions What is infrastructure support for agent-

based systems? A layered approach to infrastructure

Intelligent agents, mobile agents and middleware

Concept-centred view of agent development Paradigma: Jini-based agent system Further Work

Goals

Integration of services Effective information management Intelligent Environments at work,

home and in the community Minimised workload Optimised resource handling More fun in life!

Example: Ambient Intelligence

Home Community

The gameis starting in 5 min.

There is anurgent mail!

Milk is outof date

Hi, I am a newmobile phone

Just let me know howyou would like me to

take care of things.

Autonomous Agent

Roadblocks

A multitude of computing environments (workstations, embedded, mobile)

A multitude of platforms (Windows, Unix/Linux, Macintosh, OS/2, PalmOS, legacy,…)

Different applications for every task, little integration, too much work expected from the user (direct manipulation).

Complex administration

Required Solutions

Move from static to dynamic networks Online Communities

Dynamic registration of new devices and software

Fault-tolerance Move from object-oriented to agent-

oriented software engineering Co-ordination amongst software components Delegation of tasks and task sharing Autonomous behaviour

How to provide such solutions

Middleware technologies to create the appropriate environment

Many candidates Service Location Protocol Salutation UPnP E-Speak Jini

All still fairly new but there is progress and reasons to be hopeful

Solutions: Frameworks for agent-based systems A framework should...

Provide meanings for common concepts Enable comparison and evaluation of

alternative designs Provide for subsequent refinement and

development Challenge is to provide a framework

with a strong conceptual base that can be practically implemented!

Solutions: Design principles A common structure for both

practical and theoretical development of agent research

Use of existing technologies (Java, XML), especially as it refers to the environment (Jini middleware)

Extensibility that will allow for the natural evolution of the framework

Basic building blocks required for the development and deployment of an application

Aim is support for agent-based systems not general distributed systems.Agent infrastructure should touch upon lower-level issues as well as higher-level.

Infrastructure support for agent-based systems

What are the significant re-usable and domain independent components? What is an appropriate

framework through which to manipulate these components?

SMART

PARADIGMA

Heterogeneous Environments

Network Community

Network Community

cellular network

bluetooth

short range wireless

LAN

LAN

InternetLAN

Gateway

Gateway

Internet

Research FieldsIntelligent Agents

• reasoning• negotiation• coalition formation• autonomy• security

• resource control• optimization

• state migration• security

Mobile Agents

Middleware

• network protocols • reflection

• access policies• discovery

• security

• code mobility• binding

• communication• coordination

level of abstractionintelligent agents

(goal-directed, autonomous operation)

mobile agents(resource optimization)

middleware(registration, discovery)

Infrastructure Layers

Programming Language Support

Agent & Relationship Types (Agent Framework)

Agent Execution Environment

Infrastructure support capabilities

Capabilities, Attributes, Goals, Plans, Motivations

OS + Networking

Middleware

Domain specific capabilities

AgentProgram

ApplicationDeveloperConcern

Framework Centered View

Conceptual Infrastructure

Entities

Objects

Agents

AutonomousAgents

Entities have attributes

Objects are entities with capabilities

Agents are objects with goals

Autonomous agents are agents able to generate their own goals (based on motivations)

Structured, Modular Agent and Relationship Types (SMART)

PARADIGMA/ actSMART Infrastructure that provides base agent

concepts to ground development of specific systems without starting from scratch (conceptually), but …….

Infrastructure that avoids forcing a developer to commit to a particular agent architecture

Infrastructure that facilitates clean separation of agent behaviour from agent description, and promotes modularity of agent construction

Technical Infrastructure XML for agent specification

• XML separates agent function from agent description• No specialised tools required and enables the

creation of agent libraries• XML could, eventually, be used for agent packaging

to allow mobility. A far less costly mechanism for serialisation when compared to the Java mechanism.

Jini as the network environment• Ready Java-based implementation• Source available and well supported through Jini

community (www.jini.org)• Based on lookup, discovery, join, entries, leasing and

transactions

Overview

Formal Agent Framework

Agenthood Autonomy Coordination

PARADIGMA

JavaJini/Javaspaces

JVM/RMIXML

Network Communications (TCP/IP)

Technical Infrastructure

MessageManager

Capabilities, Attributes, Goals, Plans, Motivations

Jini + Java + Unix + TCP/IP

Domain specific capabilities

XML-based Serialization/Deserialization

Resource Access Control

DynamicLinking

NeutralObjects

ServerAgents

AutonomousAgents

EngagementTypes

Contract TypesAttributes Motivations

Goals/Plans

Capabilities

OntologyEngine

RegistrationGoal

SelectionPlan

SelectionEvent

Listener …

…

Jini as the network environment

Jini LookupService

Executing Environment

PrinterUser

Executing Environment

PrinterService

PrinterInterface

Description

1. registration2. discovery/lookup

3. retrieval

4. print request

PrinterInterface

Technical Infrastructure: Jini Agent discovery through lookup

and join Agent description using entries Agent management via leasing Information sharing can be done

using Javaspaces (Linda-like tuple-space)

Conceptual Infrastructure: SMART Some further definitions:

Server Agents - Those agents that are not autonomous Neutral Objects - Those objects that are not agents

These definitions allow for more dynamic behaviour Once a neutral object is assigned a goal it becomes a

server agent When a goal is satisfied it reverts to a neutral object This is a possible solution to the issue of agentification

(Shoham, 93) Many more issues covered (interactions,

planning, cooperation)

Paradigma: Using Neutral Objects

Jini LookupService

Neutral Object

Neutral ObjectProxy

Description

1. publish

2. lookup

3. retrieve

4. instatiate

5. call capabilities of neutral object

Autonomous Agent

Neutral ObjectProxy

Server Agent

Paradigma: Different Execution Models Execution on server’s JVM (Remote

sensor interfaces) Execution on client’s JVM (New

capabilities for engaging agent, network monitoring)

Execution on both client and server (Smart proxy)

Allows for efficient use of computing resources

PARADIGMA

XML is used to describe agents (in terms of attributes, capabilities, goals, etc)

Description are parsed to create component collections that are linked via infrastructure support and domain-specific capabilities

Agent constructors carry necessary information for agent infrastructure and domain-specific capability needs

Capabilities can be dynamically loaded Agent creation and operation are separate Currently, Jini is used for agent discovery

CapabilityCollection

Capability

GoalBase

Goal

PlanBase

PlanBase

AttributeCollection

Attribute

AttributeCollection

Attribute

Motivations

Motive

Operation

Infostore

GoalSelection

PlanSelection

ViewCreator

action

sensingDTD

DTD

Interpreter

DTDDTD

Interpreter

DTDDTD

Interpreter

DTDDTD

Interpreter

DTDDTD

Interpreter

Factory

Factory

Factory

Factory

Factory

Creation

Attributes

XML

Capabilities

XML

Goals

XML

Plans

XML

Motivations

XML

Paradigma Architecture

Decoupling agent behaviour and description

Helps deal with environmental constraints – behaviours can vary to suit executing environments while behaviours remain the same Flexibility in evaluation - alternative

algorithms (behaviours) can be applied to the same descriptions, and be clearly evaluated against each other

Provides alternative forms of mobility Enables libraries of agent components

(attributes, capabilities, plans, goals)

PARADIGMA

Conclusions

A layered approach maximizes inter-domain transfer

It can employ existing technologies, rather than competing with them, engaging user and developer communities

By placing the agent framework at the centre we focus on agent issues and better relate them to non-agent issues

Paradigma adopts this approach Through Paradigma, SMART is instantiated,

evaluated and refined

Further Work

Apply Paradigma to significant real world problems for further evaluation

Develop conceptual infrastructure to support other issues eg. mobility

Dynamic self modification of capabilities – conceptual and technical development

http://www.ecs.soton.ac.uk/~ra00r/paradigma

Part III

Applied Infrastructure:Agent Construction for Mobile Devices

with Ronald Ashri, University of Southampton, UK

Overview

Challenges for agent development on mobile devices

Desiderata for an agent construction model

Agent Construction Model Example Implementation Conclusions

Challenges

“Standard” challenges Heterogeneity Dynamicity Diverse Application Domains

Mobile devices add Memory, storage, processing power, operating

power limitations Unstable network connectivity Different devices for different tasks/trips Operating through changing organisational

domains

Desiderata

Agent construction framework that is able to deal with these challenges through: Architecture neutrality Modularity Powerful reconfiguration (at run-time

when possible)

Architecture Neutrality

Developers need to produce agent-based solutions for a range of application domains

Constraining a developer to one specific architecture (e.g. BDI) is not practical

Providing a really good generic architecture doesn’t work either

Agent construction model must be architecturally neutral

SMART

Provides the underlying theoretical approach

It is already architecturally neutral Has been used to describe a range

of agent architectures However, deals only with the

description of agent systems not their construction

Descriptive Specification (SMART)

What an agent is and does Attributes Capabilities Goals Motivations

PDAStorage: 64 MB

Connectivity: 802.11bOwner: Ronald Ashri

---Join Research Group

Receive messages from other agentsNegotiate meetings

Notify User---

Arrange a meeting with Mike---

Keep meetings as short as possible

Structural Specification The main building

blocks of the agent Sensors Actuators Controllers Infostores Each component is

described with attributes (stateless and situation) and capabilities

IncomingMessageSensor

UserPreferences

Infostore

MessageMailboxInfostore

MeetingsNegotiationController

UserNotification

Actuator

AgendaUpdate

Actuator

MessageAnalysis

Controller

OutgoingMessageActuator

IncomingMessageSensor

UserPreferences

Infostore

MessageMailboxInfostore

MeetingsNegotiationController

UserNotification

Actuator

AgendaUpdate

Actuator

MessageAnalysis

Controller

OutgoingMessageActuator

Behavioural Specification

How the agent behaves Links between

components Type of

messages exchanged

Execution sequence of components

Reconfiguration Agent aspects managed through a shell,

which directs access to each specification

Agent Shell

Sensor

InfostoreInfostore

Sensor

Controller

ActuatorActuator

Controller Execution Sequence

Agent-SpecificAttributes

Link Management

Control Policies

Example: BDI Architectures

BDI aims to model rational or intentional agency

The symbols representing the world correspond to mental attitudes

Three categories:• informative (knowledge, belief,

assumptions)• motivational (desires, motivations, goals)• deliberative (intentions, plans)

BDI Systems

BDI = Belief, Desires and Intentions Many agent architectures are BDI

based Original system was PRS More recent versions include

dMARS. Other related systems include

AgentSpeak(L) and Agentis

Folk Psychology

I believed the tutorial today was at 8am so I intended to arrive yesterday from London.

I believed the planes were not delayed and desired not to be late so I intended to arrive by 6pm.

Compelling because• familiar: what it wants, knows and intends - easier to

understand and predict behaviour.• Other agents can understand and predict behaviour• Relationship between these three categories may give

us a handle on intelligent action in general.

BDI Architectures

Beliefs - modelling world state. Desires - choice between possible

states. Intentions - commitment to

achieving particular state.

PRS/dMARS/AgentSpeak(L)

Beliefs: information about the world

Goals: tasks to achieve Plan library: procedural knowledge Intentions: partially instantiated

selected plans

Procedural Reasoning System (PRS)

Beliefs Plan library

Goals Intentions

InterpreterSensor input Action output

BDI Architecture

In general, an agent cannot achieve all its desires.

Must therefore fix upon a subset. Commit resources to achieving

them. Chosen desires are intentions. Agents continue to try to achieve

intentions until either• believe intention is satisfied, or• believe intention is no longer

achievable.

Plans

BDI model is operationalised in PRS/dMARS agents by plans.

Plans are recipes for courses of action. Each plan contains:

• invocation condition: circumstances for plan consideration;

• context: circumstances for successful plan execution;

• maintenance condition: must be true while plan is executing, in order for it to succeed; and

• body: course of action, consisting of both goals and actions.

Plan Structure

Failure

Success

Maintenance

Body

Context

Invocation

Plan Start

P1P2

P3 P4

End1 End2

End3

?g1?g2 (otherwise)

?g3 ?g4

!g1 !g2

*a1

Operation 1

Observe world and agent state, and update event queue to reflect observed events.

Generate new possible goals (tasks), by finding plans whose trigger matches event queue.

Select matching plan for execution (an intended means).

Operation 2

Push the intended means onto the appropriate intention stack in the current set.

Select an intention stack and execute next step of its topmost plan (intended means):• if the step is an action, perform

it;• if it is a subgoal, post it on the

event queue.

Intention

Plan Instance(m)

Plan Instance (m-1)

Plan Instance(1)

Applications

Air-traffic control spacecraft systems telecommunications management air-combat modelling

Example: AgentSpeak(L) -

Description Atom

Term PredicateTerm

Action

TermTerm ActionSymbol

Belief

AtomAtom booleannegated

Trigger(Internal|External)

Goal|PlanTrigger

Goal

AtomAtom

Intention

PlanPlan

Plan

TriggerTriggerContext

BeliefBelief

Formula

ActionAction GoalGoal

Example: AgentSpeak(L) – Structure

sensors

Beliefbase BDIEventProcessor

Planbase

PlanSelector

IntentionBase

IntentionSelection

BDIActionProcessor

actuators

Example: AgentSpeak(L) – Behaviour

sensors

Beliefbase BDIEventProcessor

Planbase

PlanSelector

IntentionBase

IntentionSelection

BDIActionProcessor

actuators

view(BDI)

view(BDI)

plan

intentionintention action(domain)

view(domain)

plan

plan

view(BDI)

action(BDI)

Implementation - actSMART All concepts implemented in Java,

accessible as APIs Implementation of core in J2ME AgentSpeak(L) running on Palm

m100 Desktop version configurable via

XML

Implementation – actSMART

actsmart.core

actsmart.core.attribute

actsmart.core.component

actsmart.core.shell

actsmart.core.admin

actsmart.mobile

actsmart.mobile.ui

actsmart.desk

actsmart.desk.attribute

actsmart.desk.component

actsmart.desk.ui

actsmart.desk.xml

Conclusions

Development process greatly aided through better understanding of architecture, easier debugging

Affords flexibility and allows easy comparison between different approaches (both at a theoretical and implementation level)

Can be integrated with existing methodologies or form the basis for one

Further Work

Larger scale implementation Library of architectures and

architectural patterns Integration with other aspects

(relationships, discovery)

Documents

Agent Infrastructure Michael Luck University of Southampton, UK