Develop a Multi Agent Application and Deploy into Azure

Azure

Let’s break this down into a clear roadmap so you can go from design to deployment smoothly.

🧩 Step 1: Define Your Multi‑Agent Architecture

Agents: Decide what roles your agents will play (e.g., data collector, analyzer, planner, executor).
Communication: Choose how agents will talk to each other — options include:
- REST APIs
- Azure Service Bus / Event Grid
- Direct messaging via frameworks like LangChain or AutoGen
Coordination: Decide if you’ll use a central orchestrator (controller agent) or a peer‑to‑peer model.

⚙️ Step 2: Local Development

Frameworks: Use Python with LangChain, AutoGen, or Microsoft’s Semantic Kernel for agent orchestration.
Environment: Containerize each agent with Docker for portability.
Testing: Run locally with Docker Compose or Kubernetes (kind/minikube) to simulate multi‑agent interactions.

☁️ Step 3: Azure Infrastructure Setup

Resource Group: Create a dedicated resource group for your project.
Compute Options:
- Azure Kubernetes Service (AKS) → best for scalable multi‑agent workloads.
- Azure Container Apps → simpler, serverless container hosting.
- Azure Functions → if agents are lightweight and event‑driven.
Networking:
- Use Azure Virtual Network for secure communication.
- Configure Ingress Controller or Azure API Management for external access.

🔄 Step 4: Agent Deployment

Push Docker images to Azure Container Registry (ACR).
Deploy agents into AKS or Container Apps.
Use Helm charts or Bicep/ARM templates for repeatable deployments.

📡 Step 5: Communication & Orchestration

Service Bus/Event Grid → for asynchronous messaging between agents.
Azure Logic Apps or Durable Functions → for workflow orchestration if needed.
Cosmos DB / Azure Storage → for shared state or logs.

🔍 Step 6: Monitoring & Scaling

Azure Monitor + Application Insights → track agent performance and logs.
Autoscaling → configure AKS HPA (Horizontal Pod Autoscaler) or Container Apps scaling rules.
Security → manage secrets with Azure Key Vault.

🚀 Step 7: End‑to‑End Workflow Example

User request hits API Gateway.
Controller agent receives request, delegates tasks.
Worker agents (e.g., data fetcher, analyzer, summarizer) process tasks.
Results are aggregated and returned via API.
Logs and metrics stored in Azure Monitor.

✅ Deliverables

Codebase: Python agents with orchestration logic.
Dockerfiles: For each agent.
Deployment scripts: Helm/Bicep/ARM templates.
Azure setup: Resource group, ACR, AKS/Container Apps, Service Bus, Monitor.

Perfect — let’s put this into something tangible. I’ll give you both a visual architecture diagram and a sample deployment manifest (Helm/YAML) so you can see how a multi‑agent system would be deployed end‑to‑end on Azure.

🏗️ High‑Level Architecture Diagram

                ┌───────────────────────────┐
                │       User / Client       │
                └─────────────┬─────────────┘
                              │
                      Azure API Management
                              │
                ┌─────────────┴─────────────┐
                │   Controller Agent Pod    │
                └─────────────┬─────────────┘
                              │
          ┌───────────────────┼───────────────────┐
          │                   │                   │
   Worker Agent A Pod   Worker Agent B Pod   Worker Agent C Pod
   (Data Fetcher)       (Analyzer)           (Summarizer)
          │                   │                   │
          └─────────────┬─────┴─────┬─────────────┘
                        │           │
                 Azure Service Bus / Event Grid
                        │
                 ┌──────┴───────────┐
                 │ Shared Storage   │
                 │ (Cosmos DB /     │
                 │  Blob Storage)   │
                 └──────────────────┘

Monitoring: Azure Monitor + App Insights
Secrets: Azure Key Vault
Images: Azure Container Registry
Deployment: AKS / Container Apps

📄 Sample Deployment YAML (AKS + Helm)

Here’s a simplified example of how you’d deploy controller and worker agents into AKS:

# values.yaml (Helm)
controller:
  image: myregistry.azurecr.io/controller-agent:latest
  replicas: 2
  resources:
    requests:
      cpu: "500m"
      memory: "512Mi"
    limits:
      cpu: "1"
      memory: "1Gi"

workers:
  - name: data-fetcher
    image: myregistry.azurecr.io/data-fetcher-agent:latest
    replicas: 3
  - name: analyzer
    image: myregistry.azurecr.io/analyzer-agent:latest
    replicas: 2
  - name: summarizer
    image: myregistry.azurecr.io/summarizer-agent:latest
    replicas: 2

