Elastic Agent Builder wird allgemein verfügbar: Was der neue Baukasten für KI‑Agenten für Unternehmen bedeutet

Elastic hat am 22. Januar 2026 die allgemeine Verfügbarkeit (General Availability, GA) von Agent Builder bekanntgegeben. Das Werkzeug soll es Unternehmen ermöglichen, produktionsreife, kontextgetriebene KI‑Agenten deutlich schneller und sicherer auf Basis ihres bestehenden Elastic‑Stacks zu entwickeln. Gleichzeitig stellt Elastic mit Workflows eine neue Komponente in der Tech‑Preview vor, die es Agenten erlaubt, regelbasiert Aktionen in internen und externen Systemen auszulösen.

Für Unternehmen, die bereits Elasticsearch, Elastic Observability oder Elastic Security einsetzen, ist dies ein wichtiger strategischer Schritt: Statt individuelle Agenten‑Architekturen von Grund auf zu bauen, können KI‑Funktionen jetzt direkt in die vorhandene Search‑ und Datenplattform integriert werden – inklusive Governance, Sicherheit und Observability.

Kontext: Was hat Elastic konkret angekündigt?

Agent Builder in GA

Mit der GA‑Freigabe positioniert Elastic Agent Builder als vollständigen Funktionssatz für den Aufbau von KI‑Agenten auf Enterprise‑Daten. Wichtige Eckpunkte:

• Kontext-Engineering auf Elasticsearch: Agent Builder nutzt Elasticsearch als zentrale Plattform, um Unternehmensdaten zu indizieren, zu durchsuchen und für Agenten aufzubereiten.

• End‑to‑End‑Workflow: Von Datenvorbereitung und -ingestion über Retrieval und Relevanzranking bis hin zu Tools, Konversationsebene und Agent‑Monitoring ist der Lebenszyklus eines Agents in einer integrierten Umgebung abbildbar.

• Modell‑Agnostik: Unternehmen können verschiedene LLMs nutzen – inklusive Managed Services der Hyperscaler – ohne sich auf ein Modell festzulegen.

• Native Unterstützung moderner Protokolle wie MCP und A2A, um Agenten in Frameworks wie Microsoft Foundry oder das Microsoft Agent Framework einzubetten und Elasticsearch als Wissensquelle zu nutzen.

Agent Builder ist in Elastic Cloud Serverless verfügbar und zudem in der Enterprise‑Stufe von Elastic Cloud Hosted sowie in selbstverwalteten Elastic‑Stack‑Deployments (ab der kommenden Version 9.3) enthalten.

Workflows als Tech‑Preview

Parallel zur GA von Agent Builder hat Elastic Workflows in einer technischen Vorschau vorgestellt. Die Idee dahinter:

• LLM‑Agenten sind gut im Planen und Begründen, aber weniger zuverlässig bei kritischen, deterministischen Aktionen (z. B. Änderungen in Produktivsystemen).

• Workflows ergänzen Agenten deshalb um eine regelbasierte Orchestrierungsebene, die sicherstellt, dass bestimmte Abläufe kontrolliert und nachvollziehbar ausgeführt werden.

• Agenten können Workflows nutzen, um Daten abzurufen, zu transformieren und Aktionen in internen wie externen Systemen auszulösen, ohne dass jede Einzelschrittplanung dem LLM überlassen wird.

Damit adressiert Elastic ein Kernproblem heutiger agentischer Systeme: Die Kluft zwischen beeindruckenden Demos und stabilen, auditierbaren Produktionsszenarien.

Detaillierte Analyse: Was ist neu – und warum ist es relevant?

1. Agent Builder als Kontext‑Layer für Enterprise‑Daten

Viele Unternehmen haben in den letzten 18 Monaten mit Prototypen für Chatbots, Copilots oder Agenten experimentiert. Häufige Probleme:

• Fragmentierte Datenlandschaft über verschiedene Systeme (Ticketing, Monitoring, DMS, ERP etc.)

• Schwierige Kontextanreicherung für LLMs, insbesondere bei unstrukturierten Daten

• Hoher Integrationsaufwand zwischen Vektordatenbanken, Retrieval‑Pipelines, Agent‑Frameworks und Observability

