Embracing existing AI innovation through a minimal, extensible, and adaptable approach
Jakarta Agentic AI is a newly launched project within the Jakarta ecosystem. It defines a set of vendor-neutral APIs that enable developers to build, deploy, and run AI agents on Jakarta EE runtimes in an easy, consistent, and reliable way, while integrating tightly with the Jakarta EE platform. The project is in its early stages and actively building community momentum, with an initial release targeted for Q1 2026. Jakarta Agentic AI aims to do for AI agent development what Jakarta REST did for RESTful services, with the potential to evolve into a full Jakarta EE specification.
Since its transition from the Java Community Process (JCP) to the Eclipse Foundation, Jakarta EE has strengthened its position within the Java ecosystem. According to the 2025 Jakarta EE Developer Survey, Jakarta EE has overtaken Spring in adoption (58% vs. 56%), reaffirming its position as the leading Java framework for developing cloud native applications. A key factor in this success has been the community’s ability to identify emerging trends early and incorporate new technologies into the Jakarta ecosystem – from Jakarta Servlet addressing HTTP-based application processing, to Jakarta REST enabling RESTful web services, and Jakarta Batch supporting batch workloads.
Leveraging agentic AI
It is therefore natural for Jakarta EE to respond to the rise of agentic AI, one of the most significant developments in enterprise and cloud native computing in decades. As we know from projects such as Eclipse LMOS, AI agents leverage neural networks, machine learning (ML), natural language processing (NLP), large language models (LLMs), and related AI technologies to autonomously perform tasks with minimal or no human intervention. They detect events, collect data, generate and refine plans, execute actions, evaluate outcomes, and continuously adapt. AI agents span a wide range of use cases, for example:
• Code/application generators
• Customer service agents
• Self-driving cars
• Security monitors
• Site Reliability Engineering (SRE) agents
• Stock monitors
• Health monitors
• Manufacturing/industrial robots
• Travel planners
Considering the breadth of possible use cases and scenarios, a minimal, yet effective approach is required to integrate AI innovation into the Jakarta ecosystem.
Jakarta Agentic AI scope and main features
Jakarta Agentic AI focuses on defining common usage patterns and lifecycle management for AI agents running on Jakarta EE runtimes. Rather than attempting to reinvent or overly constrain the rapidly evolving AI landscape, the project aims to provide a pragmatic, enterprise-ready foundation that aligns with Jakarta EE’s long-standing strengths: standardisation where it adds value, flexibility where innovation moves fastest, and seamless integration with the broader platform.
A vendor-neutral LLM facade
At its core, the project defines a minimal, vendor-neutral API that acts as a façade over foundational AI capabilities. This includes access to large language models (LLMs) and related AI services, without attempting to standardise the models themselves. Instead of prescribing a single AI provider or abstraction, Jakarta Agentic AI enables easy, pluggable, and configurable access to existing LLM frameworks such as LangChain4j and Spring AI. This approach mirrors a familiar pattern from Jakarta Persistence, which provides standardised access while allowing applications to unwrap and interact with non-standard, provider-specific APIs when needed.
Dynamic agent workflows
A key part of the scope is support for defining and executing agent workflows. These workflows describe how agents observe events, make decisions, invoke tools or services, and react to outcomes. Jakarta Agentic AI is expected to provide a fluent Java API for defining such workflows, favoring programmatic expressiveness and type safety over static XML configuration. Workflows are anticipated to be dynamic and adaptable at runtime rather than strictly fixed at deployment time, reflecting the adaptive nature of agentic systems. While the primary focus is on a fluent Java API, the design may allow for pluggable representations such as YAML or XML where appropriate.
Integration with the Jakarta EE platform
The project also emphasises deep integration with the Jakarta EE platform. AI agents are expected to operate as first-class citizens within enterprise applications, leveraging existing Jakarta EE APIs for concerns such as validation, RESTful communication, JSON binding, persistence, data access, transactions, NoSQL stores, concurrency, security, messaging, and more. By building on these established APIs, Jakarta Agentic AI ensures that agents can participate naturally in enterprise architectures, benefit from container-managed services, and adhere to familiar operational and security models.
Consistent configuration model
Configuration is another important aspect of the scope. Where possible, the project will aim to utilise Jakarta Config to provide a consistent and standardised configuration model. Implementations may also support MicroProfile Config, allowing flexibility across different runtime environments while maintaining a coherent developer experience.
OpenTelemetry support
Observability is treated as a first-class concern as well. Implementations may offer integrations with OpenTelemetry, enabling standardised tracing, metrics, and logging for AI agent workflows. This is particularly important in enterprise environments, where understanding agent behavior, performance, and decision making paths is critical for reliability, compliance, and operational trust.
Beyond Jakarta EE: Quarkus, Micronaut, Spring Boot
While Jakarta EE-compatible runtimes are the primary target, the project makes a reasonable effort to keep the API usable beyond traditional Jakarta EE environments. The design aims to remain compatible, where feasible, with runtimes such as Quarkus, Micronaut, and Spring Boot, enabling broader adoption and reducing friction for developers operating across different Java ecosystems.
In summary, the scope of Jakarta Agentic AI is deliberately focused: to provide a lightweight, extensible, and enterprise-aligned foundation for building and running AI agents, while embracing existing AI innovation and integrating tightly with the Jakarta EE platform.
Jakarta Agentic AI 1.0
Version 1.0 focuses on defining the foundational programming models, patterns, and lifecycles, along with a lightweight façade for LLM access. Future releases are expected to introduce more advanced capabilities, including programmatic lifecycle management, a richer workflow API, and additional features. Specifically, 1.0 introduces the annotations @Agent, @Trigger, @Decision, @Action, and @Outcome. This is illustrated in the code example below.
/*
* Simple agent for bank fraud detection.
* Doesn't actually block a transaction but marks it suspect and sends notifications.
*/
// Infers agent type and name by default.
// Default scope is agent workflow, but agents can have application scope.
// Just a CDI bean and ideally @Agent is a CDI stereotype.
@Agent
public class FraudDetectionAgent {
// Injects default LLM in the implementation, but can be configured to inject specific ones.
@Inject private LargeLanguageModel model;
@Inject private EntityManager entityManager;
// Initiates the agent workflow. For this initial release, the workflow can only be triggered by
// CDI events.
// In the future, there could be many other types of triggers such as Jakarta Messaging or
// direct invocation from a programmatic life cycle API.
@Trigger
// Return type can be void or a domain object stored in the workflow and accessible in
// the context.
// Parameters are automatically added to the workflow context.
private void handleTransaction(@Valid BankTransaction transaction) {
// Simple check to see if this is a type of transaction that makes sense to check for
// fraud detection.
// Could add a bit more data, likely looked up from a database, and return an enhanced
// version of the transaction or return another domain object entirely.
}
// Can return boolean, a built-in Result record type, or any domain object.
// In this initial release, workflows will automatically end with a negative result.
// In subsequent releases, more robust decision flows should be possible, either with
// annotations/EL and/or the programmatic workflow API.
@Decision
private Result checkFraud (BankTransaction transaction) {
/*
* One of the value propositions of the LLM facade is automatic type conversion in Java,
* both for parameters and return types.
*
* If nothing is specified, it's all strings.
* Probably only JSON and string are supported initially for conversion.
* Queries can be parameterized similar to Jakarta Persistence.
*/
String output = model.query(
"Is this a fraudulent transaction? If so, how serious is it?", transaction);
boolean fraud = isFraud(output); // Does some simple custom text parsing.
Fraud details = null;
if (fraud) {
details = getFraudDetails(output); // Does some simple custom text parsing,
// possibly involving database queries.
}
return new Result (fraud, details);
}
// Only one action here, but there could be multiple actions and/or decisions in sequence.
// In the initial version, it's just one linear flow.
// In subsequent releases, the workflow API can define complex flows, including
// pre-conditions for actions defined via annotation/EL.
@Action
// Notice that we are automatically injecting domain objects from the workflow context.
private void handleFraud (Fraud fraud, BankTransaction transaction) {
/*
* IMPORTANT FUNDAMENTAL CONCEPT:
* This is an example of hard-coded logic, which would still be possible if desired.
*
* The power of a programmatic/structured workflow, instead, is that this could change
* entirely at runtime, driven by further LLM queries.
* Even for simple, static workflows, the API helps developers think through how agents
* operate fundamentally - introducing a common vocabulary/patterns.
*
* Dynamically altered workflows could possibly be serialized into persistent storage.
*/
if (fraud.isSerious()) {
alertBankSecurity(fraud);
}
Customer customer = getCustomer(transaction);
alertCustomer(fraud, transaction, customer);
}
// In this initial release, outcomes are essentially the same as actions, but specifically
// mark the end of the workflow.
// In subsequent releases, outcomes can do more powerful things such as pass a domain
// object to a subsequent workflow or agent.
// This is probably also where it best makes sense to dynamically alter a workflow using
// a programmatic API.
@Outcome
private void markTransaction(BankTransaction transaction) {
// Mark a transaction suspect, probably in the database.
}
}
The @Agent annotation defines an AI agent and its basic lifecycle within a Jakarta EE runtime. An agent is implemented as a standard CDI bean. By default, an agent is scoped to the duration of an agent workflow, though agents may also be defined with application scope. The annotation enables agents to be discovered and looked up by type or name, supporting programmatic access through lifecycle and the workflow APIs.
@Trigger processes events and initiates an agent workflow. In the initial release, workflows are triggered exclusively by CDI events, providing a simple and well-integrated starting point. The design, however, anticipates additional trigger mechanisms, such as Jakarta Messaging, REST POST, or direct invocation through a programmatic lifecycle API.
@Decision is a simple decision point within an agent workflow. A decision method can return either a boolean value or a built-in result record type. In the initial release, workflows follow a linear model and automatically terminate when a negative result is returned. Future iterations are expected to support more expressive decision flows, enabled through annotations, expression language, or a programmatic workflow API.
@Action represents an individual step performed by an agent within a workflow. In the future, an action may declare preconditions using annotations or expression language to control when it is executed. Actions may also define an execution order beyond a simple natural or sequence in the future.
@Outcome denotes the conclusion of an agent workflow. An outcome represents the final result of execution and may, in future iterations, enable more advanced behaviours such as passing domain objects to subsequent workflows or other agents.
The initial release is deliberately minimal, aiming to establish early momentum by raising awareness, encouraging community involvement, and driving adoption. The project will then evolve rapidly, informed by ongoing industry developments in agentic AI and feedback from users.
Next steps & how to get involved
Initially, the project does not aim to be included in the Jakarta EE platform or any existing profile, but instead focuses on delivering a usable, standalone API under the Jakarta EE umbrella that vendors may choose to adopt. Over time, it may be appropriate to define a dedicated Jakarta EE profile for AI, to which this project could contribute. Such a profile could also encompass additional specifications intended to standardise other key AI concepts, including LLMs and model augmentation or context services.
The project seeks to achieve broad industry consensus by engaging a wide range of subject matter experts and API consumers, both within the Java and Jakarta EE ecosystem and beyond. If you’d like to get involved in this brand-new project, visit our GitHub page, join our mailing list or the #agentic-ai channel on the Jakarta EE Development Slack workspace.
About the Author
Reza Rahman
Reza is a recognised enterprise Java technologist, leader, architect, consultant, author, and speaker.