DEV Community: Carlos José Castro Galante

Gemma 4 Reads University Syllabi Offline So Professors Only Have to Decide

Carlos José Castro Galante — Fri, 23 Oct 2026 02:34:03 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

My request to have a single course recognized was filed in 2025 and resolved in September 2026. In Argentina that isn't unusual. When a student moves between universities, a professor has to read two long syllabi side by side, match topics by hand, count them against a percentage written in a regulation and write down what the student still has to take, and the case then climbs through faculty offices and councils. I'm not writing this to argue with the outcome of my own case. I'm writing it because most of the waiting happens around reading and counting, which is exactly the kind of work a model does well, while the decision itself should always stay with a person.

So I built Tramo, an open source assistant that drafts course equivalency reports with Gemma 4 running locally through Ollama.

You give it the analytic program of the subject a student already passed and the program of the subject they want recognized, as a PDF, a Word file or pasted text. Gemma extracts the teaching topics of both programs, compares every destination topic against the whole origin program, labels it as covered, partial or without evidence and explains each judgment with the origin topics it relied on. Plain code then computes the coverage and applies the rule of my faculty, which only allows a partial equivalency when more than half of the destination program is covered, and it lists the topics the student would still have to take. The professor can overrule any topic, and every number is recalculated on the spot.

The professor gets to be lazy about the part of the job that never needed a professor, which is reading and counting, and keeps all of the part that does, which is deciding. Students get an answer sooner. And no document ever leaves the computer, because there's no cloud anywhere in the loop.

What an equivalency is, for readers outside Latin America

Every course in an Argentine university has an analytic program, a document that lists its units and topics in detail. When you change careers or universities, you can ask the new institution to recognize courses you already passed, and the institution compares both programs to decide whether the content is equivalent. At my faculty, the Facultad de Tecnología y Ciencias Aplicadas of the Universidad Nacional de Catamarca, the regulation says that a partial equivalency can only be granted when the equivalent content exceeds 50 percent of the destination program, and that the professor must then list the topics the student has to take before the course counts as passed. It's a fair rule, but applying it means reading and counting dozens of topics by hand for every single request.

What a professor can do with Tramo

A professor can paste both programs or drop a PDF or a Word file on each field, check and correct the extracted text before running anything, and try the whole flow in seconds with a built in sample pair of programs. The analysis runs on the same computer and shows its progress as it happens. The report presents the coverage against the 50 percent threshold, the proposed verdict, a count of topics by status, the topics still to be taken, a written recommendation and the detail of every topic with its evidence and its reasoning. The list can be filtered by status, any status can be changed with a single selector, and the final report can be copied as text or printed and saved as a PDF that carries a notice saying it's a draft generated by AI.

Tramo means a stretch of road in Spanish, and the interface borrows its language from road markings. A covered topic gets a continuous line, a partial one gets a dashed line and a topic without evidence gets a dotted line, so a professor can scan a long report the way you read the lanes ahead of you.

Demo

Here's the complete flow in under a minute and a half, from loading two programs to overruling the model and reading the limits of the tool. The video has no voice, only text on screen, and the analysis is sped up eight times so you don't have to sit through the wait.

The interface is in Spanish because it's built for Argentine faculties, so here's what each screen does.

The home page explains in one sentence what Tramo does and who makes the final decision.

Both programs are loaded, and the note above the button explains what Tramo is and what it isn't before anything runs.

While Gemma works, the title and the road fill with the progress reported by the pipeline itself, stage by stage, next to an elapsed timer.

The report shows coverage against the 50 percent threshold, the verdict that follows from the regulation and a count of topics by status.

Every topic cites the origin topics behind its status and explains the reasoning in plain language.

When the professor changes a status, code recalculates everything and the AI recommendation disappears, because it was written for a report that no longer exists.

The page explains what the AI does, when it can be wrong and who is responsible for the result.

Code

carlosjcastro / tramo

Local AI assistant that compares two course syllabi and drafts a university equivalency report. Open weights, private, the professor decides.

Tramo

Tramo compares the analytic program of a subject a student has already passed with the program of the subject they want recognized, and drafts an equivalency report for the professor who reviews the case. It runs entirely on the computer of whoever uses it, with an open weights model served by Ollama, so the documents never leave the machine.

The software does not decide anything. The model proposes a status for every topic and explains its reasoning with evidence taken from the documents, plain code computes the coverage and applies the equivalency rule, and the professor remains free to overrule any single judgment before signing. The final resolution belongs to the university authorities.

The problem it addresses

Universities in Argentina and across Latin America resolve equivalencies by hand, and a single case often takes many months. The reviewing professor has to read two long analytic programs side by side…

View on GitHub

Tramo is MIT licensed. The repository includes 119 tests, a security policy with private vulnerability reporting, a contributing guide and a README that documents the architecture, every setting and the known limits in detail.

If you have Ollama installed, you can run it in a few minutes.

git clone https://github.com/carlosjcastro/tramo
cd tramo
python -m venv .venv
.venv\Scripts\activate
pip install -r requirements_dev.txt
ollama pull gemma4:e4b
python -m pytest
python -m uvicorn app.api:app

On Linux and macOS, activate the environment with source .venv/bin/activate. Then open http://localhost:8000, press the button that loads the sample programs and generate your first report.

How I Built It

Tramo runs Gemma 4 (e4b) locally through Ollama. The backend is Python with FastAPI and Pydantic, and the interface is plain HTML, CSS and JavaScript modules with no framework and no build step. Everything runs on a single computer with a consumer GPU, without a server or a cloud account.

Layer	Choice
Model	Gemma 4 e4b, open weights
Inference	Ollama on the same machine, structured outputs with a JSON schema
Backend	Python, FastAPI, Pydantic
Interface	HTML, CSS and ES modules, no framework, strict content security policy
Data	Processed in memory, never stored or logged
Tests	119 unit and API tests with fake model clients
License	MIT

I chose the e4b size of Gemma 4 because it fits entirely on the GPU of a consumer card with a context of 12288 tokens, it handled programs written in Spanish well, and it's small enough that a faculty could run it on a computer it already owns.

The model proposes, the code decides

I designed everything around one rule, which is that Gemma never produces a number that the interface presents as a fact. The pipeline has four stages, and only three of them call the model.

Topic extraction. Gemma reads each program and returns its teaching topics through the structured outputs of Ollama, so every call sends the JSON schema the answer has to follow, with temperature zero. If the answer doesn't validate, a rule based splitter takes over and the report says so, because a silent fallback would be worse than an honest one.
Topic assessment. Destination topics go to the model in batches of twelve, and each one is compared against the complete list of origin topics. The model labels it as covered, partial or without evidence, cites up to five origin topics and writes a short reason. The code then checks that every topic was assessed exactly once and that every cited source actually exists in the origin program.
The rule. Plain Python computes the coverage, counting a covered topic as one and a partial one as half, and applies the regulation of my faculty. Article 87 allows a partial equivalency only above 50 percent, and article 88 asks for the list of topics still to be taken. No text inside a document can change this result, because the model never touches it.
The recommendation. Gemma writes a short recommendation from facts the code has already computed, including the longest runs of consecutive topics without evidence. Before the text reaches the screen, any sentence with a number the code didn't produce is removed. I deliberately didn't use embeddings or retrieval for the comparison. A syllabus fits comfortably in the context window, so every destination topic sees the whole origin program instead of a few chunks picked by similarity, and topics that are worded very differently in each university still get a fair reading.

Structured outputs with Ollama

The heart of every model call is the same pattern. Ollama receives the JSON schema of a Pydantic model, Gemma answers inside that shape, and Pydantic validates the result before anything else touches it. This is a simplified version of the call.

response = client.chat(
    model="gemma4:e4b",
    messages=messages,
    format=TopicList.model_json_schema(),
    options={"temperature": 0, "num_ctx": 12288},
    think=False,
)
topics = TopicList.model_validate_json(response.message.content)

The rule that decides the verdict is the opposite of a model call. It's a few lines of arithmetic that anyone can read and test, which is exactly why it lives in code. This simplified version shows the idea.

WEIGHTS = {"cubierto": 1.0, "parcial": 0.5, "sin_evidencia": 0.0}

def coverage(statuses):
    return sum(WEIGHTS[status] for status in statuses) / len(statuses)

What broke along the way

Three moments shaped the final design more than any plan did.

My first version didn't use a model to read the programs at all. It split them with rules, and on one test it reported 55 percent coverage while proposing that the student retake the names of the professors and the weekly hours of the course. That report convinced me that reading had to be done by a model and counting by code, and never the other way around.

The second moment came from the thinking mode of Gemma 4. With thinking on, Ollama ignored my JSON schema and returned plain text, and a complete analysis took five and a half minutes. I wrote a small benchmark to compare both settings, and with thinking off the model returned valid JSON for the extraction in about 4.6 seconds. The whole analysis dropped to about a minute and a half, so thinking is off by default and a single environment variable turns it back on. The benchmark lives in the repository, so anyone can repeat the comparison on their own hardware.

The third one was a lesson in humility. Running the same pair of programs several times gave coverage between 24 and 32 percent while the verdict stayed the same. Temperature zero doesn't make a local model fully deterministic, and pretending otherwise would be dishonest. That's why every topic shows its reasoning, why the professor can change any status and why the numbers always come from code.

Streaming the progress

A minute and a half is long enough to wonder whether something froze, so the analysis is streamed. The backend runs the pipeline as a generator and sends newline delimited JSON events, and the browser reads them as they arrive.

{"type": "progress", "done": 4, "total": 9}
{"type": "report", "report": {"coverage": 0.31, "verdict": "...", "matches": []}}

Each stage has a weight, so the percentage on screen comes from completed work and never from a timer. When the professor overrules a status, the browser sends the edited list back and the server recalculates the coverage, the verdict and the pending topics with the same code that produced the original report.

After the progress screen looked frozen on my own machine because of the reduced motion setting of the system, I also added a toggle for animations. It starts from the preference of the operating system, remembers the choice, and with animations off the progress stays visible through the title, the bar and the percentage.

Treating every document as hostile

Tramo takes files from users and feeds their text to a model, so it treats every input as untrusted.

Uploads have to be PDF or Word files verified by their signature and not by their extension, and their size is capped before they're stored in memory. PDFs with scripts, launch actions or attachments are rejected, PDFs longer than 100 pages are refused, and Word files with macros, ActiveX controls, path traversal or an abnormal expanded size are rejected too. Hidden and control characters are removed from every text, and file names are cleaned before they're shown.

Program text reaches the model between delimiters as data, the delimiters are stripped from the input, and any text that tries to give the model instructions raises a visible warning in the report. Even a successful injection couldn't change the verdict, because the verdict is computed by code.

Requests are rate limited per IP address, with three analyses every ten minutes, twenty uploads per minute and one analysis running at a time. Request bodies are capped while they're being read, the Host header is validated, the API documentation is disabled, responses carry a strict content security policy, and errors never echo the submitted text or expose internals. Documents are processed in memory and never stored or logged.

Accessible and honest by design

The interface works with a keyboard, announces progress and errors to screen readers, adapts from phones to wide screens and follows the light or dark preference of the system. The content security policy forbids inline scripts and styles, so even the progress bar is driven through the CSS object model.

An equivalency is an administrative decision about a person, so honesty is part of the product. The interface says what Tramo is before anything runs, and the report, including its printed version, says that it's a draft that can contain mistakes and doesn't replace the professor or the authorities who resolve the case. A dedicated section explains what the model does, when it can be wrong, how copyright and personal data are handled and who is responsible for the result. Tramo is an independent project and it has no endorsement from any university.

What it can't do yet

Tramo compares text, so it doesn't know the practical work, the bibliography or the depth with which each course was actually taught. It can't read scanned PDFs without a text layer, and its prompts still need calibration with professors and with the official equivalency tables of each institution. The next steps I have in mind are a second verification pass for topics labeled as covered, a button to cancel a running analysis, support for other regulations through configurable rules and an export of the report to Word.

Why Does Open Innovation Matter?

The documents around an equivalency belong to a student, and sending them to a closed API means agreements, consent forms and trust in the retention policy of a company. Many faculties can't arrange that quickly, and some never will. With open weights running locally that obstacle simply isn't there, because nothing leaves the computer and there's no account, key or invoice involved. Once the model is downloaded, Tramo doesn't even need an internet connection.

Openness also makes the result auditable. The model, the prompts, the schemas and the rule live in the same public repository, so anyone reviewing a report can see exactly how it was produced. A university council can't inspect a closed model, but it can read this code and run it on its own machines.

