Microsoft Foundry: Agenten von der ersten Spur bis zum Produktions-Monitoring beobachten
Microsoft Foundry gliedert Observability fuer KI-Agenten in drei Bereiche. Tracing zeigt, was ein Agent in einem Lauf getan hat, Evaluation bewertet die Antworten anhand eigener Kriterien und Monitoring ueberwacht den Agenten im laufenden Betrieb.
Microsoft Foundry unterteilt die Observability für Agenten in drei Fähigkeiten, und jede davon beantwortet eine andere Frage. Tracing zeigt, was der Agent während eines Laufs getan hat, Evaluation bewertet, wie gut seine Antworten anhand selbst gewählter Kriterien waren, und Monitoring stellt beide Fragen weiterhin, sobald der Agent im Einsatz bei Nutzern ist. Dieser Beitrag geht sie in der Reihenfolge durch, in der man sie üblicherweise benötigt, nutzt die offiziellen Python-Beispiele und sagt, welche Teile Microsoft als allgemein verfügbar und welche als Preview einstuft, denn dieses Label entscheidet darüber, wie viel Gewicht jeder einzelne Baustein tragen kann.
Tracing ist für Prompt-Agenten und gehostete Agenten allgemein verfügbar, während Workflow-Agenten und externe Agenten sich noch in der Preview befinden. Microsofts Build-Ankündigung vom 3. Juni 2026 besagt, dass Tracing und Evaluations im Frühjahr den Status der allgemeinen Verfügbarkeit erreicht haben, doch die Referenzseiten versehen einzelne Teile weiterhin mit Preview-Labels. Auf der Seite der Agent Evaluators sind Task Adherence, Task Completion, Intent Resolution, Customer Satisfaction, Output Quality und Tool Use Quality als Preview gekennzeichnet, während die Tool Evaluators wie Tool Call Accuracy überhaupt kein Label tragen.
Auf der Monitoring-Seite sind Agent-Metriken, wiederkehrende Evaluations, Red-Team-Scans und Alerts als Preview markiert, und die Seite weist darauf hin, dass Microsoft seine Preview-Elemente nicht für Produktionsworkloads empfiehlt. Auch die GitHub Action für Evaluations befindet sich in der Preview. Ich habe diese Labels am 14. Oktober 2026 geprüft, und da sie sich schnell ändern, lohnt es sich, die verlinkten Seiten erneut zu öffnen, bevor man darauf aufbaut.
Tracing für Prompt-Agenten und gehostete Agenten läuft serverseitig, sodass man nichts am eigenen Code ändern muss. Bei aktiviertem New Foundry-Schalter öffnet man sein Projekt, geht zu Agents, wählt Traces und klickt auf Connect, um eine bestehende Application Insights-Ressource anzubinden oder eine neue anzulegen. Von diesem Zeitpunkt an werden die Läufe eines in Foundry gehosteten Agenten über OpenTelemetry aufgezeichnet, einschließlich der Modellaufrufe, der Tool-Aufrufe, der Entscheidungen des Agenten und seiner Abhängigkeiten von anderen Diensten, wie in der Observability-Übersicht beschrieben.
Um die Traces zu lesen, benötigt man die Rolle Log Analytics Reader auf der verbundenen Application Insights-Ressource, plus Privileged Monitoring Data Reader, wenn die zugrunde liegenden Log Analytics-Tabellen geschützt sind. Nachdem man den Agenten einmal ausgeführt hat, allows der Tab Traces das Durchsuchen, Filtern und Sortieren der Traces der letzten 90 Tage, das Öffnen einzelner Traces, um ihre Spans schrittweise durchzugehen, oder die Suche nach Response ID oder Trace ID sowie das Öffnen einer Conversation ID, um den Verlauf, die Token-Zahlen, die Ausführungsschritte, die Tool-Aufrufe, Eingaben und Ausgaben zu sehen. Falls nichts erscheint, empfiehlt die Einrichtungsseite, einige Minuten zu warten und die Seite zu aktualisieren, bevor man zum Troubleshooting-Abschnitt übergeht.
Diese Seite behandelt auch clientseitiges Tracing mit azure-core-tracing-opentelemetry, das optional ist und für den Code der eigenen Anwendung gedacht ist.
Ein Trace sagt einem, was passiert ist, aber nicht, ob die Antwort gut war, und genau das ist die Aufgabe der Evaluation. Das folgende Beispiel folgt der offiziellen Seite zum Evaluieren von AI-Agenten, wobei der Schritt zur Rubric-Generierung entfernt wurde, sodass nur Evaluatoren verwendet werden, die in Foundry enthalten sind. Man benötigt die Rolle Foundry User auf dem Projekt, die Microsoft von Azure AI User umbenannt hat, ohne die Rollen-IDs zu ändern, sowie ein Chat Completion-Modell-Deployment, das als Richter für diejenigen Evaluatoren dient, die ein Modell verwenden.
Diese Seite verlangt azure-ai-projects 2.4.0 oder höher, während andere Seiten derselben Dokumentation niedrigere Mindestversionen angeben, daher ist es sicherer, die neueste Version zu installieren.
pip install "azure-ai-projects>=2.4.0" azure-identity Enter fullscreen mode Exit fullscreen mode Setze die Umgebungsvariablen AZURE_AI_PROJECT_ENDPOINT und AZURE_AI_MODEL_DEPLOYMENT_NAME und erstelle eine JSONL-Datei namens test-queries.jsonl, in der jede Zeile ein query-Feld enthält. Diese drei Zeilen sind nur Beispielfragen, also ersetze sie durch die Fragen, die dein Agent erhält.
{"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?"} Enter fullscreen mode Exit fullscreen mode Der erste Teil des Skripts erstellt die Clients und lädt den Datensatz in das Projekt hoch.
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 ", ) Enter fullscreen mode Exit fullscreen mode Der zweite Teil definiert, was gemessen werden soll, und erstellt die Evaluation. Coherence wird vom Judge-Deployment bewertet, während Violence aus der Risk-and-Safety-Gruppe stammt, die das offizielle Beispiel ohne Judge-Deployment ausführt.
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, ) Enter fullscreen mode Exit fullscreen mode Der dritte Teil startet den Lauf. Mit der Quelle azure_ai_target_completions sendet Foundry jede Anfrage an den im Target genannten Agenten und bewertet die Antworten, die er zurückliefert, weshalb die obigen Mappings aus sample.output_text lesen.
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 } " ) Enter fullscreen mode Exit fullscreen mode In der Antwort liefert result_counts die Gesamtzahl sowie die Zeilen mit bestanden, nicht bestanden und Fehlern, per_testing_criteria_results schlüsselt dieselben Zahlen nach Evaluator auf, und jede Zeile enthält für jeden Evaluator einen Score, ein Label, eine Begründung, einen Schwellenwert und ein passed-Flag. Die report_url öffnet dieselben Ergebnisse im Foundry-Portal, wo sie auch unter dem Tab Evaluations erscheinen, und das reason-Feld ist der beste Einstiegspunkt, wenn eine Zeile durchfällt.
Wenn dein Agent Tools aufruft, sind die Tool Use Evaluatoren die nächste sinnvolle Ergänzung. Tool Call Accuracy prüft, ob der Agent die richtigen Aufrufe mit korrekten Parametern und ohne Redundanz getätigt hat, Tool Selection prüft, ob er die benötigten und keine zusätzlichen Tools gewählt hat, Tool Input Accuracy prüft die Parameter, Tool Output Utilization prüft, ob der Agent die Ergebnisse korrekt verwendet hat, und Tool Call Success prüft, ob die Aufrufe ohne technische Fehler abgeschlossen wurden. Vier davon nehmen tool_definitions als Eingabe entgegen, und Tool Call Accuracy bewertet auf einer Skala von eins bis fünf, bevor ein Schwellenwert diesen Score in Bestehen oder Nichtbestehen umwandelt.
Risk- and Safety-Evaluations, zu denen auch der oben verwendete Violence-Evaluator gehört, sowie Agents Playground-Evaluations werden nach Verbrauch abgerechnet, und Playground-Evaluations sind für jedes Foundry-Projekt standardmäßig aktiviert. Um sie abzuschalten, entfernt man alle Evaluatoren im Metrics-Selector des Playgrounds. Einige Funktionen unterliegen zudem regionalen Einschränkungen, nämlich Rubric-Generierung, die Erstellung synthetischer und trace-basierter Datensätze sowie die Risk- and Safety-Evaluatoren, daher sollte man die unterstützten Regionen prüfen, bevor man das Beispiel in einem bereits vorhandenen Projekt ausführt.
Die Monitoring-Daten selbst liegen in der verbundenen Application Insights-Ressource, sodass sich Aufbewahrung und Abrechnung nach der Konfiguration dieser Ressource richten.
Die Monitoring-Seite beschreibt die Continuous Evaluation, bei der eine Auswertung auf Grundlage von getastetem Traffic läuft, während der Agent Anfragen von Nutzern bedient. Der folgende Code erzeugt eine Evaluation mit einer azure_ai_source und fügt eine Regel hinzu, die diese immer dann ausführt, wenn eine Antwort des genannten Agents abgeschlossen wurde. Die verwaltete Identität des Projekts benötigt die Rolle Foundry User, damit Continuous-Evaluation-Regeln ausgeführt werden können, und die Regel ist durch max_hourly_runs begrenzt, was das Beispiel auf 100 setzt und was Microsoft als Standardlimit pro Stunde dokumentiert. Sobald das Limit erreicht ist, werden weitere Ausführungen übersprungen, bis zur nächsten Stunde oder bis der Wert erhöht wird.
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})") Um die Ergebnisse zu lesen, öffnet man den Agent im Foundry-Portal und wählt Monitor. Das Dashboard zeigt Token-Verbrauch, Latenz, Erfolgsquote der Runs, Evaluationsmetriken und Red-Teaming-Ergebnisse für den gewählten Zeitraum, und die Dokumentation nennt zwei Anhaltspunkte für die Interpretation.
Eine Latenz von mehr als zehn Sekunden kann auf Modell-Throttling, komplexe Tool-Aufrufe oder Netzwerkprobleme hindeuten, und eine Erfolgsquote der Runs unter 95 Prozent sollte eine Untersuchung der fehlgeschlagenen Runs nach sich ziehen.
Man kann die Evaluation aus Schritt 2 auch in einer Pipeline über die GitHub Action microsoft/ai-agent-evals@v3-beta ausführen, die in der Dokumentation als Preview gekennzeichnet ist. Der folgende Schritt kommt nach dem Checkout und einem Azure-Login-Schritt, der OpenID Connect verwendet, sodass der Workflow zusätzlich die Berechtigung id-token: write sowie die Client-, Tenant- und Subscription-IDs als GitHub Actions Variables benötigt.
- 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 Die Eingabe agent-ids akzeptiert Werte wie my-agent:1,my-agent:2, eine optionale Angabe baseline-agent-id legt die Version fest, die als Vergleich herangezogen wird, und die Ergebnisse erscheinen in der Zusammenfassung des Workflow-Runs mit dem Wert jeder Metrik, Konfidenzintervallen und, wenn man mehrere Agents vergleicht, einem paarweisen statistischen Vergleich, der angibt, ob ein Unterschied bedeutsam ist oder nur zufälliger Schwankung entspricht. Damit eignet sich das Ganze als vernünftiges Quality Gate für Änderungen an den Instruktionen oder dem Modell eines Agents, da derselbe Datensatz gegen beide Versionen läuft.
Wer die drei Bausteine lieber im Zusammenspiel sehen möchte, bevor er sie selbst ausprobiert, findet in der Azure-Friday-Episode Observe and evaluate agents for quality and safety in Microsoft Foundry einen Durchlauf durch Evaluation, Tracing und Monitoring mit einer Live-Demo im Foundry-Portal und in Visual Studio Code.
Welche dieser drei Fragen fällt Ihnen bei Ihren Agents heute am schwersten zu beantworten: was sie getan haben, wie gut ihre Antworten waren oder ob sie nach dem Release genauso gut bleiben?
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
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.
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.
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.
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 Enter fullscreen mode Exit fullscreen mode 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?"} Enter fullscreen mode Exit fullscreen mode 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 ", ) Enter fullscreen mode Exit fullscreen mode 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, ) Enter fullscreen mode Exit fullscreen mode 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 } " ) Enter fullscreen mode Exit fullscreen mode 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.
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.
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 } ) " ) Enter fullscreen mode Exit fullscreen mode 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.
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 Enter fullscreen mode Exit fullscreen mode 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?