For a script to do useful work, it must communicate with the application in some way. Even a simple macro needs to be able to invoke commands. There are two alternative methods for doing this.
The scripting language and the application can share an address space, with functions the application can invoke to start and stop scripts, and functions that the scripting language invokes to cause the application to issue commands - and, of course, ways to get data from the application, and to pass it back. Given that scripting languages started as macro facilities specific to an application, this is a very common method. Recent scripting languages are designed to be embedded in an application, so that a user who already knows the scripting language only needs to learn the commands specific to that application to start scripting it.
An alternative is that the scripting language and the application communicate using some form of interprocess communications facility. In this case, the application will start the script in a separate process, providing the script with the information it needs to communicate with the application. The application then uses the system's facilities to get information from the application and have it run commands.
The disadvantages of this are immediately obvious - the overhead of starting a new process, setting up a connection, and the passing the data back and forth between the two processes can be fairly hefty. The advantages are discussed in the next section.