The tool also belongs to whoever uses it. A faculty with a different regulation can change the threshold with one variable, swap Gemma for another model in Ollama or rewrite the rule in a single Python module, without asking anyone for permission. The MIT license lets any university adopt it for free, and I'd love to hear from the ones that do.

A closed API would have made privacy a promise, while here it's a property of the architecture.

The Lazy Payoff

I haven't timed a professor doing this by hand, so I won't invent a number. What I can measure is the machine side. On my computer, Tramo reads both programs, assesses every destination topic and drafts the report in about a minute and a half, and the professor starts from a list where each topic already carries its evidence and its mark. Reviewing that list is still work, but it's the kind of work that needs a professor.

This week I've been the only user. I ran Tramo many times on syllabi from two Argentine universities, the same kind of documents that sat in my own case, and every run gave me a report I could audit topic by topic in a few minutes. The next step is putting it in front of the professors who review these cases every semester and calibrating the prompts with them.

Prize Categories

Gemma. Every model call in Tramo, from topic extraction to the written recommendation, runs on Gemma 4 locally through Ollama, and the whole design depends on an open model that a faculty can run on its own hardware.

Links

If you've ever changed universities or careers, how long did it take to get your courses recognized, and what would have made that wait shorter for you?

How to learn AI from scratch with a free Microsoft Learn plan in Spanish

Carlos José Castro Galante — Wed, 21 Oct 2026 02:04:19 +0000

According to the Job Outlook 2026 Spring Update from NACE, the US based National Association of Colleges and Employers, more than one third of entry level jobs now require AI skills, which is nearly triple the share employers reported in fall 2025. The data comes from 185 employer responses, so it doesn't describe every market, but it does show where hiring expectations are heading for people about to graduate. That's why I built a free Microsoft Learn plan that takes students from any major from understanding what AI is to using it with good judgment in their studies and at work. The plan and the modules it contains are in Spanish, and in this article I'll explain what it includes, the order I recommend and how to start.

What this Microsoft Learn plan is and who it's for

A Microsoft Learn plan is a collection of official modules organized in stages, with a suggested time frame to complete them and your progress saved in your account. This one gathers three beginner level modules and is designed for students from any major, because none of the three has mandatory prerequisites. If you're looking for a free AI course for students, this plan gives you an ordered path built from official Microsoft content.

Everything in the plan is in Spanish, so it fits best if you read Spanish comfortably. I'm a Microsoft Learn Student Ambassador, and I created this plan by selecting and ordering modules that already exist on Microsoft Learn, without writing or changing their content. The plan page estimates about two and a half hours of study in total and suggests finishing it in seven days, although you can go at whatever pace suits you.

You can open the plan on Microsoft Learn and start whenever you like.

The three modules, in the recommended order

The three modules are part of the plan, and I recommend going through them from there so you can see your progress across all three in one place.

1. Using AI for everyday tasks

The module Uso de la inteligencia artificial para tareas diarias, which translates to using artificial intelligence for everyday tasks, has eight units and is aimed at students, professionals and teachers who use Microsoft Copilot. Its goals are to understand generative AI, identify ways to use it at home and at work, and write effective prompts while finding useful resources. It includes an exercise on personalizing and refining prompts, which is the most direct practice in the plan for learning how to ask AI for better results.

2. Introduction to AI concepts

The module Introducción a los conceptos de inteligencia artificial, which translates to introduction to artificial intelligence concepts, has ten units and explains what kinds of solutions AI makes possible. It covers agents and generative AI, text and natural language, speech, computer vision and information extraction, and it ends with a unit on responsible AI and an exercise exploring AI workloads. It has no mandatory prerequisites, although the page itself recommends a conceptual understanding of machine learning and suggests completing the module Introducción a los conceptos de Machine Learning first, which isn't part of this plan.

3. Work smarter with AI

The module Trabaja de manera más inteligente con IA, which translates to work smarter with AI, has nine units and is designed for professional users of Microsoft 365 Copilot, so the page asks for familiarity with productivity apps such as Word, Excel, PowerPoint and Outlook. When you finish it, you'll be able to explain what AI and generative AI are and how they differ from traditional tools, describe how AI and AI agents support daily work and why giving AI context improves results, and review AI generated content while applying responsible AI practices. It includes a specific exercise on reviewing AI generated content.

Why the order goes from using AI to working with it

I chose this order so the learning moves from the concrete to the applied. You first practice with everyday tasks and learn to write good prompts, then you understand what's behind AI, such as text, speech and vision, and finally you bring that foundation to daily work, where reviewing what AI produces becomes part of your responsibility. Responsible AI appears in the last two modules, first as a concept and then as a review practice.

How to start the plan step by step

Open the plan on Microsoft Learn in your browser.
Sign in with your Microsoft account so Learn saves your progress.
Start with the first module and follow the order shown.
Complete each module through its assessment and summary, and return to the plan page to see how much is left. ## What to keep in mind before you start

This plan is a study path and not a certification exam. The three modules were last updated between August 9 and September 30, 2026, according to the metadata of their pages, but Microsoft Learn changes often, so you may see units that differ from what I described here. If something doesn't match, what each module page shows is what applies.

If you want a technical certification afterwards

When you finish the plan and want a more technical step, the Microsoft Certified Azure AI Fundamentals certification, with the AI-901 exam, is aimed according to its page at people starting a career in developing AI solutions, and it asks for Python knowledge and familiarity with Azure resources. That makes it a later and more technical step, and not a requirement for this plan.

Which of these three areas would you most like to use AI better in, your studies, your first job or a project of your own?

How to deploy to Azure with GitHub Copilot or Claude Code using Azure Skills and the Azure MCP Server

Carlos José Castro Galante — Mon, 19 Oct 2026 22:39:00 +0000

The 2026 Stack Overflow Developer Survey found that 73% of the developers who use AI coding assistants or agents use them every day, with Claude Code at 65.5% and GitHub Copilot at 58.7% among the agents they rely on most. The same survey shows that only 20% use AI for deploying, operating or troubleshooting production systems, which tells you that most of us still let the agent write the code and then take over ourselves when it's time to ship. The Azure Skills Plugin is Microsoft's attempt to close that gap, and in this post I'll explain what it installs, how to set it up in GitHub Copilot or Claude Code, how its prepare, validate and deploy workflow behaves, and which guardrails you should understand before you let an agent work on your subscription.

What the plugin installs in your agent

The plugin bundles two layers that Microsoft describes as the brain and the hands. The first layer is a set of Azure skills, which are folders with a SKILL.md file holding workflows, decision trees and rules that the agent loads when your request matches the skill's description. When I cloned the repository on October 18, 2026, it had 28 skill folders, among them azure-prepare, azure-validate, azure-deploy, azure-diagnostics, azure-compliance, azure-quotas, azure-storage, entra-app-registration and microsoft-foundry, and the list changes often because the repository syncs from Microsoft's main GitHub Copilot for Azure project.

The second layer is the Azure MCP Server, which the README describes as more than 200 structured tools across more than 40 Azure services. Those tools are what let the agent list your resource groups, check prices, query logs or run azd commands, and the Azure Skills overview sums up the split clearly by saying that the MCP server provides the individual operations while the skills provide the workflows that combine them. The README also lists Foundry MCP for model discovery, model deployment and agent workflows in Microsoft Foundry.

Microsoft introduced the plugin in March 2026 in the post Announcing the Azure Skills Plugin, and the repository is still very active, with its last sync on October 16, 2026 bringing plugin.json to version 1.2.95.

What's generally available and what isn't labeled

The page What is GitHub Copilot for Azure says that the azure-prepare, azure-validate and azure-deploy skills install automatically with that extension, and it lists general availability for Visual Studio Code, Visual Studio 2026, Claude Code and IntelliJ, while Visual Studio 2022 is still in public preview. Neither the plugin's README nor the Azure Skills pages on Microsoft Learn give the plugin a preview or GA label of its own, so I'd treat the GA status as applying to those clients and recheck the pages before you build a team process on top of it.

What you need before installing

You'll need an Azure subscription, and if you're a student, Azure for Students gives you credit without a credit card. The README asks for Node.js 18 or later on your PATH because npx starts the MCP server, the Azure CLI signed in with az login, and the Azure Developer CLI signed in with azd auth login if you plan to deploy. The skill reference page on Learn asks for Azure CLI 2.60.0 or later, and the VS Code skills extension also needs Git installed.

node --version
az --version
az login
azd auth login

Installing it in GitHub Copilot or Claude Code

In Visual Studio Code you install the Azure MCP Server extension from the Marketplace, and according to the README it also installs a companion extension that brings the skills, so the MCP server, Foundry MCP and the skills end up configured together.

In GitHub Copilot CLI you add the marketplace the first time and then install the plugin from inside the chat.

/plugin marketplace add microsoft/azure-skills
/plugin install azure@azure-skills

In Claude Code the README points to the official plugin marketplace, while the install page on Microsoft Learn uses the same two marketplace commands shown above for Copilot CLI, so either route works.

/plugin install azure@claude-plugins-official

The README also covers Cursor, Codex CLI, Gemini CLI, IntelliJ IDEA and APM, which installs the plugin across several agents from a single apm.yml. Once it's installed, the README suggests three prompts to confirm each layer is working, and the second one is the most telling because it should come back with resource groups from your own account instead of a generic answer.

What Azure services would I need to deploy this project?
List my Azure resource groups.
What AI models are available in Microsoft Foundry?

How prepare, validate and deploy work together

The three deployment skills are designed as a chain, and each one refuses to run if the previous one didn't finish. When you ask something like "Prepare this app for Azure", the azure-prepare skill instructs the agent to write a skeleton of .azure/deployment-plan.md in your workspace before doing anything else, and then to analyze whether the project is new, being modified or being modernized, gather requirements, scan the codebase, choose a recipe and map each component to an Azure service. The default recipe is the Azure Developer CLI, with Azure CLI, Bicep and Terraform as alternatives, and the skill tells the agent to present the finished plan and wait for your approval before it generates azure.yaml, the infra folder or any Dockerfile.

The skill also carries some security decisions of its own. For example, it forbids generating administratorLogin or administratorLoginPassword in SQL Server Bicep files and requires Entra-only authentication instead, which fits well with what I covered in How to authenticate Azure apps without storing credentials. When preparation ends, the agent has to change the plan's status to Ready for Validation before it can move on.

The azure-validate skill runs a workflow script that walks the agent through each check one at a time, recording its progress in .azure/validate-status.json and writing a Validation Proof section in the plan with the commands it ran and their timestamps. The rule is that every check has to pass, and if you only asked to validate, the agent stops there and reports the results instead of deploying.

The azure-deploy skill only starts when the plan says Validated and that proof section isn't empty, and the skill itself forbids the agent from setting that status by hand. From there it runs azd up, azd deploy, terraform apply or az deployment depending on the recipe, handles errors, checks that the endpoints respond, verifies the role assignments it created against your live subscription and returns the URLs with https://. If you've followed my post on the Azure Developer CLI, this is the same azd workflow, with the agent doing the planning and the checks you'd otherwise do yourself.

These are the kinds of prompts the README suggests for the workflow and for day two operations.

Prepare this app for Azure.
Validate my Azure deployment files before I run azd up.
Deploy this project to Azure Container Apps.
Troubleshoot why my container app is failing health probes.
What role should I assign to let this managed identity read blobs?

There's one inconsistency worth knowing about. The Azure Skills overview and quickstart on Microsoft Learn, last updated in April 2026, still call the plan .azure/plan.md, while the current SKILL.md and the azure-deploy reference page from July use .azure/deployment-plan.md, and the skill explicitly tells the agent not to use any other name. If you're following the quickstart and can't find the file, that's the reason.

The guardrails, and what they don't cover

Every deployment skill links to a set of global rules that require the agent to ask you before any destructive action, which the rules define as deleting, overwriting, irreversible operations, provisioning expens`ive resources and changing access policies or RBAC. The same rules say the agent must never assume your subscription or region, must not delete your project directory and may only runazd init` with a template in an empty directory.

It's important to understand that these rules are instructions written for the model and not a technical lock. The Azure MCP Server acts with your Azure CLI credentials or a managed identity, and the Azure MCP Server overview explains that access is governed by Azure RBAC, which means the agent can do whatever your account is allowed to do. Your host's approval settings matter just as much, because Microsoft's own quickstart for building with agents in VS Code describes Autopilot as running commands and editing files without asking you again. My recommendation is to try the plugin in a subscription or resource group where your account has only the permissions the project needs, and to keep tool approvals on until you've watched the workflow a few times.

