When TAME is given input (usually submitted using a Shell), TAME processes it, changes a module context's state, and returns a result. Requests that contain the input are created, and a Response is generated after the Request is processed. The Response contains a list of items called Cues that are read by the Shell and rendered in a way that the user can read.
Input into TAME is usually a user-typed string like:
pick up lamp look at dog scream
TAME takes this input and wraps it in a Request object. The Interpreter figures out the Action and the Objects involved and then queues that action for processing, then after all actions are processed, a Response is returned, usually containing Cues that the Shell then needs to process.
Every processed TAME Request returns a Response. The Response contains things like:
After the Response is received, the Shell has to do something wih it. Each of the Cues in the Response is something for the Shell to do, in the order that they are read from the list, before it can send input again. Not every TAME Shell can or should handle these Cues, but there are a few types of Cues that ALL Shells need to handle (you can see these Cues when you run modules in this documentation in DEBUG mode).
The fact that not every Shell can handle every Cue is the thing that gives TAME additional flexibility in authoring - some Cues can describe graphical actions, some can change a screen layout, and some could tell the Shell to play music or sound effects, but this is only relevant to special Shells. If written with enough care and creativity, the same TAME module can be executed in both a rich multimedia environment, such as a web browser, as well as a purely textual environment, such as a command terminal or even in an IRC or Discord server!
But of course, TAME doesn't even know what the user wants to do unless it runs their input through an Interpreter.