MCP-Apps verändern die Form dieser Antwort. Ein Tool kann nun eine interaktive Benutzeroberfläche zusammen mit seiner Textzusammenfassung zurückgeben, und der Host (Claude Desktop, Claude.ai, VS Code Copilot, Cursor) rendert sie inline im Gespräch. Das Modell behält den kompakten Text für das Reasoning bei. Der Mensch erhält eine anklickbare Live-Schnittstelle direkt neben dem Chat.

Drei Eigenschaften unterscheiden diese Art der Integration von „einem Webhook, der eine URL zurückgibt“:

• Erhaltung des Kontexts. Die Benutzeroberfläche ist Teil des Gesprächs – kein Tabwechsel, keine Übergaben.

• Bidirektionaler Datenfluss. Die Benutzeroberfläche kann für frische Daten Tools auf dem MCP-Server aufrufen, und der Host kann neue Ergebnisse vom Agenten zurück in die Benutzeroberfläche senden. Keine separate API-Schicht oder Authentifizierungsleitung.

• Sandbox-Vertrauensgrenze. MCP-Apps laufen in einem vom Host gesteuerten iFrame. Sie können weder auf die übergeordnete Seite zugreifen, noch Cookies lesen oder ihren Container verlassen.

Sicherheitsoperationen basieren auf Triage, Untersuchungsgraphen und Attack Discovery, bei der ein KI-Agent Hunderte von Alerts in eine Handvoll Angriffsketten korreliert. Observability bedeutet verteilte Traces und detaillierte Zeitreihenanalysen. Das Erstellen in Kibana bedeutet ein Dashboard-Raster. Wenn man irgendetwas davon auf Text reduziert, geht das verloren, was es nützlich macht. Wir haben MCP-Apps für alle drei entwickelt und stellen sie gemeinsam als Open Source zur Verfügung, sodass dasselbe Gespräch von einer Triage-Warteschlange über einen Abhängigkeitsgraphen bis hin zu einem Live-Dashboard geführt werden kann, ohne dass der Chat verlassen werden muss.

Jede der drei Referenz-Apps ist ein MCP-Server, der viele interaktive Ansichten anbietet, nicht ein Bündel separater Produkte. Allein die Sicherheits-App zeigt sechs Dashboards an, die dieselbe Server-Shell, dasselbe Modell für die Sichtbarkeit von Tools und dieselbe Host-Bridge verwenden. Das Muster ist klein; die Oberfläche ist der Bereich, an dem sich der Wert zusammensetzt.

Elastic Security MCP App

Warum es für den SOC wichtig ist

Wenn ein Agent einem SOC-Analysten sagt „Es gibt 47 Alarme auf Host-314, hier ist eine Zusammenfassung“, dann hat er keine Arbeit verrichtet.. Er hat lediglich an den Ort gedeutet, an dem die Arbeit beginnt. Die eigentliche Arbeit findet in der Alarmliste, dem Prozessbaum, dem Untersuchungsgraphen und der Ticketdatei statt. Das geht nicht anhand eines Textabsatzes.

Die Sicherheits-MCP-App gibt den Workflow selbst zurück. Der Analyst erteilt dem Agenten Anweisungen, und der Agent antwortet mit einem interaktiven Dashboard im Chat, auf dem der Analyst Alerts detailliert analysieren, Bedrohungsanalysen ausführen, Angriffsketten korrelieren und Tickets eröffnen kann, ohne dabei den Gesprächsfaden zu verlieren. Und da die Ergebnisse, Anfragen und Tickets alle wieder in Elasticsearch landen, wartet dieselbe Untersuchung in Kibana, wo der Analyst nach Abschluss des Gesprächs wieder anknüpfen kann.

Sechs interaktive Dashboards

Die Elastic Security MCP-App liefert sechs interaktive Elemente, eines pro Haupt-SOC-Workflow. Jedes dieser Elemente ist eine React-Benutzeroberfläche, die inline gerendert wird, wenn der Agent das entsprechende Tool aufruft:

Tool

Was es tut

Interaktive Benutzeroberfläche

Alert-Triage

Abrufen, Filtern und Klassifizieren von Sicherheits-Alerts

Schweregradgruppierung, KI-Urteilskarten, Prozessbaum, Netzwerkereignisse

Angriffserkennung

KI-korrelierte Angriffskettenanalyse mit On-Demand-Generierung

Narrativkarten zu Angriffen mit Konfidenzbewertung, Entitätsrisiko und MITRE-Mapping

Case Management

Erstellen, Suchen und Verwalten von Untersuchungstickets

Ticketliste mit Warnungen, Beobachtungen, Kommentar-Tabs und KI-Aktionen

Erkennungsregeln

Durchsuchen, Optimieren und Verwalten von Erkennungsregeln

Regelbrowser mit KQL-Suche, Abfragevalidierung, Analyse rauschbehafteter Regeln

Threat Hunt

ES|QL-Workbench mit Entitätsanalyse

Abfrageeditor, anklickbare Entitäten und Untersuchungsgraph

Beispieldaten

Generieren von ECS-Sicherheitsereignissen für gängige Angriffsszenarien

Szenario-Picker mit vier vorgefertigten Angriffsketten

Jedes Tool liefert eine kompakte Textzusammenfassung, die das Modell für das Reasoning zurate ziehen kann, zusammen mit der interaktiven Benutzeroberfläche, auf der der Analyst agiert. Die Benutzeroberfläche kann auch frische Daten im Hintergrund über die MCP-Host-Bridge abrufen. Das vollständige Tool-Modell und die Bridge-API befinden sich im Architekturdokument des Repo.

Die App wird auch mit Claude Desktop-Skills ausgeliefert, SKILL.md -Dateien, die dem Agenten beibringen, wann und wie jedes Tool verwendet werden soll. Laden Sie vorgefertigte Skill-Zip-Dateien aus der neuesten Version herunter.

Vom Alert zum Ticket

Vier Skills decken den Kern des SOC-Kreislaufs ab. Jeder greift einen Prompt auf, ruft ein Tool auf und gibt ein interaktives Dashboard zusammen mit einer Textzusammenfassung zurück, über die das Modell nachdenkt. Der Tag eines Analysten beginnt normalerweise mit einer Alert-Warteschlange.

