Agentbasierte AIOps mit einem Kontextgraphen: Neocarta, Neo4j, LangGraph und Gemini

Während eines Ausfalls auf einer Plattform oder bei einem SRE-Team wiederholt sich dieses Muster. Ein Ingenieur verfolgt die Dynatrace-Spuren, ein anderer durchsucht die GitHub-Deploy-Geschichte nach Veränderungen, und ein Dritter bearbeitet das ServiceNow-Ticket, damit die Führung keine weiteren Updates mehr anfordert. Niemand hat das Gesamtbild, weil es nicht an einem bestimmten Ort vorhanden ist. Es ist auf drei oder zehn Tools verteilt.

Diese Fragmentierung führt meist schneller zur Wiederherstellung als der Fehler selbst oder ein fehlerhafter Deploy. Die Verzögerung entsteht dadurch, dass Menschen den Kontext neu aufbauen müssen, der bereits irgendwo in dem System vorhanden ist – nur eben nicht an einem Ort.

Ein Konzept zur Behebung dieses Problems kombiniert drei ausgewählte Technologien zu einer agierenden AIOps-Plattform. Neocarta automatisiert die Einpflege in ein Neo4j-Graf und stellt dieses Graf durch MCP den KI-Tools zur Verfügung. LangGraph übernimmt die deterministische Orchestrierung der Agenten, während das Google Gen AI SDK mit Gemini die Logik bereitstellt. Es gibt weder Lakehouses noch batchbasiertes ETL, keine manuell erstellten Webhook-Verbindungen noch Dashboards mit veralteten Metriken. Was übrig bleibt, ist ein aktuelles, abfragbares Graf der operativen Realität, auf das Agenten direkt zugreifen und darauf reagieren können.

Ein Kontextgraph anstelle von Dashboards

Viele AIOps-Tools fügen intelligente Funktionen zu einem analytischen Datenspeicher hinzu, der für Business Intelligence und nicht für Echtzeit-Logik konzipiert ist – was die falsche Grundlage darstellt. Die hier verwendete Konzeption betrachtet den Betriebszustand als Graphenproblem. Jeder Service, jede Bereitstellung, jedes Incident, jedes Team sowie jede Behebungsmaßnahme wird zu einem Knoten, während die zwischen ihnen bestehenden Beziehungen wie DEPLOYED_TO, ALERTS_ON, TRIGGERED_BY und OWNER_OF zu erstklassigen Kanten werden.

Sobald Infrastrukturereignisse einen vernetzten Graphen bilden anstelle isolierter Protokolle, verändert sich die Ursachenanalyse. Sie wird nicht mehr zu einer manuellen Untersuchung, sondern zu einem Graphen-Abstieg, einer mehrstufigen Abfrage, über die ein LLM direkt durch Graph RAG logisch vorgehen kann.

Vier Schichten, die den Kreis schließen

Vier Schichten übernehmen jeweils eine bestimmte Aufgabe, und der Kreislauf schließt sich, da die eigenen Aktionen des Agents wieder in das Diagramm geschrieben werden. Das nächste von ihm bearbeitete Incident weiß daher bereits, was bereits versucht wurde.

1. Automatisierte Erfassung mit der Neocarta ingestion CLI. Anstatt für jedes Tool einen webhook-basierten Empfänger zu schreiben, ziehen die Neocarta-Connector Metadaten und Protokolle aus ServiceNow, Dynatrace und GitHub ab und laden sie in das Diagramm. Es muss kein spezieller Erfassungsdienst für jede Quelle gepflegt werden.

Systemischer Kontext in Neo4j, bereitgestellt vom Neocarta MCP-Server. Dies ist das operative Zentrum. Repositorien, Dienste, Bereitstellungen, Vorfälle, Teams sowie Korrekturmaßnahmen sind Knoten, und jede Beziehung ist eine typisierte, gerichtete Kante. Neocarta stellt einen MCP-Server vor das Graphen, sodass jedes MCP-kompatible Tool, einschließlich des LangGraph-Agenten, darauf abfragen kann, ohne speziellen Datenbankcode verwenden zu müssen.

