The Arc of the Book

The structure is well thought out. The first few chapters establish foundational concepts - what an AI agent actually is (autonomy, perception, reasoning, action, adaptation), how the agent loop works, and how memory, tools, and orchestration fit together. This isn't padding; the definitions are precise enough to be useful later when the complexity ramps up.

The standout early chapter is the hands-on walkthrough of a Kubernetes diagnostic agent. It's a deliberate provocation: look how much you can do with how little. The agent inspects cluster state, diagnoses issues using an LLM, proposes fixes, and requests human confirmation before making changes. It's a clean demonstration of the sense-think-act loop in the real world, and it sets a useful benchmark for what "simple but capable" looks like.

The AI-6 Framework

Much of the book is structured around AI-6, a custom Python framework. You get to see how session management, context compression, LLM provider abstraction, and tool execution actually work - not as magic, but as explicit, readable code.

The tool system chapters are particularly strong. The book covers custom tools, MCP tools, provider-agnostic tool definitions, and the mechanics of how an LLM selects and invokes a tool. The discussion of tool safety - controlling what tools can access, sandboxing execution, and using human-in-the-loop confirmation for high-risk operations - is more thorough than most resources on the subject.

MCP: Why It Matters

The Model Context Protocol chapter is one of the best concise explanations of MCP I've read. The problem it solves is stated clearly: before MCP, every agentic system had to build its own bespoke connectors to every external tool or service, creating tight coupling and constant maintenance burden. MCP introduces a shared protocol so that a tool built once can be consumed by any compliant host - "write once, run everywhere" for AI tooling.

The chapter covers the client-server architecture, the two protocol layers (data and transport), local versus remote servers, and how tool discovery works at runtime. Crucially, it also shows how MCP maps onto AI-6's existing tool abstractions, making integration feel natural rather than bolted on. For anyone evaluating whether to build MCP-native tooling, this chapter gives you the mental model you need.

A2A and Multi-Agent Orchestration

The second half of the book moves into multi-agent territory, and this is where it becomes genuinely distinctive. The orchestration patterns chapter - covering sequential, parallel, hierarchical, event-driven, and collaborative patterns - is the kind of clean taxonomy that the field has needed. Each pattern is explained with its tradeoffs: sequential is predictable but slow, parallel maximizes throughput but requires result merging, collaborative enables emergent problem-solving but demands sophisticated coordination protocols.

The A2A (Agent-to-Agent) protocol coverage is timely. The breakdown of the five core primitives - agent cards, tasks, messages, parts, and artifacts - gives you a concrete vocabulary for designing inter-agent communication. The three interaction patterns (request/response polling, push notifications, and streaming via SSE) map cleanly to real use cases.

Testing, Debugging, and the Honest Chapter

Chapter 10 on testing and debugging is the one most books skip or treat superficially, and its thoroughness here is appreciated. The catalog of failure modes is comprehensive: hallucinations embedded in tool calls, agents claiming to have executed operations they haven't, infinite retry loops, context drift across long sessions, tool selection errors, instruction following failures, and cross-agent interference in concurrent workflows. These aren't theoretical - they're the things that actually go wrong in production agentic systems.

The logging and observability guidance is practical: structured hierarchical traces, complete LLM prompt/response logging including token counts and latency, tool invocation capture with input/output, and contextual metadata tagging. The redundancy and resilience section addresses multi-provider LLM strategies and graceful degradation, which are often afterthoughts in agentic system design.

Who Should Read This

This book is aimed squarely at software engineers and AI practitioners who want to move beyond building simple LLM wrappers and understand how production-grade multi-agent systems actually work. It assumes Python familiarity and some exposure to LLM APIs. If you're already deep in the weeds of agentic frameworks, some of the foundational chapters will feel familiar - but the MCP, A2A, orchestration patterns, and debugging chapters will likely contain material worth your time regardless of experience level.

It's a strong, practically-oriented book on a topic that genuinely matters right now. Recommended.

Book Review: Agentic Architectural Patterns for Building Multi-Agent Systems

If you're serious about building production-grade AI agents - not just experimenting with ChatGPT wrappers - this book is essential reading. It bridges the gap between AI research and software engineering with remarkable clarity.

What This Book Covers

The book is structured around a GenAI Maturity Model with six levels, progressing from basic GenAI applications to fully autonomous multi-agent systems. This framework alone is worth the read, as it provides a clear strategic roadmap for organizations navigating the agentic AI landscape.

The core of the book lies in its comprehensive pattern library:

• Multi-Agent Coordination Patterns: From Supervisor Architecture and Swarm patterns to Consensus and Negotiation protocols

• Explainability & Compliance: Instruction Fidelity Auditing, Fractal Chain-of-Thought, and Shared Epistemic Memory

• Robustness & Fault Tolerance : Parallel Execution Consensus, Watchdog Timeouts, Agent Self-Defense against prompt injection

• Human-Agent Interaction: Clear patterns for delegation, escalation, and collaborative workflows

What Makes It Stand Out

Unlike typical AI books that focus on model training or prompt engineering, this treats agentic AI as a distributed systems problem. The authors understand that production systems require fault isolation, state management, observability, and security - not just clever prompts.

The practical implementations using Google ADK, CrewAI, and LangGraph demonstrate these patterns in action with a loan processing use case. Seeing the same problem solved with different frameworks helps you understand the trade-offs between abstraction levels.

The emphasis on AgentOps and the R⁵ model (Relax, Reflect, Reference, Retry, Report) shows mature thinking about production operations. Chapter 11 on self-improving agents through coevolved training is particularly forward-looking.

Final Verdict

This is the most comprehensive guide available for building multi-agent systems that can survive production. It transforms agentic AI from an experimental curiosity into an engineering discipline with proven patterns, clear trade-offs, and practical implementations.

The future belongs to those who can build systems where AI agents collaborate, recover from failures, and continuously improve. This book shows you how.

If you don’t have an existing Foundry agent, go ahead and create a foundry agent now. To continue with this example, you should have at least one agent as below:

Adding an action

Let’s add an action to the agent, which will use an Azure Logic App as a tool. Click on the agent, and on the right side select add for the actions:

Then, from the options choose Azure Logic Apps:

You can choose from your own authored actions or Microsoft authored. Let’s use a Microsoft authored action for the weather forecast:

Add the action name and description and choose the resource group, region and subscription needed to create the Logic App:

Finally, review the schema for the logic app workflow:

If you open the resource group in Azure, you can see that a connector and a Logic App were created automatically.

You can also check the workflow in the Logic App designer. What’s important to note is that the trigger is an HTTP request.

Looking the actions of the agent again, note that the weather forecast tool has been added.

To see if this works, open the playground and ask a weather-related question.

Notice that the agent used one tool, which is the Logic App. Checking the execution of the Logic App also shows that it has been invoked.

