The August Azure OpenAI post covered calling models well. Between calling a model and running an AI product sits a platform layer, projects, model choice, agent orchestration, evaluation, tracing, and Azure AI Foundry is Microsoft’s consolidation of that layer into something a platform team can govern the way this series governs everything else.

Hubs, Projects, and the Governance Shape

The resource model mirrors the landing zone thinking: a hub carries the shared, governed plumbing, the network isolation, the managed identity, the connections to storage, Key Vault, and the AI Search from two days ago, and projects hang off it as the team workspaces where development happens. That split is the point: the platform team hardens the hub once (private endpoints, outbound rules, approved connections), and every project inherits the posture, the subscription vending pattern from August replayed at the AI layer. Model deployments, content filters, and quotas administer centrally, so “which teams use which models with which safety configuration” is an inventory query, not an interview series.

The Catalog and the Agent Layer

The model catalog is broader than OpenAI: frontier models alongside open weight families deployable as serverless APIs (pay per token, no infrastructure) or managed compute (your capacity, your isolation), and the practical selection method is benchmark driven, run your evaluation set against three candidates and let the numbers and the unit economics choose, because model loyalty is not an architecture. The agent service is the orchestration layer: agents defined with instructions, tools (code interpreter, function calls into your APIs behind the APIM patterns, retrieval against your indexes), and the operational scaffolding, threads, state, tracing, that every team otherwise rebuilds badly. The multi agent patterns, an orchestrator delegating to specialized agents, are genuinely useful and genuinely easy to overbuild; the rule from the rest of this series transfers intact, complexity is bought against a named requirement, and a single agent with good tools beats a committee of agents with vague ones.

Evaluation and Tracing: The Discipline That Makes It Real

AI applications regress invisibly, a prompt tweak, a model version bump, a retrieval change, and the answer quality moves with no compiler error. Foundry’s evaluation framework makes the regression test suite: datasets of real queries, scored automatically on groundedness, relevance, coherence, and your custom criteria (LLM as judge with human calibration), run in the pipeline on every change to prompt, model, or index, exactly where the Terraform tests from October sit for infrastructure. Tracing completes the loop: every request’s full path, prompt, retrieved chunks, tool calls, tokens, latency, captured and queryable, feeding Application Insights beside everything else, so the production question “why did it answer that” has forensics instead of shrugs. Add the content safety filters tuned per use case (tomorrow’s companion topic in this arc), cost per conversation on the FinOps dashboards, and provisioned throughput reserved for the workloads whose latency matters, and AI applications join the estate as governed citizens: private, identified, evaluated, traced, and billed to an owner, which is this series’ definition of production.

Cheers
Osama