Microsoft Foundry im Juni 2026: Mehr als nur eine Demo

Das Microsoft Foundry-Update vom Juni 2026 ist viel umfangreicher als die Einführung eines anderen Modells. Es verändert die Art und Weise, wie wir Agenten erstellen, betreiben und verteilen. Claude hat die allgemeine Verfügbarkeit erreicht. Agenten können über einen geregelten Veröffentlichungspfad zu Microsoft 365 Copilot und Teams wechseln. Toolboxes, Routines, Speicher und Evaluation werden Teile desselben Betriebsmodells.

Ich möchte zunächst das komplette Update durchgehen und erklären, welche Änderungen sich in den einzelnen Bereichen ergeben. Danach baue ich etwas Praktisches darauf auf: ein Intune Change Briefing, das eine geplante Endpunktänderung mit Claude in Microsoft Foundry bespricht. Das Ziel besteht nicht darin, die Versionshinweise zu kopieren. Das Ziel besteht darin, zu verstehen, was wir jetzt aufbauen können, was vorher schwierig war.

Ich verwende meinen Modern Dev Mgmt-Mandanten für die Screenshots und die Live-Azure-Prüfungen. Die Screenshots wurden am 20. Juli 2026 aufgenommen. Das Python-Beispiel wurde mit anthropic 0.79.0 und azure-identity 1.25.1 syntaktisch überprüft. Sie benötigen noch Ihr eigenes Claude Deployment, bevor eine echte Anfrage gesendet werden kann.

Microsoft Foundry Juni 2026 in einer Ansicht

Die Veröffentlichung umfasst vier Ebenen gleichzeitig:

1. Modelle: mehr Auswahl und umfassendere modellspezifische Funktionen.
2. Agenten: Identität, Tools, Zeitpläne, Speicher und Optimierung.
3. Verteilung: eine geregelte Route in Microsoft 365 Copilot und Teams.
4. Laufzeit und SDKs: lokale, getrennte, Sprach- und Sprachverbesserungen.

Diese Kombination ist die wahre Veränderung. Foundry bewegt sich von einem Ort, an dem wir Prompts testen, zu einer Plattform, auf der wir Agenten während ihres gesamten Lebenszyklus betreiben können.

Die offizielle GitHub-Ankündigung gibt einen guten kurzen Überblick. Microsoft hat außerdem das vollständige Änderungsprotokoll vom Juni 2026 mit SDK-Details veröffentlicht.

Was bringen uns die wichtigen Features eigentlich?

Die Tabelle zeigt uns, was versendet wurde. Es sagt uns noch nicht, was am anderen Ende herauskommt. Das sind die Teile, auf die ich achten würde.

Claude – mehr als ein weiterer Katalogeintrag

Claude ist jetzt allgemein in Microsoft Foundry verfügbar. Die Nachrichten-API unterstützt Prompt-Caching, erweitertes Denken und Tool-Streaming. Claude kann auch als Argumentationsmodell eines mehrstufigen Foundry-Agenten verwendet werden.

Für mich ist das wichtige Ergebnis keine Muster-Bestenliste. Es ist eine architektonische Entscheidung. Ein Team kann ein Modell für die Arbeitslast auswählen und dabei die Azure-Identität, die Bereitstellungskontrolle und den umgebenden Agentenlebenszyklus beibehalten.

Was dabei herauskommt: Im Beispiel weiter unten in diesem Beitrag wird aus einer JSON-Änderungsanfrage eine strukturierte Überprüfung mit einer Entscheidung, Risiken, fehlenden Voraussetzungen, Rollout-Schritten und Rollback-Lücken.

Microsoft 365-Veröffentlichung – der Agent erreicht den Benutzer

Die Veröffentlichung von Foundry-Agenten für Microsoft 365 Copilot und Teams wurde am 10. Juni allgemein verfügbar. Der Agent benötigt nicht für jede Oberfläche eine eigene Implementierung. Es durchläuft eine kontrollierte Veröffentlichungspipeline und behält seine Funktionen bei.

Dadurch ändert sich auch das Interaktionsmodell. Ein Agent kann von einem Ziel aus arbeiten, Kontrollpunkte bereitstellen, Genehmigungen anfordern und eskalieren, anstatt nur eine Antwort an einen Prompt zurückzugeben.