Logisches Denken mit LangGraph und Gemini. Eine LangGraph-Zustandsmaschine führt einen Zyklus aus Beobachten, Orientieren, Entscheiden und Handeln durch. Sie holt über MCP einen kontextbezogenen Teilgraphen ab, wandelt ihn in eine Anfrage um und gibt Gemini eine begrenzte Auswahl: das Problem beheben oder es an einen Menschen weiterleiten.

Beseitigung und Rückschreiben. Wenn der Agent handeln möchte, startet er die Korrekturmaßnahme – beispielsweise einen Rollback über GitHub Actions – und dokumentiert das Ergebnis anschließend im Graphen als neuen Knoten. Die meisten AIOps-Demos überspringen genau diesen Schritt, und er ist es, der den Kreislauf schließt und ihn nicht zu einer einmaligen Aktion macht.

Neocarta ersetzt den benutzerdefinierten Eingabedienst sowie die direkten Anrufe des Datenbanktreibers. Seine CLI automatisiert die Erfassung in Neo4j, und sein MCP-Server ist es, mit dem der Agent tatsächlich für den Graphenkontext kommuniziert.

Ebenen 1 und 2: Eingabe über Neocarta

Das Schema steht an erster Stelle, da es die Ontologie ist, auf der die gesamte Plattform beruht. Node-Labels und Beziehungsarten sind das, was jeder Connector sowie jede Cypher-Anfrage letztendlich liest und schreibt. Jede Entität ist ein typisierter Node, und jede Abhängigkeit, Eigentumsverbindung sowie Benachrichtigung ist eine typisierte, gerichtete Kante. Genau diese Struktur verwandelt eine Untersuchung über verschiedene Tools in einen Durchlauf durch das Graphen.

Bislang bedeutete die Dateneingabe, für jede Quelle einen eigenen webhook-Benutzer zu betreiben und für jede Payload-Struktur manuell Cypher-Code zu schreiben. Neocarta reduziert dies auf einfache Konfigurationen. Wenn man seine CLI auf ServiceNow, Dynatrace und GitHub richtet, kümmert sich das Tool um die Entdeckung des Schemas, inkrementelle Ladevorgänge sowie die Zuordnung zu den Node- und Beziehungsarten des Graphen.

# Register each source once — Neocarta handles auth, schema inference, and scheduling
neocarta connect servicenow --instance your-org.service-now.com --scope incident
neocarta connect dynatrace --tenant your-tenant-id --scope metrics,problems
neocarta connect github --org your-org --scope deployments,repos

# Point the loader at your graph and let it run
neocarta load --target neo4j://your-instance:7687 --database aiops-graph

Darunter werden die gleichen MERGE- und CREATE-Muster verwendet, wie man sie auch von Hand schreiben würde. Persistente Entitäten wie Repositorien, Services und Teams werden zusammengeführt, sodass es nie zu doppelten Knoten kommt. Ereignisse, die mit einem bestimmten Zeitpunkt verbunden sind – wie beispielsweise eine Bereitstellung oder ein Incident – werden jedes Mal als neue Knoten eingefügt, wodurch die Zeitlinie korrekt bleibt und die frühere Historie unverändert bleibt. Der Unterschied besteht darin, dass niemand den Kartencode für drei APIs pflegen muss, deren Payload-Strukturen nach eigenen Zeitplänen ändern.

Neben der Erfassung von Daten fügt Neocarta seinen MCP-Server hinzu. Sobald das Graphen gefüllt ist, wird es als MCP-Endpunkt bereitgestellt, und ein Client, der MCP versteht – unter anderem LangGraph – kann mehrstufige Graphenabfragen wie gewöhnliche Toolaufrufe senden. Der Agentcode benötigt keine Datenbanktreiber-Schicht zum Schreiben oder Pflegen.

# LangGraph's context-fetching node talks to Neocarta over MCP,
# not to a Neo4j driver directly
from langchain_mcp_adapters.client import MCPClient

neocarta_client = MCPClient(server_url="http://neocarta-mcp:8080")
tools = await neocarta_client.get_tools()   # graph_query, graph_traverse, etc.

Die Schema-Verwaltung bleibt in den Händen der Ingenieure. Einschränkungen und Indizes werden wie immer direkt in Neo4j definiert.

CREATE CONSTRAINT unique_service_id IF NOT EXISTS
FOR (s:Service) REQUIRE s.id IS UNIQUE;

