Rod Johnson, the creator of the Spring Framework, announced the 1.0.0 general-availability release of Embabel, a Java and Kotlin framework for building AI agents. The release, covered in an InfoQ article published on Aug 03, 2026, marks a shift from a project to watch to one that teams can evaluate. Embabel lets developers define agents as typed domain objects, with goals, actions, and conditions, rather than hand-coding sequences of prompts and tool calls.
Johnson co-created Embabel, which sits on top of Spring AI. Spring AI is the Spring team's library for calling models, managing embeddings, and invoking tools. Embabel does not replace Spring AI. Instead, it adds a typed layer above it. The project's README draws a direct comparison to the history of Java web development. "An analogy: Spring AI exists at the level of the Servlet API, while Embabel is more like Spring MVC."
A Spring MVC Moment for Agents
The analogy is precise. Raw servlets work, but every application ends up re-solving the same problems: parsing request parameters, dispatching handlers, and converting objects to and from HTTP. Spring MVC, which Johnson founded in 2003 alongside Spring itself, let developers write typed method signatures instead of parsing HttpServletRequest by hand. Spring MVC did not replace servlets. It sat on top of them and made the developer's job simpler.
Embabel makes the same bet for agents. Spring AI supplies the plumbing: model calls, embeddings, and tool invocation. Embabel supplies a typed declaration layer. Developers define what an agent can do as typed actions, each with preconditions and effects. They define goals as conditions to satisfy. The framework then works out how to get from the current state to the goal at runtime.
That planning step is the core of the framework. It borrows from Goal-Oriented Action Planning (GOAP), a technique from video game AI. In GOAP, an agent is given available actions with preconditions and effects. A planner searches for a sequence of actions that satisfies the goal. Embabel applies the same idea to enterprise agents. The planner can reassess if the world changes mid-task, such as when a tool call fails or new information arrives. Instead of falling over, the agent can find a new path without the workflow anticipating every branch in advance.
Planning Versus Graph Routing
The planning step is what sets Embabel apart from LangGraph, the graph-oriented orchestration layer built by LangChain. LangGraph represents an agent workflow as a directed graph. Nodes are functions, such as an LLM call, a tool invocation, or a database lookup. Edges are static or conditional routing logic. A shared state object is passed along the way. The developer defines the graph up front: nodes, edges, and conditions.
Embabel inverts that model. The planner searches for a path through available typed actions at runtime. That means Embabel can combine actions into sequences the developer never explicitly wired together. The developer declares "these are my goals and the typed actions available to reach them," and the planner does the rest.
For teams that want fixed routing, Embabel supports mixing GOAP planning with explicit state machines in the same agent. Teams can drop into LangGraph-style routing when they want deterministic control. The framework does not force one approach on every workflow.
Java developers have alternatives. LangGraph4j is a Java port of LangGraph, built to work with LangChain4j and Spring AI. It brings the same graph model to the JVM. Embabel's runtime search is a different philosophy: the structure emerges from the planner's search, not from a pre-wired graph.
Model Routing Per Action
Model choice is not made once for the whole agent in Embabel. The framework inherits provider support from Spring AI, which covers OpenAI, Anthropic, Gemini, Bedrock, Mistral, and DeepSeek. Local and self-hosted options include Ollama, Docker, and an OpenAI-compatible LMStudio endpoint.
A developer can pin an individual action to a specific model. That allows fine-grained control over cost and capability. The framework also supports role aliases defined in configuration. A developer might define a "best" model for reasoning and a "cheapest" model for routine steps. Actions can reference role aliases instead of hard-coded model names. A single agent can then run across a mix of models, routing each step by cost, privacy, or capability needs. The developer might designate a "model for the step that needs strong reasoning, a" cheaper model for a simple extraction, and a local model for sensitive data.
This per-action routing is a practical feature for production systems. A complex reasoning step can use a frontier model. A routine formatting step can use something smaller and faster. The agent's structure stays the same; only the model assignment changes.
The Competitive Landscape
Embabel is not the only framework making a bet on where agent structure should live. Akka, the Lightbend-maintained toolkit built around the actor model, takes a runtime approach. Each agent runs as an actor with isolated state and a mailbox. A supervisor hierarchy can restart actors after failure. The Akka Agentic Platform applies the actor model to agents: agent state and in-flight conversation live in an actor that survives a process crash. Akka agents can be distributed across a cluster. Akka's pitch is infrastructure: persistence, fault tolerance, and distribution.
JetBrains' Koog takes a third path. It is built around Kotlin's language features, using the language itself for agent structure. Each framework makes a different bet: the type system for Embabel, the runtime for Akka, and the language for Koog.
Stay ahead of the AI curve
The most important updates, news, and content — delivered weekly.
No spam. Unsubscribe anytime.
Akka's approach is closer to infrastructure than a programming model. It solves the hard problems of distributed systems and crash recovery. Embabel solves the problem of expressing what an agent should do. The two are not mutually exclusive, but they answer different questions.
What the 1.0 Release Means
For teams running Spring Boot services, this release marks the point to evaluate Embabel. The project's "Overview" guide walks through defining a first goal and a typed action before planning behavior. The framework is designed to feel familiar to developers who have used Spring MVC. The typed declaration layer is the same pattern that made web development manageable.
The release was announced by Johnson, who expressed excitement about the milestone. The announcement also appeared in the Java News Roundup, alongside JEPs for JDK 28, Oracle CPUs, Azul Payara, and Helidon. The timing is notable: 2026 marks more than two decades since Johnson founded Spring in 2003, and the same design instincts are now being applied to agents.
The framework's approach has a clear intellectual lineage. GOAP has been used in video games for years to let characters plan sequences of actions. Embabel adapts that technique to enterprise software. The planner searches for a path through available actions at runtime, rather than requiring the developer to wire every possible route in advance. That is a meaningful difference from graph-based orchestration.
The release also benefits from Spring AI's ecosystem. Because Embabel inherits provider support, it works with the major model providers out of the box. The local options mean developers can test without sending data to external services. The role alias system adds a layer of operational control that is often missing from agent frameworks.
The InfoQ article was written by Erik Costlow, who covered the release for the publication. The article sits in the Architecture & Design, AI, ML & Data Engineering, Java, Agents, and AI Development topics. Related coverage includes Cloudflare Making Internal DNS Generally Available, Virtual Threads After JDK 24, Rethinking Data, the Java News Roundup, Netflix's LLM Serving Platform, and Microsoft .NET 11 Preview 6.
The broader context matters. Agent frameworks are proliferating, and each one makes a different bet on where complexity should live. Embabel's bet is that a typed declaration layer, combined with runtime planning, gives developers the flexibility they need without sacrificing control. The 1.0 release is the point where that bet becomes something teams can test in production.
The framework's relationship to Spring AI mirrors the historical relationship between Spring MVC and servlets. Spring MVC did not eliminate servlets; it made them usable. Embabel does not eliminate Spring AI; it makes agent development declarative. The analogy is not just marketing. It reflects a design philosophy that has worked once before in the Java ecosystem.
For developers who have built agents by chaining prompts and tool calls, Embabel offers an alternative. Instead of writing brittle sequences, they define goals and actions. The planner handles the rest. If a step fails, the planner can find a new route. That is a different way of thinking about agent reliability.
The release also raises practical questions for teams. How does runtime planning perform under load? How does it handle complex domains with many actions? The framework's documentation and guides will answer those questions as teams begin to evaluate it. The 1.0.0 GA release is the starting point, not the end of the story.
The timing of the release, in August 2026, puts Embabel in a crowded field. LangGraph4j, Akka Agentic Platform, and Koog all offer different approaches. Each framework makes a different bet on where an agent's structure should live. Embabel's bet is on the type system and runtime planning. Whether that bet pays off will depend on how well it handles real-world agent workloads.
The InfoQ article notes that this release is the point where Embabel stops being a project to watch and starts being one to evaluate. For teams already invested in Spring Boot, the evaluation cost is low. The framework builds on familiar patterns and integrates with an existing ecosystem. The question is whether the planning approach delivers on its promise.
The announcement also highlights the growing maturity of the Java AI ecosystem. Spring AI provides the model access layer. Embabel provides the agent structure. LangGraph4j provides a graph alternative. The pieces are coming together for serious agent development on the JVM.
The framework's use of GOAP is a notable design choice. Video game AI has dealt with the problem of flexible behavior for decades. Embabel brings that experience to enterprise software. The planner's ability to reassess when the world changes is a direct response to the fragility of hard-coded agent workflows.
For now, the 1.0.0 GA release is the milestone. Rod Johnson's involvement gives the project immediate credibility in the Java community. The Spring MVC analogy gives developers a mental model for what Embabel does. The planning approach gives it a distinct identity in a crowded market.
The next step is adoption. Teams will test the framework against real workloads. They will find its strengths and its limits. The release is the starting gun, and the evaluation period has begun.