docs: update code snippets

pages/docs/concepts/agent.mdx

@@ -16,11 +16,13 @@ Agents in Rig provide a high-level abstraction for working with LLMs, combining
 An Agent consists of:
 
 1. **Base Components**
+
    - Completion Model (e.g., GPT-4, Claude)
    - System Prompt (preamble)
    - Configuration (temperature, max tokens)
 
 2. **Context Management**
+
    - Static Context: Always available documents
    - Dynamic Context: RAG-based contextual documents
    - Vector Store Integration
@@ -140,11 +142,13 @@ Bear in mind that while prompt hooks are not blocking, it's generally advisable
 ## Best Practices
 
 1. **Context Management**
+
    - Keep static context minimal and focused
    - Use dynamic context for large knowledge bases
    - Consider context window limitations
 
 2. **Tool Integration**
+
    - Prefer static tools for core functionality
    - Use dynamic tools for context-specific operations
    - Implement proper error handling in tools

pages/docs/concepts/completion.mdx

@@ -135,13 +135,15 @@ let request = model.completion_request("prompt")
 ### Request Components
 
 1. **Core Elements**
+
    - Prompt text
    - System preamble
    - Chat history
    - Temperature
    - Max tokens
 
 2. **Context Management**
+
    - Document attachments
    - Metadata handling
    - Formatting controls