# deployment.yaml (Helm template)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Chart.Name }}-{{ .Values.controller.name }}
spec:
  replicas: {{ .Values.controller.replicas }}
  selector:
    matchLabels:
      app: controller-agent
  template:
    metadata:
      labels:
        app: controller-agent
    spec:
      containers:
        - name: controller-agent
          image: {{ .Values.controller.image }}
          resources:
            requests:
              cpu: {{ .Values.controller.resources.requests.cpu }}
              memory: {{ .Values.controller.resources.requests.memory }}
            limits:
              cpu: {{ .Values.controller.resources.limits.cpu }}
              memory: {{ .Values.controller.resources.limits.memory }}
---
{{- range .Values.workers }}
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ $.Chart.Name }}-{{ .name }}
spec:
  replicas: {{ .replicas }}
  selector:
    matchLabels:
      app: {{ .name }}
  template:
    metadata:
      labels:
        app: {{ .name }}
    spec:
      containers:
        - name: {{ .name }}
          image: {{ .image }}
{{- end }}

🚀 End‑to‑End Flow

Build & push images → az acr build → Azure Container Registry.
Deploy Helm chart → helm install multi-agent ./chart.
Agents communicate via Service Bus/Event Grid.
Monitor with Application Insights.
Scale automatically with AKS HPA rules.

Excellent — let’s build out the Azure Bicep template so you can provision the entire environment (ACR, AKS, Service Bus, Key Vault, Monitor) in one go. This will give you an end‑to‑end infrastructure as code setup.

📄 Sample Bicep Template (multi‑agent app infra)

targetScope = 'resourceGroup'

@description('Name of the Azure Container Registry')
param acrName string = 'multiagentacr'

@description('Name of the AKS cluster')
param aksName string = 'multiagent-aks'

@description('Name of the Service Bus namespace')
param sbNamespace string = 'multiagent-sb'

@description('Name of the Key Vault')
param kvName string = 'multiagent-kv'

@description('Name of the Log Analytics workspace')
param logAnalyticsName string = 'multiagent-law'

@description('Location for all resources')
param location string = resourceGroup().location

// Azure Container Registry
resource acr 'Microsoft.ContainerRegistry/registries@2023-01-01-preview' = {
  name: acrName
  location: location
  sku: {
    name: 'Basic'
  }
  properties: {
    adminUserEnabled: true
  }
}

// Log Analytics Workspace
resource logAnalytics 'Microsoft.OperationalInsights/workspaces@2022-10-01' = {
  name: logAnalyticsName
  location: location
  properties: {
    sku: {
      name: 'PerGB2018'
    }
    retentionInDays: 30
  }
}

// AKS Cluster
resource aks 'Microsoft.ContainerService/managedClusters@2023-01-01' = {
  name: aksName
  location: location
  properties: {
    dnsPrefix: '${aksName}-dns'
    agentPoolProfiles: [
      {
        name: 'agentpool'
        count: 3
        vmSize: 'Standard_DS2_v2'
        osType: 'Linux'
        mode: 'System'
      }
    ]
    linuxProfile: {
      adminUsername: 'azureuser'
      ssh: {
        publicKeys: [
          {
            keyData: 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQ...'
          }
        ]
      }
    }
    servicePrincipalProfile: {
      clientId: 'YOUR-SP-CLIENT-ID'
      secret: 'YOUR-SP-SECRET'
    }
    addonProfiles: {
      omsagent: {
        enabled: true
        config: {
          logAnalyticsWorkspaceResourceID: logAnalytics.id
        }
      }
    }
  }
}

// Service Bus Namespace
resource sb 'Microsoft.ServiceBus/namespaces@2021-06-01-preview' = {
  name: sbNamespace
  location: location
  sku: {
    name: 'Standard'
    tier: 'Standard'
  }
}

// Key Vault
resource kv 'Microsoft.KeyVault/vaults@2022-07-01' = {
  name: kvName
  location: location
  properties: {
    tenantId: subscription().tenantId
    sku: {
      name: 'standard'
      family: 'A'
    }
    accessPolicies: []
  }
}

🚀 How to Deploy

Save the file as main.bicep.

Run:

az group create --name multiagent-rg --location eastus
az deployment group create --resource-group multiagent-rg --template-file main.bicep

This provisions:
- ACR → for storing agent images.
- AKS → for running multi‑agent workloads.
- Service Bus → for agent communication.
- Key Vault → for secrets.
- Log Analytics + Monitor → for observability.

🔄 Next Steps

Push your agent Docker images into ACR.
Deploy Helm chart (from earlier step) into AKS.
Configure agents to use Service Bus for messaging.
Store sensitive configs in Key Vault.
Monitor with Application Insights linked to Log Analytics.

Perfect — let’s design a CI/CD pipeline so your multi‑agent application can be built, pushed, and deployed into Azure AKS automatically. I’ll show you a GitHub Actions workflow (you could adapt it to Azure DevOps if you prefer).