Agent Builder setzt genau hier an und verlagert das Kontext‑Engineering in eine Plattform, die viele Unternehmen ohnehin bereits im Einsatz haben:

• Elasticsearch fungiert gleichzeitig als klassische Suchmaschine, Analyseplattform und Vektorspeicher.

• Hybride Retrieval‑Strategien (z. B. BM25 + Embeddings) und Re‑Ranking können nahtlos kombiniert werden.

• Die Daten bleiben im Kontrollbereich des Unternehmens, inkl. bestehender Rollen‑ und Rechtekonzepte.

Für Entscheider bedeutet dies: Statt eine zusätzliche Spezialplattform nur für Agenten einzuführen, kann die vorhandene Search‑Plattform zum zentralen Kontext‑Layer für alle agentischen Anwendungen ausgebaut werden.

2. End‑to‑End statt Tool‑Sammlung

Viele Agent‑Stacks bestehen aus lose gekoppelten Komponenten: ein LLM‑Gateway hier, ein Vektor‑Store dort, ein separates Tool‑ und Orchestrierungssystem sowie individuelle Observability‑Lösungen. Das erhöht

• Komplexität in Betrieb und Governance,

• Fehleranfälligkeit,

• und die Abhängigkeit von einzelnen Spezialisten.

Elastic positioniert Agent Builder als Antwort darauf: Ein integrierter, aber erweiterbarer Stack mit folgenden Vorteilen:

• Native Datenerfassung und ‑aufbereitung (Ingest Pipes, Konnektoren, Normalisierung)

• Konfigurierbares Retrieval & Ranking in derselben Plattform, in der die Daten ohnehin liegen

• Konversationsebene und Agent‑Logik eng mit Observability verknüpft (z. B. Logging, Tracing, Metriken)

Das reduziert Implementierungs‑ und Betriebsaufwand und erleichtert Audits, weil einheitliche Logs und Metriken vorhanden sind.

3. Workflows: Brücke zwischen LLM‑Intelligenz und deterministischer Automatisierung

Neu und strategisch bedeutsam ist die Kombination aus

• LLM‑basiertem Reasoning und Entscheidungsfindung und

• regelbasierter, deterministischer Ausführung in Workflows.

Typische Herausforderungen in reinen LLM‑Agenten:

• Unvorhersehbare Aktionssequenzen

• Halluzinationen bei Tool‑Aufrufen

• Schwierige Zertifizierbarkeit in regulierten Bereichen

Workflows adressiert dies, indem Agenten

• über vordefinierte Pfade (z. B. Genehmigungsprozesse, Eskalationslogiken) geführt werden,

• kritische Schritte (z. B. Änderungen in Produktionssystemen) nur unter klaren Bedingungen ausführen dürfen,

• und Ausführungen nachvollziehbar und reproduzierbar bleiben.

Für Branchen mit hohen Compliance‑Anforderungen (Finanzdienstleister, Versicherungen, Pharma, kritische Infrastrukturen) ist dies eine notwendige Voraussetzung, um agentische Systeme produktiv zu nutzen.

4. Integration in das Microsoft‑Ökosystem und andere Frameworks

Die native Unterstützung von Protokollen wie MCP und A2A erlaubt es, Elastic‑basierte Agenten in Microsoft Foundry und das Microsoft Agent Framework einzubetten. Damit wird Elasticsearch zu einer Wissensquelle in einem größeren Agenten‑Ökosystem, statt zu einer isolierten Insellösung.

Für Unternehmen mit einer Azure‑ oder Microsoft‑First‑Strategie ist das entscheidend:

• Elastische Daten können in Copilots und Agenten eingebunden werden, ohne proprietäre Brückentechnologien zu entwickeln.

• Die Wahl des LLM (Azure OpenAI, andere Hyperscaler, spezialisierte Modelle) bleibt flexibel.

5. Kosten‑ und Governance‑Perspektive

Aus Business‑Sicht bringt die GA von Agent Builder zwei zentrale Effekte:

1. Reduktion des Custom‑Code‑Anteils: Weniger selbstgebaute Pipelines und Ad‑hoc‑Integrationen, mehr Nutzung von Standardfunktionen der Plattform.

