azureai-samples: Azure's index of sample notebooks and code

A directory of samples, and a README that is mostly links

azureai-samples describes itself as the official community-driven Azure AI examples, and the first paragraph of the README explains its role precisely: this repository acts as the top-level directory for official Azure AI sample code and examples.

The contents are notebooks and sample code that contain end to end samples as well as smaller code snippets for common developer tasks, and the intent is stated simply: use the samples in this repository to try out Azure AI scenarios on your local machine. The project is entirely open source, with guidance on contributing and links to additional repositories provided below.

That last phrase is the key to reading the repository. The README is mostly a table of contents for other projects, and the sample code here is a directory of scenarios rather than a set of finished applications. The repository description and the topic tag are both minimal, one word each, which fits an index.

The licence is MIT, the primary language is reported as Jupyter Notebook, and the default branch is main. There are no GitHub releases, and the last push to the repository was on 2026-10-06.

The audience is a developer who has a task in mind, such as calling a model, building a retrieval augmented generation flow or wiring up an agent, and who wants a runnable example to copy from rather than documentation to read. The scenarios are the deliverable; the repository is the shelf they sit on.

What the linked repositories actually cover

The supplementary documentation section groups the neighbouring repositories by product area, and it is the most informative part of the README.

Under the Azure AI Agent Service there are four entries. The Python SDK repository has agent samples, and the .NET SDK repository has the equivalent for .NET. Two are purpose built: a travel agent sample built with the Agent Service in Python, and a simple Python Quart app that streams responses from Azure AI Agents to an HTML and JavaScript frontend using Server-Sent Events.

Under Azure AI Foundry there are three. The quickstart for an enterprise chat copilot in Azure AI Studio, an end to end solution sample for a custom RAG based retail copilot built code first with Prompty and Azure AI Studio, and an end to end solution sample for a custom multi-agent creative writer solution built the same way.

Azure AI Search has the largest group, and the pattern is language coverage rather than feature coverage: end to end samples for the Retrieval Augmented Generation pattern across data in Python, in JavaScript, in .NET and in Java. Alongside those are a LangChain.js quickstart that starts with Ollama and local models and transitions to Azure for production, and a repository with both a sample and a step by step workshop on building a custom chatbot with retrieval augmented generation in JavaScript.

The remaining entries are single items: the Azure AI Assistant Tool with Python middleware libraries for experimenting with Azure OpenAI assistants locally, the chat-copilot sample showing how to build an LLM chat copilot, the OpenAI cookbook for common tasks within OpenAI, a serverless ChatGPT with retrieval augmented generation using LangChain.js that can run locally with Ollama and Mistral 7B, and the Phi cookbook for examples and code using the Phi family of small language models.

The two patterns worth noticing are the language spread, which suggests the samples are maintained by whoever owns the SDK for that language, and the repeated appearance of Ollama and Mistral as a starting point, which is a deliberate design choice about where to begin before Azure.

The scenarios directory and the repository scaffolding

The top level of the repository is small, and it tells you where the code is.

There is a scenarios/ directory, which is where the notebooks and sample code live, and it is also the pytest test path. Around it are the files that hold the project together: pyproject.toml with the formatting, linting and test configuration, tox.ini for running the checks across environments, conftest.py for the pytest fixtures, dev-requirements.txt for the development dependencies, .infra/ for infrastructure, .pre-commit-config.yaml for the commit hooks, .gitattributes, .gitignore, CONTRIBUTING.md, LICENSE and the README.

The .infra/ directory is worth a second look. It indicates that at least some of the samples come with infrastructure definitions, which is the part most sample repositories skip and the part that decides whether a reader can actually run what they are looking at.

The contributing guidelines live in the repository rather than being described in the README, and the README points at them for both the process of adding a sample and the process of implementing one yourself. That last point matters, because the README explicitly invites feature requests for samples that should exist, which means the contents of the repository are partly determined by what people ask for.

So the shape of the project is: a directory of scenarios you can copy, a shared tooling setup so that every scenario is formatted and linted the same way, and a README that routes you to the heavier end to end solutions elsewhere.

