Design of Multi-Agent Systems

1. Design of Multi-Agent Systems • Teacher • Bart Verheij • Student assistants • Albert Hankel • Elske van der Vaart • Web site • http://www.ai.rug.nl/~verheij/teaching/dmas/ • (Nestor contains a link)

2. Overview • Introduction • Task sharing The Contract Net • Result sharing Blackboard systems Subscribe/notify • Handling inconsistency • Coordination Partial global planning Joint intentions Mutual modelling Norms and social laws

3. Working Together • Why and how do agents work together? • Important to make a distinction between: • benevolent agents • self-interested agents

4. Benevolent Agents • If we “own” the whole system, we can design agents to help each other whenever asked • In this case, we can assume agents are benevolent: our best interest is their best interest • Problem-solving in benevolent systems is cooperative distributed problem solving (CDPS) • Benevolence simplifies the system design task enormously

5. Self-Interested Agents • If agents represent individuals or organizations, (the more general case), then we cannot make the benevolence assumption • Agents will be assumed to act to further their own interests, possibly at expense of others • Potential for conflict • May complicate the design task enormously

6. Task Sharing and Result Sharing • Two main modes of cooperative problem solving: • task sharing:components of a task are distributed to component agents • result sharing:information (partial results, etc.) is distributed

7. Overview • Introduction • Task sharing The Contract Net • Result sharing Blackboard systems Subscribe/notify • Handling inconsistency • Coordination Partial global planning Joint intentions Mutual modelling Norms and social laws

8. The Contract Net • A well known task-sharing protocol for task allocation is the Contract Net: • Recognition • Announcement • Bidding • Awarding • Expediting

9. The Contract Net

10. Recognition • In this stage, an agent recognizes it has a problem it wants help with. • Agent has a goal, and either… • realizes it cannot achieve the goal in isolation — does not have capability • realizes it would prefer not to achieve the goal in isolation (typically because of solution quality, deadline, etc.)

11. Announcement • In this stage, the agent with the task sends out an announcement of the task which includes a specification of the task to be achieved • Specification must encode: • description of task itself (maybe executable) • any constraints (e.g., deadlines, quality constraints) • meta-task information (e.g., “bids must be submitted by…”) • The announcement is then broadcast

12. Bidding • Agents that receive the announcement decide for themselves whether they wish to bid for the task • Factors: • agent must decide whether it is capable of expediting task • agent must determine quality constraints & price information (if relevant) • If they do choose to bid, then they submit a tender

13. Awarding & Expediting • Agent that sent task announcement must choose between bids & decide who to “award the contract” to • The result of this process is communicated to agents that submitted a bid • The successful contractor then expedites the task • May involve generating further manager-contractor relationships: sub-contracting

14. Issues for Implementing Contract Net • How to… • …specify tasks? • …specify quality of service? • …select between competing offers? • …differentiate between offers based on multiple criteria?

15. Overview • Introduction • Task sharing The Contract Net • Result sharing Blackboard systems Subscribe/notify • Handling inconsistency • Coordination Partial global planning Joint intentions Mutual modelling Norms and social laws

16. Result Sharing in Blackboard Systems • The first scheme for cooperative problem solving: the blackboard system • Results shared via shared data structure (the blackboard) • Multiple ‘agents’ can read and write to the blackboard • Agents write partial solutions to the blackboard • The blackboard may be structured into hierarchy • Mutual exclusion over the blackboard required  bottleneck • Not concurrent activity

17. Result Sharing in Subscribe/Notify Pattern • Common design pattern in object-oriented systems: subscribe/notify • An object subscribes to another object, saying “tell me when event e happens” • When event e happens, original object is notified • Information pro-actively shared between objects • Objects required to know about the interests of other objects  inform objects when relevant information arises

18. Overview • Introduction • Task sharing The Contract Net • Result sharing Blackboard systems Subscribe/notify • Handling inconsistency • Coordination Partial global planning Joint intentions Mutual modelling Norms and social laws

19. Handling inconsistency • • Inconsistencies about: – Beliefs – Goals/intentions • • Inevitable except in small systems • • Approaches: – Do not allow or ignore – Resolve by negotiation – Design for graceful degradation (best choice)

20. Handling inconsistency • A design for graceful degradation: • Functionally Accurate/ Cooperative (FA/C) Systems (Lesser and Corkill) • A network problem solving structure: • Functionally accurate: “the generation of acceptably accurate solutions without the requirement that all shared intermediate results be correct and consistent” • Cooperative: an “iterative, coroutine style of node interaction in the network”

21. Handling inconsistency • • Characteristics of FA/C systems: – Problem solving not in a strict predetermined order, but opportunistically – Communication of high-level data, not raw data – Solve inconsistency implicitly by exchanging partial results, not at beginning or end - There exist multiple solution routes

22. Overview • Introduction • Task sharing The Contract Net • Result sharing Blackboard systems Subscribe/notify • Handling inconsistency • Coordination Partial global planning Joint intentions Mutual modelling Norms and social laws

23. Coordination • Partial global planning (Durfee) • • Partial: no plan for the entire problem • • Global: exchange of local plans for non-local view • • Stages: • Each agent decides on goals & generate short-term plans • Information on interacting plans and goals is exchanged • Each agent alters local plans • • Metalevel dictates information exchange (which agents, under which conditions)

24. Coordination • Joint intentions (Levesque et al) • Coordinated non-cooperative vs. coordinated cooperative action Going to the same place to find shelter or to perform a choreography • Commitment: a promise • Convention: a means for commitment monitoring • Commitments are assumed to persist: Joint Persistent Goals Agents have a collective commitment to bring about some goal and a motivation for the goal. Agents inform each other about the status of the goal (satisfied/impossible/disappearance of motivation)

25. Coordination • Mutual modelling (e.g., Gasser’s MACE) • • Agent keeps models of itself and other agents, e.g., with respect to roles, skills, goals, plans • • Characteristic: no explicit communication required

26. Coordination • Norms and social laws • • Important in everyday life • • Origin of conventions: • Offline design (straightforward) • Emergence (scalable, flexible) Tee shirt game (Shoham & Tennenholtz) How to update strategy? (e.g., majority or highest cumulative reward)

27. Overview • Introduction • Task sharing The Contract Net • Result sharing Blackboard systems Subscribe/notify • Handling inconsistency • Coordination Partial global planning Joint intentions Mutual modelling Norms and social laws

28. Student presentations