Triage-Alerts. Bitten Sie den Agenten, eine Triage nach Host, Regel, Nutzer oder Zeitfenster durchzuführen. Der Skill „Alert Triage“ liefert ein Dashboard mit KI-Urteilen oberhalb der ursprünglichen Alert-Liste. Jedes Urteil pro Erkennungsregel klassifiziert die Aktivität dieser Regel als gutartig, verdächtig oder bösartig und enthält eine Konfidenzbewertung sowie eine empfohlene Vorgehensweise. Klicken Sie auf eine Warnung, um eine detaillierte Ansicht mit einem Prozessbaum, Netzwerkereignissen, verwandten Warnungen und MITRE ATT&CK-Tags zu öffnen. Sie müssen nicht zwischen dem KI-Gespräch und Ihrem Benachrichtigungs-Dashboard in Kibana wechseln, alles findet in Echtzeit innerhalb Ihres Gesprächs statt.

Jagen Sie Bedrohungen. Bitten Sie den Agenten, Ihre Indizes zu durchsuchen. Der Skill „Threat Hunt“ gibt eine ES|QL-Workbench zurück, in der die Abfrage vorausgefüllt und automatisch ausgeführt wird. Jede Entität in den Ergebnissen ist anklickbar, um Details aufzurufen. Das Modell schreibt eine kurze Zusammenfassung unter die Tabelle – was ungewöhnlich ist, was verbunden ist, was einen genaueren Blick wert ist. Es bietet dann den nächsten Schritt an: Entweder tiefer in die Bedrohungssuche einzutauchen oder eine neue Fähigkeit innerhalb der MCP-App zu starten, die die bisher geleistete Arbeit ergänzt. Eine hervorragende Ergänzung dazu ist die Durchführung einer „Attack Discovery“, um mehr Kontext zu den Alerts zu sammeln, mit denen Sie sich eingehend beschäftigt haben, und zu den Bedrohungen, die Sie bisher gejagt haben.

Attack Discovery ausführen. Der Skill „Attack Discovery“ löst die Attack Discovery-API aus und gibt eine Rangliste der Ergebnisse zurück. Jedes Ergebnis besteht aus einer Reihe von zusammenhängenden Warnungen, die zu einer Angriffskette zusammengefügt werden. Dabei werden die MITRE-Taktik, eine Risikobewertung, eine Konfidenzbewertung sowie die betroffenen Hosts und Nutzer im Voraus angezeigt. Die Zusammenfassung des Agenten befindet sich unterhalb der Ergebnisse in der gleichen Rangordnung, und die Konversation enthält nun alles, was zum Handeln benötigt wird: Abfragen bei der Bedrohungsjagd, Triage-Entscheidungen, korrelierte Ketten, alles bereit für den nächsten Schritt.

Öffnen Sie Tickets, ohne den Chat zu verlassen. Genehmigen Sie die Ergebnisse gesammelt oder bitten Sie den Agenten, Tickets für bestimmte Alerts zu eröffnen. Der Skill „Case Management“ erstellt für jedes genehmigte Ergebnis ein Ticket (mit angehängtem Quell-Alert und übernommenen MITRE-Taktiken aus der Angriffskette) und zeigt die aktuelle Ticket-Liste direkt an. Klicken Sie auf ein Ticket, um die Detailansicht aufzurufen, die eine Reihe von KI-Aktionsschaltflächen enthält: Ticket zusammenfassen, Nächste Schritte vorschlagen, IOCs extrahieren und Zeitleiste generieren. Jede einzelne sendet einen strukturierten Prompt zurück an den Chat, sodass der Agent den Kontext des Tickets aufnimmt, ohne dass eine erneute Einführung erforderlich ist. Die Zusammenfassung des Agenten befindet sich unterhalb der Ticketliste und umfasst die gesamte IR-Warteschlange, einschließlich der gerade eröffneten Tickets und früherer Ergebnisse, die noch eines benötigen.

Jeder Schritt in diesem Walkthrough läuft in derselben Schleife: Ein Prompt kommt herein, der Skill nimmt ihn auf, das Tool gibt eine kompakte Textzusammenfassung zurück, die das Modell analysieren kann, zusammen mit einer interaktiven Benutzeroberfläche, auf der der Analyst arbeitet. Verkettet man die Skills miteinander, bilden sie einen durchgängigen SOC-Ablauf – suchen, priorisieren, korrelieren, Tickets öffnen und den nächsten Wechsel einleiten –, wobei das Modell den Sitzungskontext bei jedem Schritt berücksichtigt. Wenn Sie einen beliebigen einzeln aufrufen, erhalten Sie immer noch das vollständige Dashboard, das auf den von Ihnen benannten Datenausschnitt verweist. So oder so sammelt sich die Arbeit innerhalb des Gesprächs an: kein Wechseln zwischen Tabs, kein Kopieren und Einfügen, keine Übergaben.

Zwei weitere Skills vervollständigen die App: ein Browser für Erkennungsregeln zum Optimieren rauschbehafteter Regeln und ein Generator für Beispieldaten zum Erzeugen realistischer ECS-Ereignisse in einem neuen Cluster. In einem Folgebeitrag werden wir auf alle sechs näher eingehen: Untersuchungsgraph, Angriffsablauf-Canvas und vollständiger Walkthrough.

So funktionierts

Jede MCP-App ist ein kleiner Node.js-Server, dessen Tools sowohl eine kompakte Textzusammenfassung für das Modell als auch eine React-Benutzeroberfläche zurückgeben, die der Host inline rendert. Da sie auf der offenen MCP App-Spezifikation basiert, läuft derselbe Server auf jedem kompatiblen Host – siehe die Architektur-Dokumentation des Repositorys für das vollständige Design.

Ausprobieren

Erfordert Elasticsearch 9.x mit aktivierter Security, plus Kibana für Tickets, Regeln und Angriffserkennung. Der schnellste Weg ist das Ein-Klick-.mcpb -Bundle aus der neuesten Version – wählen Sie es mit einem Doppelklick in Claude Desktop aus, und Sie werden nach Ihrer Elasticsearch-URL und Ihrem API-Schlüssel gefragt. Einrichtungsanleitungen für Cursor, VS Code, Claude Code, Claude.ai und zum Kompilieren aus dem Quellcode finden Sie im Repository.

Elastic Search MCP-App: Aus Gesprächen erstellte Dashboards

Jeder Kibana-Nutzer kennt den Umweg über das Dashboard: Man unterbricht seine aktuelle Arbeit, öffnet Kibana, wählt einen Index, Felder und eine Visualisierung aus, passt alles an und speichert. Das sind fünf Kontextwechsel, bevor überhaupt ein einziges Diagramm auf dem Bildschirm erscheint.

