AISA (Artificial Intelligence Systems of Administration) is an ongoing research project whose long-term goal is development of an intelligent assistant to a business executive or administrator. The intelligent assistant will remove much of the burden of administrative chores from its human user and provide guidance, advice, and assistance in problem solving and decision making. This paper provides an overview of the system, with emphasis on the module that proposes the next item to which an administrator should give attention and suggests the appropriate action to perform with respect to that item. Expertise in the domain is represented by Horn-clause declarative knowledge and can be expanded incrementally. This work illustrates that sophisticated AI techniques can be successfully applied using microcomputers. It also addresses an increasingly important area of application, that of efficient multi-agent cooperation and communication in the administrative domain.
AISA (Artificial Intelligence Systems of Administration) is an ongoing research project of the first author, whose long-term goal is the development of an intelligent assistant to a business executive or administrator. The intelligent assistant will remove much of the burden of administrative chores from its human user and provide guidance, advice, and assistance in problem solving and decision making.
The office environment is a domain in which efficiency and success necessitate multi-agent cooperation and communication. Section 2 describes the host system and its role in an administrative organization. Section 3 describes SUGGEST, a module that proposes the next item to which an administrator should give attention and recommends the appropriate action to perform with respect to that item. Communication between SUGGEST and the overall system is described and SUGGEST's heuristics for making recommendations are discussed. Section 4 describes future possible directions for continuing this research and Section 5 presents our conclusions. .
AISA has been implemented on an IBM AT. It runs now on large-memory GCLISP and GOAL, a lisp-based logic programming language. AISA exemplifies a promising style of programming--the combination of functional and logic languages in close interaction.
AISA is conceived as an interactive and integrated electronic environment for the office worker at any level in the bureaucratic hierarchy. An AISA workstation is conceived as the synergistic coupling of a human and an electronic part, each contributing what he/she/it excels at. The computer provides secure memory and ease in the management of complex relations, and the human user provides, among other capabilities difficult to capture in a formal system, common sense and moral responsibility. .
An AISA workstation surrounds the worker, offering him/her all the support that he/she needs to perform the functions associated with his/her position. It offers the possibility of reducing on the desktop the need for traditional office instruments, i.e. paper, pencil, rubber stamps, in- and out-baskets, filing cabinets, or any other equipment for marking, holding, or grouping documents together. In addition, it contributes to the prioritization of administrative chores and dynamically adjusts its recommendations as the situation changes. Since AISA commands are programmed in modular fashion, the system can easily accept new capabilities which may be added to it in accordance with technological progress in AI and electronics.
AISA works under three main independent philosophical assumptions:
.
a) man/machine partnership at each workstation
b) supportive network relationships
c) background action of an autonomous-agent computer. .
The man/machine-partnership is viewed as a synergistic coupling in which digital computers offer objectivity, reliable memory, and speed of symbolic association, while human agents provide common sense, creativity, and ethical responsibility. The capability of symbolic accounting of the computer provides support to the non-formal ability of the human partner to make the most of a fluent and complex situation. .
The administrative web is viewed as a set of complex commission/commitment interactions between workstations. It subsumes the conventional electronic mail into a rich milieu of expectations and responsibilities. .
As an autonomous agent, AISA is a program that runs continuously, even when the user is not giving commands. It is expected to eventually learn by itself, drawing inductive lessons from its interactions with the user or even with other instantiations of itself. AISA is a step towards the "computer individual," as envisioned by Nilsson (1983).
AISA can be used as a rather comfortable single-user desk organizer or personal assistant. However, its intended purpose is to model and serve the interests of an administrative organization. It should normally run simultaneously in several workstations, as independent instances of the same program somehow customized by their interactions with their particular users. .
The system handles the interactions of all members of the organization which are basically planning and executing acts related among themselves in hierarchical fashion. These acts are able to travel from desk to desk, in different stages of realization, under the form of documents. Transitions will normally take the form of one workstation commissioning a certain task to another station, the latter assuming a commitment with regard to that task. This web of commission and commitment acts represent the shared responsibilities and mutual solidarity of a society of workers within an organization.
AISA models administrative action using planning as the basic paradigm. Everything in an administration is viewed as a plan. Each plan consists of a partially ordered set of actions, and associated with each "non-ground" action is a plan specifying how that action can be accomplished. Thus, with the exception of the top-level plan, each plan is a component of some higher-level plan, and is generally decomposable into sub-plans. The planning paradigm captures the essence of what goes on in administration: it is assumed that everything in administration has the nature of a plan in some stage of preparation or implementation: proposals are plans that have not yet been validated, reports are plans that have been partially or totally executed, and complaints are (sad) histories of plans. In addition, plans are embedded into one another in a graph-like manner and may comprise several desks, following the commission/commitment web. .
Within a single workstation, a plan is a graph (most often, just a tree) made out of a cluster of hierarchically organized individual tasks, in which each but the top-level one is composed of sub-tasks pertaining to the parent task. In between stations, the plan takes the form of a document (a dormant plan) traveling from one desk to another. Dormant plans (documents) come to life at the destination desk as soon as the owner of the desk ACCEPTs the implied task. A task is put in a dormant state (transformed into a document for traveling purposes) as soon as the owner of the desk COMMISSIONs the task and sends the corresponding letter.
The plan is the fundamental unit of administrative action and can be either active or dormant. The dormant plan, realized as a document, exists in one of two states, incoming or outgoing. .
The upshot of this is the appropriateness of representing the desk top as the interplay of three distinguishable contexts: the READ context, where incoming documents sit; the WORK context, where active plans (tasks) reside; and the WRITE context, where outgoing documents wait to be sent to another workstation. .
For reasons of completeness, a forth context is added, the CONSULT queue, where the user can retrieve past items from the archive to support the deliberative process.
The context WORK is the place where deliberation by the user occurs, and where the most interesting interactions between the user and the machine take place. It is here that problems are solved, and tasks related to assumed responsibilities are performed. .
A number of researchers have investigated problem-solving strategies. Problem reduction is the technique of decomposing a problem into a set of easier-to-solve sub-problems (Newell, 1972). Opportunistic problem solving (Hayes-Roth, 1979) is the strategy of looking for opportunities to merge the solution of a second sub-problem into the solution of the sub-problem under consideration, with relatively little additional cost. Our analysis tends to indicate that administrative problem solving can be modeled by using these two strategies. .
Administrators typically break a large task into component parts and are on the lookout for favorable interactions between problems (in the best case, problems may cancel each other out!). Negotiation, something important in administration that could not easily be explained as problem reduction, can be seen as a sort of opportunism: the merging of different problem graphs with partial common solutions. Even so, it assumes problem reduction as a prerrequisite. .
AISA represents tasks in such a way that both strategies can conveniently be employed, without either of them impeding the application of the other. This is accomplished by placing each individual task in two different structures: a specific plan of which it is an element and a queue where the user is free to reshuffle items at will as one would with papers on a desktop. .
The system offers a battery of commands which permit the inspection of a tasks either as a plan (a hierarchy of interconnected tasks) or as a queue (a random assortment of individual tasks). The user may approach the tasks either hierarchically or opportunistically, according to his/her convenience and/or inspiration. .
The expansion of tasks into sub-tasks required by hierarchical problem solving is done in AISA according to one of the following expansion types: .
| PARTS | conjunctive and parallel |
| STEPS | conjunctive and serial |
| WAYS | disjunctive and parallel |
| PRIORITIES | disjunctive and serial |
AISA runs currently in large-memory GCLISP, on an IBM-AT using 2 mbs. of JRAM memory. Much of it is in fact written in GOAL, a lisp-based logic-programming language based on HCPRVR (Chester, 1980). GOAL supports multiple knowledge bases and enables expertise to be given to AISA in declarative form. The module SUGGEST is one such knowledge base.
SUGGEST can be viewed as a program that communicates with another program, namely the host system AISA. We can distinguish three different moments in this interaction:
(1) AISA producing a series of messages to SUGGEST, to report important events in the workstation (programmed in Lisp). :
(2) SUGGEST processing those messages, the result being a heuristic agenda (Davis, 1982) programmed in GOAL. :
(3) AISA using the heuristic agenda to make recommendations to the user (programmed in Lisp). :
Moment 1 corresponds to side-effects produced by the execution of a sub-set of AISA commands, namely those whose main effect is some important change on the desktop, like the declaration of a task as DONE or FAILED, or the ACCEPTance of a report from another workstation. The result of repeated instances of moment 1 is a list of goals in the logic programming sense (Kowalski, 1979) which is made the value of the Lisp variable GOALS. :
Moment 2 consists in the running of the interpreter of the language GOAL, with GOALS as argument. The result of moment 2 is an updated set of facts under the relation HAGENDA (for Heuristic AGENDA). :
Moment 3 consists in the invocation by the user of the AISA command SUGGEST, which produces, through a friendly interface, recommendations on what to do next. This is accomplished by sorting the list HAGENDA, and extracting and displaying the different facets of each item in turn. :
Notice that what is simply a list in moments 1 or 3 is a logic structure (either goals or clauses) in moment 2. We consider the AISA-SUGGEST interaction a good example of a programming style which successfully combines functional and logic languages.
Each of the relevant commands produces, in addition to its normal effect, a very economical side-effect which consists in inserting a message at the end of the list GOALS. For instance, the ACCEPT command, applied to a letter of cancellation of a previous commission, will generate the message "(ACCEPT-CANCELLATION <letter> <task>)". In the message, <letter> is the identifier of the accepted letter currently in the READ context, and <task> is the identifier of a task currently in the WORK context. :
The message has the format of an invocation of the GOAL interpreter. It always refers to exactly one item that exists, or has just ceased to exist, in one of the AISA contexts. :
SUGGEST supports the "rationality assumption" that is normally made when two intensional systems communicate with one another (Dennet, 1981): it assumes that AISA is "well designed" and will never produce messages that do not make sense (e.g. if a message mentions an item, the item must have been created at some previous time). We consider this to be both philosophically interesting and operationally efficient (e.g. the creation of an item by itself need not generate a message; the module does not have to check the existence of items on the desktop, etc.).
At some appropriate time the logic programming interpreter is called with GOALS as its single argument. This has the effect of iterating the theorem prover over each message. That message will invoke a constellation of heuristics which represent the knowledge of the module. The heuristics are logic declarations in Horn-clause form and will be discussed later. After the interpreter GOAL runs, the variable GOALS is made empty, since the relevant information is now available in a richer representation, the appropriate entries in HAGENDA. :
The heuristic agenda (HAGENDA) is the structure created and maintained by the heuristics. It contains the actual recommendations (cluster of suggestions) to be made to the user, its supportive reasons, and the urgency of each recommendation relative to all others. Conceptually it has the dual character of a set of head-only Horn clauses (facts) for a resolution-based theorem prover, and of a list to be manipulated by a Lisp function (the interface of the SUGGEST command). :
SUGGEST is one among many AISA commands; further, it is a relevant command--in the sense discussed in 3.2. Hence, it produces side effects in the form of messages to the SUGGEST module. The messages inform the module which of the suggestions within a particular recommendation the user has preferred. The module uses this information to modify the schemata that produce recommendations, so that the order of suggestions will in the future tend to reflect the preferences of the user. :
The heuristics are the pieces of knowledge that SUGGEST uses to deduce plausible recommendations. They are Horn clauses which are invoked by the messages in GOALS. The result of their action is the inclusion of new entries in HAGENDA, the deletion of elements in it, or the modification of them (mostly alteration of their urgency values). They are declarative and modular in form, and they can be inserted in the system incrementally. Their source is common sense and expertise from the administrative domain. At the present time, the knowledge is elemental; but the mechanism permits the addition of more knowledge in a modular fashion. :
We are assuming that 4 is the initial urgency value for a task whose only reason for being performed is the reaching of its deadline. .
The invocation by the user of the AISA command SUGGEST is normally done by pressing the combination key Alt/s. What the command does is basically to activate a friendly interface written directly in Lisp, which produces recommendations on what to do next in relation to particular items in AISA contexts (letters, tasks, or drafts). Each recommendation, relative to a particular item, contains one or more suggestions on what to do with it. The command treats HAGENDA as a list, sorts it according to the urgency facet, and iterates over its members. It sends different parts of each of them to one of three different pop-up windows:
There are at least three ways in which one may hope to improve SUGGEST performance without changing its basic mechanisms. On the one hand, one could explore differences in the grain size of the messages. Having each command send more that one message, of a finer grain, may lead to a more general formulation of the heuristics. At the other extreme, a cluster of related commands may be caused to send a single message, with a result of improved efficiency.
Our work applies a successful technique (Lenat's heuristic approach) not only to a new domain (administration) but also to a new function (recommendation rather than discovery). Furthermore, it addresses an increasingly important area of application, that of multi-agent cooperation and communication in the administration domain. It demonstrates that sophisticated AI techniques can be applied with good results using microcomputers. In addition, it exemplifies a promising style of programming, i.e. the combination of functional and logic languages in close interaction (talking to each other). Finally, it offers new strong evidence of the fruitfulness of the modular and declarative approaches in the incremental development of AI systems.
While Sales Manager reads the letter of General Manager, AISA notes that task 5 is overdue; this generates the first message to go into GOALS, which eventually will create the first entry in HAGENDA.
The appropriate time at which the interpreter is called to process GOALS could be when the user is not giving commands and AISA, as a "computer individual," has time to do its homework. The other possibility is when the user invokes SUGGEST; AISA then calls the module before the interface described in moment 3 takes over. Of course, if HAGENDA is up-to-date (and GOALS empty), there is no need to update at moment 3 –which is the motivation behind having the computer individual do homework in background mode. :
The purpose and effect of running GOAL with GOALS as argument is to create, modify, or destroy entries in HAGENDA. If the message refers to an item which has no corresponding entry in HAGENDA, then a new entry is produced for that item; otherwise, the existing entry is modified (or destroyed). There can be no more than one entry in HAGENDA corresponding to an item in one of the AISA contexts. The characteristics of HAGENDA as a data structure are explained below. :
A typical message/goal looks like this: :
(ACCEPT-REPORT <letter> <task>),:
where
An interesting message, which is automatically generated as a result of AISA verification of deadlines, is:
(OVERDUE <list of tasks>).:
A more complex message is the following: :
(DONE <task> <plans>):
where <plans> is a list of all the plans of which the task is an element, and each plan is represented by a list of the form: :
(<parent task> <expansion type> <list of sibling tasks>):
This message is produced when the user declares DONE some task.
3.4 The Heuristic Agenda as Data Structure
Each entry in HAGENDA has the following facets:
item - the identifier of one item in AISA contexts, which is the object of the recommendation.
type - generic name of the recommendation ATTEND LETTER, ATTEND TASK, ATTEND DRAFT used to indicate the. general intention of the recommendation.
schema - name of the schema that produced the entry, necessary for the modification of schemata explained in the next section.
3.5 The Command SUGGEST as Generator of Messages
This mechanism is a primitive form of learning which might cooperate in the automatic construction of a model of the user. Thus, over time, the system can customize itself to reflect its user's organizational or administrative strategies.
3.6 The Heuristics
There are three kinds of heuristics: :
(1) message-receiving heuristics directly triggered by the GOALS; :
(2) schemata, which act as molds for the generation of entries in HAGENDA when they are created or modified; they encapsulate general information about entries of a certain type, and contain variables which are instantiated according to circumstances to produce the actual entries; :
(3) ancillary heuristics, which help members of sub-set 1 to do their job. :
Let us consider as an illustration, the process triggered by the message "(OVERDUE <list of tasks>)".:
The immediate response is the awakening of the message-receiving clauses:
((OVERDUE NIL))
((OVERDUE (?FIRST.?REST)) IF
(UPDATE-IF-PRESENT ?FIRST ...))
((OVERDUE (?FIRST. ?REST)) IF
(SCHEMA-ASSERT OVERDUE ?FIRST 4 NIL)
(OVERDUE ?REST)) :
what, assuming the call to the ancillary heuristic UPDATE-IF-PRESENT fails, triggers in turn the ancillary heuristic:
((SCHEMA-ASSERT ?SCHEMA ?ITEM ?URGENCY ?REASONS) IF
(SCHEMA ?SCHEMA ?ITEM ?URGENCY ?REASONS ?ENTRY)
(ASSERT ?ENTRY)) :
which in turn triggers the schema:
((SCHEMA OVERDUE ?ITEM ?URGENCY ?OLD-REASONS
(HAGENDA ?ITEM ?URGENCY "ATTEND TASK"
(DONE FAILED POSTPONE DESTROY)
("THIS TASK IS OVERDUE". ?OLD-REASONS) OVERDUE)))
before asserting the new entry in HAGENDA.
The rational behind this heuristic is that administrators usually procrastinate non-crucial tasks, but are forced to address them when their due date is imminent.
3.7 Interface for Displaying Suggestions
An additional pop-up window is provided for the user's convenience:
first suggestion (pair of AISA commands)
second supporting reason
third generic name of recommendation
Once a recommendation is thus displayed, the user is offered the following menu options:
fourth description of item referred to by current suggestion
Enter
accepting the suggestion and executing the commands Space
requesting another suggestion relative to same item Ins
requesting an all-together different recommendation
(suggestion about another item) Esc
exiting the SUGGEST command Letter key
displaying another reason, if available. 4. Future Directions
A second possibility is to taylor more knowledge into the module, so as to make it able to discriminate more specific actions in particular situations. One important case of this will be a principled way of recomputing urgency values that takes into account the global state of the heuristic agenda, beyond the limits of individual entries.
Finally, a promising avenue of development will be to make the messages convey more specific information about the items in question. The heuristics could then process that information to make more enlightened recommendations. A case in point will be to illustrate SUGGEST about the principal verb in the description of a task, and have the heuristics take the semantic content into account to deduce its relative urgency.
5. Conclusions
Appendix – A long example
illustrating among other things the use of windows associated with the AISA contexts and with the SUGGEST interface
Sales Manager sits at her electronic desk and finds the following:
Context READ contains the following letters:
(XYZ-134-88) Price-List Revision
<a commission from General Manager requesting a revision of price list due
to variations in rates of exchange>
(PQR-24-88) Equipment Configuiration
<a letter from Agent B reporting that configuration equipment for client J is ready>
Context WORK contains the following plans:
(1) Analyze marketing of product X
PARTS:
(2) Attend special client J
(1.1) Study market for product X
(1.2) Check quality of product X
PARTS:
(1.3) Negotiate wholesale prices of product X
(1.2.1) Negotiate warranty with agent
DONE 4/18/88
(1.2.2) Run compatibility tests
DONE 4/15/88
STEPS:
(3) Attend presentation of new products
(2.1) Configure equipment for client J
COMMISSIONED to Agent B
(2.2) Prepare bid for client J
(2.3) Deliver bid to client J
WAYS:
(4) Review credit application of client C
(3.1) Attend personally presentation new products
FAILED 4/20/88
(3.2) Send Technical Support Manager
FAILED 4/24/88
(3.3) Send Service Manager
PRIORITIES
(5) Send telex to client M
(4.1) Offer standard conditions, higher down payment
(4.2) Request collateral
(4.3) Ask more commercial references
Overdue!
Context WRITE has a single draft:
(d1) Sales meeting
<a draft relative to forthcoming sales meeting>
Sales Manager decides to ACCEPT the commission of General Manager; supported by AISA, she defines a task that represents her new commitment and which is added to the context WORK:
(6) Revise price list.
In addition, she ACCEPTs the report of Agent B related to task 2.1. She presses PgDn to move to context WORK and tries , to declare task 4.2 DONE (she just talked to client C and found him not willing to give higher down payment, but amenable to give collateral). However, AISA reminds her that this task is not yet executable, since 4.1 is prior. She then declares task 4.1 to have FAILED, and proceeds, this time successfully, to declare 4-2 DONE.
She now presses End to move to context WRITE, finishes up memo dl and signs it.
Currently she receives a phone call from Service Manager who tells her he is unable to attend the presentation of new products, so she decides to declare task 3.3 FAILED, which she does after pressing PgDn to move to context WORK.
She then declares task 1.3 DONE, since better prices were obtained per same volume of imports.
At this point Sales Manager is tired and unsure about what to do next; so, she decides to let AISA make suggestions. She presses Alt/s, which activates SUGGEST. SUGGEST processes the messages in GOALS and by so doing updates HAGENDA. Four different pop-up windows are displayed. Right on top of the command line (the line where the user writes her commands, the last row on the screen) a recommendation appears, preceded by the identifier of an item; in this case the recommendation line contains the following:
5 DONE.
This is in fact a proposed command line which, if accepted, will change the focus to point to task 5 and then apply DONE to that item.
Just below the top row of the screen (where the time flashes continuously) a second pop-up window shows the reason for the recommendation:
THIS TASK IS OVERDUE.
A third pop-up window, to the right on the middle of the screen, reads:
ATTEND TASK
which is the generic name of the current recommendation.
The fourth pop-up window, to the center-right of the screen, displays the actual content of the item being referred to, namely
SEND TELEX TO CLIENT M.
By pressing the space bar, Sales Manager can navigate through all suggested commands in relation to task 5; alternatively, the first pop-up window will show the following contents:
5 FAILED
5 POSTPONE
5 DESTROY.
Were Sales Manager to press Enter at this time, the contents of the first pop-up window would "fall" one row, onto the command line itself, meaning that the suggestion had been accepted (pressing Enter again would execute the command, as usual for command lines).
Pressing Ins causes the system to present the next entry in HAGENDA, i.e. the second most urgent item to attend to. When Sales Manager does this, the first pop-up window displays
2.1 DONE.
Sales Manager is happy with this recommendation, whose supporting reason ?shown on the second pop-up window? is
REPORT ACCEPTED.
Were there more reasons to support the same suggestion, the user could navigate through them pressing any letter key. Of course, the fourth pop-up key now reads .
CONFIGURE EQUIPMENT FOR CLIENT J.
Sales Manager presses Enter, thereby accepting the suggestion. Hence, the action of the SUGGEST command is over. By pressing Enter again, Sales Manager makes sure that the two commands
2.1. DONE
now on the command line get executed: 2.1 moves the focus to the item of that number, and DONE declares it done. The system records the preference of the user for the action DONE in relation to schema REPORT, confirming for future cases the current order of the recommendations with DONE as its first one.
She presses again Alt/s, requesting new suggestions. This time the response time is very fast, with less updating to do. The recommendation displayed is
4 DONE
with reason
ONE WAY OR PRIORITY IS DONE.
Sales Manager does not feel inclined to do anything about task 4, so she presses Ins. The following is displayed:
3 FAILED
with reason
LAST PRIORITY OR WAY HAS FAILED.
Again, Sales Manager presses Ins. The system responds by changing the third pop-up window to
ATTEND DRAFT,
first pop-up to
dl SEND,
fourth pop-up to
SALES MEETING, and
second pop-up to
DRAFT SIGNED.
This time task 5 was not selected, even if overdue, because procrastination has lowered its urgency ?directly at interface time.
Sales Manager feels like having a cup of coffee and presses Esc, which terminates the action of SUGGEST. AISA takes advantage of the absence of its master and checks for overdue tasks; again, it takes note of task 5, recording the relevant message. After a while, AISA enters "deep background mode" and updates the schemata with the information it has collected about the positive and negative attitude of the user with respect to particular suggestions during the activation of the SUGGEST command. Later on, it updates HAGENDA, processing the new contents of GOALS.
Sales Manager returns from her coffee brake and presses the space bar to call AISA back to foreground mode. She still wants AISA to have the initiative and presses Alt/s again. This time the system responds instantly, since HAGENDA is up to date and GOALS is empty.
The system suggests declaring DONE task 5. Sales Manager presses the space bar and now the first pop-up shows
5 FAILED.
Sales Manager presses Enter twice and the two commands–changing focus to task 5 and declaring it FAILED? get executed.
Again, Sales Manager presses Alt/s and the system responds by suggesting
4 DONE
for reason
ONE WAY OR PRIORITY IS DONE.
Her secretary enters and tells Sales Manager that he has prepared and delivered bid for client J. She then declares DONE tasks 2.2 and 2.3. Again, Alt/s is pressed. The recommendation is
2 DONE
since
LAST STEP OR PART IS DONE.
Sales Manager presses Enter twice and by so doing declares the task DONE. She goes home and leaves AISA working in deep background overnight; ideally, that time should be used by the system to review past experience and extract by induction new schemata and heuristics to improve performance of SUGGEST, and other modules of AISA now under development.