One linting setup, and the notebook exceptions it makes

The tooling configuration in pyproject.toml is the part of this repository that every contributor touches, and it is worth reading because it explains how the notebooks are handled.

Both formatters are set to the same width. Black has line-length = 120 and ruff has line-length = 120, so the two agree and a notebook formatted by one is not reflowed by the other.

The ruff lint configuration extends the default rule set with a list of rule families: B, C4, PT, RET, SIM, ARG, PTH, RUF, PLE and ANN. Those cover bugbear, comprehensions, pytest style, return statements, simplifications, unused arguments, pathlib usage, Ruff's own rules, errors and annotations. The list ends with RUF a second time, which is harmless but suggests the file grew organically.

The per-file ignores are the interesting part, because they exist for the notebooks:

"*.ipynb" = [
  "PLE1142", # await-outside-async: Jupyter Notebooks support top level await
  "E402", # module-import-not-at-top-of-file: It's relatively common to have to import "just in time"
  "E501", # line-too-long: Let black handle this
]

Each ignore has a reason attached. PLE1142 is off because notebooks support top level await, which is legal there and flagged in ordinary Python. E402 is off because importing just in time is a normal pattern in a notebook that has to do setup before it can call the service. And E501 is off because Black handles line length, so ruff should not also complain about it.

That is a small, well made decision. Notebook code and module code have genuinely different rules, and encoding the exceptions per file rather than disabling the rules globally keeps the checks on for the Python files.

The pytest configuration is equally short:

[tool.pytest.ini_options]
console_output_style = "count"
addopts = "--strict-markers"
testpaths = ["scenarios"]

The count style prints a running count of tests completed rather than a line per test, which is the sensible choice when a test run covers a directory of notebooks. The strict markers option means an unregistered marker is an error rather than a warning, and the test path is the scenarios directory, which is the confirmation that the notebooks are what gets tested.

Where this repository is the wrong starting point

There are cases where a sample here is not what you want, and they follow from what this repository is and is not.

If you want a maintained component rather than an example, this is not it. These are samples, and the licence being MIT does not make the code a library with a support commitment.

If you need a complete end to end solution with an architecture behind it, the README is telling you to go elsewhere. The Azure AI Foundry entries are described as end to end solution samples, and the Azure AI Search ones as end to end samples for the retrieval augmented generation pattern, all of which live in their own repositories. A scenario notebook here is a starting point, not an architecture.

If you cannot create Azure resources, most of these samples will not run at all, since they call hosted endpoints and need credentials and a subscription. The point of a notebook is that you can execute it, and that requires the account.

The other limitation is drift. The linked repositories are maintained independently and change on their own schedules, so a link in this README is a pointer to something that may have moved since. The same applies to the notebooks here: a scenario written against an SDK version from a year ago will not reflect the current API.

The alternative approach is to start from the SDK's own sample repository, which is maintained by the team that owns that SDK and therefore matches the current API more closely, or to use the vendor documentation for the single call you need. The difference in approach is that this repository gives you a curated entry point with a consistent tooling setup and a place to see what other people have asked for, at the cost of samples that are not tied to a release and that you will read as a starting point rather than as reference.

Editorial conclusion

azureai-samples suits somebody who wants a working Azure AI example in the shortest possible time, and who prefers a notebook with the calls spelled out over a reference document, and it suits contributors who want their sample to sit in one place with one linting and test setup. It does not suit somebody who wants a maintained production component, since these are samples, and it does not suit somebody who needs the full end to end solutions, since those live in the linked repositories and change on their own schedules. Check three things before you start from a notebook here: which Azure resources the scenario creates and what it will cost, whether the toolchain in pyproject.toml and tox.ini suits your environment, and whether the repository the README points at is a better starting point than the notebook in front of you. The last push to the repository was on 2026-10-06 and the project publishes no GitHub releases.

Frequently asked questions

Official sources

1. Azure-Samples/azureai-samples on GitHub
2. Issues
3. License: MIT
4. README