{"id":127,"date":"2026-07-23T20:35:08","date_gmt":"2026-07-23T20:35:08","guid":{"rendered":"https:\/\/www.tellpunk.it\/?p=127"},"modified":"2026-07-23T22:51:13","modified_gmt":"2026-07-23T22:51:13","slug":"azure-foundry-ai-103","status":"publish","type":"post","link":"https:\/\/www.tellpunk.it\/en\/azure-foundry-ai-103\/","title":{"rendered":"AI-103 Study Log #1: Voice Claims Intake on Microsoft Foundry"},"content":{"rendered":"

Part 1 of a series documenting the road to the Azure AI Apps and Agents Developer Associate certification (Exam AI-103), one working lab at a time.<\/em><\/p>\n\n\n\n

Why this project<\/h2>\n\n\n\n

Microsoft retired exam AI-102 on June 30, 2026 and replaced it with AI-103, “Developing AI Apps and Agents on Azure” \u2014 a certification rebuilt around Microsoft Foundry, agentic workflows, and the modern Azure AI SDKs.<\/p>\n\n\n\n

Rather than studying it from slides, I am preparing it by building four portfolio labs with an insurance and regulated-industry flavor: a multi-agent claims triage system, an ESG report intelligence pipeline, a visual damage assessment tool, and the subject of this article \u2014 a voice claims intake pipeline.<\/p>\n\n\n\n

The voice lab is deliberately the smallest of the four. Its job is to establish the working conventions of the whole monorepo (auth, configuration, cost discipline, teardown scripts) while covering the Text Analysis & Speech domain of the exam.<\/p>\n\n\n\n

The plan on paper was simple: a caller reports a car accident, speech-to-text transcribes the call, a language model extracts a structured claim record, a sentiment pass scores urgency, and text-to-speech reads back a confirmation.<\/p>\n\n\n\n

Almost none of it survived contact with the platform as designed \u2014 and that is exactly what makes it worth writing up.<\/p>\n\n\n\n

\"Microsoft
The Microsoft Foundry portal home, the starting point for every lab in this series.<\/figcaption><\/figure>\n\n\n\n

Setting up from zero<\/h2>\n\n\n\n

The environment started from a brand-new Azure free account: one Foundry project (ai103-foundry<\/em>, Sweden Central), one resource group (rg-ai103-labs<\/em>), one Speech resource on the free F0 tier.<\/p>\n\n\n\n

A single Foundry project hosts all four labs \u2014 projects in Foundry are a boundary for teams, RBAC, and environments, and a solo learner on a single environment gains nothing by fragmenting quota and endpoints across several of them.<\/p>\n\n\n\n

\"Foundry
Custom project creation: one project, one region, one resource group for all four labs.<\/figcaption><\/figure>\n\n\n\n
\"\"
The freshly created project overview, with the \/openai-capable endpoints the SDK migration will later depend on.<\/figcaption><\/figure>\n\n\n\n

Authentication was keyless from day one: az login<\/em> plus a Foundry User<\/em> role assignment scoped to the resource group, consumed in code through DefaultAzureCredential<\/em>.<\/p>\n\n\n\n

One practical footnote for personal Microsoft accounts: role assignment by e-mail fails, because in Entra ID a Gmail-based identity lives under an external name like user_gmail.com#EXT#@tenant.onmicrosoft.com<\/em>. Assigning by object ID (az ad signed-in-user show –query id<\/em>) sidesteps the lookup entirely.<\/p>\n\n\n\n

A second footnote: the RBAC roles were renamed mid-2026, so Azure AI User<\/em> no longer exists \u2014 the role is now Foundry User<\/em>.<\/p>\n\n\n\n

\"\"
Role assignment by object ID \u2014 the workaround for personal-account e-mail lookups (IDs redacted).<\/figcaption><\/figure>\n\n\n\n
\"Azure
The only non-Foundry resource: a free-tier F0 Speech service in the same resource group.<\/figcaption><\/figure>\n\n\n\n
\"Azure
The entire lab footprint: one Foundry resource, one project, one F0 Speech service in rg-ai103-labs.<\/figcaption><\/figure>\n\n\n\n

The quota maze<\/h2>\n\n\n\n

The first real lesson had nothing to do with AI: it was learning to read the Quota page. My initial model deployments failed with “not available due to insufficient quota,” which felt terminal until the numbers made sense.<\/p>\n\n\n\n

Quota in Foundry is allocated per model, per deployment SKU, and per region \u2014 and the display reads used\/available<\/em>. A row showing 0\/50K TPM<\/em> is not a disabled model; it is fifty thousand tokens per minute of untouched capacity. A row showing 0\/0<\/em> is the actual dead end.<\/p>\n\n\n\n

\"Microsoft
The Foundry Quota page, where deployment failures start making sense.<\/figcaption><\/figure>\n\n\n\n

On a trial subscription the pattern was stark: every interactive chat model had zero Global Standard quota, while a handful of regional Standard SKUs and one unexpected model had real allocations.<\/p>\n\n\n\n

The default deployment flow (“recommended settings”) targets Global Standard, which explains why it failed silently against models whose quota lived on the regional SKU. Custom deployment settings, with the SKU chosen deliberately and the TPM limit set low, are the way through.<\/p>\n\n\n\n

\"Foundry
The deploy menu: “recommended settings” targets Global Standard \u2014 custom settings are the way through.<\/figcaption><\/figure>\n\n\n\n

Deprecation roulette<\/h2>\n\n\n\n

The second lesson was about model lifecycle. Between the writing of my study plan and the actual deployment attempt, gpt-4o-mini<\/em> had entered deprecation \u2014 visible in the catalog, blocked for new deployments. Its natural successor gpt-4.1-mini<\/em> had quota available but returned ServiceModelDeprecating<\/em> on deployment.<\/p>\n\n\n\n

The catalog’s “Lifecycle” field, not the model’s fame, is what decides whether you can build on it: deprecated<\/em> means no new deployments while existing ones keep working; retired<\/em> means the API returns errors. That distinction is literally exam material in the Plan & Manage domain, and I got to learn it by collision.<\/p>\n\n\n\n

\"Foundry
Eleven thousand models in the catalog; the Lifecycle filter is the one that matters.<\/figcaption><\/figure>\n\n\n\n
\"Model
gpt-4o-mini in the catalog: deprecated, closed to new deployments.<\/figcaption><\/figure>\n\n\n\n
\"ServiceModelDeprecating
Quota available, deployment refused: ServiceModelDeprecating in the wild.<\/figcaption><\/figure>\n\n\n\n

The only model that satisfied both conditions \u2014 generally available and quota above zero \u2014 was gpt-audio-mini<\/em>, an audio-first chat model with 30K TPM of Global Standard allocation. Not the model anyone would pick for a text pipeline. It turned out to be the most interesting decision of the lab.<\/p>\n\n\n\n

\"gpt-audio-mini
The unlikely winner: gpt-audio-mini, generally available and with real quota.<\/figcaption><\/figure>\n\n\n\n

When the model refuses your architecture<\/h2>\n\n\n\n

With the classic pipeline wired up (Speech STT feeding text into the model), the first end-to-end run failed with an unambiguous message: “This model requires that either input content or output modality contain audio.”<\/em> An audio-native model rejects text-only requests.<\/p>\n\n\n\n

The workaround would have been swapping models; the better move was restructuring the lab to match the model: the WAV file now goes directly into the chat completion as an input_audio<\/em> content part, and gpt-audio-mini<\/em> performs transcription, structured extraction, and sentiment scoring in a single call.<\/p>\n\n\n\n

The separate STT stage remains in the repo as the “classic pipeline,” deliberately kept for a future A\/B comparison against a text model \u2014 which is precisely the kind of architectural trade-off (dedicated Speech services versus multimodal model) the exam’s speech domain asks about.<\/p>\n\n\n\n

The test audio itself is synthesized: Azure Speech TTS on the free tier reads a fictional claim call transcript into a 16 kHz mono WAV. The pipeline therefore runs end to end on entirely synthetic data \u2014 a non-negotiable constraint for a portfolio that borrows its scenarios from a regulated industry.<\/p>\n\n\n\n

\"Terminal
One call, four stages: the full pipeline run with the extracted claim JSON \u2014 mistranscribed policy number included.<\/figcaption><\/figure>\n\n\n\n

The SDK that retired under my feet<\/h2>\n\n\n\n

The deepest failure was the most instructive. Authentication errors that looked like RBAC problems (“audience is incorrect”) and version errors that looked like configuration problems (“API version not supported”) both traced back to a single root cause: the lab had been scaffolded on azure-ai-inference<\/em>, an SDK that is deprecated and scheduled for retirement on August 26, 2026, against an endpoint that had already stopped honoring its preview API dialects.<\/p>\n\n\n\n

The fix was not a magic api_version<\/em> string; it was migrating to the generally available OpenAI v1 surface \u2014 the standard openai<\/em> Python SDK pointed at the resource’s \/openai\/v1\/<\/em> endpoint, authenticated with an Entra bearer token provider instead of an API key.<\/p>\n\n\n\n

\"Terminal
“API version not supported”: the error that unmasked a retiring SDK.<\/figcaption><\/figure>\n\n\n\n

If you are preparing AI-103 in 2026, assume that any tutorial older than a few months is describing a platform that no longer exists in that shape. Reading ClientAuthenticationError<\/em> and BadRequestError<\/em> bodies carefully \u2014 audience, scope, version \u2014 is a faster path to a working system than any amount of tutorial-following.<\/p>\n\n\n\n

One honest bug, kept on purpose<\/h2>\n\n\n\n

The finished pipeline extracts a valid claim record: claim type, incident date, location, sentiment, an urgency score with rationale, and a spoken confirmation. It also makes one systematic mistake: the policy number POL-4482913<\/em>, read aloud by the TTS voice, comes back transcribed as PL4482913<\/em>. The record validates; the identifier is wrong.<\/p>\n\n\n\n

I am keeping the bug visible in the repo for now, because it is a perfect specimen of a whole class of production failures: audio fidelity on structured identifiers.<\/p>\n\n\n\n

The layered fix \u2014 format constraints in the prompt, a regex-validated Pydantic field so the retry loop self-corrects, and ultimately verification against a system of record \u2014 is the next commit, and a future article of its own.<\/p>\n\n\n\n

\"VS
The pipeline’s final artifact: a seven-second spoken confirmation.<\/figcaption><\/figure>\n\n\n\n

What this session actually covered<\/h2>\n\n\n\n

One evening, one working lab \u2014 and, almost incidentally, live encounters with quota management, deployment SKUs, RBAC and role renames, model lifecycle states, SDK deprecation, keyless authentication, JSON-mode extraction with validated retries, and the speech-versus-multimodal architecture decision. That is a substantial slice of the AI-103 syllabus, learned by hitting it rather than reading it.<\/p>\n\n\n\n

The monorepo is public at labnova\/ai103-labs \u2014 Lab 04: Voice Claims Intake<\/a><\/strong>. Next up: hardening the identifier extraction, then Lab 02 \u2014 an ESG report intelligence pipeline, where the retrieval and grounding domains get their turn.<\/p>","protected":false},"excerpt":{"rendered":"

Part 1 of a series documenting the road to the Azure AI Apps and Agents Developer Associate certification (Exam AI-103), one working lab at a time. Why this project Microsoft retired exam AI-102 on June 30, 2026 and replaced it […]<\/p>","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"footnotes":""},"categories":[25],"tags":[],"class_list":["post-127","post","type-post","status-publish","format-standard","hentry","category-research"],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tellpunk.it\/en\/wp-json\/wp\/v2\/posts\/127","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.tellpunk.it\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tellpunk.it\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tellpunk.it\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tellpunk.it\/en\/wp-json\/wp\/v2\/comments?post=127"}],"version-history":[{"count":5,"href":"https:\/\/www.tellpunk.it\/en\/wp-json\/wp\/v2\/posts\/127\/revisions"}],"predecessor-version":[{"id":182,"href":"https:\/\/www.tellpunk.it\/en\/wp-json\/wp\/v2\/posts\/127\/revisions\/182"}],"wp:attachment":[{"href":"https:\/\/www.tellpunk.it\/en\/wp-json\/wp\/v2\/media?parent=127"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tellpunk.it\/en\/wp-json\/wp\/v2\/categories?post=127"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tellpunk.it\/en\/wp-json\/wp\/v2\/tags?post=127"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}