There exist plenty of standards for that, Alice and Bob just haven't agreed on any.
AES by itself is just a block cipher. Like any block cipher, it transforms an input block of data into an equally sized output block data. The block size of AES is 128 bits. How this transformation is performed is controlled by a key. In case of AES keys can either be 128, 192, or 256 bits. Note that the key size is not related to the block size, the block size is always 128 bits for AES.
Now 128 bits are 16 bytes, so basically AES can only encrypt exactly 16 bytes of data. Most messages are not exactly 16 bytes of data. So if you want to encrypt more than 16 bytes, less than 16 bytes or any message that is not a multiple of 16 bytes, you require a way how to split this message up into equally sized pieces that you can feed into the AES block cipher.
The simplest way would just be to break up the message into blocks of 16 bytes and then encrypt each block on its own, padding the last block as required. But this is a very poor block chaining as the same input data will always result in the same output data. A very famous example why that is a bad idea is shown below. Below you see the Tux image to the left and the encrypted Tux image to the right where just every block was encrypted on its own using the same key:
See the problem? As the same block is always encrypted in the same way, patterns will persist even after the encryption and often these patterns reveal too much information about the otherwise protected message.
There are various better ways to do that, called block cipher mode of operation. The most widely used one is called CBC, yet for better performance many software prefers CTR today. Other well known alternatives are CFB and OFB. Not specifying the block cipher mode of operation is the first shortfall of Alice and Bob. Instead of agreeing to use AES-128, they should have agreed to use AES-128-CBC or AES-128-CFB. Note that any of these modes can be combined with any block cipher, even those with a different block size.
The next problem is that passwords are poor keys. So almost no software uses passwords for keys directly, instead they feed passwords into a key derivation function, that produces good keys out of these passwords. Alice and Bob did not agree on a key derivation function to use or about the exact parameters of such a function.
The most widely used key derivation function today is named PBKDF2 and it requires two parameters to be known: The hash method (which can be any hash function you can think of) and the number of rounds. E.g. the hash method could be SHA-1 and the number of rounds could be 5000. With the same password and the same parameters, PBKDF2 will always generate the same key. The more rounds, the more complex is the calculation of that key, which is good when people try to break encryption by guessing the password as they must run every guess through PBKDF2 before trying it and the more complex that is, the less passwords an attacker can try in the same time using the same piece of hardware.
Of course other methods exist, like bcrypt, scrypt, or the new Argon2, which was the winner of the last Password Hashing Competition in 2015. If you have no other option, you can also just hash a password using any cryptographic hash function and then shorten the hash to the required key size but this way you make it easier for attackers to try out passwords as cryptographic hash functions are designed to be fast and efficient in calculation and in this very special case, being fast is actually not desirable. Not specifying which method to use for key derivation and their parameters was the second shortfall of Alice and Bob.
Last but not least, even when using a block cipher mode of operation, the same data encrypted with the same key would still always produce the same output data and this is not desired as if a lot of messages are encrypted and some of them may be the same as previous messages (e.g. think of network packets encrypted for a VPN tunnel), an attacker not knowing the key, cannot see their content, but he can see how often the same message is being sent or at which intervals and this alone may already reveal too much information. That's why all modes of operation add some randomness to the encrypted data, which is similar how sometimes a "salt" is added to hashed data as otherwise the same data would also always result in the same hash.
This added randomness is called an initialization vector (IV), and it's a piece of data that usually equals the block size of the cipher. So in case of AES the IV is 128 bit (16 byte). The IV usually doesn't have to be special other than that the same key should never be used with the same IV to process different data. It's not horrible if this happens but every time it happens, your encryption gets weaker and weaker. Most of the time the IV is chosen randomly as 2^128 is a very big number, the same size as a UUID and thus chances for a collision are tiny as you can see here.
Of course, the other side requires to know the IV to decrypt the data again but that is not an issue. As the IV can just be a random piece of data, there is no need to protect it at all. Usually the IV is added to the beginning of the decryption output as if it was the first block. But the IV can also be added to the end or being sent separately. How, where and in which format the IV is transmitted as part of the encrypted message is the third thing that Alice and Bob failed to specify.
So the entire problem is that Alice and Bob didn't really specify most of the important details how to exchange the message. It's like saying "We will meet at 9" but without telling the other side the day, p.m. or a.m., or where the meeting will take place. If one person waits at the park at 9 a.m. on Monday but the other person waits at the mall at 9 p.m. on Tuesday, you don't really have to ask why the meeting didn't take place, do you? There were just not enough information exchanged. Saying AES just specify the block cipher being used but this is far too little for specifying a message exchange.
This is why there are standardized message formats that include all these variable parameters as part of the message, e.g. PGP (Pretty Good Privacy). If Alice and Bob had agreed just on a password and to use PGP, they would not need to know any of these details, no matter what Alice selects (maybe just keeping the defaults of her PGP software), the selection is written to the message and thus Bob doesn't need to know it as Bob's PGP software will know how to decrypt the message by just looking at the message itself. And the PGP format is supported by various apps, so Alice and Bob doesn't have to use the same software.