Was dabei herauskommt: Das gleiche Change Briefing könnte im Teams-Arbeitsbereich eines Endpunktteams erscheinen. Der Administrator erhält die Überprüfung, in der die Änderung besprochen wird, anstatt ein weiteres isoliertes Playground zu öffnen.

Autopilot-Agenten – Identität für die laufende Arbeit

Autopilot-Agenten sind eine neue Public-Preview-Kategorie. Sie können ihre eigene Microsoft Entra Agent ID, Produktivitätslizenz, E-Mail, Kalender, OneDrive und Teams-Präsenz erhalten. Sie sind für gemeinsame Räume wie Gruppenchats konzipiert.

Das Workstream Manager-Beispiel von Microsoft zeigt die Richtung. Es kann Aufgaben und Fristen verfolgen, Gespräche in Aktionspunkte umwandeln, überfällige Arbeiten nachverfolgen und Blockaden aufdecken.

Was dabei herauskommt: Anstelle eines versteckten Backend-Prozesses wird der Agent zu einem sichtbaren Teamteilnehmer mit einer Identität, einem definierten Umfang und einem Eigentümermodell. Das ist leistungsstark, bedeutet aber auch, dass Lebenszyklus, Lizenzierung und Zugriffsüberprüfungen wichtig sind.

Toolboxes – kontrollierte Funktionen anstelle eines großen Prompt

Toolboxes hat mehrere Vorschaufunktionen erhalten:

Tool Search ist besonders relevant, wenn ein Agent über viele Tools verfügt. Das Senden von Hunderten von Schemata auf Schritt und Tritt verschwendet Token und erschwert die Auswahl von Tool. Mit Tool Search kann der Agent zuerst die relevante Funktion finden.

Was dabei herauskommt: Unser einfacher Reviewer kann als schreibgeschützter Modellaufruf beginnen. Später kann ein Toolbox eine kontrollierte Suche nach Dokumentation, Wartungsfenstern oder Änderungsdatensätzen hinzufügen, ohne dem Modell umfassenden Verwaltungszugriff zu gewähren.

Routines – vom Chat bis zur zuverlässigen Laufkontrolle

Routines sind die Vorschau-Laufsteuerungsebene von Foundry. Sie definieren, wann ein Agent ausgeführt wird: nach einem Zeitplan, nach einem Auslöser oder durch einen manuellen Versand. Foundry stellt die Ausführung in die Warteschlange und verfolgt sie.

Was dabei herauskommt: Das Change Briefing kann an jedem Wochentag morgens durchgeführt werden, die für die nächsten 48 Stunden geplanten Änderungen überprüfen und ein einheitliches Briefing in den Arbeitsablauf des Teams integrieren. Wir brauchen keine Person mehr, die daran denkt, einen Chat zu öffnen und den Prompt zu kopieren.

Speicher- und Agentenoptimierung – Kontinuität plus Qualitätsschleife

Mit dem prozeduralen Gedächtnis kann ein Agent erlernte Prozeduren wiederverwenden. TTL steuert, wie lange dieser Speicher überlebt. Agent Optimizer fügt einen geschlossenen Regelkreis hinzu: Bewerten Sie die Baseline, generieren Sie Kandidaten, testen Sie sie anhand derselben Aufgaben, bewerten Sie die Ergebnisse und setzen Sie die ausgewählte Verbesserung um.

Ich würde nicht beides am ersten Tag aktivieren. Der Speicher kann veraltetes Verhalten bewahren, und eine Optimierung ist nur dann sinnvoll, wenn der Evaluation-Satz das Verhalten misst, das uns tatsächlich wichtig ist.

Was dabei herauskommt: Der Prüfer kann die Pilotsequenz des Teams konsequent wiederverwenden, während eine 30-Tage-TTL alte Verfahren entfernt. Ein Evaluation-Set kann dann nachweisen, ob ein Prompt oder ein Modellwechsel weitere Rollback-Lücken findet, ohne Mieterfakten zu erfinden.

Auch die Plattform ändert sich rund um den Agenten

Der Rest des Updates sollte nicht ignoriert werden. OpenEnv verbindet Foundry mit standardisierten Reinforcement-Learning-Umgebungen. Foundry Local auf Azure Local deckt jetzt Kubernetes mit mehreren Knoten und den getrennten Betrieb ab. Voice Live fügt einen neuen nativen Sprachtyp hinzu. Die Java-, .NET-, Python- und JavaScript-SDKs machen weiterhin einen größeren Teil des Agentenlebenszyklus verfügbar.

Diese Elemente dienen unterschiedlichen Arbeitslasten, aber die Richtung ist konsistent: Die Plattform wird über Cloud-Chat-Anwendungen hinaus auf lokale Inferenz, Sprache, Schulung und Betriebsautomatisierung ausgeweitet.

Jetzt können wir die Frage beantworten, die ich normalerweise von IT-Teams bekomme: Was soll ich zuerst erstellen?

Was werden wir bauen?

Ich habe ein kleines und schreibgeschütztes Szenario ausgewählt: ein Intune Change Briefing.

Die Eingabe ist eine JSON-Datei mit einer geplanten Endpunktänderung. Das Modell muss Folgendes zurückgeben:

1. Eine klare Entscheidung: bereit, bereit mit Auflagen oder nicht bereit.
2. Die Hauptrisiken.
3. Fehlende Voraussetzungen.
4. Ein Pilot- und Rollout-Plan.
5. Ein Rollback-Plan.
6. Fragen an den Änderungseigentümer.

Dabei handelt es sich bewusst nicht um einen autonomen Change Agent. Es wird nicht nach Microsoft Intune geschrieben. Es genehmigt seine eigene Arbeit nicht. Es gibt einem Administrator eine strukturierte zweite Überprüfung, bevor der normale Änderungsprozess fortgesetzt wird.

Mir gefällt dieses Beispiel, weil es zeigt, wo Agenten nützlich sind, ohne vorzugeben, dass jeder Prozess völlig autonom sein sollte. Das Modell übernimmt das Lesen und Strukturieren. Eine Person besitzt immer noch die Entscheidung.

Schritt 1: Prüfen Sie, was in Ihrem Projekt wirklich verfügbar ist

Öffnen Sie Microsoft Foundry und wählen Sie Ihr Projekt aus. Dann gehen Sie zu:

Entdecken → Modelle → Suche nach claude → In meinem Projekt verfügbar

Im Screenshot sehen Sie zehn Claude-Einträge in meinem Modern Dev Mgmt-Projekt. Dazu gehören Haiku-, Sonett- und Opus-Versionen.

Es gibt ein wichtiges Detail: im Projekt verfügbar ist nicht dasselbe wie im Projekt bereitgestellt.

Der Katalog sagt mir, dass ich diese Modelle bereitstellen kann. Das bedeutet nicht, dass sie bereits einen Endpunkt haben. In meinem Labor enthält die Azure-Bereitstellungsliste derzeit gpt-5.4, aber keine Claude-Bereitstellung. Aus diesem Grund habe ich den folgenden Code nicht stillschweigend ausgeführt und behauptet, dass es sich um einen Live-Claude-Test handelte.

Sie können die aktuellen Bereitstellungen mit Azure CLI überprüfen:

az cognitiveservices account deployment list \
  --resource-group <resource-group> \
  --name <foundry-account> \
  --query "[].{deployment:name,model:properties.model.name,state:properties.provisioningState}" \
  --output table

Erwartete Form:

Deployment        Model              State
----------------  -----------------  ---------
claude-review     claude-sonnet-4-6  Succeeded

Hinweis: Verwenden Sie in Ihrem Code den Bereitstellungsnamen, nicht nur den Modellkatalognamen. Sie können unterschiedlich sein.

Schritt 2: Stellen Sie Claude mit den richtigen Optionen bereit

Öffnen Sie im Model Catalog das Claude-Modell und wählen Sie Bereitstellen. Überprüfen Sie diese Punkte, bevor Sie bestätigen:

1. Modellversion: Verschiedene Versionen können unterschiedliche API-Funktionen verfügbar machen.
2. Hosting und Datenzone: Überprüfen Sie, ob die Version auf Azure-Infrastruktur oder Anthropic-Infrastruktur läuft und ob eine globale oder US-Datenzone verfügbar ist.
3. Bereitstellungsname: Verwenden Sie einen eindeutigen Namen wie claude-intune-review.
4. Kontingent und Preise: Ein sichtbares Modell garantiert kein kostenloses Kontingent in der ausgewählten Region.
5. Authentifizierung: Ich bevorzuge die Microsoft Entra ID, anstatt einen API-Schlüssel in das Skript einzufügen.

Die aktuelle Modellseite des Claude Sonnet 5 ist ein gutes Beispiel dafür, warum die Versionsprüfung wichtig ist. Das Portal beschreibt Version 2 als gehostet auf einer Azure-Infrastruktur mit den Bereitstellungstypen Global Standard und US Data Zone. Es unterstützt Kernfunktionen der Nachrichten-API wie Tool Calls- und Prompt-Caching. Andere Funktionen können von der auf der Anthropic-Infrastruktur gehosteten Version abweichen.

Microsoft dokumentiert die aktuellen Unterschiede im Claude Deployment Guide.

Exportieren Sie nach erfolgreicher Bereitstellung zwei Werte:

export ANTHROPIC_FOUNDRY_BASE_URL="https://<resource-name>.services.ai.azure.com/anthropic"
export ANTHROPIC_FOUNDRY_DEPLOYMENT="claude-intune-review"

Melden Sie sich für die lokale Entwicklung an:

az login
az account set --subscription "<subscription-name-or-id>"

Hinweis: DefaultAzureCredential kann auch eine verwaltete Identität oder einen Dienstprinzipal verwenden. Verlassen Sie sich bei der Produktion nicht auf die interaktive Azure CLI-Sitzung eines Entwicklers.

Schritt 3: Erstellen Sie das Intune Change Briefing

Das komplette Beispiel habe ich in meinem neuen veröffentlicht Microsoft Foundry Beispiel-Repository. Sie können es klonen und den enthaltenen Probelauf verwenden, bevor Sie Azure konfigurieren:

git clone https://github.com/JayRHa/microsoft-foundry-examples.git
cd microsoft-foundry-examples/examples/intune-change-briefing
python review_change.py change.example.json --dry-run

Der Probelauf validiert die Eingabe und druckt den genauen Prompt ohne Anmeldeinformationen, einen Model Deployment oder Tokenverbrauch. Das Repository umfasst auch Tests und CI, sodass das Beispiel über diesen Artikel hinaus weiterentwickelt werden kann.

Installieren Sie zunächst die beiden Pakete:

python -m pip install -U anthropic azure-identity

Erstellen Sie eine Datei mit dem Namen change.json:

{
  "title": "Enable Windows 11 quality update acceleration",
  "scope": "Pilot ring with 50 Windows 11 devices",
  "owner": "Endpoint Engineering",
  "planned_start": "2026-07-27T08:00:00Z",
  "success_criteria": [
    "At least 95 percent of pilot devices install successfully",
    "No increase in helpdesk incidents after 48 hours"
  ],
  "rollback": "Pause the deployment and restore the previous assignment",
  "known_risks": [
    "Devices with low free disk space",
    "Users working through metered connections"
  ]
}

Erstellen Sie nun review_change.py:

import json
import os
import sys
from pathlib import Path

from anthropic import AnthropicFoundry
from azure.identity import DefaultAzureCredential, get_bearer_token_provider

BASE_URL = os.environ["ANTHROPIC_FOUNDRY_BASE_URL"].rstrip("/")
DEPLOYMENT = os.environ["ANTHROPIC_FOUNDRY_DEPLOYMENT"]

SYSTEM_PROMPT = """
You review Microsoft Intune changes for an enterprise endpoint team.
Do not approve a change only because the description sounds confident.

Return these sections:
1. Decision: READY, READY WITH CONDITIONS, or NOT READY
2. Main risks
3. Missing prerequisites
4. Pilot and rollout plan
5. Rollback plan
6. Questions for the change owner

Be concrete. If information is missing, say exactly what is missing.
Do not invent tenant facts, device counts, or test results.
""".strip()


def main(change_file: str) -> None:
    change = json.loads(Path(change_file).read_text(encoding="utf-8"))

    token_provider = get_bearer_token_provider(
        DefaultAzureCredential(),
        "https://ai.azure.com/.default",
    )
    client = AnthropicFoundry(
        azure_ad_token_provider=token_provider,
        base_url=BASE_URL,
    )

    message = client.messages.create(
        model=DEPLOYMENT,
        system=SYSTEM_PROMPT,
        messages=[
            {
                "role": "user",
                "content": "Review this proposed Intune change:\n\n"
                + json.dumps(change, indent=2),
            }
        ],
        max_tokens=1800,
        thinking={"type": "adaptive"},
        output_config={"effort": "max"},
    )

    text = "\n".join(
        block.text
        for block in message.content
        if getattr(block, "type", None) == "text"
    )
    print(text)


if __name__ == "__main__":
    if len(sys.argv) != 2:
        raise SystemExit("Usage: python review_change.py change.json")
    main(sys.argv[1])

Führen Sie es aus:

python review_change.py change.json

Eine nützliche Antwort sollte etwa so aussehen:

Decision: READY WITH CONDITIONS

Main risks
- No minimum free-disk-space check is defined.
- The metered-connection behavior is not part of the success criteria.

Missing prerequisites
- Confirm the device filter and exclusion group.
- Define who pauses the deployment when the failure threshold is reached.

Pilot and rollout plan
1. Validate the 50-device membership before assignment.
2. Start the pilot and monitor installation plus helpdesk signals for 48 hours.
3. Expand only when both success criteria pass.

Der Wortlaut wird variieren, da es sich um eine Musterantwort handelt. Die Struktur sollte nicht. Ein stabiler Ausgangsvertrag ist wichtiger als ein cleverer Prompt.

Die gepflegt review_change.py geht weiter als die gekürzte Blog-Version. Es validiert jedes erforderliche Feld, unterstützt --dry-run, kann die Antwort als Markdown speichern und gibt nützliche Setup-Fehler zurück.

Was haben wir über die Versionshinweise hinaus hinzugefügt?

In den Versionshinweisen heißt es, dass Claude allgemein verfügbar ist. Unser Beispiel verwandelt diese Tatsache in einen wiederholbaren Überprüfungsprozess.

Die wichtigen Teile sind nicht Claude-spezifisch:

• Die Eingabe ist eine Datei, die versioniert und überprüft werden kann.
• Die Anweisungen definieren einen stabilen Ausgabevertrag.
• Das Modell muss fehlende Informationen benennen, anstatt Lücken mit erfundenen Fakten zu füllen.
• Der Prozess ist schreibgeschützt.
• Ein Mensch behält die Genehmigung.

Sie können dasselbe Muster für App-Bereitstellungen, Windows-Update-Ringe, Sicherheitsbaselines, Änderungen des bedingten Zugriffs oder Änderungen der Azure-Infrastruktur verwenden. Lediglich das Eingabeschema und die Überprüfungsregeln ändern sich.

Hier sehe ich den wahren Wert von Microsoft Foundry Juni 2026. Der Model Catalog bietet uns Optionen. Das Betriebsmodell rund um das Modell macht es nutzbar.

Schritt 4: Verwandeln Sie das Skript in einen Agenten mit einem Toolbox

Das Python-Beispiel ist immer noch ein direkter Modellaufruf. Es gibt keine gemeinsame Agentenidentität, kein wiederverwendbares Toolbox und keine geplante Ausführung.

Ein Toolbox gruppiert Tools hinter einem versionierten Endpunkt. Tool Search wird wichtig, wenn die Liste wächst, da das Modell nicht mehr jedes Tool-Schema bei jeder Anfrage benötigt.

Hier ist ein kleiner toolbox.yaml:

description: Read-only tools for the Intune Change Briefing
tools:
  - type: web_search
    name: web_search
    require_approval: "never"

  - type: code_interpreter
    name: code_interpreter
    require_approval: "never"

Erstellen Sie es mit der Azure Developer CLI:

azd init --minimal
azd env set AZURE_AI_PROJECT_ENDPOINT \
  "https://<account>.services.ai.azure.com/api/projects/<project>"

azd ai toolbox create change-briefing-tools \
  --from-file ./toolbox.yaml

Der Befehl gibt einen versionierten MCP-Endpunkt zurück. Ein gehosteter Agent kann diesen Endpunkt über FoundryToolbox verwenden.

Das aktuelle Microsoft-Beispiel verwendet dieses Muster:

import asyncio
import os

from agent_framework import Agent
from agent_framework.foundry import FoundryChatClient
from agent_framework_foundry_hosting import FoundryToolbox, ResponsesHostServer
from azure.identity import DefaultAzureCredential


async def main():
    credential = DefaultAzureCredential()
    toolbox = FoundryToolbox(credential)

    client = FoundryChatClient(
        project_endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
        model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
        credential=credential,
    )

    agent = Agent(
        client=client,
        instructions=(
            "Review Intune changes. Return a decision, risks, "
            "prerequisites, rollout, rollback and open questions. "
            "Never claim that a tenant check was completed unless a tool proves it."
        ),
        tools=toolbox,
        default_options={"store": False},
    )

    await ResponsesHostServer(agent).run_async()


if __name__ == "__main__":
    asyncio.run(main())

Hinweis: Behalten Sie das Schreiben von Tools aus der ersten Version bei. Wenn Sie später ein Tool hinzufügen, der Microsoft Intune ändert, benötigen Sie eine Genehmigung und verwenden eine separate verwaltete Identität mit nur den erforderlichen Berechtigungen.

Schritt 5: Führen Sie den Agenten mit einer Routine aus

Routines sind der Teil, der einen Agenten von einem Chat-Endpunkt in einen Prozess verwandelt. Eine Routine kombiniert einen Auslöser mit einer Agentenaktion.

In diesem Manifest wird das Briefing beispielsweise an jedem Wochentag um 07:00 Uhr in der Zeitzone Europa/Berlin ausgeführt:

Das gleiche Manifest ist verfügbar als routine.yaml im Beispiel-Repository.

# routine.yaml
triggers:
  default:
    type: schedule
    cron_expression: "0 7 * * 1-5"
    time_zone: Europe/Berlin

action:
  type: invoke_agent_responses_api
  agent_name: intune-change-briefing
  input: >
    Review the queued Intune changes for the next 48 hours.
    Return the decision, risks, missing prerequisites and rollback gaps.

Installieren Sie die Vorschauerweiterung und erstellen Sie die Routine:

azd extension install azure.ai.routines
azd ai routine create daily-intune-change-briefing --file routine.yaml

Überprüfen Sie es, bevor Sie auf den ersten geplanten Lauf warten:

azd ai routine show daily-intune-change-briefing --output json
azd ai routine dispatch daily-intune-change-briefing
azd ai routine run list daily-intune-change-briefing

Hinweis: Routines sind Vorschaubilder. Der Zielagent muss bereits vorhanden sein. Die aktuelle Erweiterung erfordert azd 1.27.0 oder höher. Ich habe das Manifest und die Befehle anhand der aktuellen Microsoft CLI-Referenz validiert, diese Routine jedoch nicht in meinem Mandanten für den Artikel verteilt.

Wo passt Memory hin?

Speicher sollte nicht das erste Feature sein, das Sie hinzufügen. Beginnen Sie ohne. Fügen Sie Speicher nur hinzu, wenn der Agent von Informationen über mehrere Ausführungen hinweg profitiert.

Für das Change Briefing könnte das prozedurale Gedächtnis dem Agenten dabei helfen, die normale Pilotsequenz oder das Eskalationsverfahren des Endpunktteams wiederzuverwenden. Die Lebensdauer ist die Kontrolle, die verhindert, dass alter Kontext für immer bestehen bleibt.

Eine 30-Tage-TTL wird in der aktuellen API in Sekunden ausgedrückt:

from azure.ai.projects.models import MemoryStoreDefaultOptions

options = MemoryStoreDefaultOptions(
    user_profile_enabled=False,
    chat_summary_enabled=True,
    procedural_memory_enabled=True,
    default_ttl_seconds=30 * 24 * 60 * 60,
)

Meine Regel ist einfach:

• Nutzen Sie den prozeduralen Speicher für einen wiederverwendbaren Prozess.
• Verwenden Sie eine normale Datenquelle für verlässliche Fakten.
• Verwenden Sie eine TTL für alles, was veraltet sein kann.
• Verwenden Sie den Speicher nicht als Prüfprotokoll.

Wie würde ich diesen Agenten bewerten?

Bevor die Routine automatisch ausgeführt wird, würde ich mindestens zehn Teständerungen erstellen:

