Mit KI-Stack 2.16 wird aus dem bisher aufgebauten Tool-Zugriff ein echtes Betriebsmodell für lokale KI. Die technische Grundlage dafür entstand bereits mit Open Terminal und der MCP-Integration der vorherigen Releases. 2.16 führt deshalb bewusst keinen neuen Runtime-Dienst und keine zusätzliche Sammlung spezieller Windows-Tools ein. Stattdessen wird geprüft und festgelegt, wie weit die vorhandene Architektur bereits reicht, wenn ein lokaler Assistent nicht mehr nur Informationen lesen, sondern tatsächlich auf dem eigenen System handeln soll.
Der zentrale Gedanke hinter 2.16 lautet deshalb nicht „mehr Tools“, sondern mehr nutzbare Handlungsfähigkeit auf Basis der bereits vorhandenen Werkzeuge. Die vorhandene MCP Runtime, die zwölf MCP-Tools, run_command, PowerShell und die bestehenden Lifecycle-Skripte des KI-Stacks wurden als ausreichend validiert, um Windows, WSL, Docker, Prozesse, Dateien, Dienste, Registry, geplante Tasks und lokale Anwendungen zu steuern.
Damit verändert sich die Rolle des lokalen Assistenten deutlich. Ein Sprachmodell kann nun nicht mehr nur erklären, welcher Befehl ausgeführt werden müsste. Ein entsprechend berechtigtes Profil kann den erforderlichen Schritt selbst über die vorhandene Tool-Schicht durchführen, das Ergebnis auswerten und daraus die nächste Aktion ableiten.
Von Tool-Zugriff zu Local Control
Mit MCP allein ist ein Assistent noch kein lokaler Administrator. MCP stellt zunächst nur die standardisierte Verbindung zu Werkzeugen bereit. Entscheidend ist die Frage, wie diese Werkzeuge verwendet werden und welche Aufgaben damit zuverlässig ausgeführt werden können.
Ein einfacher Tool-Aufruf könnte beispielsweise nur eine Datei lesen oder einen Prozessstatus anzeigen. Local Control geht einen Schritt weiter und betrachtet mehrere solche Aktionen als zusammenhängende Arbeitskette. Ein Assistent kann beispielsweise zunächst feststellen, dass ein Dienst nicht läuft, anschließend das zugehörige Log prüfen, eine Konfigurationsdatei untersuchen und den Dienst nach einer Korrektur neu starten.
Der Unterschied liegt damit nicht nur in der technischen Schnittstelle, sondern in der Arbeitsweise. Der Agent kann Ergebnisse aus realen Systemabfragen direkt in seine weitere Planung einbeziehen.
Warum 2.16 keine neue Control-Runtime benötigt
Bei der Planung von Local Control lag eine naheliegende Architektur auf dem Tisch: Für verschiedene Windows-Funktionen könnten eigene MCP-Tools geschaffen werden. Denkbar wären spezielle Werkzeuge für Dienste, Registry, geplante Tasks, Prozesse, Netzwerkkonfiguration oder Anwendungen.
Technisch wäre das möglich. Es hätte aber gleichzeitig eine zweite Steuerungsschicht geschaffen, die viele Funktionen nachbildet, die Windows und PowerShell bereits seit Jahren bereitstellen.
KI-Stack 2.16 verfolgt deshalb bewusst einen anderen Ansatz. Das generische MCP-Tool run_command bleibt die zentrale Brücke für allgemeine lokale Steuerung. Dahinter kann PowerShell seine bereits vorhandenen Cmdlets, Module und strukturierten Schnittstellen nutzen. Für Funktionen des KI-Stacks selbst werden weiterhin die vorhandenen Lifecycle- und Administrationsskripte verwendet.
Genau diese Architektur wurde in 2.16 bewusst beibehalten. Es gibt keinen zweiten Local-Control-Dienst, keinen zusätzlichen MCP-Port, kein weiteres Credential und keinen neuen Windows-Control-Service.
PowerShell wird zur universellen lokalen Steuerungsschicht
Für Windows ist PowerShell besonders gut für diesen Ansatz geeignet. Viele Verwaltungsfunktionen stehen bereits als strukturierte Cmdlets zur Verfügung. Ein Agent muss deshalb nicht lernen, wie jede einzelne Windows-Funktion über eine eigene proprietäre MCP-Schnittstelle angesprochen wird.
Einige typische Beispiele sind:
Get-Service
Get-Process
Get-ChildItem
Get-ScheduledTask
Get-NetTCPConnection
Get-ItemProperty
Get-CimInstance
Diese Cmdlets liefern bereits strukturierte Objekte. Das ist für einen KI-Agenten wesentlich wertvoller als beliebig formatierter Konsolentext.
Wenn beispielsweise Informationen über laufende Dienste abgefragt werden, muss der Agent nicht versuchen, Spalten aus einer Texttabelle zu interpretieren. PowerShell kann das Ergebnis stattdessen direkt in JSON umwandeln:
Get-Service | Select-Object Name, Status, StartType | ConvertTo-Json
Der Agent erhält damit eine klar definierte Struktur:
[
{
"Name": "ExampleService",
"Status": "Running",
"StartType": "Automatic"
}
]
Gerade bei komplexeren Abfragen reduziert das Fehlinterpretationen erheblich. KI-Stack 2.16 hat deshalb die strukturierte Rückgabe von PowerShell-Ergebnissen über ConvertTo-Json ausdrücklich validiert.
Dateien lesen und verändern
Ein grundlegender Bestandteil von Local Control ist der Umgang mit Dateien. Der bestehende MCP Runtime stellt dafür bereits mehrere Werkzeuge bereit, darunter Funktionen zum Lesen, Schreiben, Ersetzen und Suchen von Dateien.
Damit kann ein Agent beispielsweise eine Konfiguration untersuchen, eine bestimmte Einstellung finden und anschließend gezielt ändern. Entscheidend ist, dass die Änderung nicht zwangsläufig über einen großen Shell-Befehl erfolgen muss. Wo ein spezialisiertes Dateiwerkzeug vorhanden ist, kann dieses verwendet werden.
Ein typischer Ablauf könnte so aussehen:
Konfigurationsdatei suchen
↓
Datei lesen
↓
relevante Einstellung erkennen
↓
gezielte Änderung
↓
Datei erneut prüfen
↓
Dienst neu starten
Local Control bedeutet damit nicht, dass jede Aufgabe zwangsläufig über eine Kommandozeile erledigt wird. Die vorhandenen MCP-Werkzeuge werden je nach Aufgabe kombiniert.
Prozesse und laufende Programme steuern
Auch die Prozesssteuerung gehört bereits zur vorhandenen Tool-Oberfläche. Prozesse können aufgelistet, ihr Status abgefragt, Eingaben an laufende Prozesse gesendet oder Prozesse kontrolliert beendet werden.
In Kombination mit run_command entsteht daraus eine relativ umfassende lokale Prozesssteuerung.
Ein Agent könnte beispielsweise prüfen, ob ein lokaler Dienst beziehungsweise eine Anwendung tatsächlich läuft, feststellen, dass ein Prozess hängt, den Zustand dokumentieren und anschließend einen definierten Neustart durchführen.
Gerade hier bleibt wichtig, dass nicht automatisch jede Prozess-ID als vertrauenswürdig angesehen werden sollte. Bereits mit Open Terminal wurde deshalb Wert darauf gelegt, Prozesse nicht nur anhand einer gespeicherten PID zu identifizieren, sondern die tatsächliche Prozessidentität zu berücksichtigen.
Local Control baut auf diesem Sicherheitsmodell auf, statt einen neuen parallelen Prozessmechanismus einzuführen.
Windows-Dienste, Registry und geplante Tasks
Viele administrative Aufgaben, die früher für einen KI-Agenten nach „Spezialintegration“ aussahen, lassen sich unter Windows direkt über PowerShell lösen.
Für Dienste existieren beispielsweise Cmdlets wie:
Get-Service
Start-Service
Stop-Service
Restart-Service
Für Registry-Abfragen können die normalen PowerShell-Provider verwendet werden. Geplante Tasks lassen sich über Get-ScheduledTask, Start-ScheduledTask oder andere vorhandene Verwaltungsfunktionen steuern.
Damit entsteht ein wichtiger Architekturvorteil: Die Logik bleibt dort, wo sie hingehört.
MCP muss nicht wissen, wie die Windows Registry intern funktioniert. Der MCP Runtime muss auch keinen eigenen Task-Scheduler implementieren. Er stellt lediglich den sicheren Ausführungspfad bereit, während PowerShell die eigentliche Systemintegration übernimmt.
WSL und Docker ohne neue Spezialtools
Dasselbe Prinzip funktioniert auch außerhalb der klassischen Windows-Verwaltung.
Wenn WSL installiert ist, kann PowerShell beziehungsweise die lokale Kommandozeile wsl.exe aufrufen. Dadurch kann ein Agent Linux-Befehle innerhalb einer WSL-Distribution ausführen.
Auch Docker benötigt keine spezielle neue MCP-Schicht, solange die vorhandene Docker-CLI lokal verfügbar ist. Ein Agent kann beispielsweise Container auflisten, Logs untersuchen oder einen definierten Container neu starten.
Vereinfacht:
LLM
↓
MCP
↓
run_command
↓
PowerShell
├─ Windows Cmdlets
├─ wsl.exe
└─ docker.exe
Diese Wiederverwendung bestehender Werkzeuge ist einer der wichtigsten Punkte von 2.16. Local Control wird nicht als Sammlung zusätzlicher APIs verstanden, sondern als kontrollierter Zugang zu bereits vorhandenen Administrationsschnittstellen.
Auch der KI-Stack selbst wird über seine vorhandenen Lifecycle-Skripte gesteuert
Für die eigenen Komponenten des KI-Stacks gilt dasselbe Prinzip. Es wäre möglich gewesen, für jede Anwendung neue MCP-Tools wie start_openwebui, stop_comfyui oder restart_lmstudio einzuführen.
Das würde aber Logik duplizieren, die bereits im Stack vorhanden ist.
Deshalb verwendet Local Control dort nach Möglichkeit die etablierten zentralen Start-, Stop- und Statusmechanismen. Wenn der Assistent beispielsweise eine KI-Stack-Komponente kontrolliert neu starten soll, verwendet er die dafür vorhandenen Skripte anstatt einen zweiten proprietären Steuerungspfad aufzubauen.
Das hat einen weiteren Vorteil: Änderungen an der internen Betriebslogik müssen nur an einer Stelle gepflegt werden. Der Agent ruft dieselben Betriebsfunktionen auf, die auch ein Administrator manuell verwenden würde.
Local Control ist mehr als eine technische Schnittstelle
Mit 2.16 wurden deshalb nicht nur technische Funktionen getestet. Die MCP-fähigen Profile erhielten auch Local Control Operating Principles.
Damit wird definiert, wie der Assistent mit seiner neuen Handlungsfähigkeit umgehen soll. Ein Agent, der für jeden einzelnen harmlosen Schritt erneut nach einer Bestätigung fragt, ist praktisch kaum effizienter als ein normaler Chatbot. Gleichzeitig darf daraus keine pauschale Erlaubnis für beliebige Systemänderungen entstehen.
Die zentrale Unterscheidung lautet deshalb: gewöhnliche Reparaturen und klar eingegrenzte Systemänderungen sollen innerhalb des erteilten Auftrags selbstständig durchgeführt werden können. Kritische, weitreichende oder destruktive Eingriffe bleiben eine andere Kategorie.
Das Release nennt ausdrücklich, dass normale Reparaturen und Systemänderungen nicht mehr grundsätzlich eine pauschale Bestätigung für jeden Einzelschritt benötigen.
Warum ständige Bestätigungen Agenten unbrauchbar machen
Stellen wir uns eine einfache Diagnose vor:
Prüfe, warum Open WebUI nicht erreichbar ist, und behebe das Problem.
Ein schlecht konfigurierter Agent könnte anschließend fragen:
Darf ich den Prozessstatus prüfen?
Nach der Bestätigung:
Darf ich das Logfile lesen?
Danach:
Darf ich den Port prüfen?
Und anschließend:
Darf ich den Dienst neu starten?
Technisch wäre das sehr sicher, praktisch aber kaum automatisiert.
Local Control benötigt deshalb ein sinnvolles Delegationsmodell. Der Benutzer erteilt einen klar begrenzten Auftrag. Innerhalb dieses Auftrags darf der Agent notwendige, risikoarme Zwischenschritte selbst durchführen.
Das bedeutet nicht, dass jede Aktion automatisch erlaubt ist. Die entscheidende Grenze liegt im Risiko und in der Reichweite einer Aktion.
Lesen, reparieren und zerstören sind unterschiedliche Risikoklassen
Für Local Control ist deshalb eine einfache Risikobetrachtung hilfreich.
Eine lesende Aktion wie:
Get-Service
hat ein anderes Risiko als:
Restart-Service
Und beide unterscheiden sich wiederum fundamental von einer Aktion wie:
Remove-Item -Recurse -Force
Eine belastbare Agentenarchitektur sollte diese Unterschiede berücksichtigen. Lesende und klar reversible Operationen können weitgehend autonom erfolgen. Normale Reparaturen können innerhalb eines eindeutigen Benutzerauftrags ebenfalls automatisiert werden. Irreversible oder weitreichende Veränderungen benötigen dagegen stärkere Sicherheitsmechanismen.
MCP selbst entscheidet diese Policy nicht. Die Verantwortung liegt beim Host, beim Profil und bei den Operating Principles des jeweiligen Agenten.
Local Control bedeutet nicht unbegrenzten Zugriff
Der Begriff „autonomous Local Control“ kann leicht missverstanden werden. Er bedeutet nicht, dass ein Sprachmodell uneingeschränkten Zugriff auf den gesamten Rechner erhält und ohne Regeln beliebige Aktionen ausführen soll.
Local Control beschreibt vielmehr die Fähigkeit eines Agenten, innerhalb seiner vorhandenen Berechtigungen und seines definierten Aufgabenbereichs selbstständig technische Schritte auszuführen.
Ein Tool kann nicht mehr Rechte besitzen als der Prozess, unter dem es ausgeführt wird. Gleichzeitig begrenzen Agentenprofil und MCP-Binding, welche Werkzeuge überhaupt zur Verfügung stehen. Damit entsteht Local Control nicht durch pauschale Vollrechte, sondern durch die Kombination aus Benutzerauftrag, Profil, Tool-Freigabe und Betriebssystemberechtigung.
Ballistics Pack: MCP-Binding muss Reconcile überleben
Eine konkrete Korrektur in 2.16 betrifft das Ballistics Pack.
Bereits bei der Einführung von MCP war wichtig geworden, dass Tool-Bindings bei späteren Upgrade- oder Repair-Läufen nicht versehentlich verloren gehen. Ein Reconcile-Prozess, der ein Profil aus seiner Definition neu aufbaut, darf externe beziehungsweise ergänzte Tool-Bindings nicht einfach überschreiben.
Mit 2.16 wurde deshalb auch das Reconcile-Verhalten des Ballistics Packs angepasst. Die vorhandene MCP-Bindung bleibt erhalten und wurde zusätzlich auf Idempotenz geprüft.
Das klingt zunächst nach einem kleinen Detail, ist für einen agentischen Stack aber wichtig. Ein Systemzugriff, der nach einem gewöhnlichen Repair plötzlich verschwindet, wäre betrieblich kaum zuverlässig.
Warum Idempotenz bei Agentenkonfiguration wichtig ist
Ein Reconcile sollte einen bereits korrekten Zustand nicht unnötig verändern.
Wenn ein Agentenprofil bereits die richtige MCP-Verbindung besitzt, muss ein erneuter Lauf zum selben Ergebnis führen. Genau das bedeutet Idempotenz in diesem Zusammenhang.
Ohne diese Eigenschaft könnten Wartungsläufe schleichend Konfigurationen verändern. Ein Profil könnte beispielsweise beim ersten Lauf funktionieren, nach einem Upgrade ein Tool verlieren und nach einem weiteren Repair wieder einen anderen Zustand besitzen.
Gerade bei sicherheitsrelevanten Tool-Bindings ist ein solcher Drift unerwünscht.
Was in 2.16 tatsächlich validiert wurde
2.16 wurde nicht nur anhand der Architekturidee bewertet. Die Local-Control-Funktion wurde gegen das reale Zielsystem getestet.
Validiert wurden unter anderem Dateioperationen, Prozesse, das aktuelle Arbeitsverzeichnis, Windows-Abfragen und die Steuerung von KI-Stack-Anwendungen. Zusätzlich wurden Repository-Regressionstests, Payload-Tests, die MCP-Binding-Erhaltung des Ballistics Packs und die Idempotenz des Reconcile durchgeführt. Das veröffentlichte Release weist 34 von 34 bestandene Repository-Tests sowie 12 von 12 bestandene Payload-Validierungen aus.
Damit ist ein wichtiger Unterschied zur rein theoretischen Agentenarchitektur gegeben: Die grundlegenden Steuerungspfade wurden tatsächlich auf einem realen Windows-Zielsystem ausgeführt.
Was 2.16 bewusst nicht macht
Ebenso wichtig wie die neuen Möglichkeiten sind die Funktionen, die bewusst nicht Bestandteil dieses Releases sind.
2.16 führt keine GUI- oder Desktop-Automatisierung ein. Der Agent kann also nicht beliebige grafische Programme durch simulierte Mausbewegungen oder Tastatureingaben bedienen.
Das ist eine bewusste Grenze.
Solange ein System über PowerShell, CLI, Dateien, APIs oder vorhandene Verwaltungswerkzeuge kontrolliert werden kann, sind diese Schnittstellen meist stabiler, besser überprüfbar und einfacher zu automatisieren als grafische Benutzeroberflächen.
GUI- und Desktop-Automatisierung war deshalb für einen späteren Entwicklungsschritt vorgesehen.
Auch persistentes Memory gehört noch nicht zu 2.16. Ein Agent kann lokal handeln, besitzt damit aber noch nicht automatisch ein langfristiges Gedächtnis über mehrere Gespräche hinweg. Diese Trennung ist architektonisch sinnvoll, weil Handlungsfähigkeit und Erinnerung zwei unterschiedliche Probleme lösen.
Warum die Architektur bewusst klein bleibt
Die vielleicht wichtigste Entscheidung in 2.16 ist das, was nicht gebaut wurde.
Es gibt keinen neuen Port.
Es gibt kein neues Credential.
Es gibt keinen zusätzlichen Windows-Dienst.
Es gibt keine zweite Local-Control-Runtime.
Es gibt keine Sammlung dutzender Windows-spezifischer MCP-Tools.
Stattdessen wird die vorhandene Architektur weiterverwendet:
Open WebUI
↓
bestehender MCP Runtime
↓
bestehende MCP Tools
↓
run_command / Datei- und Prozesswerkzeuge
↓
PowerShell / WSL / Docker / KI-Stack-Skripte
↓
lokales System
Dadurch bleibt die Zahl der Komponenten überschaubar. Das reduziert nicht nur Installationsaufwand, sondern auch Updatepfade, Credentials, Netzwerkendpunkte und mögliche Fehlerquellen.
Für einen lokalen KI-Stack ist diese Reduktion besonders wertvoll. Agentische Systeme werden ohnehin schnell komplex. Nicht jede neue Fähigkeit sollte deshalb automatisch eine neue Runtime erzeugen.
Der Schritt vom Chatbot zum lokalen Assistenten
Mit 2.14 und 2.15 wurde zunächst die technische Verbindung zum Rechner geschaffen und über MCP standardisiert. 2.16 verändert nun die Nutzung dieser Verbindung.
Der Assistent kann nicht nur einen einzelnen Tool-Aufruf durchführen, sondern Werkzeuge als Teil einer technischen Aufgabe kombinieren. Er kann Systemzustände erfassen, daraus Entscheidungen ableiten und innerhalb eines definierten Auftrags Reparaturen durchführen.
Die Entwicklung lässt sich deshalb so zusammenfassen:
2.14
Lokaler Terminalzugriff
↓
2.15
Standardisierte MCP-Tool-Schicht
↓
2.16
Local Control
↓
Agent kann lokale Aufgaben durchführen
Damit nähert sich der KI-Stack einem System, das nicht mehr nur Wissen bereitstellt, sondern lokale technische Arbeit tatsächlich unterstützen und teilweise selbst ausführen kann.
Local Control ersetzt keinen Administrator
Trotz dieser Fähigkeiten bleibt ein wichtiger Unterschied bestehen.
Ein Sprachmodell besitzt kein magisches Verständnis eines Systems. Es arbeitet mit den Informationen, Werkzeugen und Regeln, die ihm zur Verfügung gestellt werden. Ein falscher Kontext, eine fehlerhafte Interpretation oder ein ungeeignetes Tool kann weiterhin zu falschen Entscheidungen führen.
Local Control sollte deshalb nicht als Ersatz für Systemarchitektur, Berechtigungsmodelle oder Betriebsprozesse verstanden werden.
Die sinnvollere Perspektive lautet:
Der Agent wird zu einer neuen Automatisierungsschicht über vorhandenen, kontrollierten Verwaltungswerkzeugen.
Je besser diese darunterliegende Umgebung strukturiert ist, desto zuverlässiger kann der Agent arbeiten.
Ein sauberer PowerShell-Befehl mit strukturierter JSON-Ausgabe ist beispielsweise eine wesentlich bessere Grundlage für einen Agenten als ein schwer interpretierbarer Screenshot aus einer grafischen Managementkonsole.
Fazit
KI-Stack 2.16 ist weniger ein Release mit vielen neuen Komponenten als ein Architekturentscheid.
Die vorhandene MCP Runtime und ihre Werkzeuge werden erstmals konsequent als allgemeine Local-Control-Schicht verwendet. PowerShell übernimmt dabei die Rolle der universellen Windows-Verwaltungsschnittstelle, während vorhandene CLIs und KI-Stack-Skripte für WSL, Docker und die eigenen Komponenten weiterverwendet werden.
Gerade dadurch bleibt die Lösung vergleichsweise schlank. Neue Funktionen entstehen nicht automatisch durch neue Dienste, Ports und Credentials, sondern durch die intelligente Kombination bestehender Schnittstellen.
Der lokale Assistent kann damit zunehmend nicht nur erklären, was auf dem Rechner getan werden müsste. Er kann innerhalb seiner definierten Berechtigungen die erforderlichen Schritte selbst durchführen, Ergebnisse prüfen und seine Arbeit fortsetzen.
Der nächste logische Entwicklungsschritt liegt damit nicht mehr beim Tool-Zugriff selbst. Nach Local Control stellt sich vielmehr die Frage, wie ein solcher Assistent relevante Informationen über mehrere Gespräche hinweg behalten kann.
Genau dort setzt KI-Stack 2.17 mit persistentem lokalem Memory an.