Die neue example-mcp-dashbuilder-Referenz-App fasst dies in einem Prompt zusammen. Bitten Sie den Agenten, „Erstelle mir ein Dashboard mit Umsatzkennzahlen, Bestelltrends und Kategorieaufschlüsselungen“, erscheint das Dashboard im Gespräch, ohne dass ein Wechseln des Tabs erforderlich ist.

Hinter diesem Prompt untersucht der Agent Ihre Elasticsearch-Daten über ES|QL und wählt Diagrammtypen aus, die zu den Daten passen: Balken für Vergleiche, Linien für Trends, metrische Karten für KPIs und Heatmaps für zweidimensionale Muster. Es ordnet Panels auf dem 48-spaltigen Raster von Kibana unter Verwendung des Borealis-Themes der Elastic-Benutzeroberfläche an, und das Ergebnis ist vollständig interaktiv: Sie können Panels direkt im Chat verschieben, ihre Größe ändern und sie in ausklappbare Abschnitte gruppieren. Wenn das Dashboard korrekt aussieht, exportiert ein einziger Tool-Aufruf es zu Kibana, wobei ES|QL-Abfragen und benutzerdefinierte Farben erhalten bleiben. Sie können ebenfalls bestehende Kibana-Dashboards zur KI-gestützten Bearbeitung wieder in den Chat importieren.

Das Prinzip ist dasselbe wie bei der Security-App: Wenn das Artefakt das Produkt ist, schließt die Rückgabe innerhalb des Gesprächs den Kreis zwischen der Beschreibung dessen, was man will, und der Anzeige des Produkts.

Unter der Haube folgt es demselben MCP-App-Muster. Ein Node.js-Server registriert ein view_dashboard modellorientiertes Tool zusammen mit einer Reihe von App-spezifischen Tools, die die Benutzeroberfläche direkt aufruft (Datenabruf, Layout-Persistenz, Zeitfelderkennung, Export/Import). Die Dashboard-Ansicht selbst ist eine einzelne, eigenständige HTML-Datei, die mit vite-plugin-singlefile geliefert wird und als MCP-App-Ressource dient. Entwickler, die das Repo forken, erhalten die gleiche Server-Shell und den gleichen Host-Bridge, die sie in der Security-App sehen, jedoch auf einen anderen Job ausgerichtet. Die example-mcp-dashbuilder README enthält die vollständige MCP-Architektur und Diagrammtyp-Referenz.

Elastic Observability MCP-App

Die dritte Referenz-App, die Elastic Observability MCP-App, behandelt die SRE-Version desselben Formproblems. Wenn etwas in der Produktion ausfällt, ist die Antwort, die der diensthabende Ingenieur benötigt, keine Grafik, sondern eine Diagnose, die aus K8s-Metriken, APM-Topologie, ML-Anomalien und Risikobewertung zusammengesetzt ist. Die Form der Antwort ist eine kausale Geschichte: Was ist gescheitert und warum, was hängt davon ab und was ist als Nächstes zu tun.

Sechs Tools zur Unterstützung des Workflows bei der Untersuchung der Beobachtbarkeit

Tool

Abhängigkeit

Was es tut

observe

Universal

Transiente ES|QL- und ML-Anomalie-Zugriffsprimitive – eine Abfrage einmal ausführen, eine Metrik live erfassen oder blockieren, bis ein Schwellenwert oder eine Anomalie ausgelöst wird.

manage-alerts

Universal

Kibana-Regeln für schwellenwertbasiertes Alerting erstellen, auflisten, abrufen und löschen. Lassen Sie die Kibana-URL weg, um im Nur-Lese-Modus auszuführen.

ml-anomalies

ML-Jobs

ML-Anomalieeinträge abfragen und eine Inline-Anomalie-Erkläransicht öffnen.

apm-health-summary

Elastic APM

Cluster-Level-Health-Rollup aus APM-Telemetrie; Layer im K8s- und ML-Kontext, wenn verfügbar.

apm-service-dependencies

Elastic APM

Serviceabhängigkeitsgraph – Upstream/Downstream, Protokolle, Aufrufvolumen.

k8s-blast-radius

Kubernetes-Metriken

Auswirkungen von Node-Ausfällen – vollständiger Ausfall, degradiert, unbeeinträchtigt, Machbarkeit der Neuplanung.

Cluster-Health-Rollup

Fragen Sie „Was ist defekt?“ oder „Gib mir einen Statusbericht“ und erhalten Sie eine Übersicht auf einen Blick: allgemeiner Zustand, beeinträchtigte Dienste mit Begründungen, die größten Pod-Speicher-Verbraucher, Aufschlüsselung des Schweregrads der Anomalien und der Service-Durchsatz – alles in einer einzigen Ansicht. Das ist der Ausgangspunkt, wenn sich etwas komisch anfühlt, Sie aber nicht wissen, wo Sie suchen sollen. Die Ansicht passt sich an die Gegebenheiten Ihres Deployments an. APM liefert Ihnen Service-Health-Informationen. Kubernetes-Metriken fügen Pod- und Node-Kontext hinzu. ML-Jobs integrieren Anomalien.

Dienstabhängigkeitsgraph

Fragen Sie „Was ruft die Kasse auf?“ oder „Zeig mir die Topologie“ und Sie erhalten einen geschichteten Abhängigkeitsgraphen – vorgelagerte Aufrufer, nachgelagerte Abhängigkeiten, Protokolle, Anrufvolumen und Latenz pro Kante. Bitten wir Claude, uns die Serviceabhängigkeiten des Frontends zu zeigen („Zeig mir die Serviceabhängigkeiten des Frontends“):

Zoomen Sie, schwenken Sie und bewegen Sie den Mauszeiger, um alle Details zu sehen, die Sie zum Verständnis der komplexen Servicebeziehungen benötigen:

Risiko mit einem Schadensradius bewerten

Fragen Sie „Was passiert, wenn mein k8s-Node ausfällt?“ und erhalten Sie ein radiales Auswirkungsdiagramm: Die Ziel-Node in der Mitte, vollständige Deployments in Rot, beeinträchtigte in Gelb und unbeeinflusste in Grau. Eine schwebende Übersichtskarte zeigt gefährdete Pods und die Machbarkeit der Neuplanung an. Single-Replikat-Deployments werden als Single Point of Failure markiert. 

Observe

