Agent workloads can sometimes be an awkward fit for the compute we would usually reach for. They can be bursty (a synthesis run spikes, then nothing for an hour), some of them are cadence-driven (a follow-up agent that wakes every 30 days), and a few run long enough that a request-response timeout is meaningless. Put that on always-on container replicas and you pay for a lot of idle.

Microsoft Foundry Hosted Agents went generally available in July 2026, and it is built for that shape.

I built a service (product) that takes standard methodologies and frameworks, then supports them with agents (without giving away too much, I will keep this general). Six agents ran on Microsoft Foundry Hosted Agents, and one ran in a sidecar container.

This post is about the hosting decisions, protocol choices, and what I learnt while building that service, where the agents were built with Microsoft Agent Framework in Python.

It also builds on a few related posts: Get Ahead with Self-Hosted Agents and Container Apps Jobs, Getting Started with Azure Developer CLI (azd), and Running Azure SRE Agent for AKS and Drasi Operations.

In short: this is a production story about choosing the right compute and protocol for each agent shape, not a generic tour of features.

TL;DR​

• Hosted Agents are excellent for bursty or scheduled workloads.
• Use Responses only when you genuinely need conversation history.
• Most task-oriented agents are better suited to Invocations.
• Size compute per agent rather than per application.
• Agents designed around in-process callbacks will not migrate cleanly.

I was setting up Application Gateway for Containers (AGC) as the ingress layer for a project cluster. The AKS add-on makes it look straightforward in Bicep - enable it, deploy your Gateway and HTTPRoute manifests, done. What I ran into instead was a version deadlock between two managed add-ons that left the Gateway stuck at PROGRAMMED: Unknown for twelve hours and Front Door returning 504 the whole time.

This is what happened, why, and how I got out of it.

Update (2026-07-23): Microsoft has clarified the add-on behavior and support matrix. If you use the AKS add-on path, ALB controller versions are pinned by cluster version + Managed Gateway API bundle support. See the official matrix: Supported Kubernetes versions for Gateway API bundle versions.

I had been building out a Fan Intelligence proof-of-technology for the FIFA World Cup 2026, and one of the things I wanted to get right from the start was the deployment model. When you have millions of fans receiving real-time notifications during a live match, the last thing you want is a bad deploy taking down a region.

The default approach for a lot of Kubernetes projects is kubectl apply and hoping for the best. That works for a dev cluster. It does not work when your RTO is measured in minutes and your blast radius spans multiple continents.

This post covers the ringed deployment pipeline I landed on: Azure Developer CLI (azd) for infrastructure and app deployment, Bicep for the infrastructure layer, Helm for the application layer, and ArgoRollouts for canary releases. No manual kubectl apply in the deployment path, automated rollback on error spikes, and a full audit trail from commit to running pods.

Even though the examples come from a Fan Intelligence workload, the pattern is platform-agnostic and can be reused for any AKS-based service that needs safe progressive delivery.

With the FIFA World Cup 2026 underway, I thought it would be a good chance to develop a World Cup 2026 fan intelligence platform in a regional deployment stamp pattern, but could also be scaled globally across other regions and locales.

This blog articles, covers the architecture, the 12 AI agent types, the Drasi event pipeline, the AKS configuration, that I used! This solution is also open source and you can deploy/modify and learn it from it all from scratch with azd (note it won't be cheap to run due to the resources deployed and needed, I was aiming for full production sizing and resourcing vs small proof of concept).

I've been spending time with LiteLLM and wanted to see how far I could take it as a self-hosted LLM gateway on Azure Kubernetes Service. The goal was simple: build a deployment that you can spin up with a single azd up command, with all the production bits - private networking, Redis caching, PostgreSQL for spend tracking, and a proper ingress with automatic TLS.

Turns out it works pretty well. Here's what I built and what I found.