There are definitely problems in the protocol, not necessarily in the encryption scheme of the asker.
The protocol allows for replay attacks, i.e. an entity R can capture messages that A sends to B, and then resends the messages without knowing what's in those messages, even though A may not have intended to send those. Then it comes down to what's contained in those messages. For example, let's a A and B are computers and A sends a message to B to reboot, and another entity E captures it. Now, just by replaying the message and observing B's behavior, E can not only cause B to behave the way it wants, it also understands what the message means even though it can't see the contents.
A second type of attack is that another entity M can spoof A and start sending B with a lot of messages. Since B doesn't know whether they are coming from a trusted source, B will attempt to decrypt those messages thus consuming resources. M may no not need as many resources since all M needs to do is create and send random data, but B will start running out of resources, that's a DOS attack.
Another attack involves M capturing the messages that A sends to B and responding with ACK on B's behalf, which it has captured in a previous exchange. B never gets the actual messages and doesn't know that it did not get the message. A never knows that it wasn't B who ACKed the message instead it was E.
There are other more sophisticated attacks that can be constructed in this fashion. The ones I listed here are typically the introductory attacks that are looked at when designing secure protocols.
Security comes with a whole plethora of things, not just encryption. Encryption solves one aspect, albeit the most important one, around security. But in your case, you are also designing a protocol, which is not secure, and thus you might as well use an existing protocol.
That's where security protocols come in which perform appropriate handshakes, authentication (to ensure the other party is the correct one), provide protection against replay attacks etc. Man-in-the-middle attacks could still be a vulnerability (if you don't trust public key infrastructure, that is), although in your case, you can solve that because A and B have a shared secret (In fact, I am assuming that you're starting with shared secret primarily because A and B do not trust anyone else in the world - usually a good reason to have shared secrets.)
Btw, once you have such security protocols, given all the data that they need to send between each other, you will end up with security tokens to ensure that all parties have a mutual understanding of what's contained in it, how it is encoded, etc. (e.g. nonce, keys, encrypted data, digital signature, etc.)
In essence, IMO, you are attempting to create your own security protocol, and as someone already mentioned, you might be better off attempting to start with an existing protocol.