Das primäre Zugriffsprimitiv des Agenten für Elastic – ein Tool, drei Modi für drei verschiedene Bedürfnisse. Fragt man „Was macht die CPU gerade?“, führt es einmal eine ES|QL-Abfrage aus und gibt eine Tabelle zurück. Sagt man „Zeige mir die Frontend-Latenz für die nächsten 60 Sekunden“, erfasst es die Metrik live und aktualisiert das Diagramm an Ort und Stelle. Sagt man „Sag mir, wenn der Speicher unter 80 MB fällt“ oder „Achte auf alles Ungewöhnliche für die nächsten 10 Minuten“, blockiert es, bis die Bedingung erfüllt ist oder das Zeitfenster abläuft. Die Ansicht passt sich an den jeweiligen Modus an: eine Ergebnistabelle für einmalige Abfragen, ein Live-Trenddiagramm mit aktuellen, Spitzen- und Basisstatistiken für Stichproben- und Schwellenwertbedingungen, und eine Triggerkarte mit Schweregradbewertung für den Anomalienmodus.

So funktionierts

Dasselbe MCP-App-Muster wie die Security- und Search-Apps: ein Node.js-Server, sechs modellorientierte Tools, die auf sechs Einzeldatei-Ansichtsressourcen verdrahtet sind. Die Tools sind nach Deployment-Backend gruppiert (Universal, APM-abhängig, K8s-abhängig, ML-abhängig), sodass sowohl der Agent als auch der Nutzer im Voraus wissen, welche Tools für eine bestimmte Deployment relevant sind, anstatt beim Aufruf Fähigkeitslücken zu entdecken. Die MCP-App enthält auch einen beispielhaften Agent Builder-Workflow: k8s-crashloop-investigation-otel, der bei einem Kubernetes-Alert ausgelöst werden kann und eine strukturierte Ursachenzusammenfassung zurückgibt, bevor Sie ein einziges Dashboard geöffnet haben.

Der Agentic Stack, interaktiv

Drei Eigenschaften dieses Musters sind es wert, direkt erwähnt zu werden. Erstens ist das Ergebnis des Tools nicht mehr das Ende der Arbeit, sondern ihr Anfang: Das Gespräch liefert eine Schnittstelle, auf der Sie handeln können, keine Zusammenfassung, auf deren Grundlage Sie handeln müssen. Zweitens können derselbe Agent, derselbe Modellkontext und derselbe Gesprächsverlauf nun zwischen den Oberflächen von Security, Search und Observability wechseln, ohne das Gespräch zu verlassen. Drittens funktioniert das nur, weil Elasticsearch und Kibana die APIs bereits bereitstellen. Die MCP-App ist eine schlanke interaktive Schicht über den bereits mitgelieferten Produktfunktionen.

Attack Discovery unterstützt bereits die Ansicht der korrelierten Ergebnisse in dieser App. Innerhalb des Stacks geht das gleiche agentische Muster noch weiter: Elastic Workflows automatisieren die deterministischen Schritte (Entitäten anreichern, Tickets erstellen, Hosts isolieren), während Agent Builder die Daten analysiert und diese Workflows als Werkzeuge aufruft. Die MCP-App bringt diese Sicherheitsebene auch in die externe Kommunikation ein; Workflows und der Agent Builder vertiefen sie innerhalb des Stacks. Verschiedene Einstiegspunkte, dieselben Elastic-APIs darunter.

Probieren Sie es aus:

• Sicherheit: example-mcp-app-security

• Suchen und Dashboards: example-mcp-dashbuilder

• Beobachtbarkeit: example-mcp-observability

Sie haben noch keinen Elasticsearch-Cluster? Starten Sie eine kostenlose Elastic Cloud-Testversion. Weitere Informationen zu den Bausteinen der Sicherheits-App finden Sie in den zugehörigen Security Labs-Beiträgen zu Elastic Workflows und Agent Builder, Agent Skills und Attack Discovery.

Deshalb stellen wir Elastic Agent Skills als Open Source zur Verfügung: native Plattform-Expertise für Elasticsearch, Kibana, Elastic Observability und Elastic Security. Fügen Sie sie in die Agenten-Runtime ein, die Sie bereits verwenden, und machen Sie Ihren Agenten aus einem „Generalisten“, der viel Syntax erraten kann, zu einem Experten, der in der Lage ist, viele der Architekturstandards genauso wie die Entwicklungsteams von Elastic selbst zu verwenden. Diese erste technische Vorschauversion konzentriert sich auf Fähigkeiten mit maximaler Kompatibilität für Elastic Cloud Serverless, wird sich aber schnell weiterentwickeln, um auch eine verbesserte Unterstützung für ältere Stack-Versionen zu bieten.

Darüber hinaus löst Elastic dieses Problem von beiden Seiten. Für Agenten auf der Elastic-Plattform ermöglicht der Elastic Agent Builder (jetzt allgemein verfügbar) das Erstellen und Chatten mit KI-Agenten, die die Zugriffskontrollen Ihrer Daten erben, integrierte Such- und Analysetools verwenden und kontextbezogen neben Ihren Dashboards, Alerts und Untersuchungen arbeiten. Wir arbeiten intensiv daran, herausragende agentische Erlebnisse auf der Elastic-Plattform zu gewährleisten. Aber nicht jeder Agent ist in Elastic integriert. Ihr Team verwendet bereits Cursor, Claude Code oder andere Laufzeitumgebungen, und diese Agenten müssen Elastic ebenfalls richtig einsetzen. An dieser Stelle kommen Agent Skills ins Spiel.

Warum Agenten mit spezialisierten Plattformen Schwierigkeiten haben

Große Sprachmodelle (LLMs) sind bemerkenswert leistungsfähige Generalisten. Sie können Python schreiben, Kubernetes-Manifeste erklären und React-Komponenten refaktorisieren, weil ihre Trainingsdaten reich an Beispielen sind. Aber wenn es um plattformspezifische Arbeit geht, die proprietäre Abfragesprachen, tiefe API-Oberflächen und domänenspezifische Best Practices beinhaltet, stoßen sie auf vorhersehbare Weise an ihre Grenzen.

Bei Elasticsearch zeigt sich die Lücke ganz konkret:

• Die Elasticsearch-Abfragesprache (ES|QL) ist Neuland. LLMs werden intensiv in SQL geschult, aber ES|QL ist eine Pipe-Abfragesprache mit anderer Syntax, anderen Funktionen und anderer Semantik. Agenten schreiben oft Abfragen, die plausibel aussehen, aber nicht parsen. Sie verwechseln WHERE mit | WHERE, erfinden Funktionen, die es nicht gibt, und übersehen das Pipe-basierte Kompositionsmodell völlig.