@@ -240,11 +242,13 @@ impl CompletionModel for CustomProvider {
 ## Best Practices
 
 1. **Interface Selection**
+
    - Use `Prompt` for simple interactions
    - Use `Chat` for conversational flows
    - Use `Completion` for fine-grained control
 
 2. **Error Handling**
+
    - Handle provider-specific errors
    - Implement graceful fallbacks
    - Log raw responses for debugging

pages/docs/concepts/embeddings.mdx

@@ -92,11 +92,13 @@ qdrant.insert_documents(embeddings).await?;
 ## Best Practices
 
 1. **Document Preparation**
+
    - Clean and normalize text before embedding
    - Consider chunking large documents
    - Remove irrelevant embedding content
 
 2. **Error Handling**
+
    - Handle provider API errors gracefully
    - Validate vector dimensions
    - Check for empty or invalid input

pages/docs/concepts/extractors.mdx

@@ -130,11 +130,13 @@ impl<T: JsonSchema + for<'a> Deserialize<'a> + Serialize + Send + Sync> Tool for
 ## Best Practices
 
 1. **Structure Design**
+
    - Use `Option<T>` for optional fields
    - Keep structures focused and minimal
    - Document field requirements
 
 2. **Error Handling**
+
    - Handle both extraction and deserialization errors
    - Provide fallback values where appropriate
    - Log extraction failures for debugging

pages/docs/concepts/loaders.mdx

@@ -130,11 +130,13 @@ impl<T: Loadable> Loadable for Result<T, PdfLoaderError> {
 ## Best Practices
 
 1. **Error Handling**
+
    - Use `ignore_errors()` for fault-tolerant processing
    - Handle specific error types when needed
    - Log errors appropriately
 
 2. **Resource Management**
+
    - Process files in batches
    - Consider memory usage with large files
    - Clean up temporary resources

pages/docs/integrations/model_providers/openai.mdx

@@ -54,6 +54,7 @@ let embedder = client.embedding_model(openai::TEXT_EMBEDDING_3_LARGE);
 1. **Tool Calling**: OpenAI models support function calling through a specialized JSON format. The provider automatically handles conversion between Rig's tool definitions and OpenAI's expected format.
 
 2. **Response Processing**: The provider implements special handling for:
+
    - Tool/function call responses
    - System messages
    - Token usage tracking

pages/docs/integrations/vector_stores/in_memory.mdx

@@ -220,11 +220,13 @@ match store.get_document::<MyDoc>("doc1") {
 ## Best Practices
 
 1. **Memory Management**:
+
    - Monitor memory usage with large datasets
    - Consider chunking large document additions
    - Use cloud-based vector stores for production deployments
 
 2. **Document Structure**:
+
    - Keep documents serializable
    - Avoid extremely large arrays
    - Consider using custom ID generation for meaningful identifiers
@@ -237,11 +239,13 @@ match store.get_document::<MyDoc>("doc1") {
 ## Limitations
 
 1. **Scalability**:
+
    - Limited by available RAM
    - No persistence between program runs
    - Single-machine only
 
 2. **Features**:
+
    - No built-in indexing optimizations
    - No metadata filtering
    - No automatic persistence

pages/docs/integrations/vector_stores/lancedb.mdx

@@ -206,10 +206,12 @@ impl RecordBatchDeserializer for Vec<RecordBatch> {
 ## Best Practices
 
 1. **Index Creation**:
+
    - Minimum of 256 rows required for IVF-PQ indexing
    - Choose appropriate distance metrics based on your use case
 
 2. **Schema Design**:
+
    - Use appropriate data types for columns
    - Consider embedding dimension requirements
 
@@ -220,10 +222,12 @@ impl RecordBatchDeserializer for Vec<RecordBatch> {
 ## Limitations and Considerations
 
 1. **Data Size**:
+
    - Local storage is suitable for smaller datasets
    - Use cloud storage for large-scale deployments
 
 2. **Index Requirements**:
+
    - IVF-PQ index requires minimum dataset size
    - Consider memory requirements for large indices
 

pages/docs/integrations/vector_stores/mongodb.mdx

@@ -136,6 +136,7 @@ The collection must have a vector search index configured:
 ## Special Considerations
 
 1. **Index Validation**: The implementation automatically validates:
+
    - Index existence
    - Vector dimensions
    - Similarity metric

pages/docs/quickstart/embeddings.mdx

@@ -25,6 +25,7 @@ Below is an example of how you can use `rig` to embed some simple documents.
 
 ```rust
 use rig::{embeddings::EmbeddingsBuilder, providers::openai};
+use rig::client::{EmbeddingsClient, ProviderClient};
 
 // Create OpenAI client and model
 // This requires the `OPENAI_API_KEY` environment variable to be set.

pages/docs/quickstart/getting_started.mdx

@@ -22,23 +22,27 @@ This will add the `rig-core` dependency in your Rust project, as well as Tokio w
 Below is a simple example of how you can use `rig` to prompt OpenAI's GPT-4 model:
 
 ```rust
-use rig::{completion::Prompt, providers::openai};
+use rig::client::{CompletionClient, ProviderClient};
+use rig::completion::Prompt;
+use rig::providers::openai;
 
 #[tokio::main]
-async fn main() {
-    // Create OpenAI client and model
-    // This requires the `OPENAI_API_KEY` environment variable to be set.
-    let openai_client = openai::Client::from_env();
+async fn main() -> Result<(), anyhow::Error> {
+    // Create OpenAI client
+    let client = openai::Client::from_env();
 
-    let gpt4 = openai_client.agent("gpt-4").build();
+    // Create agent with a single context prompt
+    let comedian_agent = client
+        .agent("gpt-5.2")
+        .preamble("You are a comedian here to entertain the user using humour and jokes.")
+        .build();
 
-    // Prompt the model and print its response
-    let response = gpt4
-        .prompt("Who are you?")
-        .await
-        .expect("Failed to prompt GPT-4");
+    // Prompt the agent and print the response
+    let response = comedian_agent.prompt("Entertain me!").await?;
 
-    println!("GPT-4: {response}");
+    println!("{response}");
+
+    Ok(())
 }
 ```
 

pages/guides/advanced/discord_bot.mdx

@@ -443,11 +443,13 @@ Let's break down the process:
 1. When an interaction is received, we first check if it's a slash command using the `Interaction::ApplicationCommand` enum variant.
 
 2. If it's a slash command, we match on the command name to determine the appropriate action.
+
    - For the `"hello"` command, we respond with a simple greeting message.
 
    - For the `"ask"` command, we extract the user's query from the command options. If no query is provided, we use a default message.
 
 3. If the command is `"ask"`, we pass the user's query to the Rig agent's `process_message` method to generate a response.
+
    - If the Rig agent successfully generates a response, we send it back to the user.
 
    - If an error occurs during processing, we log the error and send an error message to the user.
@@ -511,6 +513,7 @@ Here's how the message handling works:
 3. If the bot's user ID is found, we remove the mention from the message content to extract the actual query.
 
 4. We pass the processed message content to the Rig agent's `process_message` method to generate a response.
+
    - If the Rig agent successfully generates a response, we send it back to the channel where the message was received using `msg.channel_id.say`.
 
    - If an error occurs during processing, we log the error and send an error message to the channel.
@@ -567,6 +570,7 @@ Here's what happens in the `ready` event handler:
 3. We store the bot's user ID in the `TypeMap` using the `BotUserId` key. This allows us to access the bot's user ID in other event handlers.
 
 4. We create global slash commands using the `Command::set_global_application_commands` method.
+
    - We define two commands: `"hello"` and `"ask"`.
 
    - The `"hello"` command is a simple command that greets the user.
@@ -674,6 +678,7 @@ To invite the bot to your Discord server, follow these steps:
 Once the bot is running and invited to your server, you can test its functionality:
 
 - **Slash Commands**:
+
   - Type `/hello` to receive a greeting.
   - Use `/ask` followed by a question to interact with the bot and receive a response generated by the Rig agent.