Jakarta EE Agentic AI: Status, Vergleich mit OmniHai und LangChain4j und ein Blick auf die Roadmap

Die Java Enterprise Welt tut sich traditionell schwer damit, schnell auf Trends zu reagieren, und das ist meistens auch gut so. Doch inzwischen ist klar: Agentic AI ist kein Nischenthema mehr, sondern braucht enterprise taugliche Standards. Genau hier setzt Jakarta Agentic AI an und wir schauen auf den aktuellen Status, den Vergleich mit OmniHai und LangChain4j und die durchaus spekulative Roadmap.
Blog
29.09.2026
André Biegel
Erfahren Sie mehr
visual-office

Was ist Jakarta Agentic AI überhaupt?

Jakarta Agentic AI ist ein Anfang Oktober 2025 unter dem Dach der Eclipse Foundation gestartetes Spezifikationsprojekt. Die Zielsetzung ist ambitioniert: Es soll für KI-Agenten das leisten, was Servlets für die HTTP-Verarbeitung oder Jakarta Batch für die Batch-Verarbeitung geleistet haben - also ein gemeinsames, herstellerneutrales Programmiermodell etablieren.

Wichtig ist dabei, was das Projekt bewusst nicht sein will: Es ist keine eigene LLM-API und will LLMs nicht standardisieren. Stattdessen definiert Jakarta Agentic AI laut Projektbeschreibung auf GitHub und beim Eclipse-Foundation-Projektvorschlag:

  • gemeinsame Nutzungsmuster und Lebenszyklen für KI-Agenten auf Jakarta-EE-Laufzeiten,
  • eine sehr schlanke Facade, um auf grundlegende KI-Fähigkeiten (insbesondere LLMs) zuzugreifen, ohne diese selbst zu standardisieren,
  • einen Unwrap-Mechanismus, ganz ähnlich wie man ihn aus Jakarta Persistence kennt, um bei Bedarf auf die volle Funktionalität einer konkreten Implementierung (z. B. LangChain4j oder Spring AI) zugreifen zu können,
  • eine annotationsbasierte, fluent Java-API für Agenten-Workflows, aufbauend auf CDI als Komponentenmodell.
    Die Spezifikation soll zwar primär auf Jakarta-EE-kompatiblen Laufzeiten funktionieren, die Projektverantwortlichen legen aber ausdrücklich Wert darauf, dass sie sich auch in Quarkus, Micronaut oder Spring Boot einsetzen lässt. 

Der aktuelle Stand

Der Weg dorthin ist bereits ein Stück gegangen: Das Specification Committee Ballot für Jakarta Agentic Artificial Intelligence 1.0 wurde am 5. November 2025 erfolgreich abgeschlossen. Seitdem arbeitet das Team an konkreten Entwürfen; ein erster Draft der Spezifikation (Milestone M1, Stand 30. Juli 2026) liegt mittlerweile vor. Bewusst ist dieses erste Release sehr minimal gehalten - es geht laut Projektteam zunächst darum, Schwung, Aufmerksamkeit und Beteiligung in der Community aufzubauen, statt von Anfang an ein vollständiges Framework zu liefern.
Im Kern des ersten Releases stehen:

  1. grundlegende Programmiermodelle und Muster für Agenten,
  2. Lebenszyklen für Agenten auf Basis von CDI,
  3. eine leichtgewichtige LLM-Facade.
    Ausdrücklich betont das Projektteam, dass es nicht in Konkurrenz zu LangChain4j oder Spring AI steht, sondern standardisieren möchte. Man programmiert künftig gegen `jakarta.ai.agent` und kann die konkrete Implementierung bzw. den Provider wechseln, ohne den eigenen Code umschreiben zu müssen - ganz im Stil von Jakarta Persistence gegenüber Hibernate oder EclipseLink.

Vergleich mit OmniHai (ehemals OmniAI)

Eine interessante Ergänzung im Jakarta-EE-Ökosystem ist OmniHai, eine Bibliothek aus dem OmniFaces-Umfeld (bekannt u. a. durch Bauke Scholtz alias "BalusC"). Sie hieß ursprünglich OmniAI, musste aber umbenannt werden, weil dieser Name bereits von mehreren anderen Produkten verwendet wurde und dadurch schwer auffindbar war. Seit ihrem 1.0-Release trägt sie den Namen OmniHai - nach Angaben des Projekts, weil "Hai" wie "AI" klingt, sich aber deutlich besser suchen lässt, und weil es im Japanischen zugleich "Ja" bedeutet, was zu einer Bibliothek passt, die zu praktisch jedem AI-Provider "Ja" sagt.

