If you are studying for AI-103 and the naming feels like a moving target, you are not imagining it. Microsoft has renamed its AI platform three times in about two years, and the documentation still carries URLs from older names. This is a short reference to keep the terms straight — and to flag where genuine uncertainty remains.
A note on confidence: platform names change fast. The relationships below are accurate as of early 2026, but if you are reading this later, verify the current term on Microsoft Learn before quoting it in production docs.
The rebrand timeline
- Azure AI Studio — the name introduced at Ignite 2024 for Microsoft's unified build-and-deploy surface for generative AI.
- Azure AI Foundry — the next name, positioning the platform as a "foundry" for building AI apps and agents (project-centric, with a model catalog, deployments, and evaluations).
- Microsoft Foundry — the current name (as of early 2026). Docs now live under
learn.microsoft.com/azure/foundry/.
The through-line across all three: a project-centric platform for selecting models, deploying them, grounding them, evaluating them, and building agents. The capabilities were largely continuous; the brand kept moving.
Why ai.azure.com URLs still work
The portal domain — ai.azure.com — dates from the Azure AI Studio / Azure AI Foundry era and persists even though the product is now "Microsoft Foundry." This is normal: Microsoft (like most vendors) keeps stable URLs working through rebrands to avoid breaking bookmarks, tutorials, and deep links. So do not be thrown when the current Microsoft Foundry portal still lives at an ai.azure.com address. URL ≠ current brand name.
Foundry Tools vs Foundry Agent Service vs Foundry IQ
Three terms candidates constantly confuse:
Foundry Tools
Foundry Tools is the current umbrella for the prebuilt, point-solution APIs: Language, Vision, Speech, Document Intelligence, Translator, and Content Understanding. This is the successor term to what was Azure AI Services, and before that Azure Cognitive Services. Mental model: Foundry Tools are capabilities your app or agent calls — a captioning call, a translation call, an OCR call.
Foundry Agent Service
Foundry Agent Service is the managed agent runtime and orchestration service — the successor to Azure AI Agent Service. It is where you define agents (roles, goals, memory, tool schemas), wire in retrieval and function calling, and run single or multi-agent workflows. Mental model: Foundry Agent Service runs the agents; the agents call Foundry Tools.
The classic exam trap: an answer choice offers "Foundry Tools" where the correct answer is "Foundry Agent Service" (or vice versa). Anchor on the verb — are you calling a capability (Tools) or running an agent (Agent Service)?
Foundry IQ
Foundry IQ is a newer (Build 2026) knowledge/retrieval layer built on top of Azure AI Search. It is very new and preview-adjacent, so treat it with caution: the AI-103 objectives still use plain "semantic / vector / hybrid search," not Foundry IQ. Know the term exists, but do not over-index your study on it.
What did not get renamed
Helpfully, a few core names have been stable:
- Azure AI Search — the retrieval/indexing engine (semantic, vector, hybrid). Still the documented name in the exam objectives.
- Azure AI Document Intelligence — OCR, layout, and field extraction. The name persists even though it is marketed as part of Azure Content Understanding.
- Azure OpenAI — the model service, now consumed in Foundry.
For the retrieval side specifically, see our deep dive on semantic vs vector vs hybrid search.
Quick reference table
| Term | What it is | Legacy name |
|---|---|---|
| Microsoft Foundry | The platform (projects, catalog, deployments, evals) | Azure AI Foundry / Azure AI Studio |
| Foundry Tools | Prebuilt point-solution APIs (Language, Vision, Speech, Doc Intelligence, Translator, Content Understanding) | Azure AI Services / Cognitive Services |
| Foundry Agent Service | Managed agent runtime and orchestration | Azure AI Agent Service |
| Azure AI Search | Retrieval engine (semantic / vector / hybrid) | (unchanged) |
| Foundry IQ | New knowledge/retrieval layer on Azure AI Search | (new, preview-adjacent) |
ai.azure.com | Portal URL that survived the rebrands | — |
Read a tutorial by its resource and API, not only its brand name
A rebrand is easy to describe; a tutorial's compatibility requires a closer read. Before following an older walkthrough, identify what it creates, which client library it imports, and which endpoint it calls. Two pages can both say "Foundry" while using different project models or API generations.
Microsoft's Foundry overview includes a table mapping earlier concepts to current equivalents. That table distinguishes branding from changes to the agent API, resource model, SDKs, and endpoint conventions. Use those dimensions as a checklist rather than treating a name replacement as a complete migration plan.
For example, an old sample might create a hub-associated project and then use threads and runs to invoke an agent. Renaming every mention of Azure AI Foundry in the prose does not update those objects or the client code. Decide whether you are reproducing the classic experience or adopting the newer experience, and keep the example internally consistent.
If you are maintaining company documentation, preserve the older term once in a short mapping note. Readers searching an error message or an old resource name can then find the new page. Replace vague directions such as "open the AI portal" with the specific experience and resource the reader should select.
Work through a document-assistant scenario
Imagine an application that reads expense-policy documents and answers employee questions. The platform is the overall development surface. A document-processing capability extracts text or fields from uploaded material. Search retrieves relevant policy passages. The model uses those passages to construct an answer. If the application delegates a multistep task to an agent runtime, that runtime coordinates the workflow.
This description separates jobs that a broad product name can hide. Extracting a receipt field is a document-processing task. Finding the reimbursement rule is a retrieval task. Deciding whether to request a missing document is orchestration. Generating an explanation is a model call. Buying access to one layer does not remove the need to configure the others.
Now change the requirement: employees only need a static answer from a provided paragraph. A complete agent runtime may add unnecessary moving parts to that first prototype. Build the smallest workflow that answers the question, then add retrieval or tools when the actual input and output require them.
For study, explain each service choice using a verb. "Retrieves," "extracts," "runs," and "generates" force you to identify the component's responsibility. If your explanation consists only of a product name, you have not yet justified the architectural choice.
Troubleshoot the boundary that is failing
A portal opening successfully proves that your browser can reach the portal. It does not prove that a deployed application can call a model, access a project, or retrieve documents. When a sample fails, record the failing operation before changing any service selection.
An authorization failure suggests inspecting the identity, resource, and role involved in that request. An endpoint error suggests comparing the URL and client against the documentation for that API generation. An empty search result suggests checking indexing and query behavior. Those are different diagnoses even if all of them occur inside a Foundry project.
Keep a small inventory with the resource name, region, project, endpoint purpose, client package, and example you followed. Do not put credentials in that inventory. This gives a teammate enough information to reproduce the configuration without distributing secrets or relying on screenshots of a portal whose menus may have changed.
Keep certification notes separate from deployment notes
An exam objective is a scope document, while product documentation explains implementation. Use the objective to decide what to study; use the product's current implementation reference to decide what to deploy. A feature appearing on a marketing page does not establish its exam weight, regional availability, or readiness for your workload.
For each study card, put the task on one side and the component's role on the other. Add former names as search aliases rather than memorizing a timeline as if it were the central engineering skill. You will retain the useful distinction even when another naming update arrives.
For deployment notes, record what you actually configured and when. Link to the exact quickstart or migration guide, identify any preview-dependent behavior, and state the verification you performed. That record is more durable than a blanket statement that the project uses the "latest Foundry" because it describes the concrete integration a future maintainer will need to change.
Bottom line
The safest exam heuristic: prefer the current Microsoft Foundry naming in answers, treat Foundry Tools as "capabilities you call" and Foundry Agent Service as "the runtime that runs agents," keep Azure AI Search as the retrieval engine, and treat Foundry IQ as an emerging term rather than a core objective. Ready for the full exam? Start with the AI-103 exam guide, the certification study guide, and the learning pathway.
For a current model-catalog example, see MAI-Thinking-1 in Microsoft Foundry public preview, including the difference between a Direct from Azure model, its Chat Completions interface and the application-owned agent harness. For a September 2026 image-model example on the same catalog, see MAI-Image-2.6-Flash, Microsoft's faster, cheaper sibling to its MAI-Image-2.6 flagship.
Platform names change frequently; relationships described here are accurate as of early 2026. Verify current terminology on Microsoft Learn. explainx.ai is not affiliated with Microsoft.