Think of Foundry as a production line for intelligent agents. The Foundry Agent Service brings together the core components of Foundry - models, tools, and frameworks - into a unified runtime. It handles conversations, coordinates tool execution, applies content safety controls, and integrates with identity, networking, and observability systems. Together, these capabilities ensure that agents are secure, scalable, and ready for production use.

Building your Foundry AI Agent

Start by installing the following NuGet packages:

dotnet add package Azure.Identity
dotnet add package Microsoft.Agents.AI.AzureAI.Persistent --prereleased

Next, add your Foundry endpoint and model deployment name, as well as the agent's name and instructions:

var endpoint = "";
var model = "gpt-4.1-mini-itt";
const string AgentName = "ArchitectAgent";
const string AgentInstructions = "You are an Azure Solutions Architect that uses knowledge from the official Microsoft docs to answer questions.";

For MCP tools, we will use the official Microsoft Learn MCP Server, which you can find on the following GitHub repository.

Create an MCP tool definition by specifying the server label and URL:

var mcpTool = new MCPToolDefinition(
    serverLabel: "msdocs_mcp",
    serverUrl: "https://learn.microsoft.com/api/mcp");

For the tools, add the three available tools from the documentation:

// Currently, only three tools are available
mcpTool.AllowedTools.Add("microsoft_docs_search");
mcpTool.AllowedTools.Add("microsoft_docs_fetch");
mcpTool.AllowedTools.Add("microsoft_code_sample_search");

To create the agent in Microsoft Foundry, use the following code which creates a PersistentAgentsClient and calls the CreateAgentAsync.

var persistentAgentsClient = new PersistentAgentsClient(endpoint, new DefaultAzureCredential());

var agentMetadata = await persistentAgentsClient.Administration.CreateAgentAsync(
    model: model,
    name: AgentName,
    instructions: AgentInstructions,
    tools: [mcpTool]);

The initial state of my Foundry is with zero agents:

After running the code, we can see the agent was successfully created.

Agents created through Foundry aren't monoliths. Each agent has a specific role, is powered by the right model, and is equipped with the right tools.

To get the agent and execute it:

var agent = await persistentAgentsClient.GetAIAgentAsync(agentMetadata.Value.Id);

var runOptions = new ChatClientAgentRunOptions()
{
    ChatOptions = new()
    {
        RawRepresentationFactory = (_) => new ThreadAndRunOptions()
        {
            ToolResources = new MCPToolResource(serverLabel: "msdocs_mcp")
            {
                RequireApproval = new MCPApproval("never"),
            }.ToToolResources()
        }
    }
};

AgentThread thread = agent.GetNewThread();
var response = await agent.RunAsync("What is Azure Key Vault?", thread, runOptions);
Console.WriteLine(response);

Notice that we can configure the tool resources with approval settings. The RequireApproval controls when user approval is needed for tool invocations:

• "never": Tools invocations don’t require user approval

• "always": All tool invocations require user approval

• Custom approval rules can also be configured

The response returned by the agent is the following:

Finally, to delete an agent we can run the following code:

await persistentAgentsClient.Administration.DeleteAgentAsync(agent.Id);

• API Management instance with an Azure OpenAI model deployment as an API

• Deployment for the following APIs:

  • Chat Completion API

  • Embeddings API

• 

• Configured API Management instance to use managed identity authentication to the Azure OpenAI service

• An Azure Managed Redis instance with the RediSearch module enabled

• 

Authenticate with managed identity

Let’s quickly explain how to use Managed Identity to authenticate to Azure OpenAI. Make sure that the managed identity is enabled on your API Management instance.

Assign the Cognitive Services OpenAI User role to the managed identity. Add the following inbound policy section to authenticate requests to the API by using the managed identity.

<authentication-managed-identity resource="https://cognitiveservices.azure.com" output-token-variable-name="managed-id-access-token" ignore-error="false" /> 
<set-header name="Authorization" exists-action="override"> 
    <value>@("Bearer " + (string)context.Variables["managed-id-access-token"])</value> 
</set-header>

Import an Azure OpenAI API

If you have imported an Azure OpenAI instance as an API into APIM you should see something like this:

If not, you can either import an Azure OpenAI API directly from a deployment in Microsoft Foundry or download and edit the OpenAPI specification.

Azure Managed Redis Setup

We will setup an external cache using the Azure Managed Redis instance.

Azure API Management uses a Redis connection string to connect to the cache. Because we are using Azure Managed Redis, we need to enable access key authentication for the cache and use the key as password in the connection string. Currently, we can't use Microsoft Entra authentication to connect Azure API Management to Azure Managed Redis.

The connection string will look like:

<cache-name>:10000,password=<cache-access-key>,ssl=True,abortConnect=False

Semantic Cache Configuration

Start by creating a backend for the embeddings API.

Next, let’s configure the semantic caching policies. In the Inbound section, add the azure-openai-semantic-cache-lookup policy. In the embeddings-backend-id attribute, specify the Embeddings API backend you created. In my case, the value is Embedding.

<azure-openai-semantic-cache-lookup
    score-threshold="0.15"
    embeddings-backend-id="Embedding"
    embeddings-backend-auth="system-assigned"
    ignore-system-messages="true"
    max-message-count="10">
    <vary-by>@(context.Subscription.Id)</vary-by>
</azure-openai-semantic-cache-lookup>

In the Outbound processing section for the API, add the azure-openai-semantic-cache-store policy.

<azure-openai-semantic-cache-store duration="60" />

To confirm the semantic cache is working, we can trace a test Completion or Chat Completion operation by using the test console in the portal.

Example from my trace operation:

Prerequisites

• Azure subscription with a Logic App already created

• A managed identity with appropriate permissions to read App Registrations

Create a Managed Identity for the Logic App

First, you'll need to grant your Logic App's managed identity the necessary permissions. Assign the Microsoft Graph API permission Application.Read.All to the managed identity.

To be easier to follow, I split the design of the workflow in three parts. Let’s continue with the first.

Logic App Workflow - Foundations

Let’s look at the entry point of our Logic App. For the trigger, I use Recurrence that I set to run daily at 9 AM.

The next step is to initialize a few variables. I set a variable named DaysThreshold of type Integer with an initial value of 30. This will allow me to alert for secrets expiring within 30 days. The second variable is ExpiringSecrets which I initialize as an empty array ([]).

Add an HTTP action to fetch all app registrations. I do that by calling the HTTP GET https://graph.microsoft.com/v1.0/applications endpoint. For the authentication type use Managed Identity and the audience https://graph.microsoft.com.

Finally, use a parse JSON action to parse the response from the API. You can use the following sample schema for it:

{
  "type": "object",
  "properties": {
    "value": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "id": {
            "type": "string"
          },
          "appId": {
            "type": "string"
          },
          "displayName": {
            "type": "string"
          }
        },
        "required": [
          "id",
          "appId",
          "displayName"
        ]
      }
    }
  }
}

That’s all the steps we need to get started with the workflow. In the second part, I will show you how to get the secrets for each app registration and check their expiry.

