标签：#foundry

I spent a week building an agent that upgrades dependencies and repairs what the upgrade breaks. Dependabot opens the PR and walks away; this one stays until the tests are green. The interesting part wasn't the repairs. It was that almost every serious bug I hit — in my code, in the harness, in my own agent — announced success while being wrong. The premise Detection is solved. Dependabot, npm audit and OSV all find the advisory. What nobody automates is the bit afterwards: the fix is a major version bump, the bump breaks your build, and now it's your afternoon. So: pull real advisories, spawn one subagent per vulnerable package, each on its own branch in its own sandbox. Bump, install, run the suite. If it breaks, read the failure and patch the source. Re-verify from a clean checkout. Open a PR and stop — merging is a human decision. That's the design. Here's what actually happened. 1. The advisories weren't where I looked My first scan found nothing. The manifest said js-yaml: ^3.13.1 , which sounds vulnerable, but ^3.13.1 resolves to whatever the latest 3.x is today — and that's patched. Vulnerabilities live in the resolved tree, not the manifest. Scan the lockfile, including transitive dependencies, or you scan nothing. All three advisories I eventually found were transitive dev dependencies that appear nowhere in package.json . A scanner that reads the manifest returns "you're clean" and is wrong. It doesn't error. 2. The agent caught itself The first proper scan reported 124 vulnerable packages out of 290. Then it said something I didn't expect: "Some results look suspicious — js-yaml@4.3.2 with 10 advisories, which is usually clean." It cross-checked OSV's batch endpoint against the single-query endpoint and found its own bug: it had nested version inside the package object instead of alongside it. The API silently ignored the version and returned every advisory ever filed for each package. Real answer: three. Not 124. The API didn't reject the malformed quer

Microsoft has outlined an AI governance architecture spanning nine governance domains and four functions: policy, control, visibility, and proof. The approach connects policies with runtime enforcement, continuous evaluation, observability, identity, security, and audit evidence to help organizations verify governance requirements as AI applications and agents operate in production. By Leela Kumili

If you're a .NET developer looking to break into AI engineering, agents are the single best place to start. They're the point where "calling an LLM API" turns into "building a system that reasons, uses tools, and takes action" — and Azure AI Foundry Agent Service, paired with .NET, makes this surprisingly approachable. In this post, I'll walk through exactly how to stand up your first agent end-to-end — from the Azure side setup to the actual C# code — and share the full walkthrough in video form as well. 🎥 Watch the full hands-on video here: https://youtu.be/mrsEsculrNg Why Agents, and Why Now Most of us started our AI journey with a simple chat completion call — send a prompt, get text back. That's fine for Q&A, but it falls apart the moment you need the model to do something: run code, search documents, call an API, or hold a multi-turn conversation with real state. That's exactly the gap Foundry Agent Service closes. An agent in Foundry is: Durable — it lives as a resource in your Foundry project, not in your app's memory Tool-aware — it can invoke built-in tools (like a code interpreter) or your own custom functions Stateful — conversations persist and carry context across turns And the best part for us .NET folks: the entire thing is callable from clean, typed C# — no wrestling with raw REST payloads. What You'll Need Before writing any code, set up the Azure side: An Azure AI Foundry project with a chat model deployed (e.g., gpt-4o-mini ) The Foundry User RBAC role assigned to your account at the resource/resource-group scope — this is the single most common blocker people hit (a silent 403 when calling the SDK), so don't skip it az login run locally, so your code can authenticate without hardcoding any keys If you've worked with Cognitive Services roles before, note that agent management needs this separate Foundry-specific role — that trips up a lot of people coming from plain Azure OpenAI usage. Setting Up the .NET Project dotnet new console -n FoundryAgen

This closes out the series' capstone: the multi-agent customer support system built across Parts 6-9, now hardened with evaluation, cost governance, and observability so it can actually run in production with an on-call rotation behind it, not just in a demo environment. Continuous evaluation pipeline Evaluation: measuring quality continuously, not just at launch A one-time eval before launch tells you nothing about drift once real traffic — and real edge cases — start hitting the system. Set up a continuous evaluation pipeline using a G-Eval-style approach, where a separate model scores production outputs against explicit criteria: eval_criteria = { " correctness " : " Does the response accurately reflect the order/refund status retrieved from the tools? " , " escalation_appropriateness " : " If the case was ambiguous or high-risk, did the agent escalate to a human rather than resolving it alone? " , " tone " : " Is the response professional and appropriately empathetic given the customer ' s stated frustration level? " , } def geval_score ( response , context , criterion_name , criterion_description , eval_model_client ): prompt = f """ Evaluate the following response against this criterion: { criterion_description } Context: { context } Response: { response } Score from 1-5 and give one sentence of reasoning. Return JSON: {{ " score " : int, " reasoning " : str}} """ result = eval_model_client . complete ( prompt ) return json . loads ( result ) def run_continuous_eval ( sample_of_production_traffic ): scores = { crit : [] for crit in eval_criteria } for interaction in sample_of_production_traffic : for crit_name , crit_desc in eval_criteria . items (): result = geval_score ( interaction . response , interaction . context , crit_name , crit_desc , eval_model_client ) scores [ crit_name ]. append ( result [ " score " ]) return { crit : sum ( vals ) / len ( vals ) for crit , vals in scores . items ()} Sample a percentage of real production traffic daily (not just s