Skip to content

Add blog post: Running multi-agent orchestration frameworks on AKS - #5880

Draft
sabbour wants to merge 1 commit into
masterfrom
agentweaver-demo/blog-multi-agent-aks
Draft

Add blog post: Running multi-agent orchestration frameworks on AKS#5880
sabbour wants to merge 1 commit into
masterfrom
agentweaver-demo/blog-multi-agent-aks

Conversation

@sabbour

@sabbour sabbour commented Jul 28, 2026

Copy link
Copy Markdown
Contributor

Adds a new community blog post, "Running multi-agent orchestration frameworks on AKS," under website/blog/ following the existing YYYY-MM-DD-slug/index.md directory + frontmatter convention (title/date/description/authors/tags, <!-- truncate --> fold).

The post is a vendor-neutral, practitioner-focused walkthrough of the patterns that matter when running multi-agent AI orchestration frameworks (AutoGen, CrewAI, LangGraph, Semantic Kernel, etc.) on Azure Kubernetes Service:

  • Deployment — per-role Deployments, orchestrator behind its own Service, one-shot work as Jobs, sandboxed tool-execution sidecars
  • Scaling — KEDA / queue-depth autoscaling instead of CPU-based HPA, GPU vs CPU node pools, scale-to-zero
  • Networking — service mesh (Istio) mTLS for agent-to-agent traffic, egress allow-listing / AI gateway for external LLM & tool calls
  • State — stateless pods with externalized memory (Redis / DB / vector store) vs StatefulSets + checkpointing
  • Security — per-role workload identity, code-exec sandboxing, Key Vault CSI secrets, prompt-injection defense
  • Cost — token spend as the dominant cost, caching/dedup at the orchestrator, spot node pools, per-agent cost attribution

Author key (brian-redmond) and tags (ai, agent, scaling, best-practices) are validated against the repo's authors.yml / tags.yml.

Opening for review.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds a new Docusaurus community blog post under website/blog/ that explains practical deployment, scaling, networking, state, security, and cost patterns for running multi-agent orchestration frameworks on Azure Kubernetes Service (AKS).

Changes:

  • Introduces a new post: “Running Multi-Agent Orchestration Frameworks on AKS” with front matter (title/date/description/authors/tags).
  • Documents recommended Kubernetes patterns for multi-agent workloads (per-role Deployments/Services/Jobs, KEDA-driven scaling, service mesh + egress controls, externalized state, workload identity, and cost controls).
Comment on lines +10 to +14
Multi-agent AI systems are moving fast from experimental notebooks into production services. Instead of a single model call, these systems coordinate several specialized agents—planners, researchers, coders, critics—that collaborate to complete a task. That shift changes the infrastructure problem: you're no longer serving one stateless model endpoint, you're operating a distributed system with its own scaling, networking, state, and security requirements. Kubernetes, and Azure Kubernetes Service (AKS) in particular, is a natural home for that kind of workload.

<!-- truncate -->

This post walks through the patterns that matter most when running a multi-agent orchestration framework on AKS: how to deploy, scale, network, secure, and pay for the system.
Comment on lines +12 to +16
<!-- truncate -->

This post walks through the patterns that matter most when running a multi-agent orchestration framework on AKS: how to deploy, scale, network, secure, and pay for the system.

## What multi-agent orchestration looks like in practice

- **Assign distinct managed identities per agent role** using AKS workload identity, so a compromised tool-executing agent doesn't inherit the planner's permissions.
- **Sandbox any agent that executes generated code or shell commands.** Give it a restrictive security context, a read-only root filesystem, dropped capabilities, and ideally stronger isolation such as gVisor or confidential containers—never run it in the same container as the reasoning logic.
- **Store API keys and credentials in a secret store**, such as Azure Key Vault via the CSI Secret Store driver, rather than baking them into images or environment variables.
@sabbour
sabbour marked this pull request as draft July 28, 2026 20:22
@sabbour

sabbour commented Jul 28, 2026

Copy link
Copy Markdown
Contributor Author

Please ignore. This is part of a test.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

2 participants