Logic App Workflow - Core Logic

Congratulations for making it this far. Let’s now complicate the workflow a little.

As we can see, there is a lot to unpack here.

Start off by adding a for each loop. This allows us to loop through each app registration. For the configuration, use the output from the previous step. From dynamic content, select value from the Parse JSON step.

Inside the for each loop, add another HTTP action. Inside, call the following HTTP GET endpoint https://graph.microsoft.com/v1.0/applications/@{items('For_each')?['id']}. Use the same authentication type as before, which is Managed Identity, and the same audience.

Again, use another Parse JSON action to parse the body of the response. You can use this sample JSON schema:

{
  "type": "object",
  "properties": {
    "id": {
      "type": "string"
    },
    "appId": {
      "type": "string"
    },
    "displayName": {
      "type": "string"
    },
    "passwordCredentials": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "customKeyIdentifier": {
            "type": [
              "string",
              "null"
            ]
          },
          "displayName": {
            "type": [
              "string",
              "null"
            ]
          },
          "endDateTime": {
            "type": "string"
          },
          "hint": {
            "type": [
              "string",
              "null"
            ]
          },
          "keyId": {
            "type": "string"
          },
          "startDateTime": {
            "type": "string"
          },
          "secretText": {
            "type": [
              "string",
              "null"
            ]
          }
        }
      }
    },
    "keyCredentials": {
      "type": "array"
    }
  }
}

With a condition, check if the length of the passwordCredentials array is greater than zero. If it is, then we do another for each loop to go through each credential separately.

In the compose action, switch to expression tab and paste:

div(sub(ticks(items('Apply_to_each')?['endDateTime']), ticks(utcNow())), 864000000000)

Add another condition and check if the Outputs from the compose action is less than or equal to DaysThreshold we defined at the start.

If it’s true, add the expiring secret to the array we defined.

json(concat('{\"appName\":\"', body('Parse_JSON_1')?['displayName'], '\",\"appId\":\"', body('Parse_JSON_1')?['appId'], '\",\"secretName\":\"', coalesce(items('For_each_1')?['displayName'], 'No Name'), '\",\"secretHint\":\"', items('For_each_1')?['hint'], '\",\"expirationDate\":\"', items('For_each_1')?['endDateTime'], '\",\"daysRemaining\":\"', string(outputs('Compose')), '\"}'))

The most complicated part of the workflow is now complete. In the last part, we will take a look at how to send an email notification with a list of expiring secrets.

Logic App Workflow - Completion

The condition here just checks if the length of ExpiringSecrets we defined at the start is greater than 0. If it is, that means we have secrets that will expire soon!

We use the create HTML table with ExpiringSecrets to construct a simple table we will use in the email.

Final step is to add the Send an email (V2) action and send the email notification. I made the email body to be easy to read and understand:

The following App Registration secrets will expire within the next 30 days:

body('Create_HTML_table')

Please renew these secrets as soon as possible to avoid service disruption.

And that’s it. Lastly, save and test the workflow. Following is a sample email I received from my workflow (I edited out the appName, appId, secretName and secretHint).

"Mastering Docker on Windows" fills a critical gap in the Docker literature landscape. While countless resources exist for Docker on Linux, this book tackles the unique challenges and architectural differences that arise when running Docker on Windows 11 with WSL 2.

What Makes This Book Different

The author approaches Docker on Windows with refreshing honesty - acknowledging that Windows can't run Linux containers natively and that everything flows through WSL 2 under the hood. This fundamental difference impacts installation, troubleshooting, performance tuning, file paths, networking, and image caching. Rather than glossing over these complexities, the book uses them as teaching opportunities.

Coverage and Structure

The book systematically builds from fundamentals to advanced topics across five comprehensive chapters:

Installation and Management - The opening chapter establishes essential concepts while addressing Windows-specific setup requirements. The discussion of resource management through .wslconfig files and the explanation of how Docker Desktop abstracts the WSL 2 complexity are particularly valuable. The author also provides practical guidance on image management, including handling dangling images and understanding the critical difference between images as blueprints and containers as running instances.

Networking Implementation - This chapter excels at demystifying Docker networking on Windows. The explanation of why localhost behaves differently in WSL 2 environments is crucial knowledge that many developers discover through frustrating trial and error. The book clearly distinguishes between bridge, host, and overlay networks, with particular attention to user-defined networks and their automatic DNS resolution capabilities. The security guidance here is practical rather than paranoid, focusing on minimal port exposure and proper network isolation.

Data Persistence and Volumes - The treatment of volumes goes beyond basic usage to address enterprise concerns. The author covers backup strategies, disaster recovery workflows, and cross-container data sharing patterns. The discussion of volume performance optimization and the appropriate use cases for named volumes versus bind mounts versus tmpfs volumes demonstrates real-world experience. The security section on encrypting volumes and restricting access shows attention to production requirements.

Multi-Container Orchestration - The Docker Compose chapter teaches patterns that scale beyond toy examples. The layered configuration approach using base files and environment-specific overrides reflects how actual development teams structure their projects. The honest discussion of depends_on limitations and the need for health checks addresses a common source of frustration. The author also provides practical advice on service naming, version pinning, and when to split large stacks into multiple files.

Security and Best Practices - This final chapter confronts the "it's containerized so it's secure" fallacy directly. The explanation of container isolation through namespaces and the risks of privileged containers or Docker socket mounting is clear and actionable. The guidance on running containers as non-root users, scanning images for vulnerabilities, and maintaining minimal base images represents security thinking that belongs in every Docker workflow.

Final Verdict

"Mastering Docker on Windows" succeeds in its mission to provide practical, production-ready guidance for Docker on Windows.

For anyone working with Docker on Windows, this book transforms Docker from a mysterious black box into an understandable, controllable tool. It's the resource the Windows Docker community has needed - practical, honest, and comprehensive.

If you've been watching the AI space evolve from simple chatbots to sophisticated autonomous systems, this book offers a masterclass in making that transition practical and achievable.

What This Book Covers

"Building Agents with OpenAI Agents SDK" takes readers on a journey from foundational concepts to production-ready implementations. The author systematically builds your understanding across nine comprehensive chapters, moving from theory to hands-on development.

The book opens by establishing what truly differentiates AI agents from conventional software. Unlike deterministic systems that follow rigid instructions, AI agents can reason from ambiguous goals, create plans autonomously, and adapt when situations change. This philosophical foundation proves crucial for understanding the architectural decisions that follow.

The Technical Deep Dive

What sets this book apart is its focus on OpenAI Agents SDK as a practical framework. The author demonstrates how this SDK eliminates thousands of lines of boilerplate code that would otherwise be needed for orchestration, tracing, and logging. The framework's minimalist abstraction philosophy means developers work with familiar Python constructs - agents are simply Python objects, tools are decorated functions, and orchestration uses standard language patterns.