⚙️ CI/CD Pipeline Overview

Trigger: On push to main or PR merge.
Build: Build Docker images for each agent.
Push: Push images to Azure Container Registry (ACR).
Deploy: Use kubectl or Helm to deploy into AKS.
Monitor: Integrate with Application Insights/Log Analytics.

📄 GitHub Actions Workflow Example

# .github/workflows/deploy.yml
name: Multi-Agent CI/CD

on:
  push:
    branches:
      - main

env:
  REGISTRY: multiagentacr.azurecr.io
  AKS_CLUSTER: multiagent-aks
  RESOURCE_GROUP: multiagent-rg

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout code
      uses: actions/checkout@v3

    - name: Log in to Azure
      uses: azure/login@v1
      with:
        creds: ${{ secrets.AZURE_CREDENTIALS }}

    - name: Log in to ACR
      run: az acr login --name $REGISTRY

    - name: Build and push Controller Agent
      run: |
        docker build -t $REGISTRY/controller-agent:latest ./controller
        docker push $REGISTRY/controller-agent:latest

    - name: Build and push Worker Agents
      run: |
        docker build -t $REGISTRY/data-fetcher-agent:latest ./workers/data-fetcher
        docker push $REGISTRY/data-fetcher-agent:latest
        docker build -t $REGISTRY/analyzer-agent:latest ./workers/analyzer
        docker push $REGISTRY/analyzer-agent:latest
        docker build -t $REGISTRY/summarizer-agent:latest ./workers/summarizer
        docker push $REGISTRY/summarizer-agent:latest

    - name: Set AKS context
      run: |
        az aks get-credentials --resource-group $RESOURCE_GROUP --name $AKS_CLUSTER

    - name: Deploy with Helm
      run: |
        helm upgrade --install multi-agent ./helm-chart \
          --set controller.image=$REGISTRY/controller-agent:latest \
          --set workers[0].image=$REGISTRY/data-fetcher-agent:latest \
          --set workers[1].image=$REGISTRY/analyzer-agent:latest \
          --set workers[2].image=$REGISTRY/summarizer-agent:latest

🔑 Secrets Required

AZURE_CREDENTIALS: JSON output from az ad sp create-for-rbac (Service Principal).
Docker images will be tagged and pushed to ACR.
Helm chart values updated automatically with latest image tags.

🚀 Deployment Flow

Developer pushes code → GitHub Actions triggers.
Pipeline builds Docker images for all agents.
Images pushed to ACR.
Helm deploys/updates AKS workloads.
Agents start communicating via Service Bus/Event Grid.
Logs flow into Application Insights.

Great — here’s the Azure DevOps pipeline version of the CI/CD flow we built earlier. This YAML will automate building your agents, pushing them to ACR, and deploying them into AKS using Helm.

📄 Azure DevOps Pipeline (azure-pipelines.yml)

trigger:
  branches:
    include:
      - main

variables:
  REGISTRY: multiagentacr.azurecr.io
  AKS_CLUSTER: multiagent-aks
  RESOURCE_GROUP: multiagent-rg
  IMAGE_TAG: $(Build.BuildId)

stages:
- stage: Build
  displayName: Build and Push Images
  jobs:
  - job: BuildPush
    pool:
      vmImage: 'ubuntu-latest'
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'AzureServiceConnection'
        scriptType: 'bash'
        scriptLocation: 'inlineScript'
        inlineScript: |
          az acr login --name $REGISTRY
          docker build -t $REGISTRY/controller-agent:$(IMAGE_TAG) ./controller
          docker push $REGISTRY/controller-agent:$(IMAGE_TAG)

          docker build -t $REGISTRY/data-fetcher-agent:$(IMAGE_TAG) ./workers/data-fetcher
          docker push $REGISTRY/data-fetcher-agent:$(IMAGE_TAG)

          docker build -t $REGISTRY/analyzer-agent:$(IMAGE_TAG) ./workers/analyzer
          docker push $REGISTRY/analyzer-agent:$(IMAGE_TAG)

          docker build -t $REGISTRY/summarizer-agent:$(IMAGE_TAG) ./workers/summarizer
          docker push $REGISTRY/summarizer-agent:$(IMAGE_TAG)