CREATE INDEX incident_state_index IF NOT EXISTS
FOR (i:Incident) ON (i.state);

Schicht 3: der LangGraph-Loop

Diese Schicht verdient den Begriff „agentbasiert“. Anstelle eines einzigen Aufrufs einer KI läuft das Reasoning als Zustandsmaschine mit expliziten Knoten und Kanten ab, sodass jeder Entscheidungsweg überprüft, getestet und analysiert werden kann – im Gegensatz zum undurchsichtigen Loop vieler Agenten.

Der Zustand ist ein typisiertes Dictionary, das durch den Graphen fließt.

class AIOpsAgentState(TypedDict):
    incident_id: str
    failing_service_id: str
    graph_context_summary: Optional[str] = None
    safety_gate_passed: Optional[bool] = None
    chosen_action: Optional[str] = None
    target_repository: Optional[str] = None
    execution_result: Optional[str] = None

Vier Knoten steuern den Kreislauf:

• FetchGraphContext ruft das Tool graph_traverse auf dem MCP-Server von Neocarta auf, um einen Vorfall bis zu seinem zugehörigen Service zurückzuverfolgen, anschließend zum Deployment, das diesen Service geändert hat, zum betroffenen Repository sowie zum Team, das dafür verantwortlich ist. Der Agent-Code behält niemals eine direkte Datenbankverbindung bei.
• VerifySafetyGate überprüft über dieselbe MCP-Abfrageschnittstelle, ob in den letzten Stundene bereits Maßnahmen gegen diesen Service ergriffen wurden. Dieser Schutzmechanismus verhindert, dass ein Agent endlos auf einem instabilen Service arbeitet.
• GeminiReasoning wird nur ausgeführt, wenn die Überprüfung erfolgreich ist. Gemini 2.5 Pro erhält eine Zusammenfassung des Graphenkontexts zusammen mit einer präzisen Systemanweisung, wobei die einzige zulässige Antwort einer von zwei festgelegten Tokens ist.

ExecuteRemediationTool startet die Korrekturmaßnahme und schreibt einen RemediationAction-Node über Neocarta wieder in Neo4j, wodurch der Kreislauf geschlossen wird.

Falls ein Komponente besondere Aufmerksamkeit verdient, dann ist es das Sicherheitssystem. Es wird hier als MCP-Toolaufruf statt als reine Treibersitzung dargestellt.

async def evaluate_remediation_safety_gate(state: AIOpsAgentState) -> Dict:
    result = await neocarta_client.call_tool(
        "graph_query",
        cypher="""
            MATCH (s:Service {id: $service_id})<-[:EXECUTED_AGAINST]-(a:RemediationAction)
            WHERE a.timestamp >= datetime() - duration('PT1H')
            RETURN count(a) as active_actions
        """,
        params={"service_id": state["failing_service_id"]},
    )
    return {"safety_gate_passed": (result["active_actions"] == 0)}

Ein autonomer Aktionslauf ohne Sicherheitstür sollte niemals in Betrieb genommen werden. Die Tür verhindert, dass ein Agent alle dreißig Sekunden eine Rücksetzung auslöst, solange die zugrunde liegende Anomalie noch nicht beseitigt ist.

Der Gemini-Node ist absichtlich langweilig – und das ist seine Stärke.

system_instruction = (
    "You are an automated Agentic AIOps architect. "
    "Analyze the provided graph context summary. "
    "If a deployment recently modified the service state, "
    "output EXACTLY the word TRIGGER_ROLLBACK. "
    "If the context is clear but safe guidelines are violated, "
    "output HALT_ESCALATE. Do not append any other characters."
)

Durch Einschränkung der Ausgabe des Modells auf genau zwei Tokens verhält sich der Aufruf eher wie eine typische Funktion als wie eine Chat-Antwort – was die richtige Eigenschaft ist, wenn das Ergebnis zu einem Rollback in der Produktion führt.

Schicht 4: Schließen des Kreislaufs

Der letzte Knoten leitet entweder einen Rollback über die GitHub Actions API aus oder unternimmt nichts anderes, als den Abbruch zu protokollieren. In jedem Fall wird das Graph durch denselben MCP-Schreibweg wie alles andere aktualisiert, sodass für die Rückschreibung keine separaten Datenbank-Zugangsdaten erforderlich sind.

