Build governed asynchronous APIs with Azure API Management and Azure Service Bus
Many applications use Azure Service Bus to decouple services, handle traffic spikes, and process workloads asynchronously. However, securely exposing messaging capabilities to applications, partners, and internal teams can require custom middleware or messaging-specific client implementations. Today, we’re announcing the general availability of native Azure Service Bus integration in Azure API Management. With the send-service-bus-message policy, developers can publish messages directly from an Azure API Management gateway to an Azure Service Bus queue or topic. This provides a secure and governed HTTP interface for Service Bus workloads—without requiring teams to build and operate a separate adapter service. Connect APIs directly to Azure Service Bus Azure API Management can act as the governed entry point for applications that submit work to Azure Service Bus. A client sends a standard HTTP request to API Management. The gateway can authenticate and authorize the caller, validate or transform the request, and apply policies such as rate limits and quotas before publishing the message to a Service Bus queue or topic. Once the message is accepted, API Management can immediately respond to the caller while downstream services process the message asynchronously. Alternatively, message publication can be added to an existing API flow while the request continues to its primary backend. This integration brings together API governance in Azure API Management and reliable asynchronous messaging in Azure Service Bus—without adding another intermediary service. Greater control over Service Bus messages As part of general availability, we’re introducing additional controls for building production messaging workflows. 1. Control how messages are processed Developers can configure the following Service Bus message properties directly in the policy: Message IDs to correlate messages and support duplicate-detection or idempotent processing patterns. Session IDs to group related messages for ordered or stateful processing. Time-to-live to prevent messages from being processed after they are no longer relevant. These values can be generated dynamically using API Management policy expressions, allowing them to reflect request IDs, customer identifiers, transactions, or other application context. 2. Capture the send result The response-variable-name attribute captures information about the Service Bus send operation in an API Management context variable. Subsequent policies can use the result to add correlation information to an API response, emit telemetry, record an operational event, or apply conditional logic when a message cannot be sent. 3. Choose how failures affect the API Different messaging scenarios require different failure behavior. When publishing the message is the primary purpose of an API, a send failure can stop policy execution and invoke the API Management error-handling path. When publishing is secondary—such as sending an audit event or initiating optional downstream processing—the ignore-error option can allow the primary API request to continue. Information about the send operation remains available through the response variable for logging or subsequent policy logic. 4. Secure access with managed identity API Management authenticates to Azure Service Bus using a Microsoft Entra managed identity. Customers can use the system-assigned identity of the API Management service or specify a user-assigned managed identity. The selected identity is granted the Azure Service Bus Data Sender role for the appropriate namespace, queue, or topic. This removes the need to store Service Bus connection strings or shared access keys in API policies and makes it easier to apply least-privilege access using Azure role-based access control. Send a message with an API Management policy The following example sends the incoming request body to an orders queue. It assigns a message ID and expiration time, captures the result of the send operation, and treats successful publication as a required part of the API request. <send-service-bus-message queue-name="orders" namespace="contoso-messaging.servicebus.windows.net" message-id="@(context.RequestId.ToString())" time-to-live="00:10:00" response-variable-name="serviceBusResult" ignore-error="false"> <payload> @(context.Request.Body.As<string>(preserveContent: true)) </payload> </send-service-bus-message> A session ID can also be added when related messages need to be grouped for ordered or stateful processing. For a fully asynchronous API, the policy can be followed by return-response so that API Management acknowledges the request immediately after sending the message. For an existing API, the request can continue to its configured backend after the message is published. Common integration scenarios Create asynchronous APIs: Accept an order, document, or processing request through an HTTP API, publish it to a queue, and return immediately while downstream services complete the work. Govern partner integrations: Provide partners with a managed API contract instead of exposing the underlying Service Bus namespace. API Management can authenticate callers, validate requests, and apply quotas before publishing messages. Publish business events: Publish events to a Service Bus topic so multiple subscriptions and downstream services can process them independently. Handle bursts of incoming traffic: Use Service Bus to buffer messages when incoming API traffic temporarily exceeds the rate at which downstream services can process requests. Add events to existing API operations: Publish audit, notification, analytics, or workflow events while allowing the primary API request to continue to its configured backend. Preserve workflow affinity: Use Service Bus sessions to group related messages for ordered or stateful processing based on a customer, transaction, order, or workflow identifier. Get started To send messages from Azure API Management to Azure Service Bus: Create or select an Azure Service Bus queue or topic. Enable a system-assigned or user-assigned managed identity on the API Management service. Assign the identity the Azure Service Bus Data Sender role. Add the send-service-bus-message policy to an API operation. Configure the message payload, processing properties, output variable, and failure behavior. With native Azure Service Bus integration, Azure API Management provides a secure and governed way to connect HTTP APIs with asynchronous messaging workloads—without requiring additional middleware. Learn more Send Service Bus message policy reference Send messages to Azure Service Bus from Azure API Management Azure API Management June 2026 release notes Azure Service Bus documentationIntegrating Microsoft Foundry with OpenClaw: Step by Step Model Configuration
Step 1: Deploying Models on Microsoft Foundry Let us kick things off in the Azure portal. To get our OpenClaw agent thinking like a genius, we need to deploy our models in Microsoft Foundry. For this guide, we are going to focus on deploying gpt-5.2-codex on Microsoft Foundry with OpenClaw. Navigate to your AI Hub, head over to the model catalog, choose the model you wish to use with OpenClaw and hit deploy. Once your deployment is successful, head to the endpoints section. Important: Grab your Endpoint URL and your API Keys right now and save them in a secure note. We will need these exact values to connect OpenClaw in a few minutes. Step 2: Installing and Initializing OpenClaw Next up, we need to get OpenClaw running on your machine. Open up your terminal and run the official installation script: curl -fsSL https://openclaw.ai/install.sh | bash The wizard will walk you through a few prompts. Here is exactly how to answer them to link up with our Azure setup: First Page (Model Selection): Choose "Skip for now". Second Page (Provider): Select azure-openai-responses. Model Selection: Select gpt-5.2-codex , For now only the models listed (hosted on Microsoft Foundry) in the picture below are available to be used with OpenClaw. Follow the rest of the standard prompts to finish the initial setup. Step 3: Editing the OpenClaw Configuration File Now for the fun part. We need to manually configure OpenClaw to talk to Microsoft Foundry. Open your configuration file located at ~/.openclaw/openclaw.json in your favorite text editor. Replace the contents of the models and agents sections with the following code block: { "models": { "providers": { "azure-openai-responses": { "baseUrl": "https://<YOUR_RESOURCE_NAME>.openai.azure.com/openai/v1", "apiKey": "<YOUR_AZURE_OPENAI_API_KEY>", "api": "openai-responses", "authHeader": false, "headers": { "api-key": "<YOUR_AZURE_OPENAI_API_KEY>" }, "models": [ { "id": "gpt-5.2-codex", "name": "GPT-5.2-Codex (Azure)", "reasoning": true, "input": ["text", "image"], "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 }, "contextWindow": 400000, "maxTokens": 16384, "compat": { "supportsStore": false } }, { "id": "gpt-5.2", "name": "GPT-5.2 (Azure)", "reasoning": false, "input": ["text", "image"], "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 }, "contextWindow": 272000, "maxTokens": 16384, "compat": { "supportsStore": false } } ] } } }, "agents": { "defaults": { "model": { "primary": "azure-openai-responses/gpt-5.2-codex" }, "models": { "azure-openai-responses/gpt-5.2-codex": {} }, "workspace": "/home/<USERNAME>/.openclaw/workspace", "compaction": { "mode": "safeguard" }, "maxConcurrent": 4, "subagents": { "maxConcurrent": 8 } } } } You will notice a few placeholders in that JSON. Here is exactly what you need to swap out: Placeholder Variable What It Is Where to Find It <YOUR_RESOURCE_NAME> The unique name of your Azure OpenAI resource. Found in your Azure Portal under the Azure OpenAI resource overview. <YOUR_AZURE_OPENAI_API_KEY> The secret key required to authenticate your requests. Found in Microsoft Foundry under your project endpoints or Azure Portal keys section. <USERNAME> Your local computer's user profile name. Open your terminal and type whoami to find this. Step 4: Restart the Gateway After saving the configuration file, you must restart the OpenClaw gateway for the new Foundry settings to take effect. Run this simple command: openclaw gateway restart Configuration Notes & Deep Dive If you are curious about why we configured the JSON that way, here is a quick breakdown of the technical details. Authentication Differences Azure OpenAI uses the api-key HTTP header for authentication. This is entirely different from the standard OpenAI Authorization: Bearer header. Our configuration file addresses this in two ways: Setting "authHeader": false completely disables the default Bearer header. Adding "headers": { "api-key": "<key>" } forces OpenClaw to send the API key via Azure's native header format. Important Note: Your API key must appear in both the apiKey field AND the headers.api-key field within the JSON for this to work correctly. The Base URL Azure OpenAI's v1-compatible endpoint follows this specific format: https://<your_resource_name>.openai.azure.com/openai/v1 The beautiful thing about this v1 endpoint is that it is largely compatible with the standard OpenAI API and does not require you to manually pass an api-version query parameter. Model Compatibility Settings "compat": { "supportsStore": false } disables the store parameter since Azure OpenAI does not currently support it. "reasoning": true enables the thinking mode for GPT-5.2-Codex. This supports low, medium, high, and xhigh levels. "reasoning": false is set for GPT-5.2 because it is a standard, non-reasoning model. Model Specifications & Cost Tracking If you want OpenClaw to accurately track your token usage costs, you can update the cost fields from 0 to the current Azure pricing. Here are the specs and costs for the models we just deployed: Model Specifications Model Context Window Max Output Tokens Image Input Reasoning gpt-5.2-codex 400,000 tokens 16,384 tokens Yes Yes gpt-5.2 272,000 tokens 16,384 tokens Yes No Current Cost (Adjust in JSON) Model Input (per 1M tokens) Output (per 1M tokens) Cached Input (per 1M tokens) gpt-5.2-codex $1.75 $14.00 $0.175 gpt-5.2 $2.00 $8.00 $0.50 Conclusion: And there you have it! You have successfully bridged the gap between the enterprise-grade infrastructure of Microsoft Foundry and the local autonomy of OpenClaw. By following these steps, you are not just running a chatbot; you are running a sophisticated agent capable of reasoning, coding, and executing tasks with the full power of GPT-5.2-codex behind it. The combination of Azure's reliability and OpenClaw's flexibility opens up a world of possibilities. Whether you are building an automated devops assistant, a research agent, or just exploring the bleeding edge of AI, you now have a robust foundation to build upon. Now it is time to let your agent loose on some real tasks. Go forth, experiment with different system prompts, and see what you can build. If you run into any interesting edge cases or come up with a unique configuration, let me know in the comments below. Happy coding!Implementing / Migrating the BizTalk Server Aggregator Pattern to Azure Logic Apps Standard
While the article focuses on the migration path from BizTalk Server, the template is equally suited for new (greenfield) implementations any team looking to implement the Aggregator pattern natively in Azure Logic Apps can deploy it directly from the Azure portal without prior BizTalk experience. The template source code is open source and available in the Azure LogicAppsTemplates GitHub repository. For full details on the original BizTalk implementation, see the BizTalk Server Aggregator SDK sample. Why is it important? BizTalk Server End of life has been confirmed and if you have not started your migration to Logic Apps, you should start soon. This is one of many articles in BizTalk Migration. More information can be found here: https://aka.ms/biztalkeolblog. The migration at a glance: BizTalk orchestration vs. Logic Apps workflow The BizTalk SDK implements the pattern through an orchestration (Aggregate.odx) that uses correlation sets, receive shapes, loop constructs, and send pipelines. The Logic Apps Standard template replicates the same logic using a stateful workflow with Azure Service Bus and CorrelationId-based grouping. The BizTalk solution includes: Component Purpose Aggregate.odx Main orchestration that collects correlated messages and executes the send pipeline FFReceivePipeline.btp Receive pipeline with flat file disassembler Invoice.xsd Document schema for invoice messages InvoiceEnvelope.xsd Envelope schema for output interchange PropertySchema.xsd Property schema with promoted properties for correlation XMLAggregatingPipeline.btp Send pipeline to assemble collected messages into XML interchange The Azure Logic Apps Standard implementation The Logic Apps Standard workflow replicates the same Aggregator pattern using a stateful workflow with Azure Service Bus as the message source and CorrelationId-based grouping. The template is publicly available in the Azure portal templates gallery. Figure 2: The “Aggregate messages from Azure Service Bus by CorrelationId” template in the Azure portal templates gallery, published by Microsoft. Receives messages from Service Bus in batches, groups them by CorrelationId, decodes flat files, and responses with the aggregated result via HTTP. Side-by-side comparison: BizTalk Server vs. Azure Logic Apps Understanding how each component maps between platforms is essential for a smooth migration: Concept BizTalk Server (Aggregate.odx) Azure Logic Apps Standard Messaging infrastructure MessageBox database (SQL Server) Azure Service Bus (cloud-native PaaS) Message source Receive Port / Receive Location Service Bus trigger (peekLockQueueMessagesV2) Message decoding Receive Pipeline (Flat File Disassembler) Decode_Flat_File_Invoice action (FlatFileDecoding) Correlation mechanism Correlation Sets on promoted properties (DestinationPartnerURI) CorrelationId from Service Bus message properties Message accumulation Loop shape + Message Assignment shapes ForEach loop + CorrelationGroups dictionary variable Completion condition Loop exit (10 messages or 1-minute timeout) Batch-based: processes all messages in current batch Aggregated message construction Construct Message shape + XMLAggregatingPipeline Build_Aggregated_Messages ForEach + Compose actions Result delivery Send Port (file, HTTP, or other adapter) HTTP Response or any other regarding business need Error handling Exception Handler shapes + SuspendMessage.odx Scope + error handler actions Schema support BizTalk Flat File Schemas (XSD) Same XSD schemas in Artifacts/Schemas folder State management Orchestration dehydration/rehydration Stateful workflow with run history Key architectural differences Aspect BizTalk Server Azure Logic Apps Standard Processing model Convoy pattern (long-running, event-driven) Batch-based (processes N messages per trigger) Scalability BizTalk Host instances (manual scaling) Elastic scale (Azure App Service Plan) Retry logic Adapter-level retries Built-in HTTP retry policy (3 attempts, 10s interval) Architecture Monolithic orchestration Decoupled: aggregation + downstream processing Monitoring BizTalk Admin Console / HAT Azure portal run history + Azure Monitor Schema reuse BizTalk project schemas Direct XSD reuse in Artifacts/Schemas Deployment MSI / BizTalk deployment ARM templates, Azure DevOps, GitHub Actions How the workflow works 1. Trigger: Receive messages from Service Bus The workflow uses the built-in Service Bus trigger to retrieve messages in batches from a non-session queue. This is analogous to BizTalk's Receive Location polling the message source. 2. Process and correlate: Group messages by CorrelationId Each message is processed sequentially (like BizTalk's ordered delivery). The workflow: Extracts the CorrelationId from Service Bus message properties (equivalent to BizTalk's promoted property used in the Correlation Set) Decodes flat file content with zero refactoring using the XSD schema (equivalent to BizTalk's Flat File Disassembler pipeline component) Groups messages into a dictionary keyed by CorrelationId (equivalent to BizTalk's loop + message assignment pattern) 3. Build aggregated output Once all messages in the batch are processed, the workflow constructs a result object for each correlation group containing the CorrelationId, message count and the array of decoded messages. 4. Deliver results The aggregated output is sent to a target workflow via HTTP POST, following a decoupled architecture pattern. This is analogous to BizTalk's Send Port delivering the result to the destination system. You can substitute this action for another endpoint as needed. This, will depend on your business case. Azure Service Bus: The cloud-native replacement for BizTalk’s MessageBox In BizTalk Server, the MessageBox database is the central hub for all message routing, subscription-based delivery, and correlation. It’s the engine that enables patterns like the Aggregator — messages are published to the MessageBox, and the orchestration subscribes to them based on promoted properties and correlation sets. In Azure Logic Apps Standard, there is no MessaeBox equivalent. Instead, Azure Service Bus serves as the cloud-native messaging backbone. Service Bus provides the same publish/subscribe semantics, message correlation (via the built-in CorrelationId property), peek-lock delivery, and reliable queuing — but as a fully managed, elastically scalable PaaS service with no infrastructure to maintain. This is a fundamental shift in architecture: you move from a centralized SQL Server-based message broker (MessageBox) to a distributed, cloud-native messaging service (Service Bus) that scales independently and integrates natively with Logic Apps through the built-in Service Bus connector. Important: Service Bus is not available on-premises. However, RabbitMQ is available to cover these needs, on-premises. RabbitMQ offers a fantastic alternative for customers looking to replicate BizTalk message routing, subscription-based delivery, and correlation. Decode Flat File Invoice: Reuse your BizTalk schemas with zero refactoring One of the biggest concerns during any BizTalk migration is: “What happens to our flat file schemas and message formats?” The workflow template includes a Decode Flat File action (type FlatFileDecoding) that converts positional or delimited flat file content into XML — exactly like BizTalk’s Flat File Disassembler pipeline component. The key advantage: your original BizTalk XSD flat file schemas work as-is. Upload them to the Logic Apps Artifacts/Schemas folder and reference them by name in the workflow — no modifications, no refactoring. This means: Your existing message formats don’t change — upstream and downstream systems continue sending and receiving the same flat file messages Your BizTalk schemas are directly reusable — the same Invoice.xsd from your BizTalk project works seamlessly with the FlatFileDecoding action Migration effort is significantly reduced — no need to redesign schemas, re-validate message structures, or update trading partner agreements Time-to-production is faster — focus on workflow logic and connectivity instead of rewriting message definitions Notice that, if you need to process XML data, as your data might arrive in XML format, use the XML Operations: Validate, Transform, Parse, and Compose XML with schema. You can find more information at Compose XML using Schemas in Standard Workflows - Azure Logic Apps | Microsoft Learn. The message with correlation Id Each message in the Service Bus queue is a flat file invoice the same positional/delimited text format used in the BizTalk SDK sample. Here's an example: INVOICE12345 DestinationPartnerURI:http://www.contoso.com?ID=1E1B9646-48CF-41dd-A0C0-1014B1CE5064 BILLTO,US,John Connor,123 Cedar Street,Mill Valley,CA,90952 101-TT Plastic flowers 10 4.99 Fragile handle with care 202-RR Fertilizer 1 10.99 Lawn fertilizer 453-XS Weed killer 1 5.99 Lawn weed killer The message structure combines positional and delimited fields: Line 1: Invoice identifier (fixed-length record) Line 2: Destination partner URI — in BizTalk, this value is promoted as a context property and used in the Correlation Set to group related messages Line 3: Bill-to header (comma-delimited: country, name, address, city, state, ZIP) Line 4: Line items (positional fields: item code, description, quantity, unit price, notes) Why CorrelationId is essential In BizTalk Server, the orchestration promotes `DestinationPartnerURI` from the message body into a context property and uses it as the Correlation Set to match related messages. This requires a Property Schema, promoted properties, and pipeline configuration. In Azure Logic Apps Standard, correlation is decoupled from the message body. The `CorrelationId` is a native Azure Service Bus message property with a first-class header set by the message producer when sending to the queue. This means: No schema changes needed: the flat file content stays exactly the same No property promotion: Service Bus provides the correlation identifier out of the box Simpler architecture: the workflow reads `CorrelationId` directly from the message metadata, not from the payload Producer flexibility any system sending to Service Bus can set the `CorrelationId` header using standard SDK methods, without modifying the message body This is why the Aggregator pattern maps so naturally to Service Bus: the correlation mechanism that BizTalk implements through promoted properties and correlation sets is already built into the messaging infrastructure. Step-by-step guide: Deploy the template from the Azure portal The “Aggregate messages from Azure Service Bus by CorrelationId” template is publicly available in the Azure Logic Apps Standard templates gallery. Follow these steps to deploy it: Prerequisites Before you begin, make sure you have: An Azure subscription. If you don’t have one, sign up for a free Azure account . An Azure Logic Apps Standard resource deployed in your subscription. If you need to create one, see Create an example Standard logic app workflow . An Azure Service Bus namespace with a non-session queue configured. A flat file XSD schema (for example, Invoice.xsd) ready to upload to the logic app’s Artifacts/Schemas folder. A target workflow with an HTTP trigger to receive the aggregated results (optional, can be created after deployment). Step 1: Open the templates gallery Sign in to the Azure portal. Navigate to your Standard logic app resource. On the logic app sidebar menu, select Workflows. On the logic app sidebar menu, select Workflows. On the Workflows page, select + Create to create a new workflow. In the “Create a new workflow” pane, select Use Template to open the templates gallery and select Create button. Step 2: Find the Aggregator template In the templates gallery, use the search box and type “Aggregate” or “Aggregator”. Optionally, filter by: o Connectors: Select Azure Service Bus o Categories: All Locate the template named “Aggregate messages from Azure Service Bus by CorrelationId”. o The template card shows the labels Workflow and Event as the solution type and trigger type. o The template is published by Microsoft. Step 3: Review the template details Select the template card to open the template overview pane. On the Summary tab, review: o Connections included in this template: Azure Service Bus (in-app connector) o Prerequisites: Requirements for Azure Service Bus, flat file schema, and connection configuration o Details: Description of the Aggregator enterprise integration pattern implementation Source code: Link to the GitHub repository Select the Workflow tab to preview the workflow design that the template creates and when you are ready select Use this template. Step 4: Provide workflow information In the Create a new workflow from template pane, on the Basics tab: o Workflow name: Enter a name for your workflow, for example, wf-aggregator-invoices o State type: Select Stateful (recommended for aggregation scenarios that require run history and reliable processing) Select Next. Step 5: Create connections On the Connections tab, create the Azure Service Bus connection: o Select Connect next to the Service Bus connection. o Provide your Service Bus connection string or select the managed identity authentication option. For managed identity (recommended), make sure your logic app’s managed identity has the Azure Service Bus Data Receiver role on the Service Bus namespace. 2. Select Next. Step 6: Configure parameters On the Parameters tab, provide values for the workflow parameters: Parameter Description Example value Azure Service Bus queue name The queue to monitor for incoming messages invoice-queue Maximum batch size Number of messages per batch (1-100) 10 Flat file schema name XSD schema name in Artifacts/Schemas Invoice.xsd Default CorrelationId Fallback value for messages without CorrelationId NO_CORRELATION_ID Target workflow URL HTTP endpoint of the downstream workflow https://your-logicapp.azurewebsites.net/... Target workflow timeout HTTP call timeout in seconds 60 Enable sequential processing Maintain message order true 2. Select Next. Step 7: Review and create On the Review + create tab, review all the provided information. Select Create. When the deployment completes, select Go to my workflow. Step 8: Upload the flat file schema Navigate to your logic app resource in the Azure portal. On the sidebar menu, under Artifacts, select Schemas. Select + Add and upload your Invoice.xsd. Confirm the schema appears in the list. Notice that: for this scenario we are using the Invoice.xsd schema, you can/must use the schema your scenario needs. Step 9: Verify and test On the workflow sidebar, select Designer to review the created workflow. Verify all actions are configured correctly. Send test messages to your Service Bus queue with different CorrelationId values. Monitor the Run history to verify successful execution and aggregation. For more information on creating workflows from templates, see Create workflows from prebuilt templates in Azure Logic Apps. Conclusion The Aggregator pattern is a cornerstone of enterprise integration, and migrating it from BizTalk Server to Azure Logic Apps Standard doesn’t mean starting from scratch. By using this template, you can: Reuse your existing XSD flat file schemas directly from your BizTalk projects Replace BizTalk Correlation Sets with CorrelationId-based message grouping via Azure Service Bus Deploy in minutes from the Azure portal templates gallery Scale elastically with Azure App Service Plan Monitor with Azure-native tools instead of the BizTalk Admin Console The template is open source and available at: GitHub PR: Azure/LogicAppsTemplates#108 Template name in Azure portal: “Aggregate messages from Azure Service Bus by CorrelationId” Source code: GitHub repository Whether you’re migrating from BizTalk Server or building a new integration solution from scratch, this template gives you a solid, production-ready starting point. I encourage you to try it, customize it for your scenarios, and contribute back to the community. Resources BizTalk Server Aggregator SDK sample Create workflows from prebuilt templates in Azure Logic Apps Create and publish workflow templates for Azure Logic Apps Flat file encoding and decoding in Logic Apps Azure Service Bus connector overview BizTalk to Azure migration guide BizTalk Migration Starter toolAI Agents: The Multi-Agent Design Pattern - Part 8
This blog post, Part 8 in a series on AI agents, explores the Multi-Agent Design Pattern, outlining the benefits and key components of building systems with multiple interacting agents. It details the scenarios where multi-agent systems excel (large workloads, complex tasks, diverse expertise), highlights their advantages over single-agent approaches (specialization, scalability, fault tolerance), and discusses the fundamental building blocks for implementation, including agent communication, coordination mechanisms, and architectural considerations. The post introduces common multi-agent patterns (group chat, hand-off, collaborative filtering) and illustrates these concepts with a refund process example. Finally, it includes a practical assignment and provides links to further resources and previous posts in the series.AI Agents: Planning and Orchestration with the Planning Design Pattern - Part 7
This blog post, Part 7 in a series on AI agents, focuses on the Planning Design Pattern for effective task orchestration. It explains how to define clear goals, decompose complex tasks into manageable subtasks, and leverage structured output (e.g., JSON) for seamless communication between agents. The post includes code snippets demonstrating how to create a planning agent, orchestrate multi-agent workflows, and implement iterative planning for dynamic adaptation. It also links to a practical example notebook (07-autogen.ipynb) and further resources like AutoGen Magnetic One, encouraging readers to explore advanced planning concepts. Links to the previous posts in the series are provided for easy access to foundational AI agent concepts.
