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.How to Build AI Agents in 10 Lessons
Microsoft has released an excellent learning resource for anyone looking to dive into the world of AI agents: "AI Agents for Beginners". This comprehensive course is available free on GitHub. It is designed to teach the fundamentals of building AI agents, even if you are just starting out. What You'll Learn The course is structured into 10 lessons, covering a wide range of essential topics including: Agentic Frameworks: Understand the core structures and components used to build AI agents. Design Patterns: Learn proven approaches for designing effective and efficient AI agents. Retrieval Augmented Generation (RAG): Enhance AI agents by incorporating external knowledge. Building Trustworthy AI Agents: Discover techniques for creating AI agents that are reliable and safe. AI Agents in Production: Get insights into deploying and managing AI agents in real-world applications. Hands-On Experience The course includes practical code examples that utilize: Azure AI Foundry GitHub Models These examples help you learn how to interact with Language Models and use AI Agent frameworks and services from Microsoft, such as: Azure AI Agent Service Semantic Kernel Agent Framework AutoGen - A framework for building AI agents and applications Getting Started To get started, make sure you have the proper set-up. Here are the 10 lessons Intro to AI Agents and Agent Use Cases Exploring AI Agent Frameworks Understanding AI Agentic Design Principles Tool Use Design Pattern Agentic RAG Building Trustworthy AI Agents Planning Design Multi-Agent Design Patterns Metacognition in AI Agents AI Agents in Production Multi-Language Support To make learning accessible to a global audience, the course offers multi-language support. Get Started Today! If you are eager to learn about AI agents, this course is an excellent starting point. You can find the complete course materials on GitHub at AI Agents for Beginners.AI Agents: Mastering the Tool Use Design Pattern - Part 4
This blog post, Part 4 of a series on AI agents, delves into the Tool Use Design Pattern, a key concept in enabling agents to interact with external systems and perform a wider range of tasks. The post explains how tools, ranging from simple functions to complex API calls, are invoked by AI agents through model-generated function calls. Several use cases are presented, highlighting the versatility of this pattern, from dynamic information retrieval and code execution to workflow automation and customer support. The post further details the implementation of function/tool calling, including choosing a suitable LLM, defining a function schema, and writing the function code. Examples using Semantic Kernel and Azure AI Agent Service illustrate how agentic frameworks simplify tool integration. Finally, the post addresses security considerations and provides links to valuable resources, including the "AI Agents for Beginners" GitHub repository and related workshops, for further learning.
Sidecar Pattern in Action
The Sidecar pattern enables the extension and enhancement - of an existing process or an application container - without affecting/modifying it and thus ensuring the single-responsibility of the existing process / container. The problem context, solution, considerations and use cases for this pattern are comprehensively documented here. Exploring the usage and reviewing the implementation of this pattern, in a real-world project, is an effective way to gain a practical perspective as you start putting the pattern into practice. I have chosen two such open source projects that implement the sidecar pattern as part of their core architecture. The first one is - Dapr - Distributed Application Runtime and the other project we will look into is the Open Service Mesh . Dapr Dapr is an event driven, portable runtime for building microservices on cloud and edge. Dapr facilitates the development of microservices by providing independent building blocks like - State Management, Pub-Sub, Observability, Secrets and more - which are encapsulated as the Dapr API - in a platform-agnostic and language-agnostic manner. The independent nature of the building blocks lets you cherry-pick the set of features you want for your application and the platform-agnostic aspect gives you a wide spectrum of platforms to operate in ranging - from lean and resource-starved devices on the edge - to - power-packed , full fledged Azure Kubernetes Service clusters in the cloud. Sidecar implementation in Dapr architecture The key advantage of using Dapr is that the application utilizing it need not include any Dapr runtime code. This advantage is achieved by utilizing the - sidecar pattern. The core Dapr API itself is exposed as a sidecar - either a sidecar process or a sidecar container. If it is a sidecar process - the service code calls the Dapr API via HTTP/gRPC. In the world of containers orchestrated by Kubernetes, the Dapr API is a side car container itself - which is utilized by the application container within the same pod. Diagrams from the the Dapr project's documentation as follows - So, the use case in - Dapr's case - is where a primary application uses a heterogeneous set of languages and frameworks and the component (Dapr API) located in a sidecar service /container can be consumed by applications written in different languages using different frameworks. Open Service Mesh (OSM) OSM is a lightweight and extensible cloud native service mesh that runs on Kubernetes. This was a project initiated by Microsoft that has been now donated to the Cloud Native Computing Foundation (CNCF) where it is a Sandbox project - at the time of this writing. Sidecar implementation in OSM architecture OSM onboards applications to the mesh by enabling the automatic sidecar injection of the Envoy proxy. A look at Image 3 below (source: OSM design doc) - shows the Envoy proxy already existing as sidecar container within the Kubernetes (k8s) pod. Sidecar Container Injection To elaborate on the sidecar injection part - OSM utilizes a feature of Kubernetes called MutatingAdmissionWebhook admission controller to intercept the k8s API server request after the pod creation is initiated but before the actual persistence/creation of the pod - to augment the request to include a Envoy proxy sidecar. This injection is done by the [Webhook+Injector] in the OSM Controller Pod. Refer Image 3 above. Now the created pod has the Envoy proxy sidecar automatically. This means the powerful features of Envoy like - advanced load balancing, observability, rate limiting et.al. - are readily available to be utilized by each instance of the application and allowing the services in the mesh to communicate with each other. The separation of concerns between application's core functionality and Envoy's functionality + the ability of Envoy features to still be in proximity of the application is achieved via the sidecar pattern in the case of Open Service Mesh. On a similar note - in Dapr's case - subsequent to installation of Dapr in a Kubernetes environment - it deploys a set of pods to the Default namespace. A couple of such pods - relevant to the premise of this article - are tabulated below - Pod Responsibility dapr-operator Watches for workload pods with Dapr annotations i.e. [dapr.io/enabled: true] dapr-sidecar-injector Augments, patches and injects the sidecar container to each annotated workload pod. So, when you have your application workload's Kubernetes Deployment annotated with the requisite Dapr annotations - like [dapr.io/enabled: "true"] - the Dapr side car injector pod [dapr-sidecar-injector] as tabulated above - kicks in and injects the container. Now, every app container has a companion Dapr sidecar container within the same pod - realizing the desired intent. ------ I hope this has given you a bit more insight into the Sidecar pattern and has also piqued your interest in both the Dapr and Open Service Mesh projects! References: 1. Sidecar pattern - https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar 2. Dapr - https://dapr.io/ 3. Sidecar implementation in Dapr - https://github.com/dapr/docs/tree/master/overview#sidecar-architecture 4. Open Service Mesh(OSM) - https://openservicemesh.io/ 5. OSM component and interactions - https://github.com/openservicemesh/osm/blob/main/DESIGN.md#osm-components--interactions 6. Kubernetes Admission Controllers - https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/ 7. OSM MutatingWebhookConfiguration - https://github.com/openservicemesh/osm/blob/release-v0.3/charts/osm/templates/mutatingwebhook.yaml Note - All images used in this article are from respective project documentations, the links to which are referenced above.