• API-Oberflächen sind breit und tief. Elasticsearch, Kibana und Elastic Security stellen Hunderte von APIs für Suche, Ingestion, Alerting, Erkennungsregeln, Ticketmanagement, Dashboard und mehr zur Verfügung. Ein Agent, der nur mit allgemeinen Trainingsdaten ausgestattet ist, muss erraten, welchen Endpoint er aufrufen soll, wie der Anfragetext aussieht und wie er mit der Reaktion umgehen soll. Er rät oft genug falsch und untergräbt damit das Vertrauen.

• Best Practices liegen nicht in den Trainingsdaten. Wann sollten Sie semantic_text im Vergleich zu einer benutzerdefinierten Einbettungs-Pipeline verwenden? Wie sollte man eine Ingest-Pipeline für eine 10-GB-CSV strukturieren? Was ist die richtige Erkennungsregelsyntax für eine MITRE ATT&CK-Technik? Allgemeine Agenten haben standardmäßig kein kuratiertes, zuverlässig strukturiertes Elastic-spezifisches Wissen geladen. Sie müssten es erst einmal finden, und selbst wenn sie es fänden, spiegeln Rohdokumente nicht immer die Beurteilungen und Best Practices wider, die erfahrene Fachleute anwenden.

Das Ergebnis: Entwickler verbringen mehr Zeit damit, die Ausgabe des Agenten zu korrigieren, als sie für das Schreiben des Codes selbst benötigt hätten. Das ist nicht das, was man haben wollte.

Agent Skills: Plattformwissen, speziell für Agenten aufbereitet

Agent Skills sind selbstständige Verzeichnisse mit Anweisungen, Skripten und Referenzmaterial, die in Agentenlaufzeiten dynamisch geladen werden können. Wenn ein Skill, also eine Fähigkeit, aktiv ist, hat der Agent zum richtigen Zeitpunkt Zugriff auf den richtigen Kontext: Abfragesyntax, API-Muster, Validierungslogik, ausgearbeitete Beispiele, sodass er Aufgaben schon beim ersten Versuch korrekt ausführen kann.

Jede Fähigkeit folgt der offenen agentskills.io-Spezifikation: einem Ordner mit einer SKILL.md-Datei, die Metadaten und strukturierte Anweisungen enthält. Kein proprietäres Format, keine Anbieterabhängigkeit. Fähigkeiten funktionieren über Agentenlaufzeiten hinweg, darunter Cursor, Claude Code, GitHub Copilot, Windsurf, Gemini CLI, Cline, Codex und viele mehr.

Was enthält die erste Version 0.1.0?

Die erste Gruppe von Fähigkeiten umfasst fünf Bereiche des Elastic Stack:

• Interaktion mit den Elasticsearch-APIs (Suche, Indizierung, Clusterverwaltung)

• Erstellung und Verwaltung von Kibana-Inhalten wie Dashboards, Warnmeldungen, Konnektoren und mehr

• Domänenexpertise für Elastic Observability

• Domänenexpertise für Elastic Security

• Erstellung effektiver Agenten in Agent Builder

Skills sind kombinierbar

Skills sind nicht monolithisch. Sie sind von Natur aus modular. Ihr Agent lädt nur die Fähigkeiten, die für die jeweilige Aufgabe relevant sind. Arbeiten Sie an einer ES|QL-Abfrage? Die ES|QL-Fähigkeit wird aktiviert. Müssen Sie aus diesen Ergebnissen ein Dashboard erstellen? Die Dashboard-Fähigkeit wird aktiviert. Müssen Sie den Zustand Ihrer Anwendung beurteilen? Da kommt die Dienstzustandsfähigkeit ins Spiel. Sie untersuchen eine Sicherheitswarnung? Die Triage-Fähigkeiten werden im Verlauf der Untersuchung in Ticketmanagement- und Reaktionsfähigkeiten umgewandelt.

Diese Komponierbarkeit bedeutet, dass Sie keinen einzigen, massiven Prompt benötigen, der versucht, alles abzudecken. Jede Fähigkeit trägt genau den Kontext, den ihr Bereich erfordert, nichts mehr, nichts weniger.

Für Entwickler, die Such- und KI-Anwendungen entwickeln

Wenn Sie Daten in Elasticsearch laden, Abfragen schreiben oder Indizes migrieren, reduzieren Skills den Kreislauf aus Codegenerierung, Fehlersuche und der Suche nach der Ursache in der Dokumentation.

Bitten Sie Ihren Agenten, eine CSV-Datei zu laden und er verwendet ein Streaming-Ingestion-Tool, das Backpressure handhabt und aus den Daten Zuordnungen ableitet. Es handelt sich dabei nicht um eine handgesteuerte _bulk-Schleife, die beim Ausführen der ersten großen Datei den Speicher erschöpft. Bitten Sie ihn um eine Abfrage mit ES|QL und er entdeckt Ihre tatsächlichen Indexnamen und Feldschemata und schreibt dann gültige Pipe-Abfragen mit korrekter Syntax, geeigneten Aggregationen und versionsabhängiger Feature-Auswahl, nicht eine SQL-basierte Vermutung, die drei Runden Debugging erfordert. Fordern Sie ihn auf, die Neuindizierung Cluster-übergreifend durchzuführen und er wird dem gesamten operativen Workflow folgen: Er erstellt das Ziel mit expliziten Zuordnungen, optimiert die Einstellungen für den Durchsatz, führt den Job asynchron aus und stellt nach Abschluss die Produktionseinstellungen wieder her – das ist nicht nur ein einfacher _reindex-Aufruf, der die Hälfte der Schritte überspringt, die ein erfahrener Operator befolgen würde.

Statt eines Agenten, der Ihnen einen plausiblen Ausgangspunkt liefert, den Sie dann korrigieren müssen, erhalten Sie einen, der die operative Disziplin kodiert, die dafür sorgt, dass das Ergebnis tatsächlich funktioniert.

Beispiele für die Wirkung von Elastic Agent Skills

Eval

Was durch die Fähigkeit verändert wurde

es-audit-query-failed-logins

Anstelle einer generischen Suche wurden die Abfragemuster für das Auditprotokoll aus dem Skill verwendet

es-authz-role-mapping-ldap

Die korrekte API-Aufrufstruktur für das Rollen-Mapping wurde ausgegeben

esql-basic-query

Eine ES|QL Pipe-Syntax über Abfrage-DSL wurde geschrieben

esql-error-handling

Betrachtet zuerst das Schema, statt Feldnamen zu erraten

esql-schema-discovery

Indexnamen wurden nie erraten

es-ingest-csv-with-infer

Nur --infer-mappings verwendet, Kombination mit --source-format-CSV vermieden, was zu einem leeren Index führt

es-ingest-json-file

