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

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants