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
mainor 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 fromaz 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
azureSubscriptionabove). - 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 createcommands.
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.bicepandhelm-chart/ready.
- Azure CLI installed and logged in (
- 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
infraqueue → provisions infra → publishes completion event. - Build Agent listens on
buildqueue → builds/pushes images → publishes completion event. - Deploy Agent listens on
deployqueue → applies Helm → publishes completion event. - Monitor Agent listens on
monitorqueue → 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