Verwendete eine robuste Ingestionsmethode, die auch große Dateien verarbeiten kann

es-reindex-local-async

Zuerst wurde der Zielindex mit replicas: 0 und refresh_interval: "-1" erstellt, anschließend erfolgte eine asynchrone Neuindizierung. Baseline verzichtete auf jegliche Vorbereitung

es-security-403-privileges

Befolgte den diagnostischen Workflow der Fähigkeit für Berechtigungsfehler anstelle allgemeiner Ratschläge

Für Sicherheitsteams

Security-Teams wiederholen täglich die gleichen operativen Workflows: Priorisierung von Warnmeldungen, Anpassung von Erkennungsregeln und Verwaltung von Tickets. Agent Skills kodieren dieses prozedurale Wissen, damit Ihr KI-Agent die Workflows korrekt ausführen kann, indem er die richtigen APIs in der richtigen Reihenfolge mit den richtigen Feldnamen aufruft. Eine praktische Anleitung, die Sie von null zu einer vollständig eingerichteten Elastic Security-Umgebung führt, ohne Ihre IDE zu verlassen, finden Sie unter Erste Schritte mit Elastic Security von Ihrem KI-Agenten aus.

Für Observability- und operative Teams

Die neuen Agent Skills für Elastic Observability reduzieren den betrieblichen Aufwand bei der Instrumentierung komplexer Systeme, der Verwaltung von SLOs, der Sichtung komplexer Daten und der Bewertung des Dienstzustands. Die direkte Einbettung nativer Elastic-Expertise in KI-Agenten ermöglicht es Teams, komplexe Beobachtbarkeits-Workflows mit einfacher natürlicher Sprache auszuführen. Dadurch können SREs und Ops-Teams Vorfälle schneller beheben und zuverlässige Systeme einfacher pflegen. Weitere Informationen finden Sie in diesem Blog.

Open Source, offene Spezifikationen, Community-gesteuert

Wir veröffentlichen Agent Skills unter der Apache-2.0-Lizenz, weil wir glauben, dass Agentenwissen offen sein sollte. Die agentskills.io-Spezifikation, der die Skills folgen, ist ein offener Standard, kein proprietäres Elastic-Format. Wir möchten, dass Fähigkeiten eine Gemeinschaftsleistung sind, kein geschlossener Bereich.

Teil eines größeren Ganzen

Agent Skills ist Teil einer umfassenderen Initiative, Elasticsearch zur agentenfreundlichsten Datenplattform zu machen. Für Agenten, die in die Elasticsearch-Plattform integriert sind, geht Agent Builder noch einen Schritt weiter, indem es die Zugriffskontrollen und Berechtigungen Ihrer Daten übernimmt, integriert und individuelle Tools für Suche und Analyse bereitstellt und Nutzern erlaubt, mit Agenten im Kontext und ihren Dashboards, Warnungen und Untersuchungen zu interagieren. Schließlich wird in Kürze auch die Unterstützung für Skills in Agent Builder verfügbar sein und Entwicklern die Flexibilität geben, Elastic Agent Skills sowie Skills aus beliebigen anderen Quellen zu nutzen, um sichere, kontextbezogene Chats und Automatisierungen auf der Elasticsearch-Plattform zu ermöglichen.

Für Agenten an allen anderen Orten investieren wir in das offene Ökosystem:

• Erweiterung des Model Context Protocol (MCP)-Servers: Die Erweiterung des MCP Endpoints in Agent Builder um weitere Tools über die aktuelle Suche, ES|QL und Indexoperationen hinaus.

• Verbesserungen bei der Authentifizierung: Dies macht es für Agenten einfacher, eine sichere Verbindung herzustellen, mit dem Ziel, manuelles Kopieren und Einfügen von API-Schlüsseln zu eliminieren.

• LLM-lesbare Dokumentation: Veröffentlichung der Dateien llms.txt und AGENTS.md, damit Agenten Elastic-APIs selbstständig finden und verstehen können.

• Eine Befehlszeilenschnittstelle (CLI) für Agenten-Workflows: Ein Befehlszeilentool, das die Verbindungsverwaltung und gängige Operationen agentenfreundlich gestaltet.

Skills sind die Ebene, die Sie heute nutzen können. Der Rest folgt.

Erste Schritte

Bevor Sie beginnen: KI-Programmieragenten arbeiten mit echten Anmeldeinformationen, echtem Shell-Zugriff und oft mit den vollen Berechtigungen des Nutzers, der sie ausführt. Wenn diese Agenten auf Sicherheitsworkflows ausgerichtet werden, steigen die Risiken: Sie geben einem automatisierten System Zugriff auf Erkennungslogik, Reaktionsmaßnahmen und sensible Telemetrie. Das Risikoprofil jeder Organisation ist unterschiedlich. Bevor Sie KI-gesteuerte Sicherheitsworkflows aktivieren, sollten Sie prüfen, auf welche Daten der Agent zugreifen kann, welche Maßnahmen er ausführen kann und was passiert, wenn er sich nicht so verhält, wie erwartet.

Installieren Sie Elastic Agent Skills in Ihrer Agenten-Runtime:

npx skills add elastic/agent-skills

Dadurch werden Ihre installierten Agenten-Runtimes automatisch erkannt und die Skills im richtigen Konfigurationsverzeichnis abgelegt. Von dort aus nimmt Ihr Agent sie automatisch auf.

Sie können den Fähigkeitenkatalog auch direkt durchsuchen und einzelne Fähigkeiten manuell installieren, indem Sie den Fähigkeitenordner in das Konfigurationsverzeichnis Ihres Agenten kopieren.

Sie haben noch keinen Elasticsearch-Cluster? Starten Sie eine kostenlose Elastic Cloud-Testversion. Es dauert etwa eine Minute, bis eine vollständig konfigurierte Umgebung eingerichtet ist.

Projekt erkunden:

• Agent Skills-Repository

• agentskills.io Spezifikation

• Elasticsearch-Dokumentation

• Elastic Cloud kostenlos testen

Wir haben alle den Aufstieg von KI-Agenten gesehen. Sie sind hervorragend darin, Texte zusammenzufassen, Code-Snippets zu schreiben und Fragen anhand der Dokumentation zu beantworten. Doch für uns im Bereich DevOps und Site Reliability Engineering (SRE) gab es eine frustrierende Einschränkung. Die meisten Agenten sind im Call Center-Paradigma gefangen, d. h. sie können lesen, denken und chatten, aber sie können die Infrastruktur, die sie verwalten sollen, nicht erreichen und berühren.

