The core of an application built on top of AMPS is modeled as a single, non-blocking, event-driven process. The salient features of the application are listed below:

• The application is modelled as a FSM (Finite State Machine) that changes state as events occur.
• The application is divided into a set of modules.
• Each module is further divided into a set of functions called event handlers. Each event handler is created to handle a particular event that changes FSM from one state to other.
• Each Event Handler must terminate on every blocking operation. If it is not the case, then it needs to be taken out of the asynchronous single threaded framework and implemented as an I/O Agent (described later)
• Events can be generated as a result of occurrence of I/O operations, or due to one module trying to communicate with another module.
• The communication model between modules used by AMPS is based on rendezvous based abstraction. In this model, senders are de-coupled from receivers. Senders send their events to the rendezvous without specifying any recipients and receivers receive events of their intereset from the rendezvous without realizing exactly who sent them these events Receivers express or register their interest in receiving the events they want to receive. Senders just generate events at the appropriate time, hoping that each event will be received by all modules interested in that particular event.
• Each event need to identify to AMPS what data it needs to send to the other Event. It is then the responsibility of AMPS to deliver that data using the most efficient method available. This makes scalaing to other cores, processors or even out to cloud a seamless thing for the application.

This type of communication model enables seamless integration of new modules quite easy. The whole system becomes a service-oriented architecture. Each module provides a set of services, and requires a set of services from other modules. A module could either provide service when solicited or requested, or it could provide service asynchronously. Service itself could be some task or function required by one or more modules in the system, or it may only be some information disseminated throughout the system picked up by anyone interested in it. Note that at the architecture level, the producers and consumers of service do not need to know about each other. However, if at the application level, they want to find out about each other, they may use the data transferred in each event for this purpose. This keeps the architecture clean and maintains its simplicity.