2. Bessere Governance: Einheitliches Berechtigungsmodell, zentrale Audit‑Trails und Observability.

Beides senkt mittelfristig

• Betriebskosten (TCO),

• Time‑to‑Market für neue KI‑Use‑Cases

• und das organisatorische Risiko von Agentenprojekten, die nur im Experimentierstadium bleiben.

Praxisnahe Einsatzszenarien und Implikationen

Technischer Support und IT‑Operations

Ein typisches Szenario ist der technische Kundensupport oder interne IT‑Support, in dem heute bereits Elastic‑basierte Observability‑Daten genutzt werden:

• Logs, Metriken und Traces sind im Elastic Stack zentralisiert.

• Ticketsysteme, Wissensdatenbanken und Runbooks liegen teilweise ebenfalls in Elasticsearch oder sind über Konnektoren angebunden.

Mit Agent Builder könnte ein „Support‑Agent“:

1. Eingehende Vorfälle verstehen und zusammenfassen (z. B. aus E‑Mails oder Tickets).

2. Über hybride Suche ähnliche historische Incidents, Workarounds und Root‑Cause‑Analysen finden.

3. Hypothesen für die wahrscheinliche Ursache formulieren und standardisierte Remediation‑Steps vorschlagen.

4. Über Workflows automatisiert Diagnoseschritte ausführen (z. B. Log‑Abfragen, Health‑Checks, Rollbacks), sofern diese vordefiniert und freigegeben sind.

Nutzen für Unternehmen:

• Deutlich schnellere Störungsbehebung, insbesondere bei wiederkehrenden Problemen

• Entlastung von L2/L3‑Teams, da Routineaufgaben automatisiert werden

• Bessere Standardisierung von Lösungen über Länder‑ oder Abteilungsgrenzen hinweg

Produkt‑ und Content‑Discovery

Gerade im E‑Commerce und B2B‑Vertrieb spielt Elastic traditionell eine große Rolle in der Produktsuche. Mit Agent Builder wird daraus eine konversationelle, agentische Produkterkundung:

• Kunden oder Vertriebsmitarbeitende beschreiben Anwendungsfälle in natürlicher Sprache.

• Der Agent durchsucht komplexe Produktkataloge, technische Spezifikationen und ergänzende Dokumente (z. B. Zertifikate, Sicherheitsdatenblätter).

• Er schlägt konfigurierte Produktbündel vor, verweist auf bekannte Kompatibilitätsprobleme und berücksichtigt unternehmensspezifische Geschäftsregeln (z. B. Margen, Lagerbestände, vertragliche Einschränkungen).

Über Workflows könnten anschließend z. B.

• Angebotsentwürfe erstellt,

• Warenkörbe befüllt oder

• interne Freigabeprozesse angestoßen werden.

Security‑Automatisierung

In Security‑Teams, die Elastic Security einsetzen, bietet sich ein Threat‑Hunting‑ oder Triage‑Agent an:

• Der Agent erhält Kontext zu Alerts, Entities und vergangenen Incidents.

• Er aggregiert relevante Telemetrie (z. B. Endpoint‑Daten, Netzwerklogs) und bekannte TTPs.

• Er erstellt Investigation‑Pläne und schlägt priorisierte Maßnahmen vor.

• Über Workflows können vordefinierte Playbooks (z. B. User‑Isolierung, Quarantäne von Endpoints, Ticket‑Erstellung) angestoßen werden – eingebettet in existierende SOAR‑Prozesse.

Für Security‑Leiter hat dies unmittelbare Auswirkungen auf MTTR (Mean Time to Respond) und auf die Fähigkeit, mit Fachkräftemangel umzugehen.

Business‑Relevanz: Was Unternehmen jetzt tun sollten

1. Bestehende Elastic‑Landschaft als Agenten‑Plattform denken

Unternehmen, die bereits Elasticsearch, Elastic Observability oder Elastic Security nutzen, sollten ihre Deployments strategisch überprüfen:

• Welche Datenquellen liegen bereits zentral im Elastic Stack, welche lassen sich mit vertretbarem Aufwand anbinden?