Für unser neuestes Hackathon-Projekt haben wir beschlossen, diese Einschränkung aufzuheben.

Wir haben Augmented Infrastructure entwickelt: einen Infrastruktur-Copiloten, der Ihnen nicht nur Ratschläge gibt, sondern auch Ihre Live-Umgebung erstellt, bereitstellt, überwacht und repariert.

Das Problem: Kopieren, Neuformatieren, Einfügen

Standardagenten agieren isoliert. Wenn Ihre App ausfällt und das Unternehmen 5 Millionen $ kostet, kann Ihnen ein Standard-Agent die Bedienungsanleitung dazu vorlesen, wie Sie das Problem beheben können. Aber Sie müssen trotzdem die Arbeit machen. Sie kopieren den Code, formatieren ihn für Ihre Umgebung um und fügen ihn in Ihr Terminal ein.

Wir wollten einen Agenten, der den Unterschied zwischen dem Sprechen über Kubernetes und dem Konfigurieren von Kubernetes versteht.

Die Engine: Was ist der Elastic Agent Builder?

Um das zu realisieren, haben wir nicht bei null angefangen. Wir haben auf Elastic Agent Builder aufgebaut. Für diejenigen, die es noch nicht kennen: Elastic Agent Builder ist ein Framework, das für die schnelle Entwicklung von Agenten konzipiert wurde und als Brücke zwischen einem großen Sprachmodell (LLM) (in unserer Demo haben wir Google Gemini verwendet) und privaten Daten, die in Elasticsearch gespeichert sind, fungiert.

Agent Builder kann für dialogbasierte KI verwendet werden, indem er auf internen Daten wie Dokumenten oder Protokollen basiert. Aber sein leistungsstärkstes Feature ist die Möglichkeit, Tools zuzuweisen. Mithilfe dieser Tools kann das LLM die Chat-Schnittstelle verlassen, um spezifische Aufgaben auszuführen. Wir erkannten, dass wir, wenn wir dieses Feature bis an seine Grenzen ausreizen, Agent Builder in eine Automatisierungshochburg verwandeln könnten.

So begann es: Die erste Version

Als wir mit dem Projekt anfingen, wussten wir, dass wir die Agenten in die Lage versetzen wollten, die Außenwelt zu verändern. Wir hatten eine Idee: Was wäre, wenn wir eine Art „Runner“-Software entwickeln würden (die jeden Befehl, den sich der Agent ausdenken könnte, auf dem Host ausführt)? Und dann: Was wäre, wenn die Runner, Elastic Agent Builder und der Nutzer in einem Dreiergespräch wären?

Wir begannen mit der Entwicklung eines Python-Projekts namens Augmented Infrastructure Runners, das im Grunde eine while(true)-Schleife war, die jede Sekunde die Elastic Agent Builder Conversations API abfragte und nach einer speziellen Syntax prüfte, die wir erstellt hatten:

Anschließend aktualisierten wir den Prompt, um ihn mit unserer neuen Tool-Aufruf-Syntax vertraut zu machen. Bill ist Maintainer von FastMCP, dem beliebtesten Framework zum Aufbau von Modellkontextprotokoll-(MCP)-Servern in Python. Er machte sich daran, mit dem FastMCP-Client und dieser neuen Runner-Software MCP-Server einzubinden und deren Tools dem Runner zur Verfügung zu stellen. Als der Agent dies sah, führte er den Tool-Aufruf aus und postete die Ergebnisse zurück in die Konversation, so, als ob der Nutzer die Ergebnisse gesendet hätte. Dies veranlasste das LLM, auf das Ergebnis zu reagieren, und schon ging es los!

Das war toll, hatte aber zwei Hauptprobleme:

1. Der Agent würde all diese JSON-Daten direkt in die Unterhaltung mit dem Nutzer einspeisen.

2. Der früheste Zeitpunkt, an dem Nachrichten über die Konversations-API sichtbar waren, war, als eine Konversationsrunde abgeschlossen wurde (also als das LLM antwortete).

Also machten wir uns daran, herauszufinden, wie wir dies in den Hintergrund verschieben können.

Wir gingen dann dazu über, dem Agenten ein Tool namens call_external_tool mit zwei Argumenten zu geben: dem tool_name und den stringifizierten JSON-Tool-Argumenten. Dieser externe Toolaufruf gab kein Ergebnis ab, war aber wichtigerweise in der GET-Anfrage an die Konversations-API sichtbar. Wir gaben den Runnern dann die Erlaubnis, Dokumente direkt in Elasticsearch zu schreiben, die der Elastic Agent Builder-Agent bei Bedarf abrufen konnte. Der Agent arbeitet immer als Reaktion auf eine Nutzernachricht, daher müssen wir den Agenten mit einer Nutzernachricht starten, damit er nach Ergebnissen sucht und die Verarbeitung fortsetzt. Deshalb baten wir die Agenten, eine kurze Nachricht in den Chat einzufügen, um die Konversation fortzusetzen:

Nun hatten wir also externe Tool-Aufrufe. Wegen des zweiten oben genannten Problems mussten wir jedoch auf diesen letzten Anstoßmechanismus verzichten. Andernfalls erforderte jeder externe Tool-Aufruf eine komplette Gesprächsrunde, um die Ergebnisse abzurufen!

Das Beste daraus machen: Die Einführung von Workflows

Zusätzlich zur Elasticsearch-Abfragesprache (ES|QL) und Aufrufen von Index-Such-Tools können Agent Builder-Agenten Elastic-Workflow-basierte Tools aufrufen. Elastic-Workflows bieten eine flexible und einfach zu verwaltende Möglichkeit, eine beliebige Abfolge und Logik von Aktionen auszuführen. Für unsere Zwecke muss der Workflow lediglich eine externe Tool-Anfrage in Elasticsearch speichern und eine ID zurückgeben, anhand derer die Ergebnisse abgefragt werden können. Daraus ergibt sich die folgende einfache Workflow-Definition:

Damit können die Runner, anstatt darauf angewiesen zu sein, dass die Tool-Aufruf-Anfrage in die Konversation geschrieben wird, einfach den Elasticsearch „distributed-tool-requests“-Index nach neuen externen Tool-Anfragen abfragen und die Ergebnisse mit der bereitgestellten execution.id in einen anderen Elasticsearch-Index zurückmelden.

Damit sind die beiden oben genannten Hauptprobleme beseitigt:

1. Der Gesprächsverlauf ist nicht mehr mit den Nutzdaten der externen Tool-Aufrufe überladen.