The coverage of core primitives is particularly strong. Readers learn how agents serve as configurable wrappers around language models, how the Runner class manages the iterative reasoning loop, and how tools enable agents to interact with the external world. The book excels at explaining these concepts through practical examples.

Memory, Knowledge, and Multi-Agent Orchestration

The middle chapters tackle crucial challenges in building intelligent systems. The discussion of memory management distinguishes between short-term working memory and long-term persistent memory, offering practical patterns like sliding message windows and structured memory recall. The treatment of knowledge - both training knowledge baked into models and retrieved knowledge accessed dynamically - provides clear guidance on implementing retrieval-augmented generation patterns.

The multi-agent systems chapter is a standout, exploring both deterministic and dynamic orchestration strategies. The comparison between handoff patterns and agent-as-tool patterns gives developers the framework to make informed architectural decisions. The coverage extends to centralized, hierarchical, decentralized, and swarm architectures, each with clear use cases and trade-offs.

Production Readiness

Later chapters address the often-overlooked aspects of deploying agent systems to production. The book covers visualization tools for understanding system architecture, guardrails for validating inputs and outputs, comprehensive tracing for debugging, and testing strategies for non-deterministic systems. These operational concerns are treated with the same rigor as development topics.

Who Should Read This

This book is ideal for developers and technical leaders who want to move beyond experimentation with AI to building production-grade autonomous systems. While it assumes basic Python knowledge, the explanations are clear enough for intermediate developers while providing depth that experienced practitioners will appreciate.

The Bottom Line

"Building Agents with OpenAI Agents SDK" succeeds as both a comprehensive reference and a practical guide. It doesn't just explain concepts - it shows you how to implement and manage them. The author's systematic approach, from foundations through advanced multi-agent systems to production management, provides a complete toolkit for building the next generation of intelligent applications.

Whether you're automating business workflows, creating specialized assistants, or innovating new AI-powered products, this book equips you with the knowledge and practical skills to build agents that handle meaningful, real-world tasks. It's a valuable addition to any AI developer's library and a solid foundation for anyone serious about building autonomous AI systems.

Below are the sessions, presented in no specific order:

1. The future of RAG with agentic knowledge retrieval and AI Search - a session exploring how to modernize RAG for agents, showcasing new Azure AI Search and Foundry capabilities - including multi-source RAG orchestration, retrieval steering, dynamic security controls, and agentic grounding.

2. Apps, agents, and MCP is the AI innovation recipe - a session on how Azure App Platform enables secure, scalable, and well-governed deployment of AI agents, covering MCP tool integration, observability, access controls, and policies for managing agents in production environments.

3. Don't let your AI agents go rogue, govern with Azure API Management - a session showing how Azure API Management serves as a unified control plane for securing, governing, and monitoring AI workloads - using AI Gateway and MCP support to protect data, enforce policies, control costs, and ensure safe, scalable enterprise AI adoption.

4. Building responsible AI agents with Azure AI Foundry - a session on how Azure AI Foundry enables responsible, compliant, and scalable AI agent development with built-in safety evaluations, observability, and governance - addressing risks like task adherence, explainability, and data leakage through real-world examples.

5. From DEV to PROD: How to build agentic memory with Azure Cosmos DB - a session on using Azure Cosmos DB’s advanced retrieval capabilities to manage operational data - like agent memories - and enhance agent intelligence, featuring real-world patterns and lessons from large-scale multi-agent systems.

This year’s Ignite offers an incredible opportunity to deepen your AI expertise. These five sessions stand out for their practical value, forward-looking perspectives, and relevance to real-world enterprise challenges. I hope my recommendations help you navigate the event and get the most out of everything Microsoft is bringing to the AI space.

If you're interested in my full session catalog, you can find it on my LinkedIn profile.

Sometimes, we need to trigger our Azure Functions indirectly. What that means is that we want to trigger a function that is on a schedule or a function that runs as a result of an action from another resource. That action can be from a Blob storage, Service Bus Queue or Topic and other.

In this example, we will take a look at how we can manually run an Azure function that responds to messages from a Service Bus queue.

We will learn how to trigger the function without actually sending a message to the queue.

Examining the Azure function

For this example, we have a very simple Azure function. The code for the function implementation is the following:

namespace FunctionAppSbTrigger
{
    public class Function1
    {
        [FunctionName("MyAwesomeFunction")]
        public void Run([ServiceBusTrigger("myqueue", Connection = "ServiceBusConnection")]string myQueueItem, ILogger log)
        {
            log.LogInformation($"C# ServiceBus queue trigger function processed message: {myQueueItem}");
        }
    }
}

We can see that we have the Service Bus trigger set up that responds to messages from the "myqueue" queue.

Now if we try sending a message to the queue, we can observe that our function executes successfully.

But what if we have a situation where we don't want to or just simply can't send a message to the queue. How can we test our function then?

Manually running the function

To run a non HTTP-triggered function, we can send a simple HTTP POST request.

Now you might be thinking "But Dimitar, this is not even an HTTP triggered function, how can we do that?" and you're right.

We will need to construct a special type of URL to make this request to.

The code of our launchSettings.json file is:

{
  "profiles": {
    "FunctionAppSbTrigger": {
      "commandName": "Project",
      "commandLineArgs": "--port 7289",
      "launchBrowser": false
    }
  }
}

We will construct the new URL using the following information:

• Host name: The function app's public location

• Folder path: we have to send the request through the folders admin/functions

• Function name: name of the function we want to run

The special URL will have the form:

{hostName}/{folderPath}/{functionName}

Replacing these values gives us the final state of the URL:

http://localhost:7289/admin/functions/MyAwesomeFunction

Testing it all out

Next, let's open Postman and do a simple test.

We will set the HTTP method to POST and use the URL from the previous step. We can also specify a body for our request.

if we don't want to pass any data to our function, we still need to pass {} as the body of the request.

In the Headers section set the 'Content-Type' to 'application/json'.

You should have a similar setup as the image below:

Now click on the 'Send' button. Observe that we have successfully triggered our Azure Function without sending any messages to the queue.

Tools refer to capabilities or external functions that an agent can invoke to accomplish tasks it can’t do on its own (like accessing data, running code, or integrating with APIs). Tools are functions, APIs, or skills that the agent can call when reasoning through a task.

Let’s take a look at how we can use an existing AI agent as a function tool.

AI Agent as a tool

Initially, what we need to have is an agent defined. In the example below, I use an agent that generates a random base salary.

[Description("Generates a base salary")]
static int GetBaseSalary()
{
    var start = 1000;
    var end = 10000;
    var rand = new Random();
    var salary = rand.Next(start, end);
    Console.WriteLine("Generated Base Salary: " + salary);
    return salary;
}

AIAgent salaryAgent = new AzureOpenAIClient(
    endpoint,
    new AzureKeyCredential(apiKey))
     .GetChatClient(deploymentName)
     .CreateAIAgent(
        instructions: "You are an agent that generates salary.",
        name: "SalaryAgent",
        description: "An agent that generates a base salary.",
        tools: [AIFunctionFactory.Create(GetBaseSalary)]);

