Embabel Agent Framework Reaches 1.0

Embabel, a framework for building AI agents on the Java, reached its 1.0 general-availability release. Embabel lets Java and Kotlin developers define agents as typed domain objects (goals, actions, and the conditions that connect them) rather than hand-coding a sequence of prompts and tool calls, using a planning step to work out how to get from the current state to a goal at runtime.

That planning step borrows an idea from video game AI called Goal-Oriented Action Planning (GOAP). Instead of following a script or a pre-wired graph, the agent is given a set of available actions, each with preconditions and effects, and a planner searches for a sequence of actions that satisfies the goal. If the world changes mid-task (a tool call fails, new information arrives), the planner can reassess and find a new path rather than falling over or requiring the workflow to have anticipated that branch in advance.

Embabel doesn't replace Spring AI, the Spring team's own library for calling models, managing embeddings, and invoking tools; it's built on top of it. Embabel was co-created by the creator of the Spring Framework: Rod Johnson announced the release with "Embabel 1.0.0 GA nearly ready...excited!" Johnson founded Spring, and with it Spring MVC, in 2003, and the project's README draws a direct parallel to that history: "An analogy: Spring AI exists at the level of the Servlet API, while Embabel is more like Spring MVC." Raw servlets work, but every application ends up re-solving the same problems: parsing request parameters, dispatching to the right handler, converting objects to and from HTTP. Spring MVC didn't replace servlets; it sat on top of them and let developers write a typed method signature instead of parsing a HttpServletRequest by hand. Embabel is making the same bet for agents: Spring AI supplies the plumbing to talk to a model, and Embabel supplies the layer where a developer declares "these are my goals and the typed actions available to reach them," leaving the framework to work out the sequencing.

That same layered relationship with Spring AI carries through to model choice. Because Embabel builds on Spring AI, it inherits support for most of the providers Spring AI does (OpenAI, Anthropic, Gemini, Bedrock, Mistral, DeepSeek), plus local and self-hosted options through Ollama, Docker, or an OpenAI-compatible LMStudio endpoint. The choice isn't made once for the whole agent: a developer can pin an individual action to a specific model, or define role aliases in configuration (a "best" model for the step that needs strong reasoning, a "cheapest" one for routine steps) and have an action reference the role instead of a hard-coded name. That makes it straightforward to run a single agent across a mix of models, routing each step to whichever one fits its cost, privacy, or capability needs.

The planning step itself is what sets Embabel apart from LangGraph, the graph-oriented orchestration layer built by LangChain. Java teams can use it directly through LangGraph4j, a Java port built to work with LangChain4j and Spring AI. LangGraph represents an agent workflow as a directed graph: nodes are functions (an LLM call, a tool invocation, a database lookup) and edges are the routing logic, static or conditional, that decides which node executes next, with a shared state object passed along the way. The developer defines that graph up front: which nodes exist, which edges connect them, and under what conditions control moves between them. Embabel's planner starts from a different point: rather than the developer wiring the graph, the framework searches for a path through the available typed actions at runtime, and can combine actions into sequences the developer never explicitly wired together. Embabel supports mixing GOAP planning with explicit state machines in the same agent, so a team can still drop into LangGraph-style fixed routing for the steps where that's what they want.

Akka, the Lightbend-maintained toolkit built around the actor model, approaches the same problem from existing strength in distributed systems rather than Spring's programming-model tradition. In Akka, each unit of work (here, an agent) runs as an actor with its own isolated state and mailbox, supervised by a hierarchy that can restart it after a failure without disturbing the rest of the system. The Akka Agentic Platform applies that directly to agents: an agent's state and in-flight conversation live in an actor that survives a process crash and can be distributed across a cluster, so a long-running agent doesn't need to be rebuilt from scratch after a restart or re-architected to run across multiple machines. Embabel's pitch is a programming model: declare goals and typed actions, let the framework plan. Akka's is closer to infrastructure: the actor runtime handles persistence, fault tolerance, and distribution underneath whatever agent logic runs on top. JetBrains' Koog takes a third approach, built around Kotlin's own language features rather than a runtime or a declarative programming model. Each is making a different bet on where an agent's structure should live: the type system for Embabel, the runtime for Akka, the language itself for Koog.

For teams already running Spring Boot services, this release is the point where Embabel stops being a project to watch and starts being one to evaluate. The project's "Overview" guide walks through defining a first goal and typed action before getting into planning behavior.