- stage: Deploy
  displayName: Deploy to AKS
  dependsOn: Build
  jobs:
  - job: HelmDeploy
    pool:
      vmImage: 'ubuntu-latest'
    steps:
    - task: AzureCLI@2
      inputs:
        azureSubscription: 'AzureServiceConnection'
        scriptType: 'bash'
        scriptLocation: 'inlineScript'
        inlineScript: |
          az aks get-credentials --resource-group $RESOURCE_GROUP --name $AKS_CLUSTER
          helm upgrade --install multi-agent ./helm-chart \
            --set controller.image=$REGISTRY/controller-agent:$(IMAGE_TAG) \
            --set workers[0].image=$REGISTRY/data-fetcher-agent:$(IMAGE_TAG) \
            --set workers[1].image=$REGISTRY/analyzer-agent:$(IMAGE_TAG) \
            --set workers[2].image=$REGISTRY/summarizer-agent:$(IMAGE_TAG)

🔑 Setup Requirements

Azure Service Connection: Create a service connection in Azure DevOps pointing to your subscription (used in azureSubscription above).
ACR & AKS: Already provisioned via the Bicep template we built earlier.
Helm chart: Stored in your repo under helm-chart/.
Secrets: Managed via Azure DevOps Library or Key Vault integration.

🚀 Workflow

Developer pushes code → Pipeline triggers.
Build stage → Docker images built & pushed to ACR.
Deploy stage → Helm upgrades AKS workloads with new images.
Agents start running and communicating via Service Bus.
Logs flow into Application Insights for monitoring.

Now we will develop a small multi‑agent application that can automatically handle the full deployment pipeline we’ve been discussing (infra provisioning, container builds, pushing to ACR, Helm deploy to AKS, monitoring setup). Let’s design this as a multi‑agent system where each agent has a clear responsibility, and together they orchestrate the end‑to‑end deployment.

🧩 Multi‑Agent Application Design

Agents & Roles

Infra Agent
- Provisions Azure resources (ACR, AKS, Service Bus, Key Vault, Monitor) using Bicep/ARM.
- Runs az deployment group create commands.
Build Agent
- Builds Docker images for each micro‑agent (controller, workers).
- Pushes images to ACR.
Deploy Agent
- Applies Helm charts to AKS.
- Updates image tags automatically.
Monitor Agent
- Configures Application Insights and Log Analytics.
- Ensures telemetry is wired up.
Coordinator Agent
- Orchestrates the workflow: triggers Infra → Build → Deploy → Monitor.
- Handles retries and error reporting.

⚙️ Implementation Approach

Framework: Python with AutoGen or Semantic Kernel (github.com in Bing) for agent orchestration.
Communication: Agents interact via async tasks or Azure Service Bus.
Deployment: Each agent runs as a container in AKS or locally during bootstrap.

📄 Example Python Skeleton

from autogen import AssistantAgent, UserProxyAgent

# Infra Agent
infra_agent = AssistantAgent(name="InfraAgent", system_message="Provision Azure infra with Bicep.")
# Build Agent
build_agent = AssistantAgent(name="BuildAgent", system_message="Build and push Docker images to ACR.")
# Deploy Agent
deploy_agent = AssistantAgent(name="DeployAgent", system_message="Deploy Helm charts to AKS.")
# Monitor Agent
monitor_agent = AssistantAgent(name="MonitorAgent", system_message="Configure monitoring and logging.")
# Coordinator
coordinator = UserProxyAgent(name="Coordinator", human_input_mode="NEVER")

# Define workflow
def deployment_workflow():
    coordinator.initiate_chat(infra_agent, message="Provision infra resources")
    coordinator.initiate_chat(build_agent, message="Build and push images")
    coordinator.initiate_chat(deploy_agent, message="Deploy Helm charts")
    coordinator.initiate_chat(monitor_agent, message="Setup monitoring")

if __name__ == "__main__":
    deployment_workflow()

🚀 How It Works

Coordinator Agent kicks off the workflow.
Infra Agent provisions infra via Azure CLI/Bicep.
Build Agent builds/pushes images.
Deploy Agent applies Helm charts.
Monitor Agent configures observability.
Workflow completes with a fully deployed multi‑agent app in AKS.

🔄 Next Step

To make this truly automatic, you can:

Package each agent as a container.
Deploy them into AKS with a controller agent orchestrating tasks.
Or run them locally as part of a CI/CD pipeline.

Let’s put this all together into a working prototype of a multi‑agent application that can automatically deploy the full Azure environment, build/push images, and deploy to AKS. I’ll give you a Python-based orchestration example where each agent is a class with a clear responsibility. You can extend this into containers later.

🧩 Multi‑Agent Python Prototype

import subprocess

class InfraAgent:
    def provision(self):
        print("🚀 Provisioning Azure infra...")
        subprocess.run([
            "az", "deployment", "group", "create",
            "--resource-group", "multiagent-rg",
            "--template-file", "main.bicep"
        ], check=True)