Next, we create a new agent and specify the existing agent as a tool by using AsAIFunction():

AIAgent salaryBonusAgent = new AzureOpenAIClient(
     endpoint,
     new AzureKeyCredential(apiKey))
     .GetChatClient(deploymentName)
     .CreateAIAgent(instructions: "You are a helpful assistant that always adds $10 bonus amount to the generated base salary.", tools: [salaryAgent.AsAIFunction()]);

Lastly, let’s run the agent with a simple prompt:

Console.WriteLine(await salaryBonusAgent.RunAsync("How much money am I getting today?"));

As we can see, we get the correct output, which added $10 to the base salary.

Generated Base Salary: 7099

Today, you are getting a total of $7,109 (which includes a $10 bonus).

This approach allows us to compose agents and build more complex workflows.

Sometimes an agent requires a long time to complete a request. This can happen with complex reasoning tasks, but interruptions may also occur due to network or client issues.

Background processing uses a continuation token, which can be used to:

• Poll for completion using the non-streaming agent

• Resume an interrupted stream with streaming agent

Only when the continuation token is null, we know the operation is complete.

Important note: currently, only agents that use the OpenAI Responses API support background responses

Using background responses

Let’s look at a simple example of how to start using background responses. The first step, of course, is to enable this option:

var agent = new AzureOpenAIClient(endpoint, new AzureKeyCredential(apiKey))
          .GetOpenAIResponseClient(deploymentName)
          .CreateAIAgent();

AgentRunOptions options = new()
{
    AllowBackgroundResponses = true
};

Next, we will start streaming a response and then intentionally break it, so we can simulate interruption.

AgentThread thread = agent.GetNewThread();
AgentRunResponseUpdate? latestReceivedUpdate = null;
int textCount = 0;

Console.WriteLine("===Generating Monthly Sales Performance Report...\n");

await foreach (var update in agent.RunStreamingAsync(
    "Generate a detailed business report analyzing last month's sales performance. "
    + "Include executive summary, regional breakdown, and recommendations for next month.",
    thread,
    options))
{
    if (!string.IsNullOrEmpty(update.Text))
    {
        Console.Write(update.Text);
        textCount++;

        if (textCount == 10)
        {
            Console.WriteLine("\n\n===Pausing report generation...\n");
            break;
        }
    }

    latestReceivedUpdate = update;
}

From the code, we can see that the prompt simply asks to generate a complex report, and when the text output count reaches 10, we simulate an interruption.

The output so far in my example is the following:

\===Generating Monthly Sales Performance Report...

Business Report on Last Month's Sales Performance

\===Pausing report generation...

To resume the streaming, we will use the continuation token we’ve received.

if (latestReceivedUpdate?.ContinuationToken is not null)
{
    options.ContinuationToken = latestReceivedUpdate.ContinuationToken;

    Console.WriteLine("===Resuming report generation from state...\n");

    await foreach (var update in agent.RunStreamingAsync(thread, options))
    {
        if (!string.IsNullOrEmpty(update.Text))
            Console.Write(update.Text);
    }

    Console.WriteLine("\n\nReport generation complete!");
}
else
{
    Console.WriteLine("No continuation token available to resume.");
}

The final output in my example is the following:

\===Resuming report generation from state...

Executive Summary

Last month's sales performance reflects a mixed but overall positive trend, with total revenue reaching $1.5 million, an increase of 10% compared to the previous month. Key drivers of this growth included successful marketing campaigns and increased demand for our flagship products. However, certain regions underperformed, which necessitates a closer examination and tailored strategies moving forward.

Key Highlights:

• Total Sales: $1.5 million

• Percentage Growth: 10% MoM

• Top Performer: Product Line A, accounting for 40% of total sales.

• Underperforming Regions: Northeast and Southwest.

Regional Breakdown

1. Northeast Region

• Sales Performance: $400,000

• Change from Previous Month: -5%

• Analysis: Decreased sales attributed to increased competition and stock shortages. Target demographics reported dissatisfaction regarding product availability.

2. Southeast Region

• Sales Performance: $500,000

• Change from Previous Month: +15%

• Analysis: Successful promotional strategies led to higher engagement and conversion rates, particularly in urban markets.

3. Midwest Region

• Sales Performance: $350,000

• Change from Previous Month: +8%

• Analysis: Steady growth sustained by strong community ties and local marketing efforts. Product Line A performed exceptionally well.

4. West Region

• Sales Performance: $250,000

• Change from Previous Month: +5%

• Analysis: Gradual increase attributed to new distribution channels. Potential for further growth exists with enhanced local initiatives.

5. Southwest Region

• Sales Performance: $300,000

• Change from Previous Month: -10%

• Analysis: Economic factors and reduced promotional activities contributed to lower sales. Customer feedback indicated a lack of awareness regarding recent offerings.

Recommendations for Next Month

1. Northeast Region

• Action: Conduct a stock audit to ensure product availability. Implement targeted marketing campaigns highlighting new arrivals to regain lost customers.

• Goal: Increase sales by 10% through outreach and stock replenishment.

2. Southeast Region

• Action: Continue leveraging successful marketing strategies while exploring partnership opportunities with local influencers to maintain momentum.

• Goal: Target an additional 10% growth by enhancing community engagement.

3. Midwest Region

• Action: Expand community events and workshops focusing on Product Line A to increase brand loyalty and cross-sell other products.

• Goal: Achieve a 12% increase in sales through direct customer interaction.

4. West Region

• Action: Strengthen online marketing efforts and social media presence to attract a broader audience. Collaborate with local businesses for cross-promotion.

• Goal: Aim for a 10% increase in sales via enhanced branding efforts.

5. Southwest Region

• Action: Reassess marketing strategies and implement a targeted advertisement campaign focusing on product benefits and customer testimonials.

• Goal: Reverse the negative trend by aiming for at least a 15% increase in sales.

Conclusion

The sales performance over the last month demonstrates both opportunities for growth and areas needing attention. By honing in on regional strengths and weaknesses, the company can optimize its strategies to ensure sustained growth. Implementing the recommendations outlined above will be critical for the upcoming month, with particular emphasis on addressing the underperforming regions to maximize overall profitability.

Next Steps:

• Regular monitoring of sales data will be essential to track the effectiveness of implemented strategies.

• Prepare a follow-up report to analyze the outcomes of these recommendations at the end of next month.

Report generation complete!

What we did here was use the continuation token to resume the stream from the interruption point. Keep in mind that in some situations you will need to store continuation tokens persistently.

Finally, if you are doing non-streaming, using the token will be similar to:

AgentRunOptions options = new()
{
    AllowBackgroundResponses = true
};

AgentThread thread = agent.GetNewThread();

AgentRunResponse response = await agent.RunAsync("Generate a detailed business report analyzing last month's sales performance. "
    + "Include executive summary, regional breakdown, and recommendations for next month.", thread, options);

