fix: fixed links and minor typos (#101)

pages/concepts/agent-services/agent-explorer.mdx

@@ -1,6 +1,6 @@
 # The Agentverse Explorer 🤖🌐
 
-The Agentverse explorer is the first section of the Agentverse and represents an important part of it as it allows you to search and connect with other agents registered in the [Almanac Contract ↗️](/references/contracts/uagents-almanac/almanac-overview.md).
+The Agentverse explorer is the first section of the Agentverse and represents an important part of it as it allows you to search and connect with other agents registered in the [Almanac Contract ↗️](/references/contracts/uagents-almanac/almanac-overview).
 
 ## Active and local agents
 
@@ -10,4 +10,4 @@ Every agent available and displayed on the Explorer is denoted by a different ta
 
 Each agent registered within the Almanac is identified by 3 elements which you can use to retrieve them directly, that is: agent’s **address**, **endpoint**, or **protocols** implemented. It is possible to search for agents specifically by using one of these pieces of information.
 
-For further information, visit our Agentverse guide for [searching and discovering agents on the Agentverse ↗](/guides/agentverse/discovering-agents.mdx).
+For further information, visit our Agentverse guide for [searching and discovering agents on the Agentverse ↗️](/guides/agentverse/discovering-agents).

pages/concepts/agent-services/agent-mail.mdx

@@ -6,7 +6,7 @@ The **Mailroom** is a useful service dedicated to setting up mailboxes for your
 
 The Mailroom can be of particular interest and utility whenever you find it difficult to run a server and need some sort of trusted intermediary, the Mailroom in this case, to manage incoming messages from other people directly sending them to this hosted service, so for you to download them afterwards without the need of a continuous running server for this.
 
-Have a look at our [Agentverse guides ↗️](pages/guides/agentverse) and in particular the [Utilising the Agentverse Mailbox Service 📬↗️](/guides/agentverse/utilising-the-mailbox.mdx) guide for a better understanding of the _registration process_ and _remote communications_ between different agent.
+Have a look at our [Agentverse guides ↗️](/guides#agentverse) and in particular the [Utilising the Agentverse Mailbox Service 📬↗️](/guides/agentverse/utilising-the-mailbox.mdx) guide for a better understanding of the _registration process_ and _remote communications_ between different agent.
 
 ![](../../../src/images/mailroom.png)
 

pages/concepts/agent-services/agentverse-intro.mdx

@@ -13,3 +13,4 @@ For the more adventurous, the Agentverse provides a robust tool to create, test,
 Unleash your creativity and solve complex problems! Whether you're an experienced developer or a newcomer, the Agentverse welcomes you in the journey of developing agents for all kinds of your needs!
 
 For any additional questions, the Team is waiting for you on [Discord ↗️](https://discord.com/invite/fetchai) and [Telegram ↗️](https://t.me/fetch_ai).
+

pages/concepts/ai-engine/context-building-and-smart-routing.mdx

@@ -42,4 +42,4 @@ Trustworthiness, another dimension of this intricate dance, remains a cornerston
 
 The symphony of smart routing orchestrates a harmonious convergence of technological acumen and user-centric design. It embodies the AI Engine's commitment to not only deliver results but also to craft an environment in which every interaction resonates with reliability, efficiency, and dedication to exceed expectations.
 
-In this final step of the AI Engine's journey, we witness the culmination of its multifaceted abilities, from understanding user intent to task delegation. Smart routing bridges the chasm between intention and execution, shaping an ecosystem where technology's role transcends mere functionality, transforming into an ally that anticipates, understands, and aligns seamlessly with your needs.
+In this final step of the AI Engine's journey, we witness the culmination of its multifaceted abilities, from understanding user intent to task delegation. Smart routing bridges the chasm between intention and execution, shaping an ecosystem where technology's role transcends mere functionality, transforming into an ally that anticipates, understands, and aligns with your needs.

pages/guides/agents/cleaning-demo.mdx

@@ -23,7 +23,7 @@ First of all, let's define a protocol handling communication between a user requ
 
 1. The first step is creating a Python script for this task and name it: `touch __init__.py`
 
-2. Let's import the necessary classes from `datetime`, `typing`, `geopy.geocoders`, `geopy.distance`, `uagents`, and `.models`. Let's then define the message models and handlers for the service request, service response, service booking, and booking response using the `uagents` library. We then proceed and create a cleaning_proto object using the uagents **Protocol** class. We give it the name `cleaning` and the version `0.1.0`. This protocol will be used to define handlers and manage communication between agents using the defined message models.
+2. Let's import the necessary classes from `datetime`, `typing`, `geopy.geocoders`, `geopy.distance`, `uagents`, and `.models`. Let's then define the message models and handlers for the service request, service response, service booking, and booking response using the `uagents` library. We then proceed and create a cleaning_proto object using the uagents **Protocol** class. We give it the name `cleaning` and the version `0.1.0`. This protocol will be used to define handlers and manage communication between agents using the defined message models:
 
     ```py copy
     from datetime import datetime, timedelta
@@ -63,7 +63,7 @@ First of all, let's define a protocol handling communication between a user requ
     cleaning_proto = Protocol(name=PROTOCOL_NAME, version=PROTOCOL_VERSION)
     ```
 
-3. We would then need to define an `in_service_region` function, which determines whether a user's location is within the service area of a cleaning service provider. This function uses the `geopy` library for geolocation-related calculations and comparisons.
+3. We would then need to define an `in_service_region` function, which determines whether a user's location is within the service area of a cleaning service provider. This function uses the `geopy` library for geolocation-related calculations and comparisons:
 
     ```py copy
     def in_service_region(
@@ -91,13 +91,13 @@ First of all, let's define a protocol handling communication between a user requ
 
     This function takes in the following parameters:
 
-    - `location`: The location of the user as a string (e.g., an address).
-    - `availability`: An instance of the `Availability` class that holds information about the provider's availability.
-    - `provider`: An instance of the `Provider` class that holds information about the cleaning service provider.
+        - `location`: The location of the user as a string (e.g., an address).
+        - `availability`: An instance of the `Availability` class that holds information about the provider's availability.
+        - `provider`: An instance of the `Provider` class that holds information about the cleaning service provider.
 
     The function starts by creating a geolocator object from the `Nominatim` class with a user agent string `micro_agents`. The geolocator is then used to obtain the geographical coordinates (latitude and longitude) of both the user's location and the provider's location. The function checks whether the geocoding for both locations was successful. If either location is not found, it raises a `RuntimeError` with a relevant error message. The geographical coordinates of the user's location and the provider's location are used to calculate the distance (in miles) between them using the `geodesic` function from the `geopy.distance` module. The calculated distance is stored in the `service_distance` variable. Finally, the function compares the calculated `service_distance` with the maximum distance allowed for the provider's availability: if the calculated distance is less than or equal to the provider's maximum distance, the user's location is considered within the service range, and the `in_range` variable is set to `True`. Otherwise, the `in_range` variable is set to `False`. The function returns the value of `in_range`, which indicates whether the user's location is within the service area of the provider.
 
-4. We then need to define an event handler using the `@cleaning_proto.on_message` decorator. This handler is responsible for processing incoming service requests, evaluates various conditions, and generates appropriate responses indicating whether the request is accepted and proposing a price if applicable. It takes in `ServiceRequest` messages and generates `ServiceResponse` messages as responses.
+4. We then need to define an event handler using the `@cleaning_proto.on_message` decorator. This handler is responsible for processing incoming service requests, evaluates various conditions, and generates appropriate responses indicating whether the request is accepted and proposing a price if applicable. It takes in `ServiceRequest` messages and generates `ServiceResponse` messages as responses:
 
     ```py copy
     @cleaning_proto.on_message(model=ServiceRequest, replies=ServiceResponse)
@@ -142,7 +142,7 @@ First of all, let's define a protocol handling communication between a user requ
 
     If all conditions are met, the handler sets `accept` to `True` and calculates the proposed `price` based on the markup and availability's minimum hourly price. If any condition is not met, the handler sets `accept` to `False` and the `price` to `0`. Finally, the handler sends a `ServiceResponse` message back to the sender with the calculated `accept` flag and `price`. The handler logs relevant information using the `ctx.logger.info()` method.
 
-5.  We then define another event handler, `handle_book_request()`, using the `@cleaning_proto.on_message()` decorator. This handler processes incoming booking requests, evaluates various conditions, and generates appropriate responses indicating whether the service request was successful. It is triggered whenever a `ServiceBooking` message is received and generates a `BookingResponse` messages as response.
+5.  We then define another event handler, `handle_book_request()`, using the `@cleaning_proto.on_message()` decorator. This handler processes incoming booking requests, evaluates various conditions, and generates appropriate responses indicating whether the service request was successful. It is triggered whenever a `ServiceBooking` message is received and generates a `BookingResponse` messages as response:
 
     ```py copy
     @cleaning_proto.on_message(model=ServiceBooking, replies=BookingResponse)
@@ -354,25 +354,25 @@ We now continue and define a `models` protocol which defines the structure and r
                 - `created_at`: DateTime field automatically set to the current timestamp when the user is created.
 
         - `Service` is model representing types of cleaning services. It takes in the following fields:
-            - `id`: Auto-incrementing integer field serving as the primary key.
-            - `type`: Enum field storing the ServiceType enumeration values.
+                - `id`: Auto-incrementing integer field serving as the primary key.
+                - `type`: Enum field storing the ServiceType enumeration values.
 
         - `Provider` is a model representing cleaning service providers. It considers the following fields:
-            - `id`: Auto-incrementing integer field serving as the primary key.
-            - `name`: Character field with a maximum length of 64 for the provider's name.
-            - `location`: Character field with a maximum length of 64 for the provider's location.
-            - `created_at`: DateTime field automatically set to the current timestamp when the provider is created.
-            - `availability`: Reverse relation to the `Availability` model.
-            - `services`: Many-to-many relationship with the `Service` model.
-            - `markup`: Float field representing the markup applied to service prices.
+                - `id`: Auto-incrementing integer field serving as the primary key.
+                - `name`: Character field with a maximum length of 64 for the provider's name.
+                - `location`: Character field with a maximum length of 64 for the provider's location.
+                - `created_at`: DateTime field automatically set to the current timestamp when the provider is created.
+                - `availability`: Reverse relation to the `Availability` model.
+                - `services`: Many-to-many relationship with the `Service` model.
+                - `markup`: Float field representing the markup applied to service prices.
 
         - `Availability` is a model representing the availability of a cleaning service provider. It considers the following fields:
-            - `id`: Auto-incrementing integer field serving as the primary key.
-            - `provider`: One-to-one relationship to the `Provider` model.
-            - `max_distance`: Integer field representing the maximum distance a provider can travel for services.
-            - `time_start`: DateTime field indicating the start time of availability.
-            - `time_end`: DateTime field indicating the end time of availability.
-            - `min_hourly_price`: Float field representing the minimum hourly price for services.
+                - `id`: Auto-incrementing integer field serving as the primary key.
+                - `provider`: One-to-one relationship to the `Provider` model.
+                - `max_distance`: Integer field representing the maximum distance a provider can travel for services.
+                - `time_start`: DateTime field indicating the start time of availability.
+                - `time_end`: DateTime field indicating the end time of availability.
+                - `min_hourly_price`: Float field representing the minimum hourly price for services.
 
 3. Save the script.
 
@@ -414,7 +414,7 @@ We are now ready to define our `cleaner` agent.
 
     The `cleaner` agent includes the previously defined cleaning protocol (`cleaning_proto`) using the `include()` method. This integrates the protocol's models and handlers into the agent's capabilities. The agent is set up to interact with the cleaning service protocol, allowing it to communicate with users and providers according to the logic defined in the protocol's handlers.
 
-3. We then define the behaviors of our `cleaner` agent.
+3. We then define the behaviors of our `cleaner` agent:
 
     ```py copy
     @cleaner.on_event("startup")
@@ -554,7 +554,7 @@ We are now ready to define our `user` agent.
     fund_agent_if_low(user.wallet.address())
     ```
 
-3. Let's define a `ServiceRequest` object to represent a request for cleaning services. It includes information such as the user's name, location, start time, duration, types of services requested, and a maximum price. We also define a `MARKDOWN` to apply a discount or markdown to the service.
+3. Let's define a `ServiceRequest` object to represent a request for cleaning services. It includes information such as the user's name, location, start time, duration, types of services requested, and a maximum price. We also define a `MARKDOWN` to apply a discount or markdown to the service:
 
     ```py copy
     request = ServiceRequest(
@@ -569,7 +569,7 @@ We are now ready to define our `user` agent.
     MARKDOWN = 0.8
     ```
 
-4. We then define an event handler to handle service requests.
+4. We then define an event handler to handle service requests:
 
     ```py copy
     @user.on_interval(period=3.0, messages=ServiceRequest)
@@ -585,7 +585,7 @@ We are now ready to define our `user` agent.
 
    The `interval()` function is decorated with the `.on_interval()` decorator indicating that is is executed at regular intervals specified by the period parameter to send `ServiceRequest` messages. Within the function, the `ctx.storage.set()` method is called to store the `MARKDOWN` constant in the context's storage under the key "markdown". The function first checks the value of `completed` which is retrieved from the context's storage using `ctx.storage.get()` method. This is used to determine whether the service request has already been completed. If the service request is not marked as completed, an informational log message is generated using `ctx.logger.info()` method indicating that a cleaning service request is being made. The `{request}` placeholder in the log message is filled with the details of the request object previously created. Then, `ctx.send()` method is called to send the cleaning service request to the specified address (`CLEANER_ADDRESS`) alongside with the request object.
 
-5. We then would need to define a function for handling responses to service queries and generating service bookings based on the received response.
+5. We then would need to define a function for handling responses to service queries and generating service bookings based on the received response:
 
     ```py copy
     @user.on_message(ServiceResponse, replies=ServiceBooking)
@@ -612,7 +612,7 @@ We are now ready to define our `user` agent.
 
     If however the response message does not indicate acceptance, a log message is generated, indicating that a cleaner is not available. The "completed" key in the storage is set to `True`, indicating that the service request process has been completed.
 
-6. We finally need to define a function for handling `BookingResponse` messages.
+6. We finally need to define a function for handling `BookingResponse` messages:
 
     ```py copy
     @user.on_message(BookingResponse, replies=set())
@@ -717,7 +717,6 @@ if __name__ == "__main__":
 Run the **cleaner** agent and then the **user** agent from different terminals.
 
 - Terminal 1: `python cleaner.py`
-
 - Terminal 2: `python user.py`
 
 The output should be as follows, depending on the terminal: