The parameters associated with a goal (or subgoal) can draw on useful features to refine the request's meaning. For example, it is frequently important to be able to specify whether or not solutions are to be returned synchronously; this is done using the reply parameter, which can take any of the values synchronous, asynchronous, or none. As another example, when the goal is a noncompound query of a data solvable, the cache parameter may be used to request local caching of the facts associated with that solvable. Many of the remaining parameters fall into two categories: advice and feedback.
Feedback parameters allow a service requester to receive information from the facilitator about how a goal was handled. This feedback can include such things as the identities of the agents involved in satisfying the goal, and the amount of time expended in the satisfaction of the goal.
Advice parameters give constraints or guidance for the facilitator to use in completing and interpreting the goal. For example, the solution_limit parameter allows the requester to say how many solutions it is interested in; the facilitator and/or service providers are free to use this information in optimizing their efforts. Similarly, time_limit is used to say how long the requester is willing to wait for solutions to its request, and, in a multifacilitator system, level_limit may be used to say how remote the facilitators may be that are consulted in the search for solutions. The priority parameter is used to indicate that a request is more urgent than previous requests that have not yet been satisfied. Other advice parameters are used to tell the facilitator whether parallel satisfaction of the parts of a goal is appropriate, how to combine and filter results arriving from multiple solver agents, and whether the requester itself may be considered a candidate solver of the subgoals of a request.
As mentioned in section 5.1, advice parameters are intended to provide an extensible set of low-level, orthogonal parameters capable of combining with the ICL goal language to fully express how information should flow among participants. Multiple parameters can be grouped together and given a group name; the resulting high-level advice parameters can be used to express concepts analogous to KQML's performatives, but also to define classifications of problem types. For instance, KQML's ``ask_all'' and ``ask_one'' performatives would be represented as combinations of values given to the parameters reply, parallel_ok, and solution_limit. As an example of a higher-level problem type, the strategy ``math_problem'' might send the query to all appropriate math solvers in parallel, collect their responses, and signal a conflict if different answers are returned. The strategy ``essay_question'' would send the request to all appropriate participants, and signal a problem (i.e., cheating) if any of the returned answers are identical.
When a facilitator receives a compound goal, its job is to construct a goal satisfaction plan and oversee its satisfaction in the most appropriate, efficient manner that is consistent with the specified advice.