retkowsky/Azure-AIGEN-demos: A Notebook Cookbook for Microsoft Foundry

What retkowsky/Azure-AIGEN-demos is for

Microsoft Foundry is described in the README as a unified Azure platform-as-a-service offering for enterprise AI operations, model builders and application development. The repository is not that platform. It is a set of Jupyter notebooks that demonstrate how to call it. The README frames the project as demos, documentation and accelerators, and the top-level directory listing confirms that shape: folders such as GPT-4o, Grok, Phi-4 reasoning, Flux.1 Kontext Pro, Azure Agent Service, Observability and Fine Tuning, each containing notebooks rather than importable modules.

The audience is therefore narrow and specific. You need an Azure subscription with access to Microsoft Foundry, a working deployment of at least one model, and enough Python to run a notebook cell by cell. The repository assumes you already know why you want an agent or an evaluator; it shows the call, not the architecture decision. That is a reasonable scope for a demo collection, but it means the notebooks will not tell you whether a given model is the right choice for your workload.

How the notebooks are organized and what runs them

There is no build system, no package manifest at the root, and no CLI. The mechanism is Jupyter: you open a .ipynb file, execute cells in order, and the notebook calls Azure endpoints. The README's Latest Content tables date each addition, from the June 2025 batch (Azure AI Agent Service, Grok, Phi-4, tracing, evaluators) through gpt-5.2 in February 2026 and Prompt Agent in May 2026. The most recent push to the repository was on 2026-07-22.

The data flow inside a typical notebook is a sequence of SDK calls: authenticate against an Azure endpoint, reference a deployed model by name, send a prompt or an image, and print the response. Some folders, such as the Cohere Embed 4 examples, chain an embedding step into a downstream task like anomaly detection or auto-tagging. The Observability folder is different in kind: its notebooks exercise evaluators for agents, retrieval, risk and safety, which means they measure outputs rather than produce them. That distinction matters when you are deciding which folder to read first.

One structural quirk: several entries in the Latest Content table point at the Azure-OpenAI-demos repository rather than this one, including the Mistral Document AI, Flux.1 Kontext Pro and GPT-5 examples. If you follow a link from the README and land in a different repository, that is expected, not a broken link.

Opening your first Microsoft Foundry notebook

The repository does not document an install procedure, so there is no setup command to give. What the README does provide is the platform side: it links to the Microsoft Foundry portal at https://ai.azure.com/, where you need a project and a model deployment before any notebook cell returns something useful. The notebooks themselves are opened from a local clone or from GitHub, and the README links directly to individual .ipynb files, for example the Prompt Agent quickstart at https://github.com/retkowsky/Azure-AIGEN-demos/blob/main/Prompt%20Agent/Foundry%20Prompt%20Agents.ipynb.

Start with the Basics folder rather than the newest model. Once the notebook is open in a Jupyter environment, execute cells in order. The first cells establish the Azure endpoint and credentials; the exact variable names differ per notebook, so read the cell rather than copying a pattern from another folder. What you should see, once credentials and a deployment name are correct, is a model response printed in the cell output. If authentication fails, the error surfaces at that cell, not at import time.

Because the repository ships no requirements file, any SDK you need has to come from your own environment. Check the imports at the top of the notebook you chose and install what they name before running the rest of the file.

Where the demo format becomes a limitation

A notebook collection has no dependency contract. There is no requirements.txt at the root, no pinned SDK versions, and no lockfile in the top-level listing. A notebook written in June 2025 may import a client library whose constructor signature has since changed, and nothing in the repository will warn you. The README's dated tables tell you when content was added, not when it was last executed.

Credentials are the second constraint. Notebooks need an Azure endpoint and a key or token, and the repository does not document how to supply them beyond what each notebook does inline. That is fine for a demo and awkward for anything repeatable. If you want the same call in a pipeline, you will be extracting code out of cells and rebuilding the configuration yourself.

Finally, the repository is the wrong tool if you want a supported product. It is a personal demo collection under the MIT licence, with no release artifacts. Anyone expecting semantic versioning, a changelog or a support channel should look at Microsoft's own Foundry documentation and SDKs instead.

How this differs from Microsoft's own Foundry samples

Microsoft publishes its own sample repositories and SDK documentation for Foundry, and the difference in approach is structural rather than qualitative. Official samples are typically organized around a single SDK version, maintained alongside that SDK's release cycle, and tested against current service behaviour. This repository is organized around models and tasks: a folder per model family, a folder per use case, with dates attached to each addition.

The practical consequence is discoverability by example rather than by API. If you want to see what a Grok call looks like next to a Phi-4 reasoning call next to an evaluator run, this repository puts them side by side in one place, which official documentation rarely does. If you want the authoritative signature of a client method, the official source is the safer reference, because a notebook here may predate a change. The two are complementary: use this repository to find a scenario, then confirm the call against the current SDK.

Maintenance, licence and what upgrading costs you

The repository is not archived, and its last push was on 2026-07-22. The dated entries in the README run from June 2025 to May 2026, which shows a pattern of additions rather than a rewrite: new folders appear, older ones stay in place. That is good for reference value and bad for consistency, since a folder added in 2025 and one added in 2026 may target different SDK generations.

There are no releases in the repository, so there is nothing to upgrade in the dependency-manager sense. Your upgrade cost is the cost of re-running a notebook against a newer SDK and fixing whatever breaks. Budget for that whenever you copy code out of a notebook into something you intend to keep.

The licence is MIT, which is permissive and permits reuse with attribution. That covers the notebook code. It does not cover the Azure services the notebooks call, which are billed and governed under your own subscription and Microsoft's terms. Nothing here changes your obligations to Microsoft, and nothing here constitutes legal advice on how to handle model outputs in a regulated context.

Editorial conclusion

Adopt this repository as a reference library if you are building on Microsoft Foundry and want working notebook examples for models, agents, tracing and evaluators before writing your own code. Skip it if you need a packaged library, a CLI, or versioned releases, because none are present; the repository is a set of notebooks on a single main branch. Before relying on any notebook, open it and check its imports, model deployment names and Azure endpoints, since those values are environment-specific and the repository does not document a setup step for them.

Frequently asked questions

Official sources

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