The plugin also collects usage telemetry by default. In Claude Code it registers hooks on session start and after each tool call that send skill and tool usage events, and the script skips them when AZURE_MCP_COLLECT_TELEMETRY is set to false, the same variable that turns off telemetry in the Azure MCP Server.

`bash export AZURE_MCP_COLLECT_TELEMETRY=false `

If you want to go further with agents in your operations work, the learning path Optimize DevOps with AI agents on Azure covers GitHub Copilot plan mode for cloud operations, the Azure SRE Agent and, in its last module, how to move traditional operations tasks to agent instructions, skills and multi-agent orchestration.

When your coding agent shows you an Azure deployment plan, what's the first thing you check before you approve it?

Framejury, a culling assistant that works offline and explains every photo it rejects

Carlos José Castro Galante — Fri, 16 Oct 2026 14:33:50 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

Framejury looks through a folder of event photos, groups the frames that were shot seconds apart and look nearly the same, and marks the best one of each group to keep, while every other frame is rejected with a sentence that says why, the numbers behind that sentence are one click away, and a group that is too close to call gets flagged so the photographer makes the final choice. Any decision can be changed by the photographer and undone later, and nothing is uploaded anywhere, because the vision model runs on the same computer through Ollama.

The person who would pay for this is the photographer who delivers events such as graduations, weddings or school sports days, where a single afternoon can produce thousands of frames and long bursts of the same moment, and picking the keeper from each burst is hours of unbilled work. Paid tools that automate that work already exist, mostly as monthly subscriptions and with some of the cloud ones charging for each exported photo, so Framejury goes after the same hours with a different deal, since it's free and MIT licensed, it keeps client photos on the photographer's disk and it doesn't ask to be trusted, because every decision comes with its evidence.

The value Framejury offers is attention more than speed, because on my laptop, which has an RTX 4050 with 6 GB of video memory, the analysis takes between 27 and 36 seconds for seven photos, and in raw time that's about as fast as a person culling at four seconds per photo. The difference is that the machine can work while the photographer does something else and then ask for a human look only at the photos that deserve one. The results page estimates the time saved by assuming four seconds of manual work per photo, an assumption the user can edit, and it subtracts the analysis time, so on my small test folders it plainly reports none, and I left it that way because an inflated number would be worse than no number.

Demo

The video lasts one minute and 18 seconds, has no voice and tells the story with captions, with the analysis stage sped up, and I switched the internet connection off while the analysis ran, so what you see is the offline behavior. The sample photos are by Trougnouf (Benoit Brummer) from the 2023 ULB graduation ceremony, published on Wikimedia Commons under CC BY-SA 4.0, and they aren't part of the repository, while the frames below show the interface as a photographer would use it.

One burst, one keeper, and a reason under every photo.

The Evidence panel shows the sharpness relative to the best frame, the clipped areas and what the model observed.

Exports only write copies or new companion files.

When Ollama is off, the interface explains what happened, offers a command to copy and a retry button.

Code

carlosjcastro / framejury

A local photo culling tool for event photographers that groups near identical shots, picks the best one of each group with Gemma 4 through Ollama and explains every decision in plain words, while your photos never leave your computer.

Framejury

Framejury is a photo culling tool for event photographers that looks through a folder of photos, groups the shots that are nearly identical, picks the best one of each group and explains the choice in words you can read, check against the evidence and change with a single click. Everything runs on your own computer, which means your photos are never uploaded anywhere and the vision model that compares them runs locally through Ollama.

Demo

A minute and a half with captions and no sound needed. Watch it on YouTube.

Sample photos in the demo are by Trougnouf (Benoit Brummer), from the 2023 ULB graduation ceremony, via Wikimedia Commons, under CC BY-SA 4.0.

Why Framejury exists

After a wedding, a concert or a company event, a photographer comes home with thousands of frames, and a large share of them are bursts of the same moment, so choosing the…

View on GitHub

The repository has a Python package called framejury in backend, a Next.js interface in frontend, and the MIT license together with a security policy and a contributing guide. It needs Python 3.10 or newer, Node.js 20.9 or newer and Ollama, and after pulling the model with ollama pull gemma4:e4b-it-qat the two parts start in separate terminals.

uvicorn framejury.api:app --host 127.0.0.1 --port 8000
npm run dev

A graphics card speeds up the model step, although Ollama also runs on a processor alone, only more slowly, and the analysis can skip the model and work from measurements only. The engine also runs without the interface through python -m framejury analyze <folder>, which writes a report and plain lists of the photos to keep, reject and review, and the backend has 42 tests that use a simulated Ollama connection, so they run without the model, while the history in the repository starts on October 13.

How I Built It

Framejury runs as two local processes, a FastAPI service that handles jobs, thumbnails, manual overrides and exports, and a Next.js 16 interface with React 19 and Tailwind 4 that talks to it, while the open pieces are Gemma 4, in the quantized build gemma4:e4b-it-qat, and Ollama, which serves it on localhost to the engine through a small httpx client.

A group of photos starts with ordinary image analysis, where sharpness is the variance of the Laplacian computed on a six by six grid of tiles over an image reduced to 1,024 pixels and the score is the 90th percentile of those tiles, so a face in focus against a soft background still counts as sharp. Exposure counts the pixels that are nearly white or nearly black, a 64 bit difference hash gives each photo a visual fingerprint, and the capture time comes from EXIF with the file's modified date as a fallback.

A photo joins the current group when it was taken within 12 seconds of the previous one and its hash differs by at most 24 of 64 bits from at least one photo already in the group, both limits being settings in the interface, and by default only the four sharpest photos of each group go on to the model while the rest are rejected right away with their sharpness relative to the best frame, which keeps the cost of a group bounded.

The model receives that shortlist as images and answers with JSON that a schema forces into shape, giving for each photo the number of people, how many of them have closed eyes, an expression score and a subject focus score from 1 to 5, plus the photo it would keep, with thinking turned off and the temperature set to 0. Python rules in decision.py, a file of about 200 lines, then turn those observations and the measurements into a score that follows these weights.

What counts	Points
Sharpness relative to the best photo of the group	up to 60
Subject focus reported by the model	up to 15
Expression reported by the model	up to 15
The model's pick, when both passes agree	5
Hard flag, which means under 60% of the best sharpness, subject focus of 2 or less, any closed eyes, more than 25% blown highlights or more than 40% crushed shadows	minus 50
Soft flag, which means an expression of 2 or less	minus 15

The model's vote is worth 5 points out of a possible 95, so Gemma works as a witness whose observations feed the rules and never as the judge, and a keeper that carries a hard flag becomes Review instead of Keep, while a group whose two best scores are within 5 points is flagged as needing a look and the runner up's reason starts with a note that it's very close to the kept photo.

Language models tend to favor the image that comes first, so each group is judged twice with the order reversed and the model's pick only counts when both passes agree, and when they disagree the rules decide on the measurements alone.

The most instructive bug came from the notes, because Gemma kept writing sentences such as "the second image has closed eyes", which mean nothing on the card of a single photo, so I changed the prompt to ask for a description of each photo on its own and added a filter that discards any sentence pointing at a photo by position, in English or in Spanish, which makes the card fall back to the reason written by the rules.

The same distrust applies to the closing note that the model can write after an analysis, since the engine gives it only a JSON of facts and discards the answer if it mentions a file name or a number that isn't in those facts, letting a template write a plain note instead, which is also what happens when Ollama can't be reached.

Because the engine reads private photos, it listens only on 127.0.0.1, refuses any host name other than localhost and 127.0.0.1, rejects requests that change something when they come from another origin, and checks that every thumbnail path stays inside the folder the user chose.

Nothing about the analysis is locked in, since the advanced options let the user choose which criteria count among sharpness, exposure, closed eyes, subject focus and expression, limit the file types to JPEG, PNG, WebP or RAW, include subfolders, skip files by pattern, adjust the time window, the similarity threshold, the number of candidates and the strictness about soft shots, and compare a selection chosen by hand as one group, with the reasons written in English or in Spanish.

On the interface side, the home page checks that Ollama and the model are ready before anything starts and every failure becomes a plain message with a command to copy, each decision is shown with an icon and a corner mark that differ between Keep, Review and Reject so color is never the only signal, buttons expose their pressed state and are at least 44 pixels tall on phones, and animations follow the reduced motion setting unless the user opts in with a switch in the header, while a print view turns the results into a PDF that can be sent to a client.

Exports copy the Keep and Review photos into a framejury-export folder next to the originals, bringing along RAW and JPEG pairs and existing sidecar files and adding the rejects too if the user asks, a CSV lists every decision with its reason and measurements, and optional XMP sidecars carry a color label, green for Keep and red for Reject, without overwriting any sidecar that already exists, an option that is marked experimental in the interface because Lightroom reads those labels for RAW files and ignores them for JPEG, and I haven't opened the sidecars in Lightroom myself.

I used Claude as an assistant for guidance, code review and fixing errors, including drafts of some of the fixes, and I ran, tested and committed every change myself, and Framejury also depends on the open source work of others, namely Gemma from Google, Ollama, Pillow, NumPy, OpenCV, rawpy, httpx, FastAPI, Uvicorn, Next.js, React and Tailwind, as well as on the sample photos credited above.

The small Gemma model has the weaknesses of a small model, since the notes it writes are often generic, closed eyes are harder to detect behind glasses or on small faces and RAW files are judged from their embedded preview and not from the full sensor data, while the Review status is rare because close calls stay as Keep or Reject with a flag on the group, which is also why the header can say zero reviews while the results page counts photos that deserve a look. One burst in the Wikimedia set also split into three groups because its frames had been cropped differently, and I would fix these points first.

Why Does Open Innovation Matter?

A cloud service needs the photos to leave the photographer's computer, and for client work that decision isn't always the photographer's to make, whereas with Gemma running through Ollama the only network use is the single download of the model, plus the packages and fonts needed to install and start the interface, so the analysis itself works in a venue or on a train without a connection.

Cost follows the same logic, since a group can send up to eight image evaluations to the model, four photos in two passes, and a hosted vision API would bill each of them on every run, while a local model costs electricity on a machine the photographer already owns.

Control is the third reason, because the engine lists the models installed in Ollama and flags which ones can see images, so a photographer with a stronger graphics card can pick a larger model in the advanced options and one with an older computer can pick a smaller one without waiting for me, and a pinned local model at temperature 0 also behaves next month the way it does today, while a hosted model can change underneath the tool and quietly alter the decisions on a folder that was already delivered.

The rules are the last piece, and they're ordinary Python that anyone can read and change, so much so that the contributing guide asks that new criteria arrive as readable rules in decision.py and not as hidden behavior inside a prompt, and a closed API would have given me a faster first version but not a tool I could ask a photographer to trust with a client's photos.

Prize Categories

I'm entering Best Use of Gemma, because Framejury runs Gemma 4 locally through Ollama to judge closed eyes, expression and subject focus with structured output, asks it twice in opposite order to reduce position bias, and lets the user swap the model for any other vision model installed on their machine.

If you shoot events, which decisions would you still want to make yourself, and what would a culling tool have to show you before you trusted its keepers?

How to trace and evaluate an AI agent in Microsoft Foundry, from the first trace to production monitoring

Carlos José Castro Galante — Thu, 15 Oct 2026 23:04:16 +0000

Microsoft Foundry splits agent observability into three capabilities, and each one answers a different question. Tracing shows what the agent did during a run, evaluation scores how good its answers were against criteria you choose, and monitoring keeps asking both questions once the agent is in front of users. This post goes through them in the order you'll usually need them, using the official Python samples, and it says which parts Microsoft labels as generally available and which as preview, because that label decides how much weight each piece can carry.

What's generally available and what isn't

Tracing is generally available for prompt agents and hosted agents, while workflow agents and external agents are still in preview. Microsoft's Build announcement from June 3, 2026 says tracing and evaluations reached general availability in the spring, but the reference pages still attach preview labels to individual pieces. On the agent evaluators page, Task Adherence, Task Completion, Intent Resolution, Customer Satisfaction, Output Quality and Tool Use Quality are labeled preview, while the tool evaluators such as Tool Call Accuracy don't carry any label at all. On the monitoring page, agent metrics, recurring evaluations, red team scans and alerts are labeled preview, and the page says Microsoft doesn't recommend its preview items for production workloads. The GitHub Action for evaluations is in preview too. I checked these labels on October 14, 2026, and since they change quickly, it's worth reopening the linked pages before you build on any of them.