class BuildAgent:
    def build_and_push(self):
        print("🔨 Building and pushing Docker images...")
        agents = {
            "controller": "./controller",
            "data-fetcher": "./workers/data-fetcher",
            "analyzer": "./workers/analyzer",
            "summarizer": "./workers/summarizer"
        }
        registry = "multiagentacr.azurecr.io"
        for name, path in agents.items():
            image = f"{registry}/{name}-agent:latest"
            subprocess.run(["docker", "build", "-t", image, path], check=True)
            subprocess.run(["docker", "push", image], check=True)

class DeployAgent:
    def deploy(self):
        print("📦 Deploying agents to AKS...")
        registry = "multiagentacr.azurecr.io"
        subprocess.run([
            "az", "aks", "get-credentials",
            "--resource-group", "multiagent-rg",
            "--name", "multiagent-aks"
        ], check=True)
        subprocess.run([
            "helm", "upgrade", "--install", "multi-agent", "./helm-chart",
            "--set", f"controller.image={registry}/controller-agent:latest",
            "--set", f"workers[0].image={registry}/data-fetcher-agent:latest",
            "--set", f"workers[1].image={registry}/analyzer-agent:latest",
            "--set", f"workers[2].image={registry}/summarizer-agent:latest"
        ], check=True)

class MonitorAgent:
    def configure(self):
        print("📊 Configuring monitoring...")
        subprocess.run([
            "az", "monitor", "app-insights", "component", "create",
            "--app", "multiagent-app",
            "--location", "eastus",
            "--resource-group", "multiagent-rg"
        ], check=True)

class CoordinatorAgent:
    def __init__(self):
        self.infra = InfraAgent()
        self.build = BuildAgent()
        self.deploy = DeployAgent()
        self.monitor = MonitorAgent()

    def run_workflow(self):
        self.infra.provision()
        self.build.build_and_push()
        self.deploy.deploy()
        self.monitor.configure()
        print("✅ Multi-agent deployment complete!")

if __name__ == "__main__":
    CoordinatorAgent().run_workflow()

🚀 How to Use

Save this as multi_agent_deploy.py.
Ensure you have:
- Azure CLI installed and logged in (az login).
- Docker installed and running.
- Helm installed.
- Your main.bicep and helm-chart/ ready.
Run:
```
python multi_agent_deploy.py
```
The workflow will:
- Provision infra (ACR, AKS, Service Bus, Key Vault, Monitor).
- Build/push agent images.
- Deploy Helm chart to AKS.
- Configure monitoring.

🔄 Next Steps

Wrap each agent into its own container for true distributed execution.
Use Azure Service Bus for inter‑agent communication instead of sequential Python calls.
Add error handling and retries for robustness.

Excellent — let’s extend the prototype into a containerized multi‑agent application so each agent runs independently inside AKS. This way, the deployment itself is automated and self‑contained.

🧩 Containerized Multi‑Agent Setup

1. Dockerfiles for Each Agent

Example: InfraAgent

# controller/Dockerfile
FROM python:3.10-slim

WORKDIR /app
COPY infra_agent.py .

RUN pip install azure-cli

CMD ["python", "infra_agent.py"]

Repeat similar Dockerfiles for build_agent.py, deploy_agent.py, and monitor_agent.py.
Each agent script contains its logic (Azure CLI, Docker, Helm commands).

2. Kubernetes Manifests (AKS)

infra-agent-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: infra-agent
spec:
  replicas: 1
  selector:
    matchLabels:
      app: infra-agent
  template:
    metadata:
      labels:
        app: infra-agent
    spec:
      containers:
      - name: infra-agent
        image: multiagentacr.azurecr.io/infra-agent:latest
        env:
        - name: AZURE_SUBSCRIPTION_ID
          valueFrom:
            secretKeyRef:
              name: azure-secrets
              key: subscriptionId

build-agent-deployment.yaml, deploy-agent-deployment.yaml, monitor-agent-deployment.yaml follow the same pattern, each pointing to its respective image.

3. Coordinator Agent (Orchestrator)

You can run the CoordinatorAgent as a Job in Kubernetes:

apiVersion: batch/v1
kind: Job
metadata:
  name: coordinator-agent
spec:
  template:
    spec:
      containers:
      - name: coordinator
        image: multiagentacr.azurecr.io/coordinator-agent:latest
      restartPolicy: Never

This job triggers the workflow: Infra → Build → Deploy → Monitor.
Agents can communicate via Azure Service Bus or HTTP APIs inside the cluster.

4. Secrets & Config

Store credentials in Azure Key Vault or Kubernetes Secrets.
Example secret:

apiVersion: v1
kind: Secret
metadata:
  name: azure-secrets
type: Opaque
data:
  subscriptionId: <base64-encoded-value>
  clientId: <base64-encoded-value>
  clientSecret: <base64-encoded-value>

