A notebook per folder, and the newest announcements point at another repository

The three oldest index sections link to a different repository

The date-ordered index on the README runs from the newest entry down. Reading upward from the bottom, the three oldest sections do not point inside this repository at all. Everything dated 09 September 2025, including the Mistral Document AI walkthrough and two Flux image generation notebooks, links to `retkowsky/Azure-OpenAI-demos`. So does everything dated 26 August 2025, which is the GPT-5 example. So does the entire 26 June 2025 section, twelve rows covering Bing-connected agents, Grok, Phi-4 reasoning, tracing, and a run of five evaluator notebooks. Only the entries from 16 January 2026 onward resolve to this repository. That is not a small fraction of the index, and nothing on the page marks the boundary, so a reader planning a Foundry project from the front page will follow links into a sibling repository without being told they have left.

The index stops two months behind the last commit

The newest entry is dated 27 May 2026, a Prompt Agent quickstart notebook. The most recent commit on the default branch is dated 2026-07-22. So whatever landed in those two months is not in the index, and the index is the only navigation this repository offers, since there is no per-directory index and no tags. The list is otherwise disciplined in one respect: it is strictly newest first, and each section header carries its own date, which makes it easy to see the gap once you compare it against the commit history. The last heading in the list is incomplete, stopping partway through its date line, so the very end of the chronology is cut as well. Between a two month gap at the top and an unfinished heading at the bottom, the page needs a reader who already knows the repository to be useful.

Two paragraphs of platform copy sit above the actual index

The opening of the page describes the product, not the demos. The first paragraph defines Microsoft Foundry as a unified Azure platform-as-a-service for enterprise AI operations, model builders and application development, and says the foundation combines production-grade infrastructure with friendly interfaces so developers can focus on applications. The second says it unifies agents, models and tools under one management grouping, with tracing, monitoring, evaluations and configurable enterprise setup, and with RBAC, networking and policies under one Azure resource provider namespace. The two paragraphs overlap, and neither tells you what is in the repository. After all that, the first thing you learn about the contents is a table row with a flame marker and a link. A visitor deciding whether to clone gets the vendor pitch first and the repository layout somewhere after that.

The same table calls one platform two different names

The page title says Microsoft Foundry. The row descriptions inside the index say Azure AI Foundry, and so do the notebook filenames, which carry strings like `Image Anomaly Detection with Cohere Embed 4 on Azure AI Foundry.ipynb` and `Azure AI Foundry - gpt5.ipynb`. The rename is visible in the same document: entries from January 2026 onward use the new name in their prose, while entries carried over from 2025 keep the old one inside the filename and occasionally inside the description. That is not fatal, since the files still work and the portal link at the top points at the current service, but it does mean a search for one name or the other returns a partial view. Directory names carry the same drift, with entries like `Azure Open AI quick demos/` and `Azure OpenAI Batch/` sitting in the same listing and differing by a space.

Directory names contain typos that no search will rescue

The top level is sixty entries, one directory per scenario, and several of the names are misspelled in ways that a visitor cannot guess around. There is a directory called `GPPT-4Turbo Json/`, with two letters where one belongs. There is a markdown file called `Informations.md`, pluralised as if it were a French document. There is `GPT4-V-Plant/`, whose intended subject is not recoverable from the name, alongside a separate `GPT4-Vision and Azure AI enhancements/`. `GPT35-Instruct/` writes the model without its separator. Casing drifts too, with `Dall-E3/` sitting next to `GPT-4o/` and `Gpt-4o-Text-FineTuning/`, and the 4o work split across three directories that spell the name three ways. Search will find the ones that are spelled correctly and quietly miss the others.

Fine-tuning lives in three folders with three spellings

The clearest duplication in the layout is around model adaptation. There is a `Fine Tuning/` directory, a `Gpt-4o Fine tuning/` directory and a `Gpt-4o-Text-FineTuning/` directory, three separate folders for closely related work, with two of them prefixed by a specific model and one of them scoped to text. Alongside them sit `AzureOpenAI Batch/` for batch jobs, `Data generation/` for producing training data, and `Benchmarks/`. A newcomer looking for fine-tuning has to guess which of the three folders is current, and nothing in the README says whether the others are older, text only, or simply abandoned. The same shape repeats elsewhere in the listing, with `Image to Image/`, `Images comparison/` and `Image storytelling/` as three image folders, and `Images_tagging_cohere/` as a fourth tagging example alongside the one the index calls auto tagging.

Safety and red teaming demos sit unseparated from media generation

The top-level listing mixes evaluation and defensive work with media generation in one alphabetical run, with no grouping beyond the folder names themselves. `AI Red Teaming/` and `Azure Safety Content for text and images/` sit in the same list as `Artificial images with Dall-e 2/`, `From PDF to Video/`, `Avatar/` and `Chat with your own videos/`. Domain folders follow the same pattern, with `FHIR analysis/`, `Health report analysis/` and `Insurance report analysis/` next to each other and next to `Grammar checking/` and `Emoji translation/`. The README adds no index of its own for any of these, so the only way to find the safety material is to know the folder name already, or to read the index section that happens to cover it. For a repository whose pitch is enterprise readiness, the layout does not advertise that half of the work.

There is no install step because the deliverable is the notebook

Nothing on the page tells you to install anything, and that is consistent with what the repository is. The primary language is recorded as Jupyter Notebook, and the top level holds sixty scenario folders plus a gitignore, a code of conduct, a contributing file and one markdown file. No requirements file, no lockfile and no package manifest appear at the root, so whatever each notebook imports has to be present in the environment you run it in. The page does point at the portal, `https://ai.azure.com/`, as the place where the work happens, and one entry is an Azure API pricing fetcher notebook, which is the kind of script that needs credentials to return anything. There are also no GitHub releases, so there is no version to pin a notebook against.

Editorial conclusion

This repository works as a catalogue. Sixty directories, each a self-contained scenario, with a README that tells you which ones are recent and roughly what each one touches, is a reasonable way to find a starting point for a Foundry script. Two caveats decide whether it is useful to you. The newest material is not in this repository, since three sections of the index link to a sibling one, so a reader following the front page is partly reading someone else's roadmap. And nothing is pinned: no requirements file, no package manifest, no releases, and directory names with typos and inconsistent casing that no search will help you guess. Treat each notebook as a starting sketch rather than a maintained sample.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. retkowsky/Azure-AIGEN-demos on GitHub