Agentic Control Layer · Enterprise Agent Runtime
Agentic Control Layer:
KI-Agent für IT-Operations, Kontrolle bei jedem Schritt
Ein Agentic Control Layer ist die deterministische Governance-Schicht zwischen LLM-Intelligenz und technischer Ausführungsinfrastruktur. Der Agent arbeitet wie ein erfahrener Admin Schritt für Schritt: nachsehen, handeln, nachprüfen. Das LLM wählt den nächsten Schritt — der Control Layer entscheidet bei jedem einzelnen Schritt, was ausgeführt wird. AdminsBuddy implementiert dieses Prinzip für Unternehmens-IT.
Was ist ein Agentic Control Layer?
Abgrenzung: Chatbot · Copilot · freier Agent · Control Layer
Die meisten KI-Automatisierungsansätze operieren auf einem Spektrum: vom einfachen Chatbot (beantwortet Fragen) bis zum vollautonomen Agenten (wählt und ruft Tools frei auf). Ein Agentic Control Layer liegt bewusst zwischen diesen Extremen.
Gibt Empfehlungen, beantwortet Fragen, unterstützt menschliche Entscheidungen. Kein eigenständiges Ausführen von Aktionen in Infrastruktur.
Ruft beliebige Tools oder Shell-Befehle auf, ohne festen Katalog und ohne deterministischen Kontrollrahmen. Für Produktionsumgebungen mit schreibenden Zugriffen nicht geeignet.
LLM arbeitet Schritt für Schritt und bewertet jedes Ergebnis. Deterministischer Control Layer entscheidet über jeden einzelnen Werkzeugaufruf — anhand Tool Catalog, Policies und Autonomy Contracts. Vollständiger Audit-Trail.
Systemarchitektur
Conversation Layer
Web-UI · Teams Bot · MCP (ChatGPT / Claude)
Agentic Control Layer ← Sie sind hier
Tool Loop: Ziel → Schritt → Ergebnis → nächster Schritt
Policy Engine · Tool Catalog · Autonomy Contracts · Approval · Memory · Audit
Execution Layer
POD (PowerShell im Kundennetz) · Automation Engine
Zielsysteme
Active Directory · M365 · VMware · Azure · APIs
Tool Loop: so arbeitet der Agent
Kein starrer Plan, sondern viele kleine, kontrollierte Schritte
Der Agent arbeitet wie ein erfahrener Admin: Er schaut nach, handelt, prüft das Ergebnis und entscheidet dann den nächsten Schritt. Jeder einzelne Werkzeugaufruf läuft durch den Control Layer.
Ziel & Abhakliste
Die Anfrage wird zu einem Ziel und einer Abhakliste, sichtbar im Chat. Fehlt eine Angabe, fragt der Agent nach.
Nachdenken & wählen
Das Modell denkt nach und wählt genau ein Werkzeug aus dem Catalog, mit Argumenten
Prüfen & ausführen
Control Layer prüft Catalog, Policy und Autonomy Contract, holt bei Bedarf eine Freigabe ein und dispatcht an POD oder Automation Engine
Ergebnis sehen & neu entscheiden
Der Agent sieht das echte Ergebnis und entscheidet danach den nächsten Schritt, auch einen anderen Weg
Belegter Abschluss
Fertig erst, wenn jeder Punkt mit einem Ergebnis aus dem Lauf belegt oder ehrlich begründet offen ist
Was die Arbeitsweise bringt
Agentisch arbeiten, ohne die Kontrolle abzugeben
Reagiert auf echte Ergebnisse
Ein vorab festgelegter Plan scheitert, wenn die Wirklichkeit anders aussieht. Der Agent sieht jedes Ergebnis, bevor er weitermacht: Ist das Konto gar nicht gesperrt, entsperrt er es auch nicht, sondern sagt das.
Early AccessFragt nach statt zu raten
Gibt es zwei passende Konten oder fehlt eine Angabe, stellt der Agent eine Rückfrage im Chat und arbeitet mit der Antwort weiter. Platzhalter oder erfundene Werte lehnt der Control Layer ab.
Early AccessBelegte Antwort statt Behauptung
Jeder Punkt der Abhakliste braucht einen Beleg aus dem Lauf: eine Ausführung, eine Datei oder eine erteilte Freigabe. Ohne Beleg nimmt die Plattform den Abschluss nicht an. Was nicht ging, steht mit Grund in der Antwort.
Early AccessSichtbar, was gerade passiert
Abhakliste und Zwischenstände erscheinen während des Laufs im Chat. Wer die Anfrage gestellt hat, sieht, woran der Agent arbeitet und wo er auf eine Freigabe wartet.
Early AccessFeste Grenzen je Lauf
Höchstzahl an Schritten, Werkzeugaufrufen und ändernden Aktionen sowie ein Kostendeckel für die Modellnutzung sind je Mandant einstellbar. Ein Lauf kann sich nicht endlos im Kreis drehen.
Early AccessGeheimnisse bleiben verborgen
Bevor ein Werkzeugergebnis an das Modell geht, werden Kennwörter, Schlüssel und als sensibel markierte Felder geschwärzt. Zugangsdaten liegen in DataSets und erreichen das Modell nicht.
Early AccessGedächtnis im Gespräch
Folgefragen im selben Gespräch kennen die vorherigen Aufgaben, Ergebnisse und Belege. „Und jetzt das Gleiche für die Gruppe Vertrieb“ funktioniert ohne alles neu zu erklären.
Early AccessLernt aus Läufen
Bewährte Lösungswege fließen als Playbooks in spätere Läufe ein. Fehlt ein Werkzeug, landet die Lücke im Backlog, statt dass der Agent improvisiert.
Early AccessGovernance-Mechanik
Die Bausteine des deterministischen Control Layers
Tool Catalog & Capability-Modell
Nur explizit im Catalog hinterlegte Tools können vom LLM aufgerufen werden. Jedes Tool hat definiertes Schema, erlaubte Parameter und Autonomy Contract. Das LLM kann keine Tools ad hoc "erfinden".
LiveAutonomy Contracts & Policy Engine
Jedes Tool hat einen definierten Autonomy Contract: Allow (automatisch ausführen), Approval (Freigabe nötig), Deny (blockiert). Diese Entscheidung trifft die deterministische Policy Engine — nicht das LLM.
LiveHuman-in-the-Loop Approval
Bei kritischen Aktionen (z.B. Benutzer deaktivieren, Gruppenänderungen) pausiert der Run und wartet auf explizite menschliche Freigabe. Ein Admin genehmigt oder lehnt ab — danach fährt der Run entsprechend fort.
LiveAudit & Prompt Provenance
Jede LLM-Entscheidung, jede Tool-Auswahl, jede Ausführung und jedes Ergebnis wird im Audit-Trail gespeichert — einschließlich des Prompts, der die Entscheidung ausgelöst hat. Vollständige Nachvollziehbarkeit.
LiveLLM als Denkkomponente
Das LLM denkt vor jedem Schritt nach, wählt das nächste Werkzeug aus dem Catalog und bewertet jedes Ergebnis. Es hat keine direkte Ausführungshoheit — diese liegt ausschließlich beim Control Layer. Zwei getrennte Verantwortlichkeiten.
LiveMCP-Server für externe KI-Assistenten
Ein MCP-Server (JSON-RPC 2.0, OAuth 2.0) bindet externe KI-Assistenten wie ChatGPT, Codex und Claude mandantengebunden an. Lesend: Ressourcen, Job-Status, Skript-Inhalt, AC-Run-Informationen. Schreibend nur mit je Verbindung freigeschalteter Berechtigung: Entwürfe für Tools und Automationen anlegen und – mit ausdrücklicher Bestätigung – Jobs oder Läufe starten. Freigaben erteilt immer ein Mensch in AdminsBuddy.
Live (lesend) · Early Access (schreibend)Produktstand
Heute verfügbar — und was auf der Roadmap steht
Der Agentic Control Layer ist implementiert und produktiv in Betrieb. Die Governance-Mechanik ist stabil. Die Arbeitsweise Schritt für Schritt (Tool Loop) ist im Early Access und wird in begleiteten Pilotfällen eingesetzt.
Live / Early Access
- Tool Loop: Abhakliste, Schritt für Schritt mit Policy-Prüfung je Werkzeugaufruf, belegter Abschluss
- Tool Catalog mit definierten Capability-Contracts
- Autonomy Contracts: Allow / Approval / Deny per Tool
- Deterministische Policy Engine
- Human-in-the-Loop Approval Gates
- Vollständiger Audit-Trail mit Prompt Provenance
- MCP-Server für ChatGPT, Codex & Claude: lesend; schreibend mit Berechtigung und Bestätigung (Early Access)
- Bridge zur Automation Engine (produktiv in Betrieb)
- AD, WinRM, DNS, Storage, M365-Tools über Tool Catalog
Roadmap
- Progressive Trust: dynamische Freigabeanpassung
- Cross-System Learning aus erfolgreichen Runs
- A2A Gateway: Agent-zu-Agent-Kommunikation
Der Agentic Control Layer befindet sich in aktiver Weiterentwicklung. Für erste produktive Einsätze empfehlen wir ein begleitetes Pilotprojekt mit klar abgegrenztem Use Case.
Technische FAQ
Was Architekten und IT-Entscheider fragen
Verwandte Themen
Vertiefende Seiten
Nächster Schritt
Architekturgespräch für Ihren Agentic-Control-Einstieg
Wir besprechen, welcher Use Case sich als erster kontrollierter Agentic-Control-Pilot in Ihrer IT-Umgebung eignet — mit klaren Governance-Grenzen und begleitetem Setup.