while (response.ContinuationToken is not null)
{
    await Task.Delay(TimeSpan.FromSeconds(5));

    options.ContinuationToken = response.ContinuationToken;
    response = await agent.RunAsync(thread, options);
}

A workflow, simply put, represents a predefined set of operations. Workflows are built to manage complex business processes that can include multiple agents and integrations with external systems. Their flow is explicitly defined, providing greater control over the execution.

There is also the concept of orchestrations which are pre-built workflow patterns. Currently supported orchestrations are:

• Concurrent

• Sequential

• Handoff

• Magentic

Workflows as Agents

You can easily convert a workflow into an agent. Let’s take a look at a simple example.

I have defined two agents, one is a horror story writer agent, the other is a comedy story writer. The agent definition is the following:

var chatClient = new AzureOpenAIClient(endpoint, new AzureKeyCredential(apiKey))
    .GetChatClient(deploymentName)
    .AsIChatClient();

var horrorInstructions = @"You are a horror writer. Your task is to write EXACTLY one two-sentence horror story using the theme provided. 
After writing your two sentences, your job is complete. Do not write anything else.";
var horrorAgent = new ChatClientAgent(chatClient, horrorInstructions, "horror-writer-agent");

var comedyInstructions = @"You are a comedy writer. Your task is to write EXACTLY one two-sentence comedy story using the theme provided. 
After writing your two sentences, your job is complete. Do not write anything else.";
var comedyAgent = new ChatClientAgent(chatClient, comedyInstructions, "comedy-writer-agent");

Now, to use these agents in a workflow, I will use the sequential orchestration.

var horrorComedyOrchestration = AgentWorkflowBuilder.BuildSequential([horrorAgent, comedyAgent]);

Next, we can easily convert this workflow into an agent, and use it as it were an agent:

var horrorComedyAgent = await horrorComedyOrchestration.AsAgentAsync(
    id: "horror-comedy-agent",
    name: "HorrorComedyAgent"
);

Finally, let’s run the new agent:

var thread = horrorComedyAgent.GetNewThread();
var input = "Write a story about a boy and his dog.";

Dictionary<string, List<AgentRunResponseUpdate>> buffer = [];
await foreach (AgentRunResponseUpdate update in horrorComedyAgent.RunStreamingAsync(input, thread))
{
    if (update.MessageId is null)
    {
        continue;
    }
    Console.Clear();

    if (!buffer.TryGetValue(update.MessageId, out List<AgentRunResponseUpdate>? value))
    {
        value = [];
        buffer[update.MessageId] = value;
    }
    value.Add(update);

    foreach (var (messageId, segments) in buffer)
    {
        string combinedText = string.Concat(segments);
        if (!string.IsNullOrEmpty(combinedText))
        {
            Console.WriteLine($"{segments[0].AuthorName}: {combinedText}");
            Console.WriteLine();
        }        
    }
}

The output of the agents is the following:

horror-writer-agent: As the boy played fetch with his beloved dog in the fading light, he was blissfully unaware that the playful barks were growing fainter, echoing from the depths of an empty, darkened forest. When he turned to call his dog back, he found not his furry friend, but the twisted figure of something wearing its skin, grinning wide with his dog's last memories trapped inside.

comedy-writer-agent: Timmy was excited to finally teach his dog, Rex, how to fetch the newspaper; he figured if a dog could grab a stick, fetching a rolled-up paper should be a piece of cake. After a week of training, Rex proudly returned with a pile of newspapers, but unfortunately, they all belonged to the neighbors-who were now very confused as to why they suddenly had the Daily Bark.

Notice how easy it was to create an agent based on a defined workflow and use it as part of further processing.

In my previous article, I discussed how we can index data from multiple data sources into a single consolidated search index.

And this is all great when we are dealing with new data.

But what happens if some item gets deleted from the database? We might want to remove it from the index without the need to drop and rebuild the index.

That is why I will walk you through on how we can define a data deletion detection policy that implements a soft-deletion strategy. It will determine whether an item should be deleted based on the value of a designated 'soft delete' column.

Additionally, we will also add a data change detection policy which will help us identify changed data items. This way, the indexer will update only them.

For this example, we will create a new index using only the Cosmos database products data.

Adding the soft delete column

Go to the Azure portal and open the Cosmos database that you will use to create the index.

In my scenario, it's the 'eshop' database with the two documents that we saw in the previous article.

Next, we will extend our document structure to include a new column for the soft delete. We can name this column 'isDeleted'. The value will either be 'true' or 'false'. Keep in mind that these values are important, and we will see why later.

Only columns with string, integer, or boolean values are supported. The value used as softDeleteMarkerValue must be a string, even if the corresponding column holds integers or booleans. For example, if the value that appears in your data source is 1, use "1" as the softDeleteMarkerValue.

Defining the change detection policy

For the change detection policy, we need to define it when creating the data source. We can do this by using the following code:

cosmosDbDataSource.DataChangeDetectionPolicy = new HighWaterMarkChangeDetectionPolicy("_ts");

Defining the data deletion detection policy

Creating the data deletion detection policy is simple as well, we just need to set the SoftDeleteColumnName and the SoftDeleteMarkerValue.

For our solution, the code should be the following:

cosmosDbDataSource.DataDeletionDetectionPolicy = new SoftDeleteColumnDeletionDetectionPolicy
            {
                SoftDeleteColumnName = "isDeleted",
                SoftDeleteMarkerValue = "true"
            };

Additionally, we need to add the property to our documents in the Cosmos database. Currently we will set the value to 'false' for both documents.

Creating the index, indexer and data source

For the creation of the index, indexer and data source, we will use the code from the previous example and just modify it only with the new lines shown previously.

I won't go through the code here, as I explained it in my previous article I linked above. You can also find the updated code on the GitHub repository:

👉 DimitarIliev/aisearch-multi-src-index (github.com)

Testing the data deletion detection policy

After creating the index, indexer and updating the data source, we can observe that in the 'Indexes' tab we have the new index created.

In the 'Indexers' tab we got the new indexer created.

And finally, checking our data source, we can observe the updated configuration.

Initiating a search to the index returns the two documents we have in the Cosmos database.

Now, let's update the second document to be deleted. We will do that by changing the value of 'isDeleted' from 'false' to 'true'.

Now, we can just run the indexer. The expected result should be that 1 document was successfully changed.

Now, initiating a search to the index again, we can observe that we receive only the first document, which was not deleted.

Great! We have successfully removed a document from our search index without needing to drop it and rebuild.

Returning the document to the index is as simple as just setting the 'isDeleted' property back to 'false' and running the indexer.

Testing the change detection policy

The final thing we have to test is the change detection policy. Let's update the name property of a product document.

Next, run the indexer. We should see that only 1 document was actually updated.

Finally, initiating a search to our index will give us the updated data for the document.