• Wo bestehen heute wiederkehrende Entscheidungs‑ oder Analyseaufgaben, die sich durch KI‑Agenten unterstützen oder teilweise automatisieren lassen?

Ziel ist, eine Karte der potenziellen Agenten‑Use‑Cases zu erstellen, die auf der bestehenden Datenbasis aufsetzen können.

2. Governance‑Rahmen für agentische Systeme definieren

Mit GA von Agent Builder und Workflows rückt die Frage nach Governance in den Vordergrund:

• Rollen- und Rechtemodelle: Welche Agenten dürfen auf welche Daten und Systeme zugreifen?

• Kritikalitätsklassen für Aktionen: Welche Aktionen dürfen Agenten vollautomatisch, teilautomatisiert (mit menschlicher Bestätigung) oder nur lesend ausführen?

• Auditierbarkeit: Wie werden Entscheidungen und Aktionen der Agenten protokolliert und überprüft?

Unternehmen sollten diese Richtlinien frühzeitig definieren, um spätere Skalierung zu erleichtern.

3. Pilotprojekte mit klaren Metriken starten

Empfehlenswert ist der Start mit engen, gut messbaren Use‑Cases, z. B.:

• Automatisierte Vorschläge für Ticketklassifizierung und -routing

• Standardisierte Erstanalysen bei Infrastruktur‑Alerts

• Konversationsbasierte Suche in einem klar abgegrenzten Dokumentenkorpus (z. B. interne Richtlinien, Produktdokumentation)

Wichtige KPIs:

• Zeitersparnis pro Vorgang

• Qualität der Ergebnisse (z. B. über Peer‑Review, Nutzerfeedback)

• Reduktion manueller Zwischenschritte

Diese Ergebnisse bilden die Grundlage für eine Skalierungsentscheidung.

4. Architektur‑ und Tooling‑Strategie abstimmen

Agent Builder fügt sich in ein breiteres Ökosystem aus LLM‑Anbietern, Agent‑Frameworks und Unternehmensanwendungen ein. Architekturfragen, die jetzt adressiert werden sollten:

• Welche LLM‑Provider sollen genutzt werden (Hyperscaler, spezialisierte Anbieter, On‑Prem‑Modelle)?

• Wie werden Kosten für Inferenz und Kontextbereitstellung gesteuert (z. B. Kontextlängen, Caching, hybride Suche)?

• Welche Rolle spielt Elastic im Vergleich zu anderen Plattformen (z. B. Data Warehouses, Lakehouses, MLOps‑Stacks)?

Eine klare Antwort darauf verhindert Doppelstrukturen und erleichtert Investitionsentscheidungen.

5. Kompetenzen aufbauen

Auch wenn Agent Builder vieles vereinfacht, bleibt agentische KI ein anspruchsvolles Feld. Unternehmen sollten gezielt in Kompetenzen investieren:

• Search‑ und Relevance‑Engineering (Ranking, Hybrid Retrieval)

• Prompt‑ und Tool‑Design für Agenten

• Monitoring und Evaluation von Agentenverhalten

Hier bieten sich enge Kooperationen zwischen Data‑, Operations‑ und Fachteams an, um sicherzustellen, dass Agenten nicht nur technisch funktionieren, sondern auch fachlich akzeptiert werden.

Fazit: Agent Builder als Baustein für produktionsreife Agenten

Mit der allgemeinen Verfügbarkeit von Agent Builder und der Einführung von Workflows verschiebt Elastic den Fokus von isolierten KI‑Experimente hin zu betrieblich tragfähigen, kontextgetriebenen Agenten. Für Organisationen, die bereits stark auf den Elastic Stack setzen, entsteht damit eine klare Migrationspfad von klassischer Suche und Observability hin zu agentischen Anwendungen.

Zentrale Takeaways für Unternehmen:

• Agent Builder nutzt bestehende Elastic‑Daten als Kontext‑Layer und reduziert damit Integrations- und Entwicklungsaufwand beim Aufbau von KI‑Agenten.

• Workflows ergänzen LLM‑Intelligenz um deterministische Orchestrierung, was besonders für regulierte und geschäftskritische Prozesse relevant ist.