await neocarta_client.call_tool(
    "graph_write",
    cypher="""
        MATCH (s:Service {id: $service_id}), (i:Incident {id: $incident_id})
        CREATE (a:RemediationAction {id: $action_id, timestamp: datetime(), status: 'SUCCESS_ROLLBACK'})
        CREATE (a)-[:EXECUTED_AGAINST]->(s)
        CREATE (a)-[:ATTEMPTED_TO_FIX]->(i)
    """,
    params={"service_id": service_id, "incident_id": incident_id, "action_id": action_id},
)

Was dieses System zu einem Schließkreissystem macht und nicht zu einem einmaligen Automatisierungsscript, ist ein einfacher Aspekt: Das Ergebnis der eigenen Aktion des Agents wird zum Kontext für den nächsten Vorfall, den er bewertet. Dadurch wird die Plattform im Laufe der Zeit situationsbewusster statt weniger.

Ein Vorfall von Anfang bis Ende

Der Entwurf beinhaltet eine Simulation im Ausprobiermodus, die zeigt, wie die einzelnen Komponenten zusammenarbeiten, und ein Auszug daraus ist aufschlussreich.

1. 14:00:00. Der Zahlungsgateway-Dienst beendet eine Bereitstellung, wodurch ein Deployment-Knoten, der mit diesem Dienst verbunden ist, hinzugefügt wird.
2. 14:05:00. Dynatrace meldet eine kritische Anomalie im selben Dienst.
3. 14:06:00. Ein P1-Vorfall erscheint in ServiceNow und wird zu einem Incident-Knoten, der über einen ALERTS_ON-Edge mit dem Dienst verknüpft wird.

Der LangGraph-Agent wird am neuen Incident-Node aktiviert. FetchGraphContext durchläuft nacheinander die Ebenen Incident, Service, Deployment, Repository und Team und stellt fest, dass das Deployment fünf Minuten vor der Anomalie stattgefunden hat.

VerifySafetyGate findet in den letzten Stundeneine frühere Behebung nicht, sodass der Weg frei ist.

Gemini erhält die Zusammenfassung des Kontexts, erkennt, dass das Deployment zum Incident geführt hat, und gibt TRIGGER_ROLLBACK zurück.

Der Tool-Executor startet den Rollback-Ablauf in GitHub Actions und speichert anschließend einen neuen RemediationAction-Node in Neo4j.

Von der Anomalie bis zur Behebung vergehen Minuten – nicht ein Telefonat im Krisenstab. Jeder Schritt der Abwägung bleibt danach im Graph nachvollziehbar, sodass man ermitteln kann, warum der Agent genau das getan hat.

Sobald das Incident kartiert wurde, bildet es eine einzige, vernetzte Struktur, die Team, Code, Bereitstellung, Service, das Incident selbst sowie die Korrekturmaßnahmen des Agenten umfasst. Genau dieser Teilgraph ist der Grund, warum Gemini auf eine solche Struktur setzt – anstelle von drei separaten Dashboards ermöglicht diese einheitliche Struktur es dem Agenten, ein P1-Incident bis zum zugrunde liegenden Commit zurückzuverfolgen.

Dieselbe Abfolge kann in drei Schritte unterteilt werden, aus denen der Graph entsteht: die Bereitstellung, der Absturz und die Behebung. Jeder Schritt stellt einen separaten Datenbank-Eintrag dar, doch zusammen bilden sie eine kontinuierliche Zeitachse, die innerhalb von sieben Minuten von einem Git-Merge über eine Produktionswarnung bis hin zu einer abgeschlossenen Behebung reicht.

Eine Übersicht des Graphen für Ingenieure

Ein autonomes System, das Ingenieure nicht überprüfen können, stellt ein Risiko dar. Deshalb beinhaltet der Entwurf einen auf pyvis basierenden Streamlit-Dashboard, der die aktuelle Graphentopologie sowie eine fortlaufende Aufzeichnung aller Aktionen anzeigt.

net = Network(height="600px", width="100%", bgcolor="#1a1c1e", directed=True)
color_map = {
    "Team": "#5f3dc4", "Repository": "#24292e", "Deployment": "#007acc",
    "Service": "#11a685", "Incident": "#c41c1c", "RemediationAction": "#cc0088"
}

