Einen Microsoft Intune KI-Agenten mit Foundry bauen

Wir alle haben schon PowerShell-Skripte zum Abfragen von Intune geschrieben, sie in etwas Automatisierung verpackt und es dabei belassen. Das funktioniert. Aber mit dem Azure OpenAI Service und Modellen wie GPT-4.1 und GPT-5.2, die für Tool-Calling optimiert sind, gibt es einen spannenderen Ansatz – einen echten KI-Agenten zu bauen, der mit deiner Intune-Umgebung kommunizieren kann.

Anstatt für jede Abfrage ein Skript zu schreiben, baust du einen einzigen Agenten, der natürliche Sprache versteht und die Graph API in deinem Auftrag aufruft. Frag ihn „Welche Windows-Geräte sind nicht konform?” und er findet den richtigen API-Aufruf, führt ihn aus und fasst die Ergebnisse zusammen. Das ist keine Zauberei – es ist Function Calling mit einer schönen Oberfläche.

In diesem Beitrag führe ich dich durch zwei verschiedene Ansätze, um diesen Agenten zu bauen: den klassischen Ansatz mit dem direkten SDK und das neuere Microsoft Agent Framework. Beide verwenden denselben zugrunde liegenden Graph-API-Client, unterscheiden sich aber darin, wie sie die KI orchestrieren. Legen wir los.

Architekturüberblick

Bevor wir in den Code eintauchen, sehen wir uns an, wie alle Teile zusammenpassen. Das folgt demselben übergeordneten Muster wie KI-gestützte Intune-Richtliniendokumentation und Konfliktanalyse: KI nutzen, um Intune-Daten zu interpretieren, statt sie nur abzurufen.

Abbildung 1: Übersichtsarchitektur des Intune-KI-Agenten

Der Agent fungiert als Orchestrator zwischen dem Benutzer, Azure OpenAI und Microsoft Graph. Wenn du eine Frage stellst, sendet der Python-Agent sie an Microsoft Foundry / Azure OpenAI, das entscheidet, welche Tools aufgerufen werden. Der Agent führt diese Tools über die Graph API aus und gibt die Ergebnisse zur Interpretation an die KI zurück.

Zwei Implementierungsansätze

Dieses Projekt bietet zwei Wege, denselben Agenten zu bauen. Beide nutzen dieselbe graph_helper.py für Graph-API-Aufrufe, unterscheiden sich aber darin, wie sie sich in Azure OpenAI integrieren:

Abbildung 2: Direct SDK vs. Microsoft Agent Framework

Aspekt	Direct SDK (main.py)	Agent Framework
Python-Version	3.9+	3.10+ erforderlich
Tool-Definition	Manuelles JSON-Schema	@ai_function-Decorator
Parameter	Explizites JSON-Schema	Annotated[type, “desc”]
Genehmigungsablauf	Manuell (im System-Prompt)	Integriertes approval_mode
Observability	Eigenes Logging	Natives OpenTelemetry
Ausführungsmodell	Synchron	Asynchron (asyncio)
Reife	Produktionsreif	Preview (–pre)

Welchen solltest du wählen? Nutze den Direct-SDK-Ansatz, wenn du heute Produktionsstabilität brauchst oder mit Python 3.9 arbeitest. Nutze das Agent Framework, wenn du saubereren Code, integrierte Genehmigungs-Workflows möchtest und mit Preview-Software einverstanden bist.

Was ist Microsoft Foundry?

Wenn du Azure AI Studio verfolgt hast, ist dir vielleicht das Rebranding aufgefallen. Auf der Ignite 2024 stellte Microsoft den Azure AI Foundry Agent Service als Public Preview vor, und bis Mai 2025 ging er mit über 10.000 Kunden, die ihn bereits nutzten, in die allgemeine Verfügbarkeit (GA). Die Plattform hat sich seitdem zu Microsoft Foundry weiterentwickelt – einer einheitlichen Erfahrung zum Erstellen, Bereitstellen und Verwalten von KI-Agenten mit Sicherheit auf Enterprise-Niveau.

Die für uns wesentlichen Bestandteile:

• Foundry Agent Service – die Laufzeitumgebung, die deine Agenten hostet, Konversationen abwickelt, Tool-Aufrufe orchestriert und den Zustand verwaltet
• Foundry Models – Zugriff auf GPT-5.2, GPT-4.1, Claude und mehr als 11.000 weitere Modelle über einen einzigen Endpunkt
• Microsoft Agent Framework – das einheitliche SDK (Nachfolger von Semantic Kernel + AutoGen) zum lokalen Bauen von Agenten
• Function Calling – dein Agent kann eigene Tools aufrufen – wie die Microsoft Graph API

GPT-4.1 vs. GPT-5.2: Welches Modell solltest du nutzen?

Beide Modelle sind im Azure OpenAI Service verfügbar und für unterschiedliche Szenarien optimiert.

Aspekt	GPT-4.1	GPT-5.2
Kontext	1 Mio. Tokens Eingabe	272K Tokens
Latenz	Schnell – für Echtzeit optimiert	Langsamer – tiefes Reasoning braucht Zeit
Tool-Calling	Exzellent für Coding/Tools	Vollständige Tool-Unterstützung, rohe Payloads
Am besten für	Schnelle Abfragen, Echtzeit-Chat	Komplexe Analysen, agentische Workflows

Wie der Konversationsablauf funktioniert

Die Magie passiert in der Tool-Calling-Schleife. Hier ist der Schritt-für-Schritt-Ablauf, wenn du dem Agenten eine Frage stellst:

Abbildung 3: Die Tool-Calling-Schleife, die den Agenten antreibt

Die zentrale Erkenntnis ist, dass sich die Schritte 3-6 mehrfach wiederholen können. Wenn deine Frage Daten aus mehreren Quellen erfordert, ruft die KI möglicherweise mehrere Tools nacheinander auf und kombiniert die Ergebnisse, um dir eine vollständige Antwort zu geben.

Ansatz 1: Direktes Azure OpenAI SDK

Dies ist der klassische Ansatz, bei dem das openai Python-Paket direkt verwendet wird. Du definierst Tools als JSON-Schemas und verwaltest die Konversationsschleife selbst.

Tool-Definition (main.py)

Tools werden als Liste von JSON-Objekten mit expliziten Schemas definiert:

TOOLS = [
    {"type": "function", "function": {
        "name": "get_devices_by_os",
        "description": "Filter devices by operating system",
        "parameters": {
            "type": "object",
            "properties": {
                "operating_system": {
                    "type": "string",
                    "description": "OS: Windows, iOS, Android, macOS"
                }
            },
            "required": ["operating_system"]
        }
    }},
    // ... 21 more tool definitions
]

Die Konversationsschleife

Du verwaltest die Tool-Ausführungsschleife manuell:

response = client.chat.completions.create(
    model=model,
    messages=messages,
    tools=TOOLS,
    tool_choice="auto"
)

# Handle tool calls in a loop
while assistant_message.tool_calls:
    for tool_call in assistant_message.tool_calls:
        result = execute_tool(
            tool_call.function.name,
            json.loads(tool_call.function.arguments)
        )
        messages.append({
            "role": "tool",
            "tool_call_id": tool_call.id,
            "content": result
        })
   
    # Get next response
    response = client.chat.completions.create(...)
    assistant_message = response.choices[0].message

Ansatz 2: Microsoft Agent Framework

Das Microsoft Agent Framework (Nachfolger von Semantic Kernel + AutoGen) bietet eine sauberere, pythonischere Möglichkeit, Tools mithilfe von Decorators und Type-Hints zu definieren.

Tool-Definition mit @ai_function

Tools werden als Methoden mit dem @ai_function-Decorator definiert:

from agent_framework import ai_function
from typing import Annotated

class IntuneTools:
    @ai_function(description="Filter devices by operating system")
    def get_devices_by_os(
        self,
        operating_system: Annotated[str, "OS: Windows, iOS, Android, macOS"]
    ) -> str:
        """Filter devices by operating system."""
        result = self.client.get_devices(
            f"operatingSystem eq '{operating_system}'"
        )
        return json.dumps({'count': len(result), 'devices': result})

Beachte, wie die Parameterbeschreibung aus dem Annotated-Type-Hint stammt – kein separates JSON-Schema nötig!

Integrierter Genehmigungsmodus für destruktive Aktionen

Ein herausragendes Feature sind die integrierten Genehmigungs-Workflows:

@ai_function(
    description="Retire a device from Intune. USE WITH CAUTION!",
    approval_mode="always_require"  # Built-in human-in-the-loop!
)
def retire_device(
    self,
    device_id: Annotated[str, "The device ID to retire"]
) -> str:
    result = self.client.retire_device(device_id)
    return json.dumps(result)

Mit approval_mode=”always_require” pausiert das Framework automatisch, bevor es destruktive Operationen ausführt, und fragt nach der Bestätigung des Benutzers.

Vereinfachte Agentenerstellung

Die Erstellung und Ausführung des Agenten ist deutlich sauberer:

from agent_framework.azure import AzureOpenAIChatClient

client = AzureOpenAIChatClient(
    endpoint=os.environ['AZURE_OPENAI_ENDPOINT'],
    credential=credential,
    api_version="2024-10-21"
)

agent = client.create_agent(
    name="IntuneAgent",
    instructions=SYSTEM_PROMPT,
    model=os.environ['MODEL_DEPLOYMENT_NAME']
)

# Run with all tools - framework handles the loop!
result = await agent.run(
    user_input,
    tools=intune_tools.get_all_tools()
)

Verfügbare Tools (beide Ansätze)

Beide Implementierungen bieten dieselben 22 Tools in 7 Kategorien:

Abbildung 4: Alle 22 Funktions-Tools nach Kategorie organisiert

Quick Start

Beide Ansätze teilen sich dasselbe Setup:

# Clone and setup
https://github.com/JayRHa/IntuneAgent
cd IntuneAgent
python -m venv venv
source venv/bin/activate

# Install dependencies
pip install -r requirements.txt

# Configure Azure (creates app registration automatically)
az login
./setup.sh

# Run your preferred approach
python main.py                    # Direct SDK
python main_agent_framework.py    # Agent Framework

Was kannst du damit tatsächlich machen?

• „Zeig mir alle nicht konformen Geräte” – sofortiges Compliance-Dashboard
• „Welche Windows-Geräte haben sich seit 48 Stunden nicht synchronisiert?” – Fehlerbehebung bei veralteten Geräten
• „Schlüssle unsere Flotte nach OS auf” – schnelle Bestandsanalyse
• „Finde Geräte ohne Festplattenverschlüsselung” – Sicherheitsaudit
• „Synchronisiere alle Windows-Geräte” – Batch-Operationen
• „Zeig mir den Autopilot-Bereitstellungsstatus” – Bereitstellungsverfolgung

Das Fazit

Einen KI-Agenten für Intune zu bauen ist keine Science-Fiction mehr. Mit dem Azure OpenAI Service und der Graph API kannst du an einem Nachmittag etwas wirklich Nützliches erstellen. Der schwierigste Teil ist ehrlich gesagt nur das Einrichten der Berechtigungen für die App-Registrierung.

Der Direct-SDK-Ansatz gibt dir volle Kontrolle und funktioniert heute in der Produktion. Der Agent-Framework-Ansatz ist sauberer und leistungsfähiger, mit integrierten Genehmigungs-Workflows und Observability – aber er befindet sich noch in der Preview-Phase. Wähle je nach deinen Anforderungen.

Der vollständige Code für beide Ansätze ist auf GitHub verfügbar. Wenn du etwas Cooles damit baust, lass es mich wissen – ich würde gerne sehen, was die Leute erstellen. Wenn du die frühere Azure-OpenAI-Studio-Version dieser Idee möchtest, schau dir Create your own Intune Co-Pilot using Azure OpenAI Studio an.

Ressourcen

Microsoft Agent Framework – Überblick
Agent Framework GitHub-Repository
Microsoft Foundry – Dokumentation
Azure OpenAI Service – Modelle
Microsoft Graph API für Intune
GPT-4.1 Ankündigung
GPT-5.2 Ankündigung