AgenticOps ohne Illusionen: Was ein Netz können muss, bevor Agenten darin arbeiten

Es gibt zwei Arten, über KI im Netzbetrieb zu sprechen. Die eine beschreibt eine Zukunft, in der sich Netze selbst heilen. Die andere fragt, was ein Agent an einem Dienstagnachmittag mit einem konkreten Ticket tut, welche Daten er dafür braucht und wer haftet, wenn er einen Port abschaltet. Dieser Text nimmt die zweite.

Was 2026 tatsächlich angekündigt wurde

Auf der Cisco Live 2026 lag der Schwerpunkt erklärtermaßen auf AI-nativem Networking — nicht als Zusatzfunktion, sondern als Betriebsmodell. Drei Bausteine sind für die Praxis relevant.

Cisco Cloud Control ist die angekündigte gemeinsame Umgebung, in der menschliche Betreiber und Agenten Infrastruktur verwalten, überwachen und verteidigen sollen. Cisco stellte sie am 2. Juni 2026 auf der Cisco Live US vor und nennt für denselben Tag den Eintritt in Controlled Availability in den Vereinigten Staaten, globale Verfügbarkeit soll folgen. AI Canvas ist der geteilte Arbeitsraum darüber: Mensch und Agent arbeiten auf derselben Live-Telemetrie, Dashboards entstehen im Verlauf einer Untersuchung statt vorher. Und unter beidem liegen zweckgebaute Modelle — darunter ein Deep Network Model, das Cisco als speziell für Netzwerkaufgaben trainiert und gegenüber allgemeinen Modellen als präziser beschreibt.

Parallel dazu ist der AI Network Assistant direkt in Catalyst Center verfügbar, und die Plattform führt 2026 zwei parallele Zweige (3.1.x und 3.2.x) mit mehreren Releases. Wer die Funktionen prüft, sollte deshalb zuerst den eigenen Versionsstand gegen die aktuellen Release Notes halten: Zwischen den Zweigen liegen spürbare Unterschiede.

Der eigentliche Bruch: deterministisch gegen probabilistisch

Klassische Netzautomatisierung ist deterministisch. Ein Playbook, ein Template, ein Skript tun bei gleicher Eingabe immer dasselbe. Das ist der Grund, warum sich Automatisierung überhaupt freigeben lässt: Man prüft den Ablauf einmal gründlich und vertraut ihm danach.

Ein Agent arbeitet anders. Er bekommt ein Ziel, wählt Schritte, interpretiert Ergebnisse und entscheidet, wann er fertig ist. Bei gleicher Ausgangslage kann er zwei verschiedene, beide vertretbare Wege gehen. Das ist die Stärke — er kommt mit Situationen zurecht, für die niemand ein Playbook geschrieben hat — und gleichzeitig der Grund, warum die Freigabefrage neu gestellt werden muss.

Die brauchbare Aufteilung ist deshalb keine Entweder-oder-Entscheidung. Sie trennt nach Umkehrbarkeit:

Die vier Voraussetzungen

Jede der angekündigten Fähigkeiten setzt dasselbe voraus, und keine davon ist neu. Wer die vier Punkte hat, profitiert sofort. Wer sie nicht hat, kauft eine Oberfläche.

1. 01

   Source of Truth

   Eine Stelle, die verbindlich sagt, was es gibt und wie es aussehen soll. Solange Standortlisten in drei Tabellen leben, hat ein Agent drei Wahrheiten und keine Grundlage für eine Empfehlung.

2. 02

   Telemetrie, die etwas aussagt

   Nicht mehr Daten, sondern zusammenhängende: Zustand, Ereignis und Änderung müssen sich zeitlich zueinander in Beziehung setzen lassen. Sonst korreliert jedes Modell Zufälle.

3. 03

   Ein einziger Änderungsweg

   Wenn Änderungen wahlweise per Konsole, per Controller oder per Skript passieren, existiert kein Punkt, an dem ein Agent geprüft, begrenzt und protokolliert werden kann. Der Weg über Repository und Pipeline ist die Voraussetzung, nicht die Kür.

