Embabel Agent: a JVM agent framework where a planner, not the programmer, orders the steps

The problem Embabel solves: agent logic that survives a code review

Most agent code on the JVM starts as a chain of prompt strings glued together with if-statements. It works until someone adds a fifth tool, at which point the ordering logic is buried in control flow nobody wants to touch. Embabel's answer is to model the flow in terms of Actions (steps an agent takes), Goals (what it is trying to achieve), Conditions (checks assessed before an action runs and after each action completes), and a domain model of typed objects that informs all three. The README states that application developers usually do not deal with these concepts directly, because most conditions are inferred from data flow defined in code. That inference is the part worth examining: you declare what an action consumes and produces, and the framework derives the pre and post conditions from those types.

The audience is specific. This is for Java and Kotlin engineers who already run Spring services and want agent behaviour inside them, not beside them. The README notes that Spring can inject and manage agents, including using Spring AOP to decorate functions, and that persistence and transaction management are available. If your agent needs to write to the same database your order service uses, that is the case Embabel is built for. If you are prototyping in a notebook, it is not.

How the planner works, and why replanning is the whole design

The mechanism the README describes is a planning step that is not an LLM call. The system formulates a Plan, a sequence of actions to reach a goal, and the programmer does not write that sequence. After each action completes, the system replans. The README calls this an OODA loop: observe, orient, decide, act, then loop. Conditions are reassessed after each action, which is how new information changes what the planner considers next.

Two consequences follow directly from that. First, adding domain objects, actions, goals and conditions can extend what the system can do without editing existing flow definitions, because there are no flow definitions to edit. Second, the plan is not knowable in advance. The README positions this against finite state machines and sequential execution with nesting, and claims the planner can combine known steps in a novel order and make decisions about parallelization at runtime. That is a real architectural choice with a real cost: you cannot read a file and know which actions will run. You can read the available actions and the goal, and reason about it, but the ordering is produced at execution time. Teams that need deterministic, auditable step sequences should treat this as a mismatch, not a configuration problem.

The repository layout supports the modularity claim. There are separate top-level modules for embabel-agent-openai, embabel-agent-anthropic, embabel-agent-mcp, embabel-agent-rag, embabel-agent-a2a, embabel-agent-observability, embabel-agent-shell and embabel-agent-cache. The README notes that platform abstraction keeps the programming model separate from platform internals, so you can run locally and change quality of service in production without changing application code.

Where to get Embabel and how a first run is meant to start

Embabel publishes to Maven Central under the group com.embabel.agent, and the README badge links the embabel-agent-api artifact. The repository also contains an embabel-agent-starters directory, which is where the Spring Boot starter artifacts live, and separate provider modules for OpenAI and Anthropic. The README does not print a dependency block or a build command, so there is no install line to copy here. Resolve the artifact and version you want from Maven Central, and read the guide linked from the README's docs badge, which points at docs.embabel.com for the 1.5.0-SNAPSHOT line.

For a first real use, the repository offers two entry points that do not require you to invent a project structure. The embabel-agent-starters modules are the intended path for a Spring Boot application, since the README describes agents as Spring-managed beans that can be injected and decorated with Spring AOP. The embabel-agent-shell module is the interactive path: the README lists it among the integrations without documenting its commands, so it is best treated as a way to observe the planner choosing actions once you have a model provider configured.

Model access comes from the provider modules. The README lists embabel-agent-openai and embabel-agent-anthropic at the top level, and the README's claim about mixing LLMs is that the framework makes it easy to combine models, including using local models for point tasks where cost and privacy matter. The README does not specify property names or environment variables for credentials, so check the docs site rather than guessing a key. The README also points at hub.embabel.com, described as an Embabel agent that answers questions about the framework in natural language. That is a running agent, not a specification, so treat its answers as a starting point and confirm anything load-bearing against the guide.

The limitation that matters: an inferred plan is not an inspectable plan

Embabel's strongest feature and its sharpest limitation are the same thing. Because the planner formulates and reformulates the sequence, the framework can do work it was not explicitly programmed to do. It also means that when an agent behaves unexpectedly, the failure is not in a line of code you can point at. It is in the interaction between the available actions, the conditions the framework inferred from your types, and whatever the model returned on that run. Debugging shifts from reading a stack trace to reasoning about a search space.

The README does address testability, stating the framework is designed for it from the ground up, with both unit testing and agent end-to-end testing. The repository contains an embabel-agent-test-support module, which is consistent with that claim. What the README does not document is how to pin or replay a specific plan, and it does not describe rollback behaviour for a partially executed plan. If your workload requires either, that is unverified ground and you should establish it before building on top.

The wrong-tool case is equally clear. If your process is genuinely a fixed sequence with a few branches, a state machine expresses it more directly and produces an artifact a reviewer can read. Embabel's planning machinery is overhead in that scenario, and the inference that saves you from writing conditions will not save you anything when the conditions were never in question.

Embabel compared with Spring AI, and what the difference actually is

The comparison people search for is Embabel against Spring AI, and the two sit at different layers. Spring AI is a model integration layer: it gives Spring applications clients for chat and embedding models, prompt templating, vector store integrations, and tool calling. Embabel is an orchestration layer that sits above model access and decides which actions to run and in what order. The repository layout reflects this. Embabel has provider modules for OpenAI and Anthropic rather than a single abstraction it promotes as the point of the project.

In practice you can use both. Spring AI handles the call to the model; Embabel handles the decision about what to do with the result and what to do next. The README's claim about mixing LLMs points at the same split: it states the framework makes it easy to build applications that combine models, using local models for point tasks where cost and privacy matter. That is an orchestration concern, not a client concern.

The honest difference is in what you write. With Spring AI you write the control flow and call the model inside it. With Embabel you declare actions and goals and let the planner produce the control flow. Neither is strictly better. One is legible, the other is adaptive, and the trade is real.

Licence, maintenance and the cost of upgrading

Embabel is Apache-2.0, which permits commercial use, modification and redistribution under the terms of that licence. The repository ships a LICENSE file at the top level. This is a permissive licence with a patent grant, and it is the same licence most Spring projects use, so it should not create friction with corporate policy that already accepts Spring. That is an observation about the licence text, not legal advice; your own counsel decides what your organisation can ship.

The last push to the default branch was on 2026-09-10, and the repository is not archived. The release cadence visible in the project's releases is rapid: v1.0.0 on 2026-07-20, v1.5.0 on 2026-08-11, and v1.5.1 on 2026-08-24. Five minor versions in roughly five weeks is a fast-moving API surface, and the README's own docs badge points at a 1.5.0-SNAPSHOT guide URL, which suggests documentation tracks the development line rather than a frozen release.

The upgrade cost follows from that cadence. If you adopt Embabel today, budget for dependency bumps and for reading release notes before each one, because a framework that is adding modules at this rate is also changing the ones it has. Pin your version in Maven, and check the docs site for the guide that matches the version you pinned rather than reading the snapshot guide against a released artifact.

Editorial conclusion

Adopt Embabel if your team already ships Spring Boot services on the JVM and you want agent logic expressed as typed actions and goals instead of prompt strings and hand-written graphs. Skip it if you need a Python ecosystem, a visual flow editor, or a framework whose plan you can fully predict before runtime. Before committing, verify three things on your own machine: that the embabel-agent artifacts you intend to use resolve from Maven Central at the version you want, that your chosen model provider module (embabel-agent-openai or embabel-agent-anthropic) matches the credentials you actually hold, and that you accept a planner which replans after every action, since that is the behaviour the framework is built around.

Frequently asked questions

Official sources

1. embabel/embabel-agent on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases