1. Capabilities, Plans, and Events Each capability is further broken down either into further capabilities or, eventually into the set of plans that provide the details of how to react to situations, or achieve goals Capability Overview Diagram –Capability internals (may contain nested capabilities) –Plans –Messages (note: one of the incoming messages to a plan needs to be identified as the triggering message) Figure 9.1 on page 111, shows a capability diagram for the Stock managing capability of the Stock Manager agent-since this capability is fairly large, we break it down into three smaller capabilities: Ordering, Delay handling and Handling new stock. Figure 9.2 shows the plans that realize the Ordering capability

2. Sub-tasks and Alternative Plans At the lowest level of detail, each incoming message to the capability must have one or more plans that respond to that message Each plan is broken down into a number of sub- tasks, each of which is represented by an internal message – see page 112 -113 Initially, one plan per sub-task is sufficient Each plan is triggered by a specific event (i.e., a percept, message from other agent, internal message, or sub-task within agent.

3. Context Conditions specify the conditions or situation under which the various plans are applicable Often represents information about the state of the environment, which makes the plan suitable for use in that situation, e.g., –A plan to recompense a customer for a lost book by immediately sending a new book may have as a context condition that the required book is in stock. An alternative plan may provide the customer with a refund and have as a context condition that the book is not in stock Representation of necessary context conditions helps ensure the correct functioning of the agent – see bottom of page 114

4. Coverage refers to the concept of whether, for a given event, there will always be some plan with a matching context condition Do careful analysis to ensure that there is no gap in coverage –If no plan/response in some situations, identify how this is handled by the implementation platform (e.g., some define an “empty” plan)

5. Overlap refers to whether it is possible, in some situations, to have more than one plan that is applicable, necessitating a choice between them. There are two mechanisms by which this can happen: –When two context conditions overlap, that is, there is some situation in which both could be true simultaneously –Where the context condition contains variables that can potentially take on multiple values at a single point in time, leading to multiple plan instances of a single plan type Preferred plan can be controlled by platform, and/or at implementation time

6. Events Specify the information type, and allowable values, carried by each event. If some done earlier (as part of percept or message specification), refine it and expand on it. E.g., If there is a book order event, as a min info about book, and who ordered must be carried. As a plan is being developed the rest of the info will emerge. –For messages between agents, specify whether a reply is expected, and the details of it –Events representing percepts from the environment must specify the info carried as part of the percept See middle of page 117

7. Action, Percept, Data, and Plan Detail design should consider source –If it is non-agent, consider its notation and/or methodology (e.g., may involve use of API) –For data, consider Relational Schemas, Object Models, etc. Plan descriptors provide for an identifier, the triggering event type, context conditions, plan steps, messages, and list of data used/produced (data lists should be tied to particular data descriptors rather than being generic descriptors) and more – see middle page 119)

8. Check for Completeness and Consistency Completeness –Does it implement the required functionality? Are all messages required for its specified participation in protocols generated and received? –Ensure that all data is used/produced, and messages sent/received Consistency between final design artifacts –Overview Diagrams (bottom of page 121) –Between Overview Diagrams and Descriptors –Scenarios, Processes and Plan Sets –Processes consistent with Protocols and Overview Diagrams –Design “walk through” of key scenarios