OmniHai versteht sich explizit nicht als Framework, sondern als schlanke Utility-Bibliothek. Laut GitHub-Repository und Release-Ankündigung bietet sie:

  • eine einheitliche API für mehrere KI-Provider (u. a. auch Ollama für lokale/offline Modelle),
  • keine externe HTTP-Bibliothek, sondern nur `java.net.http.HttpClient` - minimale Abhängigkeiten,
  • fertige Text-Utilities wie Zusammenfassung, Übersetzung, Extraktion von Kernpunkten und Moderation als First-Class-Features,
  • native CDI-Integration inklusive Expression Language, z. B. `@AI(apiKey = "#{config.key}")`,
  • MicroProfile-Config-Unterstützung, strukturierte Ausgaben, Datei-Anhänge und Konversationsgedächtnis (seit dem zweiten Meilenstein).

Was OmniHai bewusst nicht mitbringt: Tools, Embeddings, RAG-Pipelines oder ein Agenten-Framework. Das ist, wie die Projektbeschreibung selbst betont, kein Mangel, sondern eine Designentscheidung - wer RAG-Pipelines, Agenten-Frameworks oder Vektor-Stores braucht, wird explizit auf LangChain4j oder Spring AI verwiesen.

Spannend ist der Ausblick der Macher selbst: Sollte sich Jakarta Agentic AI etablieren, könnte OmniHai perspektivisch entweder als leichtgewichtige Implementierung von Teilen dieser Spezifikation dienen - oder als schlanke, komplementäre Alternative für alle, die keinen vollen Agenten-Stack benötigen, bestehen bleiben.

Vergleich mit LangChain4j

Ganz anders positioniert sich LangChain4j. Es gilt mittlerweile als das etablierteste Java-Framework für den Bau von LLM-gestützten Anwendungen und deckt RAG, agentische Workflows und die Integration gängiger LLMs sowie Vektor-Datenbanken ab.Bis 2025 hatte LangChain4j bereits formale Integrationen mit Quarkus, Spring Boot, Micronaut und Helidon - also praktisch allen relevanten Java-Anwendungsframeworks.

Kernstück von LangChain4j ist das Muster der AI Services: Statt imperativen Code für LLM-Aufrufe zu schreiben, deklariert man ein Interface, versieht es mit Annotationen wie `@SystemMessage` oder `@UserMessage`, und LangChain4j generiert daraus die Implementierung.

Für die CDI-Integration - und damit für die Brücke zu Jakarta EE - gibt es das Subprojekt langchain4j-cdi. Es soll sicherstellen, dass alle CDI-fähigen Laufzeiten das volle Spektrum von LangChain4j nutzen können, inklusive agentenbezogener Funktionen. Mit dem Modul `langchain4j-agentic` lassen sich Sequential-, Loop-, Conditional- und Parallel-Patterns sowie ein "Supervisor"-Pattern umsetzen, bei dem Agenten selbst entscheiden, welche Aufgaben sie ausführen; komplette Workflows können zudem als "Compound Agents" gebündelt werden, samt `AgenticScope` zur Kontrolle über Kontext und Aufrufkette.

Der zentrale Unterschied zu Jakarta Agentic AI: LangChain4j ist eine konkrete, wenn auch Open-Source-Bibliothek eines einzelnen Anbieters – laut GitHub-Projektbeschreibung von Jakarta Agentic AI vergleichbar mit Jakarta Data oder Spring Data, wobei der jeweilige KI-Provider fast wie ein austauschbarer JDBC-Treiber fungiert. Jakarta Agentic AI hingegen will genau diese Austauschbarkeit auf Spezifikationsebene festschreiben. Im besten Fall verschwindet die Konkurrenz sogar ganz: Eine Implementierung der Jakarta-Agentic-AI-Spezifikation kann intern durchaus LangChain4j oder Spring AI nutzen.

Die drei Ansätze im Überblick

 Jakarta Agentic AIOmniHaiLangChain4j
ArtVendor-neutrale SpezifikationSchlanke Utility-BibliothekVollwertiges Agenten-Framework
Fokus

Standardisierte Lebenszyklen,

CDI-Integration, LLM-Facade

Einheitliche Chat-/Text-API über 

viele Provider

RAG, Tools, Memory, 

Multi-Agent-Orchestrierung

ReifegradSehr früh (1.0-M1, Draft)1.0 stabil, aber bewusst minimalistischEtabliert, aktiv weiterentwickelt

RAG/Agenten

/Tools

Geplant über Facade/Unwrap, 

nicht selbst standardisiert

Bewusst nicht enthaltenVoll unterstützt
Jakarta-EE-BezugNativ, CDI als KernmodellNativ (CDI, MicroProfile Config)Über `langchain4j-cdi`-Subprojekt

Die Roadmap: Wohin geht die Reise?