2. Da die Runner den Elasticsearch-Index anstelle des Konversationsverlaufs abfragen, werden sie nicht dadurch blockiert, dass die Konversationsrunde abgeschlossen sein muss, damit die Anfragen an das externe Tool sichtbar werden.

Der zweite Punkt hat den großen Vorteil, dass die Verarbeitung der externen Tool-Aufrufe bereits in der Denkphase des Agenten beginnt (und nicht erst nach Abschluss der Gesprächsrunde). Dadurch können wir den LLM im System-Prompt anweisen, die Ergebnisse des externen Tools abzufragen, bis diese verfügbar sind, und die Notwendigkeit einer Startnachricht entfällt. Insgesamt hat dies den angenehmen Effekt, dass sich die Konversation natürlicher anfühlt: Das LLM kann mehrere externe Tool-Anfragen innerhalb einer einzigen Konversationsrunde verarbeiten (anstatt für jede Tool-Anfrage eine Konversationsrunde zu benötigen) und kann somit komplexere Nutzeranfragen in einem Durchgang erledigen.

Aus den Einzelteilen entsteht ein Ganzes

Um die Lücke zwischen dem LLM und dem Server-Rack zu schließen, entwickelten wir eine spezielle Architektur, die die Funktionen des Agent Builders nutzt:

1. Runner für erweiterte Infrastruktur: Wir stellten Lightweight-Runner innerhalb der Zielumgebungen (Server, Kubernetes-Cluster, Cloud-Konten) bereit. Diese Runner sind direkt mit Elastic verbunden und verwenden gesicherte Endpoints und Secrets, die nur dem jeweiligen Runner zur Verfügung stehen.

2. ES|QL-Abfrage: Der Copilot verwendet die Elastic ES|QL, um hybride Suchen durchzuführen. Er sucht nicht nur nach Wissen; er sucht nach Fähigkeiten. Er fragt die verbundenen Runner ab, um zu sehen, welche Tools verfügbar sind (zum Beispiel list_ec2_instances, install_helm_chart).

3. Workflow-Ausführung: Sobald der Agent sich für eine Vorgehensweise entschieden hat, erstellt er einen strukturierten Workflow.

4. Rückkopplungsschleife: Die Runner führen den Befehl lokal aus und senden den Bericht an Elasticsearch zurück. Der Copilot liest das Ergebnis aus dem Index und entscheidet über den nächsten Schritt.

Die Demo: Von Ausfall zu Beobachtbarkeit

Im Video haben wir zwei unterschiedliche Szenarien gezeigt, die die Kraft dieser Architektur demonstrieren.

Szenario 1: DevOps-Rettung

Wir begannen mit einem Nutzer, der wegen eines Ausfalls von 5 Millionen $ durch einen blinden Fleck in seinem Kubernetes-Cluster in Panik geriet.

• Die Anfrage: „Wie kann ich sicherstellen, dass dies nicht wieder vorkommt?“

• Die Aktion: Der Agent stellte nicht nur ein Tutorial bereit. Er identifizierte den Cluster, erstellte die notwendigen Namespaces, generierte Kubernetes-Secrets, installierte den OpenTelemetry Operator und stellte sofort einen Link zu einem Live-APM-Dashboard bereit.

• Das Ergebnis: Vollständige Kubernetes-Beobachtbarkeit und Anwendungseinblicke, ohne dass der Nutzer auch nur eine einzige YAML-Zeile schreiben muss.

Szenario 2: Security-Übergabe

Eine Grundregel der Infrastruktursicherheit lautet: Was man nicht sieht, kann man nicht schützen. Während der Durchführung unserer DevOps-Rettung sieht der Agent eine Möglichkeit, die Sicherheit der Umgebung zu verbessern.

Ausgehend von einer Warnung, die im Rahmen einer früheren Untersuchung im Zusammenhang mit Elastic Observability ausgelöst wurde, zeigen wir, wie ein Sicherheitsexperte direkt mit seiner Infrastruktur kommunizieren kann: erstens, um die Assets und Ressourcen in seiner Cloud-Umgebung aufzulisten, und zweitens, um die notwendigen Tools bereitzustellen, um die Sicherheit der Umgebung zu gewährleisten.

• Entdeckung: Der Copilot zählte die AWS-Ressourcen für den Sicherheitsexperten auf und identifizierte eine kritische Lücke: eine Amazon Elastic Compute Cloud (EC2)-Instanz und ein Amazon Elastic Kubernetes Service (EKS)-Cluster, bei denen öffentliche Endpoints keinen Endpoint-Schutz besaßen.

• Behebung: Mit einer einfachen Freigabe stellte der Copilot Elastic Security Erweiterte Erkennung und Reaktion (XDR) und Cloud-Erkennung und -Reaktion (CDR) für die anfälligen Assets bereit und sicherte die Umgebung in Echtzeit.

• Das Ergebnis: Schutz der bereitgestellten AWS-Assets und -Ressourcen mit vollständiger Laufzeitsicherheit.

Die Zukunft: Alles augmentiert

Dieses Projekt beweist, dass Elastic Agent Builder die zentrale Steuerungseinheit für verteilte Operationen sein kann. Wir beschränken uns nicht nur auf die Infrastruktur. Unsere Runner-Technologie kann Folgendes unterstützen:

• Augmentierte Synthetics: Diagnose von TLS-Fehlern bei globalen Runnern.

• Augmentierte Entwicklung: Erstellung von Pull-Anfragen und Implementierung von CAPTCHAs auf Frontend-Diensten.

• Augmentierten Betrieb: Automatische Neukonfiguration der DNS-Resolver bei einem Ausfall.

Probieren Sie es selbst aus

Wir glauben, dass es bei der Zukunft der KI nicht nur um Chat-Support geht, sondern um augmentierte Infrastruktur. Es geht darum, einen Partner zu haben, der gemeinsam mit Ihnen bereitstellen, reparieren, beobachten und schützen kann.

Sehen Sie sich den Code an und probieren Sie ihn noch heute mit verteilten Runnern (GitHub) plus Elastic Agent Builder auf Elastic Cloud Serverless aus!

• Erstellen Sie ein serverloses Projekt auf Elastic Cloud.

• Stellen Sie den Code auf einem Runner bereit.

• Richten Sie den Runner ein.

• Konfigurieren Sie Ihre mcp.json.

• Starten Sie den Runner, der automatisch Ihren Agenten und seine Tools erstellt.

• Chatten Sie mit einem Agenten, der Aktionen für Ihre verteilten Runner planen und ausführen kann!

Das Team: Alex, Bill, Gil, Graham und Norrie