The first thing you see when you start the program is the interface. Depending on the configuration, the agent could be one of 5 variants. In any case, the text entry box is the same. To start a conversation, type something in that box and press Enter.
What happens next is relatively straightforward. The interface passes the student input string to the Tutor and asks for a response in return. The Tutor consists of a series of modules, each of which operates on the output of the last, to generate the tutor response. This flow of work is organized around the State Table, a notion introduced in AutoTutor 3.0 and further refined here. The State Table consists of a set of attribute/value pairs representing all of the state used by the tutor in the session. What do I mean by state? Memory. All of the memory of the tutor, that which makes the current turn different from all other turns, is held in the state table. Thus the notion is not too dissimilar from the TrindiKit notion of information state. Moreover, you can recreate any point in the tutoring session based on just the last state table. Thus the state table is not only the object that all the modules in the Tutor operates on, it is also the perfect thing to log to the log files.
The state table is passed from module to module, ending with the dialogue management module. Any new module that you might want to add should follow the examples of the existing modules. Each module looks at the state table, operates on its data, and adds more information. For example, the language analysis module, which includes the tagger and speech act classifier, consults the student input, and returns a speech act classification tag. By the time the state table reaches the dialogue manager, it contains all of the information the dialogue manager should need to make a decision. Since the heart of the dialogue manager is written in Prolog, the state table is made available to Prolog via the mechanisms for this in tuProlog/2Prolog. In this way, the keys/values in the state table can be consulted by the Prolog rules. The dialogue manager's Prolog engine also has the ability (through tuProlog) to call methods in C# from Prolog. This substantially simplifies some aspects of the Prolog programming: the procedural aspects can be left to C#, and the remaining declarative dialogue logic can be left to Prolog.
Finally, the dialogue string returned by the dialogue manager is passed back to the interface and acted out by the agent.