Step 1, connect Application Insights and read your first trace

Tracing for prompt agents and hosted agents works on the server side, so you don't need to change anything in your code. With the New Foundry toggle turned on, open your project, go to Agents, select Traces and choose Connect, then attach an existing Application Insights resource or create a new one. From that point the runs of an agent hosted in Foundry are recorded through OpenTelemetry, including the model calls, the tool invocations, the decisions the agent took and its dependencies on other services, as described in the observability overview.

To read the traces you'll need the Log Analytics Reader role on the connected Application Insights resource, plus Privileged Monitoring Data Reader when the underlying Log Analytics tables are protected. After you run the agent once, the Traces tab lets you search, filter and sort the traces from the last 90 days, open one to step through its spans, or search by Response ID or Trace ID and open a Conversation ID to see the history, token counts, run steps, tool calls, inputs and outputs. If nothing shows up, the setup page recommends waiting a few minutes and refreshing before you head to its troubleshooting section. That page also covers client side tracing with azure-core-tracing-opentelemetry, which is optional and meant for the code of your own application.

Step 2, evaluate the agent with a small dataset

A trace tells you what happened but not whether the answer was good, and that's the job of evaluation. The sample below follows the official page on evaluating your AI agents, with the rubric generation step removed so it only uses evaluators that ship with Foundry. You'll need the Foundry User role on the project, which Microsoft renamed from Azure AI User without changing the role IDs, and a chat completion model deployment that acts as the judge for the evaluators that use a model.

That page asks for azure-ai-projects 2.4.0 or later, while other pages in the same documentation list lower minimums, so it's safer to install the latest release.

pip install "azure-ai-projects>=2.4.0" azure-identity

Set the environment variables AZURE_AI_PROJECT_ENDPOINT and AZURE_AI_MODEL_DEPLOYMENT_NAME, then create a JSONL file called test-queries.jsonl where each line holds a query field. These three lines are only example questions, so swap them for the questions your agent gets.

{"query": "What is the difference between an Azure region and an availability zone?"}
{"query": "When should I use Azure Functions instead of a virtual machine?"}
{"query": "How do I stop a storage account from being publicly accessible?"}

The first part of the script creates the clients and uploads the dataset to your project.

import os
import time

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient

endpoint = os.environ["AZURE_AI_PROJECT_ENDPOINT"]
model_deployment = os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"]
AGENT_NAME = "my-agent"  # replace with the name of your agent

project_client = AIProjectClient(endpoint=endpoint, credential=DefaultAzureCredential())
client = project_client.get_openai_client()

dataset = project_client.datasets.upload_file(
    name="agent-test-queries",
    version="1",
    file_path="./test-queries.jsonl",
)

The second part defines what to measure and creates the evaluation. Coherence is scored by the judge deployment, while Violence comes from the risk and safety group, which the official sample runs without a judge deployment.

from azure.ai.projects.models import TestingCriterionAzureAIEvaluator
from openai.types.eval_create_params import DataSourceConfigCustom

testing_criteria = [
    TestingCriterionAzureAIEvaluator(
        type="azure_ai_evaluator",
        name="Coherence",
        evaluator_name="builtin.coherence",
        initialization_parameters={"deployment_name": model_deployment},
        data_mapping={
            "query": "{{item.query}}",
            "response": "{{sample.output_text}}",
        },
    ),
    TestingCriterionAzureAIEvaluator(
        type="azure_ai_evaluator",
        name="Violence",
        evaluator_name="builtin.violence",
        data_mapping={
            "query": "{{item.query}}",
            "response": "{{sample.output_text}}",
        },
    ),
]

data_source_config = DataSourceConfigCustom(
    type="custom",
    item_schema={
        "type": "object",
        "properties": {"query": {"type": "string"}},
        "required": ["query"],
    },
    include_sample_schema=True,
)

evaluation = client.evals.create(
    name="Agent Quality Evaluation",
    data_source_config=data_source_config,
    testing_criteria=testing_criteria,
)

The third part starts the run. With the azure_ai_target_completions source, Foundry sends every query to the agent named in the target and evaluates the answers it gets back, which is why the mappings above read from sample.output_text.

eval_run = client.evals.runs.create(
    eval_id=evaluation.id,
    name="Agent Evaluation Run",
    data_source={
        "type": "azure_ai_target_completions",
        "source": {"type": "file_id", "id": dataset.id},
        "input_messages": {
            "type": "template",
            "template": [
                {
                    "type": "message",
                    "role": "user",
                    "content": {"type": "input_text", "text": "{{item.query}}"},
                }
            ],
        },
        "target": {"type": "azure_ai_agent", "name": AGENT_NAME},
    },
)

while True:
    run = client.evals.runs.retrieve(run_id=eval_run.id, eval_id=evaluation.id)
    if run.status in ["completed", "failed"]:
        break
    time.sleep(5)

print(f"Status: {run.status}")
print(f"Report URL: {run.report_url}")

In the response, result_counts gives the total, passed, failed and errored rows, per_testing_criteria_results breaks the same numbers down by evaluator, and each row carries a score, a label, a reason, a threshold and a passed flag for every evaluator. The report_url opens the same results in the Foundry portal, where they also show up under the Evaluations tab, and the reason field is where I'd start reading when a row fails.

If your agent calls tools, the tool use evaluators are the ones worth adding next. Tool Call Accuracy checks that the agent made the right calls with correct parameters and without redundancy, Tool Selection checks that it chose the tools it needed and no extra ones, Tool Input Accuracy checks the parameters, Tool Output Utilization checks whether the agent used the results correctly, and Tool Call Success checks that the calls ended without technical errors. Four of them take tool_definitions as an input, and Tool Call Accuracy scores on a scale of one to five before a threshold turns that score into a pass or a fail.

What it costs and where it's restricted

Risk and safety evaluations, which include the Violence evaluator used above, and agents playground evaluations are billed on consumption, and playground evaluations are enabled by default for every Foundry project. To turn them off, clear all the evaluators in the playground's metrics selector. Some features also have regional restrictions, namely rubric generation, synthetic and trace based dataset creation, and the risk and safety evaluators, so check the supported regions before you run the sample in a project you already have. The monitoring data itself lives in the connected Application Insights resource, so its retention and billing follow however you've configured that resource.

Step 3, keep evaluating after release

The monitoring page describes continuous evaluation, which runs an evaluation on sampled traffic while the agent serves users. The code below creates an evaluation with an azure_ai_source and attaches a rule that runs it whenever a response from the named agent completes. The project managed identity needs the Foundry User role for continuous evaluation rules to run, and the rule is capped by max_hourly_runs, which the sample sets to 100 and which Microsoft documents as the default limit per hour. Once the cap is reached, further runs are skipped until the next hour or until you raise the value.

import os

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import (
    EvaluationRule,
    ContinuousEvaluationRuleAction,
    EvaluationRuleFilter,
    EvaluationRuleEventType,
)

endpoint = os.environ["AZURE_AI_PROJECT_ENDPOINT"]
agent_name = os.environ["AZURE_AI_AGENT_NAME"]

with (
    DefaultAzureCredential() as credential,
    AIProjectClient(endpoint=endpoint, credential=credential) as project_client,
    project_client.get_openai_client() as openai_client,
):
    eval_object = openai_client.evals.create(
        name="Continuous Evaluation",
        data_source_config={"type": "azure_ai_source", "scenario": "responses"},
        testing_criteria=[
            {
                "type": "azure_ai_evaluator",
                "name": "violence_detection",
                "evaluator_name": "builtin.violence",
            }
        ],
    )

    rule = project_client.evaluation_rules.create_or_update(
        id="my-continuous-eval-rule",
        evaluation_rule=EvaluationRule(
            display_name="My Continuous Eval Rule",
            description="Runs on agent response completions",
            action=ContinuousEvaluationRuleAction(
                eval_id=eval_object.id, max_hourly_runs=100
            ),
            event_type=EvaluationRuleEventType.RESPONSE_COMPLETED,
            filter=EvaluationRuleFilter(agent_name=agent_name),
            enabled=True,
        ),
    )
    print(f"Rule created (id: {rule.id})")

To read the results, open the agent in the Foundry portal and select Monitor. The dashboard shows token usage, latency, run success rate, evaluation metrics and red teaming results for the time range you pick, and the documentation gives two starting points for interpreting it. Latency above ten seconds may point to model throttling, complex tool calls or network issues, and a run success rate below 95 percent warrants an investigation of the failed runs.

Running the same evaluation on every commit

You can also run the evaluation from Step 2 in a pipeline through the microsoft/ai-agent-evals@v3-beta GitHub Action, which the documentation labels as preview. The step below goes after the checkout and an Azure login step that uses OpenID Connect, so the workflow also needs the id-token: write permission and the client, tenant and subscription IDs stored as GitHub Actions variables.

      - name: Run Evaluation
        uses: microsoft/ai-agent-evals@v3-beta
        with:
          azure-ai-project-endpoint: "<your-ai-project-endpoint>"
          deployment-name: "<your-deployment-name>"
          agent-ids: "<your-ai-agent-ids>"
          data-path: ${{ github.workspace }}/path/to/your/data-file

The agent-ids input takes values such as my-agent:1,my-agent:2, an optional baseline-agent-id sets the version used as the comparison, and the results show up in the workflow run summary with the score of each metric, confidence intervals and, when you compare several agents, a pairwise statistical comparison that tells you whether a difference is meaningful or just random variation. That makes it a reasonable quality gate for changes to an agent's instructions or model, since the same dataset runs against both versions.

If you'd rather see the three pieces working together before you try them, the Azure Friday episode Observe and evaluate agents for quality and safety in Microsoft Foundry walks through evaluation, tracing and monitoring with a live demo in the Foundry portal and in Visual Studio Code.

Which of those three questions is the hardest to answer about your agents today, what they did, how good their answers were, or whether they stay that good after release?

How I prepared for the AZ-900 and why it's the certification where you should start with Azure

Carlos José Castro Galante — Tue, 29 Sep 2026 00:49:31 +0000

In 2023, when I prepared for the AZ-900, I was studying Computer Science and had limited hands-on experience with cloud infrastructure. What stood out when studying was the exam's scope: it doesn't start with Azure services but with cloud computing fundamentals, which makes it useful for both technical and non-technical profiles.

The AZ-900 (Microsoft Azure Fundamentals) is the introductory certification to the Azure ecosystem. It doesn't require prior tech experience, doesn't assume knowledge of programming, and doesn't expect you to have administered a server. It's designed for anyone who wants to understand how Microsoft's cloud works, both from the technical side and the organizational and financial one.

How I got to this exam

I got access through a program run by Microsoft and the Fundación Tomás Alva Edison in Mendoza, Argentina. The foundation has a partnership with Microsoft to bring these certifications to students and young people in the region.

Today the exam is available through two channels. Most people book it through Pearson Vue, either in person at an authorized testing center or remotely from home through its OnVUE system. Students and educators can also book it through Certiport, which was the platform I used myself back in 2023 and remains active today as an option for that audience.

I'm a Microsoft Student Ambassador, and part of what I do in that role is help other students work through this same path. That's why I put together a study plan on Microsoft Learn that organizes all the official modules in the order I'd recommend going through them: AZ-900 Study Plan. You can start it right now while you read this.

What the exam covers

The AZ-900 has between 40 and 60 questions, requires a minimum score of 700 out of 1000 to pass, and you'll have 45 minutes to complete the assessment. There are no hands-on labs or case studies, and there's no penalty for wrong answers, so it's always worth answering even when you're not sure.

The cost is $99 USD in the United States, though Microsoft adjusts pricing by country. In Argentina, the official price is $59 USD. Check the exact price for your region on the official scheduling page before booking.

The content is organized into three major areas.

Cloud concepts

The first area covers foundational concepts and is the most theoretical of the three. Before getting into Azure services specifically, the exam evaluates whether you understand what the cloud is and why it exists.

The consumption model

One of the most important concepts is the difference between CapEx and OpEx. CapEx (Capital Expenditure) is the upfront investment in physical infrastructure you own: you buy servers, set them up, maintain them, and that cost stays with you for the life of the equipment. OpEx (Operational Expenditure) is the operating expense model: you pay for what you use, when you use it, with no upfront hardware investment. The cloud operates under OpEx, and that shifts the financial equation entirely, especially for smaller organizations.

The service models

