There are two related questions:
1. What is a micro-service?
2. How is a micro-service architecture implemented?
The first is subject to some debate, and it's not a debate I'm particularly interested in so I'll leave it as an exercise.
Micro-service architectures are generally implemented in two ways: push and pull. A collection of REST API's will tend to produce a push architecture of explicit requests and responses. A log to which all requests and responses are written with each individual service responsible for finding applicable messages is a way of implementing a pull architecture. Queues can play a role in either but are at an implementation detail at a lower level of abstraction.
Chat bots [1] can be seen as an example of a pull architecture with a log. Bots scan the continuous stream of messages and ignore what does not apply and act upon what does apply, typically they return results to the message stream. A chat bot might have a queue to manage requests and responses (input/output) or not, but that's an implementation detail not a high level architectural one at the level of a chat system.
A chat system will tend to grow by adding more bots rather than expanding existing bots and each bot will tend to have little or no knowledge of other bots. Each bot will be independent: one will run Jenkins another will make coffee.
The big point is that services are a way of organizing a system architecture and micro-services are one granularity at which the system may be decomposed. It's probably arguable that what constitutes a micro-service versus a service is relative to the size of the overall system. In practice, what is and isn't a micro-service has some correlation to the practicality of delegating responsibility to a team <= two pizzas.
YMMV.
[1]: A chat bot might be an example of something that is small enough to be 'micro'-- or deci, nano, atto, yocto etc. -- (or not).