Nach dem sehr bewusst minimalen 1.0-Release will das Jakarta-Agentic-AI-Team laut eigener Aussage "schnell iterieren", basierend auf Feedback aus der Community und der sich rasant entwickelnden Agentic-AI-Landschaft. Für kommende Releases sind vor allem folgende Themen angekündigt:

  • Programmatisches Lifecycle-Management - eine differenziertere, code-gesteuerte Kontrolle über den Lebenszyklus von Agenten, über das erste, sehr grundlegende Modell hinaus.
  • Eine Workflow-API - um Agenten-Workflows nicht nur deklarativ per Annotation, sondern auch dynamisch zur Laufzeit zusammenzustellen.
  • Tiefere Integration mit bestehenden Jakarta-EE-Spezifikationen wie Validation, REST, JSON Binding, Persistence, Data, Transactions, NoSQL, Concurrency, Security und Messaging.
    Auf einer größeren Zeitachse skizziert die Eclipse Foundation zusätzlich eine – wie sie selbst in einem Foliensatz von Developer Advocate Ivar Grimstad einordnet - "durchaus spekulative" KI-Roadmap für Jakarta EE insgesamt, mit Meilensteinen etwa zwischen 2024 und 2030. Konkret werden im begleitenden Jakarta-EE-Blogbeitrag zu KI mehrere Bausteine genannt, an denen Jakarta EE parallel zur eigentlichen Agentic-AI-Spezifikation arbeiten könnte:
  • MCP (Model Context Protocol): Jakarta EE könnte eine stabile, standardisierte API-Schicht bereitstellen, über die Enterprise-Java-Anwendungen mit KI-Modellen interagieren - inklusive Modell-Lifecycle-Management und Governance, was besonders für regulierte Branchen relevant ist.
  • Agent2Agent-Protokoll (A2A): Die Messaging - und Transaktionsinfrastruktur von Jakarta EE gilt laut Blogbeitrag als naheliegende Grundlage für sichere, zuverlässige Interaktionen zwischen mehreren Agenten - etwa für Multi-Agenten-Orchestrierung über verteilte Systeme hinweg.
  • RAG-Standardisierung: Bestehende Datenzugriffs-Standards wie Jakarta Data und JPA könnten so erweitert werden, dass sie auch Vektordatenbanken und Retrieval-Augmented-Generation-Muster unterstützen.
  • Agentische Workflows über CDI-Events und Jakarta Messaging: Die ereignisgesteuerte Architektur von Jakarta EE soll als Grundlage dienen, damit Agenten auf Geschäftsereignisse reagieren und Aktionen orchestrieren können.

Bemerkenswert ist, dass die Eclipse Foundation dabei auch benachbarte, sehr frühe Projekte im Blick hat - etwa Embabel (Agenten auf Basis von Spring AI), Langgraph4j (graphbasierte Agenten-Orchestrierung auf Basis von LangChain4j) oder Experimente von Akka mit seinem Aktorenmodell für Agentic AI. Der eigene Anspruch von Jakarta EE ist dabei ausdrücklich kein Alleingang, sondern Kollaboration: Viele der genannten Anbieter sind Mitglieder der Jakarta EE Working Group, und die Foundation wirbt aktiv dafür, Erfahrungen aus diesen Frameworks in offene, herstellerneutrale Standards einfließen zu lassen. Diese Einordnung deckt sich mit einer aktuellen Analyse, wonach Jakarta Agentic AI nicht als Ersatz für LangChain4j oder Provider-SDKs gedacht ist, sondern als Standard-Programmiermodell für den Bau von KI-Agenten mit Jakarta EE.

Fazit

Der Vergleich zeigt drei sehr unterschiedliche, aber keineswegs widersprüchliche Antworten auf die Agentic-AI-Frage im Java-Ökosystem:

  • OmniHai eignet sich, wenn man in einer Jakarta-EE- oder MicroProfile-Anwendung schnell und mit minimalen Abhängigkeiten multi-provider-fähigen Chat, Textanalyse oder Content-Moderation einbauen möchte - ohne den Overhead eines vollen Agenten-Frameworks.
  • LangChain4j ist die richtige Wahl, wenn tatsächlich komplexe agentische Workflows, RAG-Pipelines, Tool-Aufrufe oder Multi-Agenten-Orchestrierung gefragt sind – heute schon produktionsreif und mit breiter Framework-Unterstützung.
  • Jakarta Agentic AI ist noch ganz am Anfang seines Weges, verfolgt aber ein Ziel, das der Enterprise-Java-Community seit jeher wichtig ist: Herstellerunabhängigkeit. Wer heute schon auf LangChain4j oder Spring AI setzt, muss sich also keine Sorgen machen - im Gegenteil, diese Bibliotheken sind explizit als mögliche Implementierungsgrundlage der künftigen Spezifikation vorgesehen.

Es lohnt sich, das Projekt auf GitHub (`jakartaee/agentic-ai`) im Auge zu behalten - gerade weil die nächsten Releases entscheiden werden, ob aus dem heutigen, bewusst minimalen Entwurf tatsächlich ein für Enterprise-Anwendungen tragfähiger Standard für KI-Agenten wird.

Quellen

Share

LinkedIn X Facebook Xing