IaaS (Infrastructure as a Service) gives you the highest level of control. You rent the infrastructure (virtual servers, networking, storage) and you manage everything running on top: the operating system, middleware, applications, and data. A virtual machine on Azure is the clearest example. Think of it like renting an empty apartment where the building is already there but you decide everything that goes inside.

PaaS (Platform as a Service) removes the responsibility for the operating system and underlying infrastructure. You get a ready-to-use environment for building and deploying applications. Azure App Service fits here: you push your code and the platform handles the rest. It's like working at a coworking space where the desk, internet, and infrastructure are already set up and you just show up to work.

SaaS (Software as a Service) is the model most people use every day without thinking about it. Microsoft 365, Teams, Gmail, and Notion are all SaaS. You use a finished application without thinking about any of the infrastructure underneath.

Deployment models

Public cloud is infrastructure the provider shares across multiple customers. Private cloud is infrastructure dedicated exclusively to a single organization. Hybrid cloud combines both, which is especially useful for organizations with legacy systems they can't fully migrate.

The study plan covers all of this with hands-on exercises where you can practice without needing your own subscription.

Azure architecture and services

This is the most extensive area of the exam and the one that covers the greatest number of individual services. It's also the one that requires the most study time.

Regions and availability zones

Azure is physically distributed across more than 70 regions worldwide. A region is a geographic area containing one or more datacenters. When you create a resource, you choose which region it lives in, and that choice affects latency, cost, and your organization's data residency requirements.

Within many regions there are availability zones, which are physically separate datacenters within that same region, connected by low-latency networks. If one zone fails, the others keep running. Azure also has region pairs: each primary region has a secondary region that's geographically distant, for disaster recovery at a larger scale.

Subscriptions and resource groups

Every Azure resource lives inside a well-defined hierarchy. The top level is the Microsoft Entra ID tenant, which represents your organization. Within the tenant there are subscriptions, which are the billing unit. Within each subscription you create resource groups, which are logical containers that group related services for a project or application. Every Azure resource always belongs to exactly one resource group.

Compute

Azure Virtual Machines are the classic IaaS model: a full server in the cloud that you manage from the operating system upward. They're the most flexible option and also the one that carries the most management overhead.

Azure App Service is the PaaS platform for web apps and APIs. It supports .NET, Java, Node.js, Python, and PHP, and you don't manage the underlying server.

Azure Functions is the serverless option. Functions execute only when something triggers them (an HTTP request, an event, a queue message) and you pay only for actual execution time.

Azure Kubernetes Service (AKS) is the managed Kubernetes service for orchestrating containers at scale. Azure Container Instances is the simpler option for running individual containers without needing a full cluster.

Networking

A Virtual Network (VNet) is the private network where your Azure resources live. You can segment it into subnets, control traffic with Network Security Groups (NSGs), and connect your on-premises network to Azure through VPN Gateway or Azure ExpressRoute, which provides a private dedicated connection that doesn't go through the public internet.

Azure Load Balancer distributes traffic across multiple instances to ensure availability. Azure Application Gateway does something similar at the application layer and includes a Web Application Firewall. Azure CDN brings static content closer to users by distributing it across points of presence around the world.

Storage

Azure Blob Storage is Azure's object storage service, designed for unstructured data like files, images, videos, and backups. It has three access tiers based on how frequently data is needed: Hot for frequent access, Cool for data accessed less than once a month, and Archive for data that's rarely retrieved and where hours of retrieval latency is acceptable.

Azure Files provides a shared file system compatible with the SMB protocol and accessible from Windows, Linux, and macOS. Azure Queue Storage is a messaging service for decoupling components of an application.

On the redundancy side, LRS replicates data three times within a single datacenter, ZRS replicates across availability zones, GRS replicates to a secondary region, and GZRS combines zone redundancy with geo-replication.

Identity and access

Microsoft Entra ID (formerly Azure Active Directory) is Microsoft's cloud identity service. It manages authentication and authorization for Azure, Microsoft 365, and third-party applications.

Role-Based Access Control (RBAC) lets you assign specific permissions to users, groups, or service identities over specific resources, following the principle of least privilege. The most common built-in roles are Owner, Contributor, and Reader.

Multi-Factor Authentication (MFA) adds a second verification layer beyond the password. Conditional Access lets you define policies that evaluate the context of an access attempt, such as location, device, or application, before allowing or blocking it.

Management and governance

The third area covers how to manage, monitor, and control costs in Azure. It's the one most people underestimate during study and the one that carries real weight in the actual exam.

Management tools

The Azure Portal is the main web interface for creating and managing resources. Azure CLI and Azure PowerShell are the command-line alternatives for those who prefer automation or scripting. Azure Cloud Shell is a terminal available directly from the browser, with Azure CLI and PowerShell already configured, with no local installation needed.

Azure Resource Manager (ARM) is the layer that processes all resource creation, modification, and deletion requests, whether they come from the portal, the CLI, or an API. ARM templates and Bicep allow you to define infrastructure as code and deploy it repeatably.

Azure Arc extends Azure's management capabilities to resources running outside of Azure, like servers in other clouds or in on-premises datacenters.

Costs

Azure Cost Management lets you see your detailed spending, set budgets, and configure automatic alerts when consumption approaches a defined limit. The Azure Pricing Calculator helps estimate the cost of an architecture before deploying anything. The Total Cost of Ownership (TCO) Calculator helps compare the cost of maintaining on-premises infrastructure against migrating to the cloud.

Pay-as-you-go lets you pay for what you use with no prior commitments. Azure Reservations let you reserve specific capacity for one or three years in exchange for discounts of up to 72% compared to the pay-as-you-go price.

Governance

Azure Policy lets you define and enforce rules on resources within a subscription, for example requiring that all new resources have mandatory tags, or restricting which VM sizes can be created. Resource Locks protect critical resources from accidental deletion or modification, even for accounts with administrator-level permissions.

Monitoring

Azure Monitor is the platform's central monitoring service. It collects metrics and logs from all your resources and lets you create alerts, dashboards, and analysis workbooks.

Application Insights is an Azure Monitor extension built specifically for applications. It tracks response times, exceptions, dependencies, and user behavior in real time.

Azure Service Health reports on the current status of Azure services in each region and on any incidents or planned maintenance that might affect your resources.

Microsoft Defender for Cloud assesses the security posture of your resources and generates concrete recommendations for reducing risk.

How to prepare

Study time varies depending on your background. Without any prior tech experience, two to four weeks of consistent study is realistic. With a technical foundation already in place, under two weeks is very doable.

Microsoft Learn has the official learning path completely free, with interactive modules and sandboxes where you can practice directly in Azure without needing your own subscription or a credit card. Microsoft also offers a free official practice assessment that lets you get familiar with the real exam format before the day you sit for it.

The free Azure account includes $200 in credit to use within your first 30 days, plus permanent access to a set of always-free services. It's useful for experimenting beyond Learn's sandboxes.

The study plan I put together organizes the Microsoft Learn modules in the order I'd recommend working through them, grouped by exam area. You can complete each module at your own pace and track your progress as you go.

To close

Once you pass the AZ-900, the natural next steps on the technical Azure path are the AZ-104 (Administrator) or the AZ-204 (Developer). On the AI side, the AI-900 is the equivalent introductory cert before moving to the AI-102 or AI-103.

If you'd like to study alongside others, on October 15 we're organizing an event where we'll go through the most important exam topics together. Leave a comment or reach out directly if you're interested.

The study plan is already there: AZ-900 Study Plan on Microsoft Learn.

Azure Multicloud Interconnect, how Azure and AWS now connect without a middleman

Carlos José Castro Galante — Tue, 22 Sep 2026 15:26:57 +0000

A private connection between an Azure VNet and an AWS VPC has traditionally required assembling Azure ExpressRoute, AWS Direct Connect, a connectivity provider or colocation footprint, customer-managed routers, BGP sessions, and link-layer encryption, then owning the resiliency design and day-to-day operations across all of it. The result was typically slow to deliver, difficult to troubleshoot, and inconsistent in performance.

On August 31, 2026, Microsoft and AWS jointly announced Azure Multicloud Interconnect, a co-engineered managed service that replaces that assembly with a single interconnect resource, turning the private path between clouds into something you provision rather than something you build.

For the official overview and creation guide: What is Azure Multicloud Interconnect?

What the service actually is

Azure Multicloud Interconnect isn't a rebranding of ExpressRoute with a different interface but rather a new resource type that sits on top of ExpressRoute's infrastructure and abstracts everything on both sides of the connection. Under the covers, Microsoft and AWS coordinate the circuits, routing, and encryption on your behalf using the open API specification for network interoperability that AWS introduced at re:Invent 2025 and brought to general availability in April 2026. Microsoft adopted that specification for Azure.

The physical design is quad-redundant with a 400G-class backbone and MACsec encryption at the hardware layer, which means the encryption happens at the link level without consuming host CPU resources on either end. Without any of that configuration on your part, you create an interconnect resource, exchange an activation key with the AWS side, and the managed path between your Azure Virtual Network and your AWS VPC is ready.

The distinction from ExpressRoute comes down to what you're managing: with a traditional ExpressRoute circuit connected to AWS through a carrier, you're the systems integrator for the full stack, while with Azure Multicloud Interconnect, Microsoft and AWS own the underlying complexity and you consume the outcome.

For a detailed look at how the service fits into the existing connectivity landscape: Azure Multicloud Interconnect FAQ

How provisioning works

The setup process moves through four stages. The first is creating an ExpressRoute circuit and selecting the Azure Multicloud Interconnect port type rather than a carrier-based port. The second is creating the Interconnect resource itself, which generates the activation key that coordinates the connection between providers. The third is provider setup on the AWS side, where you redeem the activation key and select the Direct Connect Gateway that the connection terminates on. The fourth is connecting your Azure Virtual Networks through an ExpressRoute gateway so that workloads in your Azure VNet and workloads in your AWS VPC can communicate over the managed path.

Both sides must use separate, non-overlapping IP address spaces, which is a standard requirement for any BGP-routed private connection.

On the AWS side, the experience mirrors what AWS already provides for Google Cloud and Oracle Cloud Infrastructure through AWS Interconnect, so teams that have already connected AWS to another cloud provider using that service will find the workflow familiar.

What the preview limits mean in practice

The Azure preview launched with constraints worth understanding before building production plans on top of it.

Throughput during preview is capped at 1 Gbps, while the Google Cloud pairing, which reached general availability in April 2026, already supports up to 100 Gbps. AWS confirmed that general availability for the Azure connection is expected to reach the same ceiling eventually, but the timeline isn't published. For workloads that move large volumes of data between clouds, whether for AI training pipelines, database replication, or large-scale analytics, 1 Gbps is a meaningful constraint. For control-plane traffic, API calls between microservices split across providers, or proof-of-concept deployments, it's sufficient.

There's no SLA during preview, which is standard for preview services but matters for teams evaluating the service for anything that needs an uptime commitment from the provider.

Regional availability in preview covers four Azure regions: Australia East, East US, Germany West Central, and West US, each paired with a corresponding AWS region: Asia Pacific (Sydney), US East (N. Virginia), Europe (Frankfurt), and US West (N. California). Cross-region connectivity isn't supported during preview, meaning an Azure VNet in East US connects to the AWS US East (N. Virginia) pair and can't route through a different region pair.

The official source for current supported regions, bandwidth tiers, and SLA status: Azure Multicloud Interconnect product page

How it differs from ExpressRoute

The FAQ for the service makes the distinction explicit: choose Azure Multicloud Interconnect for managed connectivity between Azure and a supported cloud service provider, and choose ExpressRoute for on-premises, colocation, carrier-based connectivity, or Microsoft peering scenarios. The two aren't alternatives for the same use case because they're designed for different connectivity targets that happen to share the same underlying technology.

An important implication is that existing ExpressRoute circuits don't automatically become Multicloud Interconnect resources, so if you're already connecting Azure and AWS through an ExpressRoute circuit over a carrier, the new service requires provisioning a new resource with the Azure Multicloud Interconnect port type, which is a separate circuit from what you may already be paying for.

The broader context

Azure Multicloud Interconnect launched as part of a pattern AWS established with the open interoperability specification it published at re:Invent 2025. Google Cloud was the first provider to adopt the specification and reached general availability with AWS in April 2026. Oracle Cloud Infrastructure entered preview in May and reached general availability in July, and Azure followed into preview in August.

That sequence matters for teams comparing the maturity of each pairing. The Google Cloud and OCI connections through AWS Interconnect have already moved through preview and into production-grade service with published SLAs and higher bandwidth tiers. The Azure pairing is earlier in that lifecycle, but the underlying specification is the same and the GA trajectory follows the same path the other pairings already completed.