5. Deployment Flow

Build Docker images for each agent.

docker build -t multiagentacr.azurecr.io/infra-agent:latest ./infra
docker push multiagentacr.azurecr.io/infra-agent:latest

Apply manifests:

kubectl apply -f infra-agent-deployment.yaml
kubectl apply -f build-agent-deployment.yaml
kubectl apply -f deploy-agent-deployment.yaml
kubectl apply -f monitor-agent-deployment.yaml
kubectl apply -f coordinator-agent-job.yaml

Coordinator triggers workflow → agents execute tasks → full deployment automated.

✅ With this setup, you now have a self‑deploying multi‑agent system inside AKS. Each agent is containerized, scalable, and independently responsible for its part of the pipeline.

Let’s wrap everything into a Helm chart so you can deploy the entire multi‑agent system (infra, build, deploy, monitor, coordinator) with a single helm install command.

🏗️ Helm Chart Structure

multi-agent-chart/
├── Chart.yaml
├── values.yaml
├── templates/
│   ├── infra-agent-deployment.yaml
│   ├── build-agent-deployment.yaml
│   ├── deploy-agent-deployment.yaml
│   ├── monitor-agent-deployment.yaml
│   ├── coordinator-agent-job.yaml
│   └── _helpers.tpl

📄 Chart.yaml

apiVersion: v2
name: multi-agent
description: Helm chart for multi-agent deployment automation
version: 0.1.0
appVersion: "1.0"

📄 values.yaml

registry: multiagentacr.azurecr.io

infraAgent:
  image: infra-agent:latest
  replicas: 1

buildAgent:
  image: build-agent:latest
  replicas: 1

deployAgent:
  image: deploy-agent:latest
  replicas: 1

monitorAgent:
  image: monitor-agent:latest
  replicas: 1

coordinatorAgent:
  image: coordinator-agent:latest

📄 templates/infra-agent-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: infra-agent
spec:
  replicas: {{ .Values.infraAgent.replicas }}
  selector:
    matchLabels:
      app: infra-agent
  template:
    metadata:
      labels:
        app: infra-agent
    spec:
      containers:
      - name: infra-agent
        image: "{{ .Values.registry }}/{{ .Values.infraAgent.image }}"

📄 templates/build-agent-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: build-agent
spec:
  replicas: {{ .Values.buildAgent.replicas }}
  selector:
    matchLabels:
      app: build-agent
  template:
    metadata:
      labels:
        app: build-agent
    spec:
      containers:
      - name: build-agent
        image: "{{ .Values.registry }}/{{ .Values.buildAgent.image }}"

📄 templates/deploy-agent-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-agent
spec:
  replicas: {{ .Values.deployAgent.replicas }}
  selector:
    matchLabels:
      app: deploy-agent
  template:
    metadata:
      labels:
        app: deploy-agent
    spec:
      containers:
      - name: deploy-agent
        image: "{{ .Values.registry }}/{{ .Values.deployAgent.image }}"

📄 templates/monitor-agent-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: monitor-agent
spec:
  replicas: {{ .Values.monitorAgent.replicas }}
  selector:
    matchLabels:
      app: monitor-agent
  template:
    metadata:
      labels:
        app: monitor-agent
    spec:
      containers:
      - name: monitor-agent
        image: "{{ .Values.registry }}/{{ .Values.monitorAgent.image }}"

📄 templates/coordinator-agent-job.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: coordinator-agent
spec:
  template:
    spec:
      containers:
      - name: coordinator
        image: "{{ .Values.registry }}/{{ .Values.coordinatorAgent.image }}"
      restartPolicy: Never

🚀 Deployment

Package and install:

helm install multi-agent ./multi-agent-chart

Helm will deploy all agents (infra, build, deploy, monitor) plus the coordinator job.
Coordinator triggers the workflow → agents execute tasks → full deployment automated.

Great — let’s extend the Helm chart with Azure Service Bus integration so your agents can communicate asynchronously inside AKS. This way, instead of just running sequentially, they’ll publish/subscribe to topics and queues for coordination.

🧩 Updated Helm Chart Structure

multi-agent-chart/
├── Chart.yaml
├── values.yaml
├── templates/
│   ├── infra-agent-deployment.yaml
│   ├── build-agent-deployment.yaml
│   ├── deploy-agent-deployment.yaml
│   ├── monitor-agent-deployment.yaml
│   ├── coordinator-agent-job.yaml
│   ├── servicebus-secret.yaml
│   ├── servicebus-configmap.yaml

📄 values.yaml (extended)

registry: multiagentacr.azurecr.io

serviceBus:
  namespace: multiagent-sb
  connectionString: "" # injected via secret

infraAgent:
  image: infra-agent:latest
  replicas: 1