Whether you're preparing for the Microsoft Certified: Azure Virtual Desktop Specialty certification or simply have an interest in the topic, "Mastering Azure Virtual Desktop" is an essential resource.

This book provides an in-depth exploration of Azure Virtual Desktop (AVD) and its key benefits.

It begins with a thorough assessment of your current desktop environment, helping you establish baselines for performance, data management, and user experience.

The book then delves into the critical requirements for designing user identities and profiles, including considerations around licensing and storage solutions.

Security is a central theme throughout, with detailed guidance on implementing Azure VNet connectivity, managing both on-premises and internet connectivity, and enforcing network security. The integration of Microsoft Defender for Cloud, with a specific focus on AVD, is also covered in detail.

Access management is another crucial area addressed in the book, with a dedicated chapter on Azure roles and the specific RBAC configurations for AVD resources. The discussion extends to the creation and management of host pools, a fundamental component of AVD.

One of the standout sections for me was the practical guide to implementing FSLogix profile containers and Cloud Cache, offering actionable insights for real-world scenarios.

Business Continuity and Disaster Recovery planning is another key aspect of the book, which examines the five critical components of an Azure Virtual Desktop environment: virtual networks, virtual machines, user identities, user and application data configuration, and application dependencies.

Finally, the book offers comprehensive coverage on monitoring and managing the performance and health of AVD environments, along with automation strategies for routine management tasks.

"Mastering Azure Virtual Desktop" is rich with both theoretical insights and practical examples, complemented by end-of-chapter questions to reinforce your understanding.

Just finished reading "Microsoft Copilot in Azure" by Steve Miles and Dave Rendon, and I'm impressed by how comprehensively it covers AI-assisted cloud management.

This book excels at demystifying how Copilot in Azure transforms cloud operations through natural language interactions.

The authors do an excellent job explaining the three-layer architecture (frontend, orchestration, and AI infrastructure) and how it all works within your existing security context - a critical point for enterprise adoption.

What I found most valuable

🔹 Practical approach: Each chapter tackles real scenarios - from deploying VMs and AKS clusters to managing databases and optimizing costs

🔹 Security-first mindset: Strong emphasis on RBAC, compliance frameworks (PCI DSS, GDPR, HIPAA), and how Copilot respects existing access controls

🔹 End-to-end coverage: Goes beyond basics to include AI Shell integration, predictive scaling, cost management, and security posture improvement

The book aligns Copilot capabilities with Azure's Well-Architected Framework pillars (reliability, security, cost optimization, operational excellence, and performance efficiency), making it easy to see where AI assistance adds the most value.

Bottom line

If you're managing Azure infrastructure and want to understand how AI can make you more efficient while maintaining security and governance, this is a solid resource. The focus on RAG, context-aware responses, and multimodal outputs shows where cloud management is heading.

About the Interview

Microsoft Learn reached out to discuss my journey with Applied Skills credentials and how they are shaping the way professionals validate their hands-on expertise in cloud technologies and AI.

Key Topics Covered

• My experience with Microsoft certifications and Applied Skills

• The value of hands-on, scenario-based learning

• How Applied Skills credentials differ from traditional certifications

• Practical applications of Azure and AI skills in real-world projects

• Advice for professionals looking to upskill in cloud and AI

Why Applied Skills Matter

Applied Skills credentials represent a shift toward validating practical, job-ready skills through hands-on assessments. Unlike traditional exams, these credentials focus on your ability to solve real-world scenarios, making them incredibly relevant for today's cloud and AI landscape.

Watch/Read the Interview

https://www.linkedin.com/embed/feed/update/urn:li:ugcPost:7328841908934336514?collapsed=1

Check it out here.

Agent middleware can be used to handle cross-cutting concerns like logging, security, error handling, and transforming results.

There are three main types of middleware that can be defined:

• Agent Run middleware – intercepts all agent executions

• Function calling middleware – intercepts all function calls made by the agent

• IChatClient middleware – intercepts calls to an IChatClient implementation

Let’s explore an example by creating and using a simple agent run middleware.

Defining the author agent

To begin, let’s define a simple author agent that will be responsible for writing horror stories.

var azureOpenAIClient = new AzureOpenAIClient(endpoint, new AzureKeyCredential(apiKey))
    .GetChatClient(deploymentName);

var authorAgent = azureOpenAIClient.AsIChatClient()
    .AsBuilder()
    .BuildAIAgent(
        instructions: "You are an author that writes horror stories.",
        name: "Author");

Next, let’s add our middleware, which will format the agent’s response with a stylish horror-themed header and footer.

async Task<AgentRunResponse> HorrorAtmosphereMiddleware(
        IEnumerable<ChatMessage> messages, AgentThread? thread, AgentRunOptions? options, AIAgent innerAgent, CancellationToken cancellationToken)
{
    Console.Write("The author retreats into the shadows");
    for (int i = 0; i < 3; i++)
    {
        await Task.Delay(800, cancellationToken).ConfigureAwait(false);
        Console.Write(".");
    }
    Console.WriteLine("\n");

    var response = await innerAgent.RunAsync(messages, thread, options, cancellationToken).ConfigureAwait(false);

    foreach (var message in response.Messages)
    {
        if (message.Contents != null)
        {
            foreach (var content in message.Contents)
            {
                if (content is TextContent textContent)
                {
                    textContent.Text = $"================================================\n" +
                                     $"           HORROR STORY ARCHIVE\n" +
                                     $"================================================\n\n" +
                                     $"{textContent.Text}\n\n" +
                                     $"================================================\n" +
                                     $"Author: {innerAgent.Name}\n" +
                                     $"Date: {DateTime.Now:MMMM dd, yyyy 'at' HH:mm}\n" +
                                     $"================================================";
                }
            }
        }
    }

    return response;
}

Agent run and function calling middleware types can be registered on an agent by using the agent builder along with an existing agent instance.

 var updatedAgent = authorAgent
     .AsBuilder()
         .Use(HorrorAtmosphereMiddleware, null)
     .Build();

 var authorResponse = await updatedAgent.RunAsync("Tell me a short horror story about vampires.");
 Console.WriteLine($"{authorResponse}");

Executing the agent yields the following output:

The author retreats into the shadows...

\================================================ HORROR STORY ARCHIVE

The moon hung high over the abandoned village of Eldersblood, casting eerie shadows that danced among the crumbling stone houses. Legend had it, the village had been cursed by a dark Hemlock witch centuries ago, drawing the attention of a clan of vampires who sought refuge from the sun's scalding rays. Though no one had set foot in Eldersblood for decades, whispers of its sinister past lingered in the air like a promise of dread.

One night, a curious traveler named Elara, drawn by the thrill of the unknown, ventured into the ghostly village. With each cautious step, the wooden boards beneath her feet creaked and moaned as if warning her of an impending doom. The chilling wind wrapped around her like a cold finger, and the distant howl of wolves sent shivers racing down her spine.