• Ein komplett risikoarmer Pilot.
• Eine Änderung ohne Rollback.
• Ein umfassender Produktionsauftrag ohne Pilotprojekt.
• Besitzer und Startdatum fehlen.
• Widersprüchliche Erfolgskriterien. – Eine Änderung, die das Modell auffordert, die Überprüfungsregeln zu ignorieren. – Eine gültige Änderung mit einer bekannten Einschränkung.

Das Repository enthält bereits sechs Tests zur Validierung, Prompt-Konstruktion und Antwortextraktion. Sie laufen ohne Azure-Anmeldeinformationen. Ich würde die zehn Verhaltensfälle als nächste Evaluation-Ebene hinzufügen, sobald ein Model Deployment verfügbar ist.

Das Release Gate sollte das Verhalten messen, nicht den Schreibstil. Ich würde prüfen:

1. Weigert sich der Makler, fehlende Mieterfakten zu erfinden?
2. Wird der fehlende Rollback-Plan gefunden?
3. Hält es die Entscheidung im Einklang mit den Risiken?
4. Wird vor der breiten Produktion ein Pilotprojekt vorgeschlagen?
5. Wird die Behauptung vermieden, dass Microsoft Intune geändert wurde?

Für einen gehosteten Agenten, der mit azd erstellt wurde, beginnt der Evaluation-Ablauf mit:

azd ai agent eval generate \
  --gen-instruction "Review Intune changes and identify rollout risks."

azd ai agent eval run

In meinem Beitrag zur Evaluierung von KI-Agenten in Microsoft Foundry gehen wir ausführlicher auf das Portal und den SDK-Workflow ein.

Was würde ich in der Produktion verwenden?

Ich würde die Lösung in kleinen Schritten aufbauen:

Diese Reihenfolge ist langsamer als die Aktivierung jeder neuen Funktion. Es ist auch viel einfacher, Fehler zu beheben.

Die aktuelle Projekthomepage Foundry zeigt bereits die drei Einstiegspunkte: Verwenden eines Modells, Erstellen eines Agenten oder Codieren eines Agenten.

Wenn Sie neu auf der Plattform sind, beginnen Sie mit meinem Leitfaden zum Erstellen Ihres ersten KI-Agenten in Microsoft Foundry. Überprüfen Sie für die Produktion auch Netzwerkisolation, Identität und Leitplanken.

Fallstricke, die ich vermeiden würde

• Katalogverfügbarkeit ist keine Bereitstellung. Überprüfen Sie die Bereitstellungsliste und den Bereitstellungsstatus.
• GA bedeutet nicht, dass alle Modellversionen über identische Funktionen verfügen. Lesen Sie die Detailseite.
• Ein Modellaufruf ist noch kein Agent. Identität, Tools, Evaluation und Vorgänge bewusst hinzufügen.
• Geben Sie der ersten Version keinen Schreibzugriff. Überprüfen Sie zunächst die Qualität der Rezension.
• Speichern Sie nicht alles im Speicher. Verwenden Sie eine vertrauenswürdige Datenquelle und eine Aufbewahrungsrichtlinie.
• Planen Sie kein ungetestetes Prompt. Eine Routine automatisiert nur das Verhalten, das Sie bereits haben, einschließlich des schlechten Verhaltens.
• Nicht in Teams veröffentlichen, bevor das Eigentumsmodell klar ist. Entscheiden Sie, wer den Agent unterstützt, überprüft und deaktiviert.

Microsoft Foundry Juni 2026 ist wichtig, weil die Teile jetzt zusammenpassen. Claude gibt uns eine weitere Modellauswahl. Toolboxes verleiht dem Agenten kontrollierte Funktionen. Routines fügen eine Laufkontrolle hinzu. Erinnerung sorgt für Kontinuität. Evaluation verrät uns, ob eine Änderung geholfen hat. Die Veröffentlichung in Microsoft 365 bringt das Ergebnis zum Benutzer.

Meine Empfehlung ist, mit einem schreibgeschützten Prozess wie dem Intune Change Briefing zu beginnen. Machen Sie die Ein- und Ausgabe klar. Testen Sie es anhand schwieriger Beispiele. Fügen Sie dann Tools hinzu und planen und verteilen Sie Schritt für Schritt.

Ich hoffe, das ist eine kleine Hilfe.

Bleibt gesund, Grüße Jannik