For the full technical announcement from the Azure Networking team: Simpler, private connectivity between Azure and AWS with Azure Multicloud Interconnect

References

Information based on official Microsoft and AWS documentation as of September 2026. Azure Multicloud Interconnect is in public preview and service capabilities including supported regions, bandwidth tiers, and SLA status are subject to change. Always verify current status at Microsoft Learn before building production architectures on preview features.

Azure Developer CLI, from zero to deployed in three commands

Carlos José Castro Galante — Fri, 18 Sep 2026 16:00:00 +0000

Deploying an application to Azure by hand means provisioning resources in the portal, noting their connection strings, configuring environment variables, writing a deployment script, setting up a CI/CD pipeline, and repeating most of that process every time you start a new project or add a new environment. The Azure Developer CLI, known as azd, replaces that sequence with a small set of commands that handle provisioning, deployment, and environment management together instead of as separate concerns you have to coordinate manually.

This post covers what azd actually does, how to use it with a Next.js project, the configuration file that makes everything work, the commands you will use daily, and the significant updates that shipped in 2026, including multi-language hooks in April, the azd tool command group in May, and the extension framework reaching general availability in August.

For the official overview and installation guide: Azure Developer CLI overview on Microsoft Learn

What azd does differently from the Azure CLI

The Azure CLI (az) is a general-purpose interface to Azure's API that gives you a command for every Azure operation without an opinion about how your project is structured or how to coordinate provisioning and deployment together. azd is opinionated. It assumes your project has infrastructure code, application code, and one or more environments, and it provides commands that work across all three at once.

The workflow azd enables is: write your application, define your infrastructure with Bicep or Terraform, describe the mapping between them in azure.yaml, and then use three commands for everything else. azd init to set up the project, azd provision to create Azure resources, and azd deploy to push your code. azd up does the last two in a single step. azd down tears everything down when you're done.

Installation

# macOS
brew tap azure/azd && brew install azd

# Windows (winget)
winget install microsoft.azd

# Linux
curl -fsSL https://aka.ms/install-azd.sh | bash

# Verify
azd version

The current version as of August 2026 is 1.32.0. azd updates frequently with monthly releases, so running azd version after installation is worth doing to confirm you have a current build.

To install azd for the first time or update your installation: Install or update the Azure Developer CLI

The azure.yaml file

The azure.yaml file at the root of your project is what azd reads to understand how your application maps to Azure. A typical file for a Next.js app looks like this:

name: my-nextjs-app
metadata:
  template: my-nextjs-app@0.0.1-beta

services:
  web:
    project: .
    language: js
    host: appservice

hooks:
  preprovision:
    shell: sh
    run: ./scripts/setup-env.sh
  postdeploy:
    shell: sh
    run: ./scripts/verify-deployment.sh

The services section maps each part of your application to an Azure host. The hooks section runs scripts at specific points in the provisioning and deployment lifecycle. Starting in April 2026, hooks support Python, JavaScript, TypeScript, and .NET alongside the existing Bash and PowerShell options, with automatic dependency management so you don't have to install anything separately.

hooks:
  preprovision:
    shell: pwsh
    run: ./scripts/preflight.ps1
  postprovision:
    language: python
    run: ./scripts/seed-database.py
  predeploy:
    language: typescript
    run: ./scripts/build-check.ts

For the complete azure.yaml schema reference: azure.yaml schema documentation

Core commands

azd init sets up a new project either from a template in the gallery or from your existing codebase:

# Initialize from a template
azd init --template todo-nodejs-mongo

# Initialize from the current directory
azd init

azd provision creates the Azure resources defined in your Bicep or Terraform files without deploying any application code, which is useful when you want to inspect or validate infrastructure separately from your deployment:

azd provision

# Override subscription and location without changing config
azd provision --subscription your-subscription-id --location eastus

The --subscription and --location flags arrived in February 2026 and make it straightforward to provision to different targets per environment without modifying azure.yaml.

azd deploy pushes your application code to the already-provisioned resources:

azd deploy

# Deploy a specific service only
azd deploy --service web

azd up runs provision and deploy together, which is what you will use most of the time, and azd down deletes all resources associated with the current environment:

azd up

azd down

# Delete without confirmation prompt
azd down --force --purge

Environment management

azd manages environments as named collections of configuration values that persist between commands, where each environment stores the Azure subscription, location, and any variables your infrastructure needs:

# Create environments for different stages
azd env new staging
azd env new production

# Switch between environments
azd env select staging
azd up

azd env select production
azd up

# See all environments and their active status
azd env list

# Get all values from the active environment
azd env get-values

Each environment maps to a separate set of Azure resources, so staging and production never share infrastructure even when they come from the same template.

The azd tool command group

One of the more useful additions that shipped in May 2026 is azd tool, a unified command group for discovering, installing, and managing Azure development tools directly from the CLI without hunting for separate install documentation:

# List all available tools with their install status and version
azd tool list

# Show details for a specific tool
azd tool show azure-functions-core-tools

# Install a tool
azd tool install azure-functions-core-tools

# Update a tool
azd tool update azure-functions-core-tools

# Uninstall with a dry run first to see what would be removed
azd tool uninstall azure-functions-core-tools --dry-run
azd tool uninstall azure-functions-core-tools

This replaced the pattern of going to separate documentation pages for each tool and running different package manager commands depending on the operating system. The August 2026 release added guidance for bulk removal and per-agent skill output.

The extension framework

The azd extension framework reached general availability in August 2026 and extensions can now be installed directly from an HTTPS URL without registering a source first:

# Install an extension from the official registry
azd extension install microsoft.azd.extensions.foundry

# Install directly from a URL
azd extension install https://your-server.com/my-extension.tar.gz

# List installed extensions
azd extension list

Microsoft ships two extensions worth knowing. The azd AI agent extension for Microsoft Foundry integrates azd workflows with Foundry projects, and the GitHub Copilot coding agent configuration extension sets up the configuration Copilot needs to understand and work with your azd project. Both are available through the official extension registry.

CI/CD pipeline integration

azd can configure a GitHub Actions or Azure DevOps pipeline for your project with a single command that creates the workflow files, sets up the necessary federated credentials, and configures the repository secrets azd needs to run in CI:

azd pipeline config

Starting in August 2026, federated authentication support for Azure DevOps is documented and supported, replacing the older approach that required managing client secrets manually.

For CI/CD pipeline setup: Explore Azure Developer CLI support for CI/CD pipelines

Templates

The template gallery is the fastest way to get a complete azd-ready project structure without writing Bicep from scratch, where each template includes the azure.yaml, the infrastructure definitions, and often the application scaffolding:

# Browse and select a template interactively
azd init

# Initialize directly from a known template
azd init --template azure-samples/todo-python-mongo-swa-func
azd init --template azure-samples/azure-search-openai-demo
azd init --template azure-samples/chat-with-your-data-solution-accelerator

The AI App Templates gallery is the relevant starting point for anything that involves Azure OpenAI, Azure AI Search, or Microsoft Foundry: azd templates and the template gallery

References

Information based on official Microsoft documentation and verified sources as of September 2026. azd ships monthly releases and some commands or flags may have changed. Always verify current behavior at Microsoft Learn before implementing in production workflows.

Foundry IQ, the knowledge layer that stops every agent from rebuilding its own RAG

Carlos José Castro Galante — Tue, 15 Sep 2026 16:30:00 +0000

Every team that builds more than one AI agent eventually hits the same problem. The first agent gets its own retrieval pipeline with data connectors, chunking logic, embeddings, routing, and permission enforcement. The second agent needs to answer from the same documents, so the pipeline gets duplicated. By the third agent, there's a tangle of fragmented, siloed pipelines that are expensive to maintain and inconsistent in quality, with each one rebuilding the same foundation from scratch.

Foundry IQ is Microsoft's answer to that problem. Rather than adding more tools to the pipeline, it moves the retrieval layer out of each agent and into a shared, managed knowledge layer that multiple agents can query through a single API. The agents stop owning retrieval; they delegate it.

Before going further, it's worth clarifying a naming detail that causes confusion. Microsoft ships three distinct IQ products under the Microsoft Foundry umbrella. Foundry IQ handles enterprise documents and knowledge sources, which is what this article is about. Work IQ is a contextual intelligence layer for Microsoft 365 that captures signals from documents, meetings, chats, and workflows. Fabric IQ models business data in OneLake and Power BI so agents can reason over analytics. They're separate products with different semantics, freshness characteristics, and authorization boundaries. A policy assistant may need only Foundry IQ, while a sales-planning agent might combine Work IQ, Fabric IQ, and web context. This article stays focused on Foundry IQ.

For the official overview of what Foundry IQ is and how it fits into Microsoft Foundry, the Microsoft Learn documentation is the authoritative source: What is Foundry IQ?

What Foundry IQ is built on

Foundry IQ is built directly on Azure AI Search. This is the part most introductions skip over, and it matters for architecture decisions. A Foundry IQ knowledge base is not a separate service sitting next to Azure AI Search. It's a top-level object that lives on your Azure AI Search service and orchestrates agentic retrieval. When you create a knowledge base, you're creating an object in Azure AI Search that defines which knowledge sources to query and how retrieval behaves at query time.

The practical consequence is that you don't choose between Foundry IQ and Azure AI Search. Foundry IQ is the new interface for building agents on top of Azure AI Search, wrapping the underlying search capabilities in a managed, permission-aware, multi-agent-ready layer.

To explore the agentic retrieval capabilities that underpin knowledge bases, the Azure AI Search documentation covers the model in detail: Create a knowledge base in Azure AI Search

Knowledge sources and knowledge bases

Two concepts are foundational to how Foundry IQ is structured. A knowledge source is a connection to data, whether that's an Azure Blob Storage container, a SharePoint site, an OneLake lakehouse, an existing Azure AI Search index, or a web source accessed through the public internet or an MCP server. A knowledge base bundles one or more knowledge sources, up to ten per knowledge base, plus the parameters that control retrieval behavior. The knowledge base is what agents actually query.

The distinction matters because multiple agents can share the same knowledge base. An HR assistant and a policy assistant might both need access to the same document library. With a traditional RAG approach, each agent builds its own pipeline to that library. With Foundry IQ, both agents point at the same knowledge base and the retrieval layer handles routing, permissions, and answer synthesis once.

Knowledge sources come in two classes. Indexed sources are ingested into a search index on your Azure AI Search service, where the content is chunked, vectorized, and kept fresh through an indexer schedule. This class includes existing Azure AI Search indexes, Azure Blob Storage containers, and OneLake lakehouses, and these are generally available in the 2026-04-01 REST API. Federated sources are queried at runtime without pre-ingestion, including web sources and MCP servers, and these remain in preview in the 2026-05-01-preview and 2026-08-01-preview APIs.

GA versus preview: what this means for production

Some of the most useful Foundry IQ features are still in preview, and the distinction matters when deciding what to build on. The 2026-04-01 REST API provides a production-endorsed path with general availability for knowledge bases and core indexed knowledge sources. Features that remain in preview as of the time of writing include answer synthesis using an LLM for query planning and response generation, configurable reasoning effort tiers, document-level permissions, multi-turn conversational retrieval, and most of the portal-based management experience. The Azure portal and Microsoft Foundry portal continue to provide preview-only access to all agentic retrieval features regardless of which API version you use.

For a proof-of-concept or a hackathon project, the preview features are usable and the free tier of Azure AI Search is sufficient to get started. For a production deployment with SLA requirements, it's worth reviewing which specific capabilities you need against the GA boundary before committing to an architecture.

The product page for Foundry IQ on Azure has a current overview of generally available capabilities: Foundry IQ on Azure

Creating a knowledge base programmatically

The Python SDK for working with Foundry IQ knowledge bases uses azure-search-documents version 2026-05-01-preview or later for the knowledge base surface, combined with azure-ai-projects version 2.0.0 or later for the agent integration. Both are available on PyPI with no additional package feeds.

from azure.identity import DefaultAzureCredential
from azure.search.documents.indexes import SearchIndexClient
from azure.search.documents.indexes.models import (
    KnowledgeBase,
    KnowledgeSource,
    SearchIndexKnowledgeSource,
)

credential = DefaultAzureCredential()
search_endpoint = "https://your-search-service.search.windows.net"

index_client = SearchIndexClient(
    endpoint=search_endpoint,
    credential=credential,
    api_version="2026-05-01-preview",
)