buildAgent:
  image: build-agent:latest
  replicas: 1

deployAgent:
  image: deploy-agent:latest
  replicas: 1

monitorAgent:
  image: monitor-agent:latest
  replicas: 1

coordinatorAgent:
  image: coordinator-agent:latest

📄 templates/servicebus-secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: servicebus-secret
type: Opaque
stringData:
  connectionString: {{ .Values.serviceBus.connectionString | quote }}

📄 templates/servicebus-configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: servicebus-config
data:
  namespace: {{ .Values.serviceBus.namespace }}

📄 Example Agent Deployment with Service Bus Integration

build-agent-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: build-agent
spec:
  replicas: {{ .Values.buildAgent.replicas }}
  selector:
    matchLabels:
      app: build-agent
  template:
    metadata:
      labels:
        app: build-agent
    spec:
      containers:
      - name: build-agent
        image: "{{ .Values.registry }}/{{ .Values.buildAgent.image }}"
        env:
        - name: SERVICEBUS_CONNECTION
          valueFrom:
            secretKeyRef:
              name: servicebus-secret
              key: connectionString
        - name: SERVICEBUS_NAMESPACE
          valueFrom:
            configMapKeyRef:
              name: servicebus-config
              key: namespace

🔄 Communication Flow with Service Bus

Coordinator Agent publishes a message to a topic (e.g., deployment-steps).
Infra Agent subscribes to infra queue → provisions infra → publishes completion event.
Build Agent listens on build queue → builds/pushes images → publishes completion event.
Deploy Agent listens on deploy queue → applies Helm → publishes completion event.
Monitor Agent listens on monitor queue → configures monitoring → publishes completion event.

This makes the workflow event-driven and resilient.

🚀 Deployment

Inject your Service Bus connection string into Helm:

helm install multi-agent ./multi-agent-chart \
  --set serviceBus.connectionString="Endpoint=sb://multiagent-sb.servicebus.windows.net/...;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=..."

All agents will be deployed with Service Bus credentials and namespace.
Agents communicate asynchronously via topics/queues.

Let’s wire up the agents’ communication logic using the Azure Service Bus SDK for Python. This will let each agent send and receive messages asynchronously via queues/topics, making the system event‑driven instead of sequential.

🧩 Install Dependencies

pip install azure-servicebus

📄 Example Agent Code

Coordinator Agent (Publisher)

from azure.servicebus import ServiceBusClient, ServiceBusMessage

CONNECTION_STR = "<your-servicebus-connection-string>"
QUEUE_NAME = "infra-queue"

def send_message():
    with ServiceBusClient.from_connection_string(CONNECTION_STR) as client:
        sender = client.get_queue_sender(queue_name=QUEUE_NAME)
        with sender:
            msg = ServiceBusMessage("Provision infra")
            sender.send_messages(msg)
            print("✅ Coordinator sent: Provision infra")

if __name__ == "__main__":
    send_message()

Infra Agent (Subscriber)

from azure.servicebus import ServiceBusClient

CONNECTION_STR = "<your-servicebus-connection-string>"
QUEUE_NAME = "infra-queue"

def receive_message():
    with ServiceBusClient.from_connection_string(CONNECTION_STR) as client:
        receiver = client.get_queue_receiver(queue_name=QUEUE_NAME)
        with receiver:
            for msg in receiver:
                print(f"📥 InfraAgent received: {msg.body}")
                # Run infra provisioning logic here (az deployment group create ...)
                receiver.complete_message(msg)

if __name__ == "__main__":
    receive_message()

Build Agent (Subscriber + Publisher)

from azure.servicebus import ServiceBusClient, ServiceBusMessage

CONNECTION_STR = "<your-servicebus-connection-string>"
QUEUE_NAME = "build-queue"

def receive_and_build():
    with ServiceBusClient.from_connection_string(CONNECTION_STR) as client:
        receiver = client.get_queue_receiver(queue_name=QUEUE_NAME)
        with receiver:
            for msg in receiver:
                print(f"📥 BuildAgent received: {msg.body}")
                # Run docker build/push logic here
                receiver.complete_message(msg)

                # Publish completion event
                sender = client.get_queue_sender(queue_name="deploy-queue")
                with sender:
                    sender.send_messages(ServiceBusMessage("Build complete"))
                    print("✅ BuildAgent published: Build complete")

if __name__ == "__main__":
    receive_and_build()

Deploy Agent (Subscriber)

from azure.servicebus import ServiceBusClient

CONNECTION_STR = "<your-servicebus-connection-string>"
QUEUE_NAME = "deploy-queue"

