Part 1: What You Can Build

The book opens by framing system design not as memorized solutions but as a trail of decisions and trade-offs, built on domain knowledge, design skill, and behavioral intelligence — the three things it argues AI hasn't displaced. From there it methodically builds a shared vocabulary: network models and protocols, DNS resolution, symmetric vs. asymmetric encryption, hashing vs. checksums vs. tokenization, and the throughput/latency/bandwidth distinctions interviewers love to probe.

It then moves into the algorithms and patterns that make distributed systems actually work — Snowflake IDs for globally unique ordering, consistent hashing for even data distribution, Raft for consensus, Bloom filters for cheap membership testing, and resilience patterns like circuit breakers, Merkle trees, and scatter-gather.

The building-blocks chapter is the densest: stateful vs. stateless services, sticky sessions, load balancing, sync vs. async communication, SQL vs. NoSQL decision-making, API gateway design, and a clear breakdown of when to reach for WebSockets (full-duplex, chat apps), SSE (one-way server push), or webhooks (server-to-server events).

A full chapter on security and observability covers encryption at rest/in transit, JWT-based stateless auth, OAuth2/OIDC, RBAC vs. ABAC, rate limiting vs. throttling, and the logs/metrics/traces triad — plus a pointed reminder never to log PII.

Where the book earns its keep is the case study chapters: a Slack-like messaging system (with per-channel append-only logs for ordering), a distributed key-value datastore built around write-ahead logs and partitioning, a millisecond-latency real-time bidding platform, an Instagram-like system covering fan-out and presigned URLs for media uploads, and — the standout — an agentic AI system for investment research, complete with tool-access guardrails, a forward-proxy allow-list, golden-dataset regression testing, and negative/adversarial testing for prompt injection.

Part 2: How You Behave While Building It