4. 04

   Rechte und Protokoll

   Ein Agent braucht ein eigenes Konto mit engem Rechteschnitt, nicht das Sammelkonto der Automatisierung. Und jede Aktion braucht eine Spur, die später ohne Zutun des Agenten lesbar ist.

Diese vier Punkte sind exakt das, was wir in Network Automation und rund um Catalyst Center aufbauen — unabhängig davon, ob am Ende ein Agent oder ein Mensch die Änderung auslöst. Das ist kein Zufall, sondern der Grund, warum die Grundlagenarbeit auch dann trägt, wenn ein Produktversprechen später anders aussieht als angekündigt.

Warum die Schnittstelle wichtiger ist als das Modell

Die technisch folgenreichste Entwicklung ist unauffälliger als die Modellankündigungen: die Standardisierung, wie ein Sprachmodell überhaupt an Werkzeuge und Daten kommt. Das Model Context Protocol wurde im Dezember 2025 an die Agentic AI Foundation unter dem Dach der Linux Foundation übergeben, mitgetragen unter anderem von Anthropic, Block und OpenAI.

Für den Netzbetrieb ist das die relevantere Nachricht. Ein Modell ist austauschbar; die Frage, welche Werkzeuge ein Agent aufrufen darf und welche Daten er dabei sieht, ist Architektur. Wer heute eine saubere Abstraktion baut — Inventar, Zustandsabfrage, Prüfung, Änderungsvorschlag als getrennte, einzeln berechtigte Werkzeuge —, kann das Modell dahinter wechseln, ohne die Sicherheitsgrenze neu zu verhandeln.

Der Markt bewegt sich sichtbar in dieselbe Richtung — Anbieter von Netzautomatisierungsplattformen kündigen reihenweise agentische Fähigkeiten an. Belastbare Marktzahlen dazu nennen wir hier bewusst nicht: Die kursierenden Prognosen ließen sich nicht bis zur Primärquelle zurückverfolgen. Was ohnehin folgt, ist keine Produktauswahl, sondern eine Vorbereitung.

Wo Agenten heute schon tragen

Drei Anwendungen funktionieren nach heutigem Stand belastbar, weil sie nichts verändern und ihr Ergebnis sofort überprüfbar ist:

• Vorqualifizierung von Störungen. Der Agent sammelt Zustand, letzte Änderungen und Nachbarschaft und liefert eine begründete Vermutung — die der Mensch in Sekunden bestätigt oder verwirft.
• Abweichungsberichte. Ist-Konfiguration gegen Soll, in lesbarer Sprache statt als Diff über 4.000 Zeilen.
• Vorbereitung von Changes. Betroffene Systeme, Abhängigkeiten, Rückfallplan und Prüfschritte als Entwurf, den ein Engineer prüft und zeichnet.

Was heute nicht ohne Freigabe gehört: alles, was den Datenpfad verändert. Nicht weil Agenten grundsätzlich unzuverlässig wären, sondern weil das Verhältnis von Nutzen zu Risiko dort schlecht steht. Eine Minute gesparte Zeit gegen einen ungeplanten Ausfall ist kein Handel, den ein Betreiber eingeht.

Die Frage vor dem Piloten

Bevor ein Werkzeug ausgewählt wird, lohnt eine unbequeme Selbstprüfung. Wie lange dauert es heute, verlässlich zu beantworten, welche Geräte welchen Softwarestand fahren? Wie viele Wege gibt es, eine Konfiguration zu ändern? Wann wurde zuletzt geprüft, ob der dokumentierte Sollzustand mit dem Netz übereinstimmt?

Wenn diese drei Fragen unangenehm sind, ist die erste Investition keine agentische Plattform, sondern die Grundlagenarbeit, die den Nutzen aller späteren Werkzeuge bestimmt. Wenn sie leicht zu beantworten sind, ist ein Pilot sinnvoll — und wird schnell etwas beitragen.