AI

Do you need to train a model? Which Azure services fit your application? A reading guide to my five-part AI on Azure series.

Architecture diagrams are useful, but they eventually have to become files that run together. In this tutorial I build one complete vertical slice of a personal operations assistant, first on a Windows workstation with no Azure dependency, then on Azure Container Apps with Azure OpenAI and Azure AI Search. The companion implementation is in labs/personal-assistant in my agentic-infra-handbook repository. The commands and snippets below match that lab. The lab’s README also has its own step-by-step Azure deployment walkthrough, covering App Registration, the AZD environment, callback registration, validation, and cleanup as a standalone reference. ...

Azure AI Foundry: from zero to production What I cover when a customer asks “we want to build AI applications on Azure, where do we start?” TL;DR: Azure AI Foundry is the unified platform for building AI apps on Azure. Start with Standard PAYGO, use Priority Processing selectively when latency matters but traffic is bursty, and move predictable baseline traffic to PTU when utilization exceeds 60-70%. Use ptucalc.com to model your costs before committing. ...

From reactive firefighting to proactive operations: custom skills for Azure SRE Agent TL;DR: Azure SRE Agent is great at reactive incident response, but doesn’t cover proactive operations out of the box. I built an open-source pack of 8 custom skills that add governance audits, FinOps reporting, capacity planning, postmortems, and more. Combined with Scheduled Investigations, they move your operations from reactive to proactive. How a customer conversation revealed the gap between what Azure SRE Agent does out of the box, and what production teams actually need. ...

You’ve probably used MCP from the host side already. This post is the other angle: what is actually on the wire. If the MCP 101 post was the architecture diagram, this one is the packet trace. The short version is that MCP is JSON-RPC 2.0 plus capability discovery, per-request metadata, and two standard transports. As of protocol version 2026-07-28, the core is stateless. If LSP standardized editor-to-language-server traffic, MCP does the same for host-to-tool-server traffic. ...

Chapter 5: Governance on Microsoft Foundry The previous four posts built agents I designed myself, so I could still keep the whole thing in my head. That arrangement lasts right up until another team stands up its own agent on the same platform. Then the question stops being “is this tool safe” and becomes “how do I know what is running, where, and with which permissions?” That is the point where governance stops being a nice habit and becomes table stakes. ...

Chapter 4: Multi-Agent Orchestration So far the series has built two separate things: in post 1, an agent that talks to AKS via aks-mcp to diagnose the cluster; in posts 2 and 3, a watchdog that watches TPM consumption on Azure OpenAI and decides how urgent an alert should be. Both are useful on their own. Together, they still leave the first SRE question hanging in the air: when token consumption jumps out of nowhere, did somebody deploy something? In most teams, that answer still lives in two browser tabs and one annoyed human. ...

Chapter 3: From Script to Agent In the previous post, the Azure OpenAI quota watchdog was a script with if pct_of_tpm > 0.8: alert. That works, but it has the same flaw every blunt monitoring rule has: context does not exist. A batch job that predictably eats 90% of TPM for 10 minutes at month-end looks identical to an agent gone feral and burning tokens all afternoon. Both cross the threshold. Only one should wake somebody up. ...

Chapter 2: The Deterministic 429 Watchdog In the previous post I explained what MCP is and how an agent decides its next move from the tools available. Now for something you could actually ship over a weekend: an MCP server that watches token consumption on your Azure OpenAI or Foundry deployment and warns you on Slack or email before the 429 lands in production. tl;dr Watch Azure Monitor metrics before the client hits the first 429. Start with a deterministic threshold plus a rising-trend check. Add agent reasoning later, after the telemetry and alert path prove they work. Why this is subtler than it looks The first reaction from anyone who’s never been bitten by a 429 is “easy, just measure usage and compare it to the quota.” The problem is that TPM (tokens per minute) and RPM (requests per minute) on Azure OpenAI are evaluated over short rolling windows, not a smooth average across the minute. That means you can blow the limit even while staying “under quota” in aggregate, simply because requests arrived in a burst instead of spread out. That’s why teams report 429s “even within the documented limit”: the problem isn’t total volume, it’s distribution over time. ...

You build a RAG pipeline, connect it to Azure OpenAI, and the answers come back… meh. Generic. Sometimes it ignores the context you sent. Sometimes it makes things up. The model is powerful, but input quality usually determines most of the result. Context engineering is the discipline of assembling that input so the model gives you what you actually need. It is not just “prompt engineering” with a fresher label. It is engineering: structure, constraints, and trade-offs. ...