Die Ingenieure erhalten eine anpassbare, vergrößerbare Ansicht der gesamten Kette – von der Git-Integration über Incidents in der Produktion bis hin zur automatisierten Behebung – zusammen mit einem Seitenleisten-Protokoll, das jede von dem Agenten ausgeführte Aktion in der richtigen Reihenfolge auflistet. Genau diese Transparenz macht ein autonomes System zuverlässig genug, um in der Produktion eingesetzt zu werden, da nichts von dem, was es tut, undurchsichtig ist.

Eine Implementierung, die die Produktion schont

Der empfohlene Ansatz ist zurückhaltend: Er erfolgt in drei Phasen statt in einem einzigen Schritt.

• Woche 1: Eingabe und Validierung. Richten Sie die Neocarta-Connector auf Sandbox-Kopien jeder Quelle aus, erstellen Sie die Graphenbeschränkungen und überprüfen Sie, ob die Knoten korrekt zugeordnet und miteinander verbunden sind, bevor Produktionsdaten verwendet werden.

Woche 2: Probeabläufe in der Staging-Umgebung. Der LangGraph-Orchestrator wird auf einer nur zum Lesen zugänglichen Staging-Datenbank entwickelt, um zu beobachten, wie Gemini ohne tatsächliche Ausführung entscheidet. Hier treten Probleme mit Prompts oder Kontexten auf.

Woche 3: Automatisierung im Schließkreis. Layer 4 wird mit den tatsächlichen Staging-API-Endpunkten verbunden, um zu überprüfen, ob die Schreibvorgänge den Kreislauf abschließen und dem Sicherheitssystem echte Historie zur Verfügung stellen.

Nur wenn alle drei Phasen funktionieren, sollten die Korrekturwerkzeuge auf die Produktions-Endpunkte verweisen.

Warum das Design funktioniert

Mehrere Entscheidungen unterscheiden eine Demo von einer zuverlässigen Lösung in der Produktion.

• Zustandsmaschinen sind besser als freie Agentenschleifen. LangGraph macht jeden Entscheidungsweg explizit und überprüfbar – es gibt keine versteckten Schlussfolgerungsketten, die nicht reproduziert werden können.
• Ein Sicherheitstor geht jeder LLM-Aufruf voraus, der eine Aktion auslösen könnte. Wenn kürzlich eine Korrekturmaßnahme ausgeführt wurde, kann der Agent den Reasoning-Node nicht erreichen. Diese Überprüfung findet im deterministischen Code statt, nicht in einer Anweisung.
• Das Ausgabeformat ist eingeschränkt. Von Gemini wird keine Prosa erwartet. Die Beschränkung auf einen von zwei Tokenen sorgt dafür, dass das Ergebnis genauso zuverlässig ist wie der Rückgabewert einer Funktion.
• Das Graph dient als Speicher und nicht nur als Lager. Korrekturmaßnahmen werden in dasselbe Graph geschrieben, das der Agent liest, sodass sein situatives Bewusstsein anwächst und bei jedem Vorfall nicht zurückgesetzt wird.
• MCP ist die Verbindung zwischen Agent und Graph. Da der MCP-Server von Neocarta zwischen LangGraph und Neo4j steht, besitzt der Agent niemals einen Datenbanktreiber oder verwaltet keine Verbindungs-Pools. Er ruft stattdessen Tools auf. Diese Verbindung ermöglicht außerdem den Austausch von Gemini gegen ein anderes Modell oder von LangGraph gegen einen anderen Orchestrierer, ohne die Eingabeschicht oder die Graphschicht anzufassen.

Der im Graph nativ vorhandene Kontext, ein mit festen Schritten ausgestatteter Schlussfolgerungszyklus sowie ein in den Code integrierter Circuit Breaker machen autonome Behebungsmechanismen zu etwas, das tatsächlich implementiert werden kann – anstatt nur auf einer Präsentationsdiagonale gut auszusehen. Sinnvolle Weiterentwicklungen wären die Bereitstellung des gesamten Stack mit Docker Compose sowie das Senden von Slack-Benachrichtigungen über den Layer 4-Router, damit alle über jede autonome Aktion informiert werden, selbst wenn niemand eingreifen musste.