knowledge_source = KnowledgeSource(
    name="company-docs-source",
    type=SearchIndexKnowledgeSource(
        index_name="company-documents",
    ),
)

knowledge_base = KnowledgeBase(
    name="company-docs-kb",
    description="Internal company documentation for agent grounding",
    knowledge_sources=[knowledge_source],
)

result = index_client.create_or_update_knowledge_base(knowledge_base)
print(f"Knowledge base created: {result.name}")

This creates a knowledge base that wraps an existing Azure AI Search index. The knowledge base inherits the permissions model of the underlying search service, so access control lists configured on the index are enforced at query time without additional configuration.

Connecting an agent to Foundry IQ

Once the knowledge base exists, connecting a Foundry Agent to it requires declaring the knowledge base as an MCP tool in the agent configuration. The Foundry IQ MCP endpoint is exposed per knowledge base and any MCP-compatible agent can use it.

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import (
    Agent,
    McpTool,
    AgentMcpToolDefinition,
)

project_client = AIProjectClient(
    endpoint="https://your-foundry-project.services.ai.azure.com/api/projects/your-project",
    credential=DefaultAzureCredential(),
)

mcp_tool = McpTool(
    connection_id="your-search-service-connection-id",
    tool_names=["knowledge_base_retrieve"],
    knowledge_base_name="company-docs-kb",
)

agent = project_client.agents.create_agent(
    model="gpt-4.1-mini",
    name="document-assistant",
    instructions="""
        You are an assistant that answers questions about company policy.
        When answering, always use the knowledge base to retrieve relevant information.
        You must never answer from your own training knowledge when company-specific
        information is available in the knowledge base.
        Always cite the source documents in your responses.
    """,
    tools=[AgentMcpToolDefinition(mcp=mcp_tool)],
)

print(f"Agent created: {agent.id}")

The knowledge_base_retrieve tool is what allows the agent to query the knowledge base through agentic retrieval. When the agent receives a question, it uses this tool to plan queries, run parallel searches across the configured knowledge sources, and aggregate results with citations before generating a response.

How agentic retrieval works

The retrieval process that happens when an agent queries a knowledge base is more than a keyword or vector search. The agentic retrieval engine analyzes the incoming query, decomposes it into sub-queries when necessary, searches the configured knowledge sources in parallel using a combination of keyword, vector, and hybrid search depending on the source type, enforces user permissions at query time by checking access control lists and Microsoft Purview sensitivity labels, and returns extractive content with citations that trace each answer fragment back to its source document.

The reasoning effort applied to this process is configurable. Lower effort tiers use fewer tokens and respond faster at the cost of retrieval quality for complex multi-part questions. Higher effort tiers apply more query planning and source selection logic but consume more tokens per request. The appropriate tier depends on the agent's use case and the complexity of the questions it needs to answer.

For production agents, the permission enforcement behavior is particularly relevant. Foundry IQ synchronizes access control lists for supported knowledge sources and enforces them at query time, which means the agent never returns content that the querying user doesn't have permission to see, even if that content exists in the knowledge base. This is handled at the knowledge layer rather than requiring the application to implement permission filtering separately.

The full guide to connecting agents to Foundry IQ knowledge bases, including the current API version requirements and role assignments, is in Microsoft Learn: Connect Agents to Foundry IQ Knowledge Bases

Querying the knowledge base directly

Outside of a Foundry Agent context, knowledge bases can also be queried directly through the Azure AI Search REST API or SDK. This is useful for building custom application layers that need grounded retrieval without using Foundry Agent Service.

from azure.search.documents import SearchClient

search_client = SearchClient(
    endpoint=search_endpoint,
    index_name="company-documents",
    credential=credential,
    api_version="2026-05-01-preview",
)

results = search_client.knowledge_base_retrieve(
    knowledge_base_name="company-docs-kb",
    query="What is the expense reimbursement policy for travel?",
    effort="standard",
    top=5,
)

for result in results:
    print(f"Source: {result['metadata_source']}")
    print(f"Content: {result['content']}")
    print(f"Score: {result['@search.score']}")
    print("---")

The effort parameter controls the reasoning tier applied to the query. Available values depend on which API preview version is being used, with standard being the baseline tier available across versions.

When to use Foundry IQ versus building custom RAG

Foundry IQ makes most sense when the same document corpus needs to serve multiple agents, when permission enforcement at the knowledge layer is a requirement, when the team doesn't want to own the chunking, embedding, and indexer infrastructure, or when the project is already built on Microsoft Foundry and Azure AI Search.

A custom RAG implementation built directly on Azure AI Search makes more sense when the retrieval logic needs behavior that Foundry IQ doesn't expose as a configurable parameter, when the knowledge base abstraction adds more friction than it removes for a single-agent use case, or when specific preview features needed for the project might change in ways that would break a production deployment before reaching GA.

The two approaches aren't mutually exclusive. The underlying Azure AI Search service is the same in both cases, which means migrating from a custom search index to a Foundry IQ knowledge base that wraps the same index is a configuration change rather than a data migration.

References

Information based on official Microsoft documentation and verified sources as of September 2026. Foundry IQ features are actively evolving and some capabilities described may move from preview to general availability or change behavior between API versions. Always verify current status at Microsoft Learn before building production systems.

How to authenticate Azure apps without storing credentials

Carlos José Castro Galante — Sat, 05 Sep 2026 18:22:22 +0000

Every Azure project eventually has the same conversation. Where do we store the connection string? Someone suggests an environment variable, and someone else points out that environment variables end up in deployment pipelines, in Docker compose files, in Terraform state, and occasionally in accidental commits. A secret manager gets proposed, and the secret manager needs its own credentials to access the secrets. The problem recurses.

Managed Identity doesn't solve the secret manager problem by adding another layer. It removes the credential from the equation entirely for workloads running inside Azure, so the application doesn't authenticate with a stored credential but as itself, using an identity that Azure manages automatically.

What Managed Identity actually does

When you enable a Managed Identity on an Azure resource, Azure creates an identity in Microsoft Entra ID tied to that resource's lifecycle. The resource can then request short-lived tokens from the Azure Instance Metadata Service endpoint at 169.254.169.254, which is only reachable from within Azure infrastructure, and those tokens are what the resource uses to authenticate against other Azure services. There's nothing to store, nothing to rotate manually, and nothing that can be leaked in a repository because the credential never exists as a static string anywhere in your codebase or configuration.

The key property from Microsoft's documentation is precise: managed identities give code running on an Azure resource access to other resources without developers needing to handle or put credentials directly into code. The emphasis on "code running on an Azure resource" matters because Managed Identity only works from within Azure. A local development machine can't reach the Instance Metadata Service endpoint, which means the local development flow still needs an alternative authentication mechanism, typically az login or a service principal configured for development only.

System-assigned vs user-assigned

There are two types of Managed Identity, and Microsoft's current recommendation, updated in its official best practice documentation, is that user-assigned identities are more efficient in a broader range of scenarios.

A system-assigned identity is created directly on a resource and its lifecycle is tied to that resource, so when the resource is deleted, the identity is deleted too. This sounds convenient but creates a management problem at scale: every resource gets its own identity, every identity needs its own role assignments, and if you have twenty App Services that all need read access to the same storage account, you end up managing twenty separate identities with twenty separate role assignments that have to stay synchronized.

A user-assigned identity is created as a standalone resource in Azure and can be assigned to multiple resources simultaneously, with its lifecycle independent of any particular resource. If you delete the App Service, the identity persists. You can pre-define what a user-assigned identity can access, get it approved by whoever owns your access control policy, and then assign it to new resources as they're created without going through a new approval cycle each time.

Microsoft's naming recommendation makes the operational difference clear: name identities after their permission set rather than after the consumer. An identity named id-blogreader-prod-eastus outlives any specific workload and its purpose stays readable in audit logs, while an identity named id-appsvc-01 doesn't communicate what it can do and its permissions tend to drift over time as the team changes.

The security mistake most developers make

Turning on Managed Identity and removing the hardcoded credential is the right first step, but stopping there is where most teams leave a significant gap.

Managed identities do not make a workload secure. They make it credential-free, and that distinction matters because the identity still holds whatever permissions you've granted it, and those permissions are available to anything running on the resource the identity is assigned to. Microsoft's own documentation states this explicitly: if a user has access to install or execute code on a resource with a managed identity, that user has access to everything the identity can reach, even if they have no direct access to those target resources.

This means that granting a Managed Identity broad permissions like Contributor on a storage account and then assigning it to a shared compute resource where multiple teams run code effectively elevates every team's access to that storage account. The credential problem is gone but the permission problem remains and is now implicit rather than visible in a secrets manager.

The practical fix is applying least-privilege role assignments: instead of Contributor, assign Storage Blob Data Reader if the workload only reads blobs, and instead of Key Vault Administrator, assign Key Vault Secrets User if the workload only reads secrets. Azure RBAC has purpose-specific built-in roles for most common scenarios, and using them reduces the blast radius if a workload is ever compromised.

Using DefaultAzureCredential

The practical implementation for most teams is DefaultAzureCredential, part of the Azure Identity SDK and available for Python, JavaScript, Java, and .NET. It tries a sequence of authentication methods in order and uses the first one that succeeds, which means the same code works in both local development and in Azure without any environment-specific branching.

from azure.identity import DefaultAzureCredential
from azure.storage.blob import BlobServiceClient

credential = DefaultAzureCredential()
client = BlobServiceClient(
    account_url="https://mystorageaccount.blob.core.windows.net",
    credential=credential
)

In a local environment, DefaultAzureCredential typically picks up the credentials from az login, and on an Azure resource with Managed Identity enabled it picks up the managed identity token from the Instance Metadata Service. The same line of code handles both cases.

The order of credential resolution matters when debugging authentication issues. DefaultAzureCredential tries EnvironmentCredential, WorkloadIdentityCredential, ManagedIdentityCredential, SharedTokenCacheCredential, VisualStudioCodeCredential, AzureCliCredential, AzurePowerShellCredential, and AzureDeveloperCliCredential in that sequence. If you're seeing unexpected authentication behavior in local development, it's usually because an earlier credential in the chain is being picked up unexpectedly, typically an environment variable in the shell that's overriding the az login credential.

import { DefaultAzureCredential } from "@azure/identity";
import { SecretClient } from "@azure/keyvault-secrets";

const credential = new DefaultAzureCredential();
const client = new SecretClient(
  "https://mykeyvault.vault.azure.net",
  credential
);

const secret = await client.getSecret("my-database-connection-string");

Where Managed Identity doesn't work

Two scenarios where a service principal with a client secret or certificate is still the right choice: workloads running outside Azure that can't reach the Instance Metadata Service, and federated scenarios where the workload needs to authenticate to Azure from a non-Azure environment like GitHub Actions or another cloud provider. For GitHub Actions specifically, Microsoft supports OIDC-based federation that eliminates the stored secret problem without requiring the workload to run in Azure.

The 2026 shift toward identity-first

Azure's direction in 2026 is increasingly identity-first by default, with system-assigned managed identities now the default for Kubernetes workloads on AKS, replacing API keys in that context. The pattern is becoming a baseline expectation rather than an advanced configuration, and for new projects starting on Azure, configuring Managed Identity from the beginning is significantly easier than retrofitting it into an existing codebase that passes credentials around as strings.

For the full Microsoft documentation on Managed Identity and how to configure it for specific Azure services:

👉 Managed identities for Azure resources - Overview

References

Information based on official Microsoft documentation and verified sources as of September 2026. Azure services and recommendations may change. Verify current guidance at Microsoft Learn before implementing in production environments.

How to activate Azure for Students without a university email in 2026

Carlos José Castro Galante — Wed, 02 Sep 2026 14:07:32 +0000

Azure for Students gives enrolled university students $100 in Azure credits, access to free services, and no credit card requirement. The standard path to activate it assumes your university email domain is registered in Microsoft's verification system, and for many institutions, especially in regions outside North America and Europe, it simply isn't. When you enter your university email and get the message "your email domain is not currently registered with us", that's not a rejection. It's the system telling you to use a different verification method.

There are two paths that work when your institutional domain isn't recognized: verifying with official academic documentation, or using the GitHub Student Developer Pack as proof of student status. Both are supported by Microsoft and SheerID, the verification provider behind Azure for Students.

What you need before starting either path

Regardless of which path you take, you need a Microsoft account. If you already have an Outlook or Hotmail account, that works. If you don't, create one at account.microsoft.com before anything else. This is the account that will hold your Azure for Students subscription and the same one you will use later if you apply to the Microsoft Student Ambassadors program, so use one you plan to keep active.