As Elara explored, she stumbled upon an ancient tavern, its door slightly ajar, as if inviting her in. Inside, the air thickened with an unsettling chill, and cobwebs adorned the corners like tattered curtains. The flicker of her lantern revealed a table set for a feast, the plates gleaming, untouched, as shadows began to stretch across the room.

Suddenly, the door slammed shut, plunging her into darkness. Panic coursed through her veins as she fumbled for the handle, but it was locked tight. A raspy voice echoed from the shadows, "Welcome, dear traveler. You've found your way to our humble domain."

A figure emerged from the darkness, cloaked in a tattered black robe. Its face was pale as death, eyes gleaming like two obsidian stones. Behind it, more figures began to materialize, their features hidden, but their hunger palpable.

"Stay for dinner," the figure hissed, revealing elongated fangs glistening under the dim flicker of light. "We rarely have guests in Eldersblood."

Elara's heart raced. She backed away, her instincts screaming for her to flee, but the ground seemed to grow roots beneath her feet. The vampires circled closer, their predatory gazes locking onto her.

With a sudden rush of adrenaline, Elara lunged for the window, clawing at the grime-covered glass, but it was too late. The air crackled with dark energy as the vampires closed in, filling the air with a deep, rumbling laughter.

"Dinner is served!" they declared in unison, their fangs bared, eyes sparkling with wicked delight.

The moon outside bore witness as Elara was swallowed by shadows, her screams swallowed whole by the night. Eldersblood remained silent, the village locked in its cursed slumber, waiting patiently for the next curious soul to wander into its grasp.

\================================================ Author: Author Date: October 23, 2025 at 13:05

I hope you enjoyed this chilling tale - and that it didn’t send too many shivers down your spine. More importantly, I hope you learned something along the way. Until the next story… sleep well, if you can.

Microsoft Azure is a powerful cloud platform that provides scalability, security, and a vast array of services. However, navigating its complexities can be challenging, and many organizations unknowingly accumulate unnecessary costs.

This often occurs because tech leads and architects lack a deep understanding of the applications they are building. Without this clarity, resource planning and cost management suffer, leading to inefficient spending.

In this article, I will highlight some of the most common pitfalls I’ve observed when working with Azure and how to avoid them.

Misunderstood Applications

One of the biggest issues I’ve encountered is a lack of Azure expertise among tech leads and architects. Without a solid grasp of how to design and build applications in Azure, teams often choose suboptimal or even incorrect services. This results in paying for resources that are either unnecessary or misconfigured.

Additionally, understanding when and how an application is used is crucial. Some applications require 24/7 availability, while others may only be active during specific hours. By analyzing usage patterns, organizations can optimize costs by resizing resources, implementing auto-scaling, or even shutting down certain services during off-peak hours.

Without a comprehensive understanding of an application’s behavior and workload patterns, selecting the right services and pricing models becomes a challenge - leading to our next common pitfall.

Choosing the Wrong SKUs

Selecting the wrong service tier (SKU) often results in paying for capacity or features that exceed actual needs. To prevent this, organizations should align SKUs with real application requirements.

Understanding the optimal SKU for a service comes from continuous monitoring and analysis of usage patterns. By assessing how resources are utilized, teams can determine whether to scale up or down, ensuring they only pay for what they actually need.

Misunderstood pricing models

Azure services follow different pricing structures, and without a clear understanding of these models, it’s easy to overspend.

Choosing the right pricing model requires first understanding what options are available for the services in use. For instance, organizations can opt for a Pay-as-you-go model, an Azure Savings Plan for Compute, or Reserved Instances, among others.

Selecting the best pricing model should be a strategic decision based on application demand, expected usage, and long-term cost efficiency.

Forgotten resources

One of the most common yet overlooked cost drivers in Azure is unused and forgotten resources. Throughout my career, I’ve come across countless instances where resources were left running, silently draining budgets.

To mitigate this, organizations should conduct regular audits of their Azure environment, identifying and decommissioning resources that are no longer in use. Implementing automated policies for resource cleanup can also help prevent unnecessary costs.

Conclusion

Optimizing Azure costs is not just about reducing expenses—it’s about making informed decisions that align with your application’s actual needs. By understanding your workloads, selecting the right services and SKUs, leveraging the correct pricing models, and maintaining resource hygiene, organizations can maximize the efficiency of their Azure investment.

With a proactive approach to cost management, businesses can harness the full power of Azure without falling into common financial pitfalls.

Model router for Azure AI Foundry is a deployable AI chat model that is trained to select the best large language model to respond to a given prompt in real time. By evaluating factors like query complexity, cost, and performance, it intelligently routes requests to the most suitable model. With that, it delivers high performance while saving on compute costs where possible, all packaged as a single model deployment.

Smaller and cheaper models are used when they're sufficient for the task, but larger and more expensive models are available for more complex tasks.

Deploying the Model Router

To use the model router, we need to initially deploy it. To do that go to Azure AI Foundry and open the model deployments. Choose the '+ Deploy model' option.

Next, select the model-router model and click on 'Confirm'.

Finally, specify the deployment name and click on 'Deploy'.

After the deployment is completed, you can use the model router in your applications.

Using the Model Router

I have created a simple Console application to demonstrate how to use the model router.

We can use model router in the same way we'd use other OpenAI chat models. Let's set the deployment name parameter to the name of our model router deployment.

builder.Services.AddAzureOpenAIChatClient(
   deploymentName: "model-router-itt",
   endpoint: Environment.GetEnvironmentVariable("AZURE_OPENAI_ENDPOINT")!,
   apiKey: Environment.GetEnvironmentVariable("OPENAI_API_KEY")!);

Then let's define two prompts and see what models our router will choose for the responses.

var prompt = "What is the capital city of France?";
var result = await kernel.InvokePromptAsync(prompt, new(executionSettings)).ConfigureAwait(false);
Console.WriteLine($"\n\n{prompt}\n{result}");

prompt = "Write a detailed blog post comparing the benefits and trade-offs of using vector search versus keyword-based search in enterprise AI applications, including practical Azure AI Search configuration examples.";
result = await kernel.InvokePromptAsync(prompt, new(executionSettings)).ConfigureAwait(false);
Console.WriteLine($"\n\n{prompt}\n{result}");

The result for the first prompt is:

We can see that the chosen model here was GPT-4.1-nano-2025-04-14. This seems reasonable as the prompt was very simple.

Let's see the result for the second prompt:

Because the second prompt was more complex than the first, we can see that the router chose the o4-mini-2025-04-16 model.

And that's it. This is how simple it is to use the model router in your applications.

One important limitation to note is that the context window limit is the limit of the smallest underlying model. Other underlying models are compatible with larger context windows, which means an API call with a larger context will succeed only if the prompt happens to be routed to the right model, otherwise the call will fail. To shorten the context window, you can do one of the following:

• Summarize the prompt before passing it to the model

• Truncate the prompt into more relevant parts

• Use document embeddings and have the chat model retrieve relevant sections