• Die Integration in Frameworks wie Microsoft Foundry macht Elasticsearch zu einer zentralen Wissensquelle in größeren Agenten‑Ökosystemen.

• Typische Einsatzfelder liegen in technischem Support, Observability, Security‑Automatisierung sowie Produkt‑ und Content‑Discovery.

• Unternehmen sollten jetzt Governance, Architektur und Pilotprojekte definieren, um Agent Builder pragmatisch zu testen und skalierbare Standards zu etablieren.

• Kompetenzaufbau in Kontext‑Engineering und Agent‑Monitoring ist entscheidend, damit die neuen Möglichkeiten nicht nur als Demos, sondern als belastbare Produktionssysteme ankommen.

Häufig gestellte Fragen (FAQ)

Was ist der Elastic Agent Builder und wofür wird er eingesetzt?

Der Elastic Agent Builder ist ein Baukasten zum Entwickeln kontextgetriebener KI‑Agenten direkt auf dem Elastic‑Stack. Unternehmen können damit produktionsreife Chatbots, Copilots und Automatisierungsagenten erstellen, die auf ihre eigenen Such‑, Observability‑ und Security‑Daten zugreifen.

Wie funktioniert Agent Builder technisch im Zusammenspiel mit Elasticsearch?

Agent Builder nutzt Elasticsearch als zentralen Kontext‑Layer: Daten werden dort indiziert, durchsucht und als Vektor‑ und klassische Suchindizes bereitgestellt. Hybride Retrieval‑Strategien (z. B. BM25 plus Embeddings), Re‑Ranking und Konversationsebene laufen in einer integrierten Umgebung, die auch Logging, Metriken und Monitoring umfasst.

Welche Rolle spielen die neuen Workflows im Elastic‑Ökosystem?

Workflows ergänzen LLM‑Agenten um eine regelbasierte, deterministische Orchestrierungsebene. Sie stellen sicher, dass kritische Aktionen nur entlang vordefinierter Pfade und mit klaren Bedingungen ausgeführt werden, sodass Prozesse auditierbar, reproduzierbar und für regulierte Branchen besser kontrollierbar sind.

Was ist der Unterschied zwischen LLM‑Agenten und Workflows bei Elastic?

LLM‑Agenten sind für das Verstehen von Kontext, das Planen und Begründen zuständig, können aber bei konkreten Systemaktionen unvorhersehbar sein. Workflows übernehmen die streng definierte Ausführung von Schritten, etwa Genehmigungen, Playbooks oder Systemänderungen, und begrenzen damit Risiken wie Halluzinationen oder fehlerhafte Tool‑Aufrufe.

Welche praktischen Einsatzszenarien gibt es für Agent Builder in Unternehmen?

Typische Use Cases sind technischer Support und IT‑Operations, Security‑Automatisierung sowie Produkt‑ und Content‑Discovery. Beispiele reichen von Support‑Agenten, die Incidents analysieren und Remediation‑Schritte anstoßen, über Threat‑Hunting‑Assistenten bis hin zu konversationeller Produktsuche mit automatisierter Angebotserstellung.

Wie integriert sich Agent Builder in bestehende Microsoft‑ und Cloud‑Umgebungen?

Agent Builder unterstützt moderne Protokolle wie MCP und A2A, sodass Elastic‑basierte Agenten in Microsoft Foundry und das Microsoft Agent Framework eingebettet werden können. Unternehmen können dabei verschiedene LLM‑Provider, inklusive Hyperscaler‑Dienste, flexibel nutzen und Elasticsearch als zentrale Wissensquelle in ihrem Agenten‑Ökosystem etablieren.

Was sollten Unternehmen jetzt konkret tun, um Agent Builder optimal zu nutzen?

Unternehmen sollten ihre bestehende Elastic‑Landschaft als potenzielle Agenten‑Plattform analysieren, geeignete Pilotfälle mit klaren KPIs definieren und frühzeitig Governance‑Regeln für Rollen, Berechtigungen und Aktionsklassen festlegen. Parallel empfiehlt sich der gezielte Aufbau von Kompetenzen in Kontext‑Engineering, Prompt‑ und Tool‑Design sowie Agent‑Monitoring, um schnell von Experimenten zu stabilen Produktionsszenarien zu kommen.