def receive_and_deploy():
    with ServiceBusClient.from_connection_string(CONNECTION_STR) as client:
        receiver = client.get_queue_receiver(queue_name=QUEUE_NAME)
        with receiver:
            for msg in receiver:
                print(f"📥 DeployAgent received: {msg.body}")
                # Run helm upgrade/install logic here
                receiver.complete_message(msg)

if __name__ == "__main__":
    receive_and_deploy()

Monitor Agent (Subscriber)

from azure.servicebus import ServiceBusClient

CONNECTION_STR = "<your-servicebus-connection-string>"
QUEUE_NAME = "monitor-queue"

def receive_and_monitor():
    with ServiceBusClient.from_connection_string(CONNECTION_STR) as client:
        receiver = client.get_queue_receiver(queue_name=QUEUE_NAME)
        with receiver:
            for msg in receiver:
                print(f"📥 MonitorAgent received: {msg.body}")
                # Configure Application Insights / Log Analytics here
                receiver.complete_message(msg)

if __name__ == "__main__":
    receive_and_monitor()

🔄 Workflow Example

Coordinator Agent publishes "Provision infra" → infra-queue.
Infra Agent provisions infra → publishes "Infra complete" → build-queue.
Build Agent builds/pushes images → publishes "Build complete" → deploy-queue.
Deploy Agent applies Helm → publishes "Deploy complete" → monitor-queue.
Monitor Agent configures monitoring → workflow ends.

🚀 Next Step

You can containerize each agent with its own Dockerfile and deploy them via the Helm chart we built earlier. Each agent will subscribe to its queue, perform its task, and publish the next step — giving you a fully automated, event‑driven multi‑agent deployment system on Azure.

Let’s extend the automation so your Helm chart + Bicep template not only deploys the agents but also provisions Service Bus queues/topics automatically. This way, you won’t need to manually create messaging infrastructure — it’s fully declarative.

🧩 Updated Bicep Template (Service Bus Queues/Topics)

Add this to your main.bicep:

// Service Bus Namespace
resource sb 'Microsoft.ServiceBus/namespaces@2021-06-01-preview' = {
  name: sbNamespace
  location: location
  sku: {
    name: 'Standard'
    tier: 'Standard'
  }
}

// Queues for each agent
resource infraQueue 'Microsoft.ServiceBus/namespaces/queues@2021-06-01-preview' = {
  parent: sb
  name: 'infra-queue'
  properties: {
    enablePartitioning: true
  }
}

resource buildQueue 'Microsoft.ServiceBus/namespaces/queues@2021-06-01-preview' = {
  parent: sb
  name: 'build-queue'
  properties: {
    enablePartitioning: true
  }
}

resource deployQueue 'Microsoft.ServiceBus/namespaces/queues@2021-06-01-preview' = {
  parent: sb
  name: 'deploy-queue'
  properties: {
    enablePartitioning: true
  }
}

resource monitorQueue 'Microsoft.ServiceBus/namespaces/queues@2021-06-01-preview' = {
  parent: sb
  name: 'monitor-queue'
  properties: {
    enablePartitioning: true
  }
}

This provisions the namespace + queues for Infra, Build, Deploy, and Monitor agents.

📄 Helm Chart Integration

values.yaml

serviceBus:
  namespace: multiagent-sb
  connectionString: "" # injected via secret
  queues:
    infra: infra-queue
    build: build-queue
    deploy: deploy-queue
    monitor: monitor-queue

templates/servicebus-secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: servicebus-secret
type: Opaque
stringData:
  connectionString: {{ .Values.serviceBus.connectionString | quote }}

Example Agent Deployment (Build Agent)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: build-agent
spec:
  replicas: {{ .Values.buildAgent.replicas }}
  selector:
    matchLabels:
      app: build-agent
  template:
    metadata:
      labels:
        app: build-agent
    spec:
      containers:
      - name: build-agent
        image: "{{ .Values.registry }}/{{ .Values.buildAgent.image }}"
        env:
        - name: SERVICEBUS_CONNECTION
          valueFrom:
            secretKeyRef:
              name: servicebus-secret
              key: connectionString
        - name: QUEUE_NAME
          value: {{ .Values.serviceBus.queues.build }}

Each agent gets its queue name injected via Helm values.

🚀 Deployment Flow

Run Bicep → provisions ACR, AKS, Service Bus namespace + queues.
Helm install → deploys all agents with Service Bus credentials + queue names.
Agents subscribe/publish to their queues automatically.
Workflow becomes event‑driven: Infra → Build → Deploy → Monitor.

✅ With this, you now have a self‑deploying, event‑driven multi‑agent system on Azure.
The infra, messaging, and agents are all provisioned declaratively.

It will help to gain more knowledge https://learn.microsoft.com/en-us/azure/devops/pipelines/?view=azure-devops