In a traditional client–server model, the application would form a number of queries, send them to a number of services, and then collect the results and display them. In the Telescript model, the application would instead build a new agent populated with the data from the request, stamp it with their name and address, and then send that to a store place on a server for processing. That server could then handle the request directly, or hand off the agent to other places, like the actual vendors' places, for further processing. The results could be placed in the agent's internal data fields and sent back through the network to the user's device, or a new "messenger" agent could be spawned to carry only the result data and sent back to minimize network data transfer. The model also differs from traditional solutions in the way that data exchange occurs in the case of interacting programs. For instance, if the user chooses to buy one of the barbecues they found in their previous search, in a conventional system the task of filling out the order forms and confirming payment would be accomplished through direct communications between the user's device and the remote server, requiring a "live" communications channel throughout the process. In the Telescript model, a new agent with the information needed to complete the purchase is sent to that vendor's store place, interacts with the store place or agents from the vendor, and then returns with the success or failure. The main communications takes place between the agents and places on the remote server, so communications over the network is required only at the start and end of the process. Telescript was object-oriented (OO) and used a number of uncommon terms to describe object state and communications. "Attributes" correspond to what other languages refer to as instance variables or fields. Method calls were known as "requests", and the act of running a method's implementation was known as "performing" it. All such calls always responded with a message indicating success or failure, it was up to the requesting object to optionally trap those and respond to them. Hints on how to pass the data into and out of method calls were known as "constraints", and covered the common "by ref" and "by value", among others. Telescript was generally stateless in terms of data lifetime. All data within the program, both instance and local variables, were always serialized. Agents could be invoked or suspended at any instant, and would not lose their state. This same mechanism also allowed agents to be easily communicated between hosts.