The second half redefines behavioral intelligence as a learnable, observable set of choices — distinct from IQ and from emotional intelligence — that predicts performance and gets tested deliberately in interviews. It walks through real workplace friction (conflict resolution via RACI, risk mitigation, stakeholder alignment via Mendelow's Matrix and the Salience Model, DORA metrics for engineering performance) before turning to interview preparation itself: building a story bank, calibrating stories to seniority using STAR, STAR+R, CAR, CARL, SOAR, and PAR, and understanding that a JD is a signal, not a checklist.

The closing chapters pull back the curtain on how Big Tech interviews are actually scored — core values as the real evaluation criteria, live scorecards, level calibration — and then look past the offer: negotiating, onboarding in the first 90 days, and eventually becoming the interviewer yourself.

Takeaway

The book's real argument isn't "learn system design, then learn to interview." It's that clear technical thinking and clear communication are the same underlying discipline — and that discipline, not any single technology, is what actually gets evaluated.

The Generative AI Career Masterplan: A Systems-Thinking Guide to an AI-Driven Career

There's no shortage of books promising to help you "future-proof" your career against AI. Most either drown you in hype or oversimplify into a list of prompts to memorize. The Generative AI Career Masterplan takes a different, more durable approach: it treats a GenAI career the way you'd treat building a reliable AI system — through clear objectives, disciplined iteration, and evidence that things actually work.

From tools to agentic enterprises

The book opens by framing generative AI as a genuinely transformative force, not just a productivity add-on. It traces the shift from AI as a static tool to AI as an autonomous agent capable of planning, reasoning, and executing multi-step work — and the organizational consequence of that shift: the "agentic enterprise," where humans move from supervising every step to setting goals and auditing outcomes from above. The discussion of AI agents as emerging "corporate citizens," complete with identities, permissions, and accountability, is a nice preview of governance conversations that are only going to get louder.

Concepts without the jargon overload

The middle chapters do solid work demystifying the technical core — generative versus discriminative models, transformers and attention, diffusion models, in-context learning — without turning into a textbook. It's practical enough for a business reader but has real technical substance for practitioners, covering architecture evolution (MHA to GQA, Mixture of Experts, hybrid and sliding-window attention), RAG and multimodal RAG, and the increasingly important distinction between workflows (code-orchestrated) and true agents (model-driven decision loops).

A genuinely useful career map

Where the book earns its keep is Chapter 3's role taxonomy: Builders, Shapers, Guardians, Enablers, and Adopters. Rather than chasing whatever job title is trending, the book argues for anchoring your trajectory in systems and evidence — pick a role family, build something real, evaluate it rigorously, and govern it responsibly. That advice holds up regardless of which model or framework is popular next year, which is exactly the point.

Tools, hard skills, and the agentic frontier

Later chapters survey the practical toolkit (LangGraph, LlamaIndex, vLLM, Hugging Face, fine-tuning frameworks like Axolotl and Unsloth) and the hard skills that underpin it all — Python, SQL, evaluation methodology. Chapter 7's treatment of agentic AI is one of the strongest sections: the sense–reason–plan–coordinate–act–reflect loop, two-tiered agent memory, harness engineering, and security concerns like indirect prompt injection are all explained clearly and tied back to what it means for human oversight (the "Human-Above-the-Loop" model in particular is a useful mental model).

The human layer

What keeps this from reading like a pure engineering manual is the consistent return to human factors — personal branding as "distribution and proof of work" rather than vanity, ATS-aware but human-honest job searching, STAR-based interview prep, and a closing chapter that's refreshingly unglamorous: show up, be reliable, find mentors, protect your capacity to last. Career compounding, the book argues, isn't about chasing virality — it's about integrity and consistency over years.

Bottom line: A well-organized, evidence-oriented guide that treats career-building with the same rigor the book recommends for AI systems themselves — measure, iterate, govern, repeat.

The analyzer concept has been expanded to include contentCategories and enableSegment, which let you classify and split the input data processed by your application. This analyzer capability can classify an entire input file at once, and it can also detect multiple documents—or multiple copies of the same document—contained within a single input file.

Beyond this, Content Understanding lets you build custom classification workflows that direct your content to the appropriate analyzer. Through routing, you can pass several data streams through one shared pipeline while making sure each is handled by the analyzer best suited to its type.

Architecture Overview

Input file enters the pipeline as the raw document you want to process.

Classifier analyzer sits at the center. This is the analyzer configured with contentCategories and enableSegment — it looks at the input file and both classifies it and splits it into segments.

That classifier fans out into three example categories, each representing a type of content the classifier can detect:

• Category A and Category B are each routed to their own custom analyzer, which extracts the relevant fields from that piece of content and produces structured output.

• Category C (e.g. a cover page) has no analyzer linked to it. Not every category needs one — if a segment just needs to be identified and removed rather than further processed, you can leave it unrouted and you can simply discard it from the pipeline.

Creating a base classifier

To create the base classifier, first you need to define the custom categories with names and descriptions. These definitions will be used by the analyzer to classify the input file.

Here is an example definition of a list of categories. For simplicity, I define only one category in the list. To improve classification and splitting quality, use a good category name and description so that the model can understand the categories with some context.

public sealed record ContentUnderstandingCategory(string Name, string Description);

public static readonly IReadOnlyList<ContentUnderstandingCategory> All =
[
    new("Walmart_Invoice",
        "Invoice containing Walmart as the title on the top right of each page.") 
];

Then, create the classification analyzer for your input file:

 var config = new ContentAnalyzerConfig
 {
     ShouldReturnDetails = false,
     EnableOcr = true,
     EnableLayout = true,
     EnableFormula = false,
     EnableFigureDescription = false,
     EnableFigureAnalysis = false,
     ChartFormat = ChartFormat.ChartJs,
     TableFormat = TableFormat.Html,
     AnnotationFormat = AnnotationFormat.Markdown,
     EnableSegment = true,
     SegmentPerPage = false,
     ShouldOmitContent = false
 };

 foreach (var category in ContentUnderstandingCategories.All)
 {
     var definition = new ContentCategoryDefinition { Description = category.Description };
 
// If you have more than one category, each will have a different analyzer linked
definition.AnalyzerId = _options.ExtractAnalyzerId;

config.ContentCategories.Add(category.Name, definition);
 }

 var analyzer = new ContentAnalyzer
 {
     BaseAnalyzerId = "prebuilt-document",
     ProcessingLocation = ProcessingLocation.Geography,
     Config = config,
 };

 analyzer.Models["completion"] = _options.CompletionModelName;

 await CreateOrReplaceAsync(_options.ClassifierAnalyzerId, analyzer, ct).ConfigureAwait(false);

To route to a custom analyzer, we need to create one. Below is the code for the analyzer that will extract information from the Walmart invoice:

public async Task CreateOrUpdateExtractAnalyzerAsync(CancellationToken ct = default)
 {
     var analyzer = new ContentAnalyzer
     {
         BaseAnalyzerId = "prebuilt-document",
         Config = new ContentAnalyzerConfig
         {
             EnableOcr = true,
             EnableLayout = true,
             EstimateFieldSourceAndConfidence = true,
         }
         FieldSchema = new ContentFieldSchema(
             WalmartFields.All.ToDictionary(
                 f => f.Name,
                 f => ExtractField(f.Type, f.Description))),
     };

     analyzer.Models["completion"] = _options.CompletionModelName;

// You will create one analyzer per category needed to be processed
     await CreateOrReplaceAsync(_options.ExtractAnalyzerId, analyzer, ct).ConfigureAwait(false);
 }

As mentioned above, you don't need to link an analyzer to a category if that category doesn't require further processing.

If you're a Linux engineer trying to figure out where AI actually fits into your day-to-day work - not the hype, the actual workflow - this book delivers a solid, practical roadmap.

It opens by grounding AI in something engineers already understand: logs. Instead of treating AI as a black box, the book frames it as a context-aware layer on top of the logging and monitoring systems Linux already gives us, while being upfront about the tradeoffs - data privacy, redaction of sensitive values, and the need for approval gates before any AI-suggested action touches production.

From there it walks through the concepts in a logical order: demystifying AI/ML/LLMs and where each layer (ML, deep learning, generative AI) maps to real Linux tasks like anomaly detection and log summarization; setting up an AI-ready environment with Python, virtual environments, containers, and a clear-eyed comparison of CPUs vs GPUs vs specialized accelerators; and a tour of the open-source ecosystem that any engineer building AI tooling will run into.

Where the book really earns its "for Linux engineers" title is in the back half. It gets into automating operations with AI assistants (with an emphasis on safety validation, dry-runs, and auditability rather than just "let the AI run commands"), building bounded, least-privilege autonomous agents, using LLMs for monitoring and troubleshooting via a dialog-style interface over your telemetry, and applying RAG so systems can reason over your actual logs and runbooks instead of hallucinating. It closes with deployment on Kubernetes, security/guardrails (STRIDE, prompt injection), and a forward-looking chapter on how much autonomy is actually appropriate in infrastructure.

The throughline that stuck with me most: not every problem needs the same level of intelligence. The book keeps circling back to governance, human approval for high-impact changes, and progressive rollout - starting with read-only operations before expanding scope. It's a refreshingly sober take in a space full of overpromising.

Bottom line: a practical, well-structured guide that treats AI as a serious operational tool rather than magic - recommended for any Linux engineer or SRE looking to move from reactive firefighting to more proactive, AI-assisted system management.

Building Agent-Powered Applications is the kind of book you wish existed when you first started trying to make sense of the LLM ecosystem. It opens with a grounded overview of ML and NLP fundamentals - not exhaustive, but just enough to build shared vocabulary before diving into the real substance.

The middle chapters are where the book earns its keep. The coverage of prompt engineering goes well beyond "write clearer prompts" - it walks through chain-of-thought, tree-of-thought, few-shot strategies, and multi-prompt chaining with enough context to understand the trade-offs. The RAG chapter is similarly practical: it distinguishes between lexical, semantic, and hybrid retrieval, explains TF-IDF and vector databases without oversimplifying, and keeps the focus on engineering decisions rather than just theory. Fine-tuning gets honest treatment too - the book is clear about when it's the right tool versus when RAG or prompting will serve you better, and it covers the real costs of full versus partial fine-tuning.

The final stretch, covering agent architecture and evaluation, is the strongest part. The agent chapter pulls everything together - memory design, tool orchestration, MCP, multi-agent coordination - and frames it as a software engineering problem, not just an AI one. That framing matters. It treats reliability, error handling, and human-in-the-loop design as first-class concerns rather than footnotes.

The evaluation chapter deserves special mention because it's often the first thing cut from books like this. Here it gets proper attention: offline vs. online evaluation, lexical and semantic metrics, LLM-as-judge approaches, and safety/adversarial testing all feature. The core message - that evaluation should be defined at the start of a project, not bolted on at the end - is exactly right.

If you're building AI-powered applications and want a single resource that takes you from foundational concepts all the way through to production-ready agents, this is the one to read.

Hybrid search combines full-text and vector queries into a single request, running against an index that holds both plain-text content and generated embeddings.

Vector search excels at surfacing information that is conceptually related to your query, even when no exact keywords match in the inverted index. Full-text search, on the other hand, offers precision, and can be paired with optional semantic ranking to further improve the quality of results.

Prerequisites

• A Cosmos database with sample documents to index

• An Azure AI Search service

• A search index containing searchable vector and nonvector fields.

• Search service must have the semantic ranker enabled

Overview of the services

The Cosmos database has five documents with the following structure:

{
    "id": "doc-005",
    "title": "Azure OpenAI Integration Patterns",
    "category": "AI Architecture",
    "tags": [
        "OpenAI",
        "Azure",
        "Integration"
    ],
    "content": "Azure OpenAI can be integrated with backend systems using APIs, event-driven architectures, or orchestration frameworks like Semantic Kernel. It enables intelligent applications with natural language capabilities.",
    "summary": "Patterns for integrating Azure OpenAI into applications.",
    "author": "Michael Green",
    "createdDate": "2025-05-01T16:20:00Z",
    "region": "EU",
    "accessLevel": "public"
}

The Azure AI Search contains an index with field configuration:

Notice the text_vecor field used for the vector query.

Finally, the semantic configuration defined:

Rise of the working example

Let’s walk through how to build this in C#. Here’s the code:

using Azure;
using Azure.Identity;
using Azure.Search.Documents;
using Azure.Search.Documents.Models;
using Azure.AI.OpenAI;

string searchEndpoint = Environment.GetEnvironmentVariable("AZURE_SEARCH_ENDPOINT")!;
string indexName = "rag-hybrid";

string openAiEndpoint = Environment.GetEnvironmentVariable("AZURE_OPENAI_ENDPOINT")!;
string deploymentName = "text-embedding-ada-itt";

var azureOpenAIClient = new AzureOpenAIClient(
    new Uri(openAiEndpoint),
    new DefaultAzureCredential());

// Create embedding client
var embeddingClient = azureOpenAIClient.GetEmbeddingClient(deploymentName);

string query = "how to integrate RAG";

// Generate embedding
var embeddingResponse = await embeddingClient.GenerateEmbeddingAsync(query);

// Convert to float[]
var queryVector = embeddingResponse.Value.ToFloats();

string searchKey = Environment.GetEnvironmentVariable("AZURE_SEARCH_KEY")!;

SearchClient client = new(
    new Uri(searchEndpoint),
    indexName,
    new AzureKeyCredential(searchKey));

SearchResults<SearchDocument> results = await client.SearchAsync<SearchDocument>(
    query,
    new SearchOptions
    {
        VectorSearch = new()
        {
            Queries =
            {
                new VectorizedQuery(queryVector)
                {
                    Fields = { "text_vector" },
                    Exhaustive = true,
                    KNearestNeighborsCount = 5
                },
            }
        },
        QueryType = SearchQueryType.Semantic,
        SemanticSearch = new SemanticSearchOptions
        {
            SemanticConfigurationName = "rag-hybrid-semantic-configuration"
        },
        Select = { "summary", "chunk", "category", "author" },
        Size = 5
    });

await foreach (SearchResult<SearchDocument> result in results.GetResultsAsync())
{
    Console.WriteLine($"{result.Document["category"]} -> {result.Document["summary"]} \n" +
        $"{result.Document["chunk"]}");
    Console.WriteLine();
}

The core of the example is the SearchAsync call, which sends a query that does four things simultaneously.

First, the query string is passed as the first argument to SearchAsync, which triggers traditional keyword search.

Second, the VectorizedQuery uses the float vector generated earlier to search the text_vector field in the index. It also finds the 5 nearest neighbors.

Third, the results from keyword search and vector search are merged, producing a single ranked list.

Fourth, the QueryType is set to Semantic, which activates Azure's semantic re-ranker. This re-ranks the fused results using a language model that understands context, not just keywords. The semantic configuration defines how the re-ranker interprets fields like title and content, guiding how relevance is computed.

Let's observe the results returned by running two different queries. The first query is string query = "how to integrate RAG"; while the second is string query = "written by Michael Green";

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.