Your Microsoft account does not need to be linked to your university email. A personal Gmail cannot be a Microsoft account on its own, but you can create a Microsoft account using a Gmail address at signup.live.com. Either way, what matters is that you have a stable Microsoft account ready before starting.

Path 1: Documentation-based verification

This path works when you don't have access to a recognized institutional email and you're not yet verified on GitHub Education. It requires uploading an official document that proves your current enrollment.

Step 1: Go to the Azure for Students page

Navigate to azure.microsoft.com/free/students and click the "Activate now" button. Sign in with your Microsoft account when prompted.

Step 2: Enter your information

The form will ask for your email address. Enter your Microsoft account email, not your university email. When the system cannot verify the domain automatically, it will present an alternative verification option where you can submit academic documentation.

Step 3: Upload your enrollment document

The document that works is an official enrollment certificate or student registration certificate issued by your university. It needs to show your full name, your institution's name, and confirmation of your current enrollment status. A student ID card alone is generally not sufficient because it doesn't always show the enrollment year or current academic status. An official letter or certificate from the registrar's office is the correct document.

In my case I uploaded a constancia de alumno regular, which is the standard enrollment certificate issued by Argentine universities, and the verification was accepted without issues.

The verification is processed by SheerID. In most cases it completes within minutes, but it can take up to 48 hours. If it hasn't resolved after 48 hours, you can contact Azure Education Support at azureforeducation.microsoft.com/institutions/contact.

Step 4: Confirm activation

Once verified, you'll receive a confirmation email and your Azure for Students subscription will appear in the Azure portal at portal.azure.com. The subscription includes $100 in credits valid for 12 months and access to a set of always-free services.

Path 2: GitHub Student Developer Pack

This path works if you already have or plan to get the GitHub Student Developer Pack. GitHub Education accepts enrollment documents and student ID cards for verification, and once approved, the Pack can be used to activate Azure for Students directly without repeating the documentation process.

Step 1: Apply for the GitHub Student Developer Pack

Go to education.github.com/pack and click "Get student benefits". Sign in with your GitHub account and follow the verification flow. You'll need to provide your university name, your enrollment email if you have one, and upload a proof of enrollment document if your email isn't recognized. A student ID, enrollment certificate, or official letter from your university all work here. GitHub's verification usually takes up to 72 hours.

Step 2: Wait for confirmation

GitHub sends a confirmation email when your student status is verified. The Pack and all its benefits become active at that point. Don't try to activate Azure before receiving that confirmation because the verification link won't work until GitHub completes the process on their end.

Step 3: Activate Azure for Students through the Pack

Once verified, go to signup.azure.com/studentverification and sign in with your Microsoft account. When the page asks how you want to verify your student status, select the option to connect with GitHub and complete the GitHub OAuth step. This confirms to Microsoft that you're a verified student through GitHub Education.

After completing the OAuth step, wait a few minutes and then open the Azure portal at portal.azure.com. Your Azure for Students subscription should appear active in the subscriptions list. If it doesn't appear after 10 minutes, try signing out and back in.

If you get an error saying your GitHub account doesn't have student benefits enabled

This error can appear even when your Student Developer Pack is active and verified. The most reliable fix is to open a support ticket with GitHub Education by going to support.github.com and selecting "I am a verified student having trouble redeeming my Global Campus offers." GitHub support typically resolves these within a few hours.

Do not try to activate Azure multiple times before resolving this error. Azure for Students is limited to one activation per Microsoft account. If you trigger multiple failed attempts, the offer may become unavailable for that account and you'll need to contact Azure Education Support to reset it.

If both paths fail: manual support ticket

Neither path above is guaranteed to work in every situation. The official Azure for Students documentation states that verification requires an institutional email address, and the document-upload option in the self-service flow is not available in all regions or for all institutions. If you complete both paths and still cannot activate the subscription, a manual support ticket is the next step.

This process is not officially documented as a standard path, but multiple Microsoft Q&A threads from 2026 confirm that Microsoft's education support team can manually review student eligibility when the automated system fails. The outcome is not guaranteed, but it is the correct escalation channel.

What to prepare before opening a ticket:

You will need clear scans or photos of your student ID card showing your name and current academic year, an official enrollment certificate or letter from your university's registrar office showing your full name, institution name, and current enrollment period, and a screenshot of the error or rejection message you received during the self-service verification flow. If you completed the GitHub Student Developer Pack, include a screenshot confirming your approved status there as well.

How to open the ticket:

If you already have any Azure account (including a free account), go to portal.azure.com, click "Help + Support" in the top right corner, and create a new support request. Select "Subscription Management" as the issue type, then "Account" and "Azure for Students verification" as the subcategories. Attach your documents and explain that your institution does not provide an institutional email address and that you are requesting manual verification.

If you do not have any Azure account yet and cannot access the portal, use the Azure for Education contact form directly:

👉 azureforeducation.microsoft.com/institutions/contact

You can also post your situation with full details in the official Microsoft Q&A forum at learn.microsoft.com/answers, where Microsoft moderators actively respond to student verification questions and can escalate your case internally.

Alternative if manual verification is not granted:

If Microsoft confirms that your institution is not supported and manual verification cannot be completed, the Azure for Students Starter program at azure.microsoft.com/free/students/starter provides access to a limited set of free Azure services without requiring student verification or a credit card. It does not include the $100 credit, but it gives access to services like App Service, Azure Functions, and Azure SQL Database at no cost, which may be sufficient for learning purposes.

Once your Azure for Students subscription is active, the Microsoft account holding it is the one you use for everything related to Microsoft programs. If you plan to apply to the Microsoft Student Ambassadors program, you'll register at studentambassadors.microsoft.com using this same Microsoft account. The program verifies your Azure for Students subscription during registration, and the button to proceed only becomes active once that subscription is confirmed.

To check your credit balance, remaining time, and the services included in your subscription, go to the Azure portal at portal.azure.com and look for the Education section in the left navigation menu. That is where Azure for Students accounts track their credits and usage, separately from the general Subscriptions section that paid accounts use. The $100 in credits is valid for 12 months from activation, and unused credits do not roll over, so it's important starting to explore Azure services once the subscription is active.

For a full guide on the Microsoft Student Ambassadors program and how to get started after activating Azure for Students:

👉 https://learn.microsoft.com/azure/education-hub/azure-dev-tools-teaching/azure-students-program?wt.mc_id=studentamb_510930

The information in this article is based on official Microsoft documentation, GitHub Education documentation, and personal experience as of September 2026. Verification processes, eligibility requirements, and available benefits may change at any time without notice. This article is provided for informational purposes only. The author is not responsible for any issues arising from following these steps, including but not limited to failed verifications, credit losses, or account restrictions. Always verify current requirements directly on the official Azure for Students page and the GitHub Student Developer Pack page before proceeding.

Azure OpenAI Service vs OpenAI API, which to use and when in 2026

Carlos José Castro Galante — Wed, 26 Aug 2026 00:12:06 +0000

When someone asks whether to use Azure OpenAI Service or the direct OpenAI API, the starting point is this: the models running on both platforms are identical. GPT-4o, GPT-5, and the o-series models you deploy on Azure have the same weights, the same capabilities, and the same output quality as the ones you call from platform.openai.com, and what changes between the two platforms is the infrastructure where they run, the authentication mechanism, and the compliance guarantees the provider can offer on those requests.

What changed in 2026

Azure AI Foundry was renamed Microsoft Foundry on January 1, 2026, and Azure OpenAI Service now lives inside that unified platform alongside the model catalog, development tooling, and agents. References to Microsoft Foundry in new documentation point to what used to be Azure AI Foundry.

In July 2026, the GPT-5.6 family arrived with Sol, Terra, and Luna available on Azure the same day as on the direct OpenAI API. Historically Azure lagged four to eight weeks behind new model releases because Microsoft validates them within their compliance frameworks before making them available, and while that gap still exists for some specific features and APIs, for the main models in the GPT-5 family availability is converging.

Where data is processed

When you call GPT-4o from the OpenAI API, the request goes to OpenAI's own infrastructure, which is centralized and gives you no control over which region processes your data. For most use cases that doesn't matter, but for organizations with data residency requirements, regulatory compliance needs, or industries like healthcare, banking, or government, that detail can determine whether the service is usable at all.

Azure OpenAI runs the same models within the boundary of your Azure tenant, so the data you send in prompts doesn't leave to OpenAI's infrastructure but processes in the Azure regions you choose. That's what makes it possible to meet HIPAA, SOC 2, EU data residency, and other certifications that companies in regulated industries need before they can deploy to production.

Authentication

The OpenAI API uses API keys, strings you need to store, rotate, distribute, and protect from ending up in a repository. Azure OpenAI can authenticate using DefaultAzureCredential, which delegates authentication to Microsoft Entra ID and can use Managed Identity so the service obtains tokens automatically without any hardcoded or stored credentials anywhere.

from azure.identity import DefaultAzureCredential
from openai import AzureOpenAI

credential = DefaultAzureCredential()
token = credential.get_token("https://cognitiveservices.azure.com/.default")

client = AzureOpenAI(
    azure_endpoint="https://my-resource.openai.azure.com/",
    azure_ad_token=token.token,
    api_version="2026-04-01-preview"
)

In environments where a security review is required before deploying anything to production, being able to remove API keys from the authentication flow carries practical weight in the approval process.

Pricing and billing modes

Prices for the main models are comparable between the two platforms. The GPT-5.6 family in Global Standard on Azure follows the same OpenAI list rates, with ranges from $0.20 to $5 per million input tokens for mainstream models in the current catalog. For the GPT-5.6 Sol model, Azure announced promotional pricing of $4.00 per million input tokens and $20.00 per million output tokens from September 1 through at least November 30, 2026.

Azure has Provisioned Throughput Units (PTUs), reserved capacity blocks you pay for hourly rather than per token. When your application's sustained usage exceeds 60-70% of a PTU's capacity, that mode starts making economic sense. Below that threshold, pay-as-you-go per token is more efficient.

Something most pricing guides don't mention is that in enterprise deployments with private networking, Azure adds supporting infrastructure costs including Azure AI Search, Blob Storage, private endpoints, and network egress that can add 15 to 40% on top of token costs in full private networking production deployments.

Content filtering

OpenAI has baseline moderation that runs on all requests. Azure OpenAI lets you configure custom filters through Azure AI Content Safety, with granular control over the thresholds for each content category based on your application's specific needs. For medical use cases where certain clinical terms might trigger general filters, that granularity can be necessary for the service to work correctly.

When to use each one

The direct OpenAI API makes sense when you're prototyping and need setup speed without bureaucracy, when you want immediate access to new features without waiting for Azure's validation cycle, or when you're building a consumer application where compliance requirements aren't a blocker. It has no quota gate on the standard tier, so you can start calling the API the same day without requesting additional capacity.

Azure OpenAI makes sense when the project needs to meet specific regulations for the industry, when you need data to process within a specific Azure region, when the organization already has contracts and governance on Azure and needs the AI service integrated into that ecosystem, or when you need credential-free authentication through Managed Identity. Quota requests for high-demand models in specific regions can take a week or more to process, so starting that process early helps.

A common and perfectly valid scenario is using both: you prototype with the OpenAI API which gives immediate access to everything, and when the project moves to production with compliance or private networking requirements, you migrate to Azure OpenAI with minimal code changes.

Migrating from one to the other

If you already have code pointing to the OpenAI API and want to move it to Azure, the change is configuration rather than logic. The client changes from OpenAI to AzureOpenAI, you add your Azure resource endpoint and api_version, and the rest of the code stays the same. Model names change because in Azure you deploy named instances rather than calling the model by its global name.

# Before (direct OpenAI)
from openai import OpenAI
client = OpenAI(api_key="sk-...")

# After (Azure OpenAI)
from openai import AzureOpenAI
client = AzureOpenAI(
    azure_endpoint="https://my-resource.openai.azure.com/",
    api_key="...",
    api_version="2026-04-01-preview"
)

With Managed Identity, the api_key disappears from the code entirely and is replaced by the Entra ID credential flow shown above.

To explore Azure OpenAI Service and the model catalog available in Microsoft Foundry:

👉 https://azure.microsoft.com/products/ai-services/openai-service/?wt.mc_id=studentamb_510930

Information based on official Microsoft documentation and verified sources as of August 25, 2026. Prices and model availability may change. Verify current figures on the official Azure OpenAI pricing page before making architecture or budget decisions.