Typed actions give the planner a bounded set of moves
Embabel models an agent as domain objects, goals, actions, and conditions. Developers write Java annotations or a Kotlin DSL, then the platform chooses a path through available actions. The default planner uses Goal Oriented Action Planning rather than asking an LLM to invent the workflow. That separation is attractive in business software: the model can transform data or choose a tool, while code defines the operations it is allowed to perform.
The framework is substantial. Our commit 74db1c7 checkout contained 1,984 files and about 297,419 source lines, though it occupied only 18.5 MB before dependencies. It supports focused execution for a specific capability, closed execution that selects among known agents, and open execution that can combine actions across agents. Open mode is expressly less deterministic. Even there, Embabel can only call steps developers have defined, unless a step itself delegates broad behavior to a model.
Dynamic planning pays off when actions can be reused
A fixed workflow is simpler when the steps never change. Embabel becomes interesting when several agents can share domain objects and actions, or when new capabilities should become available without editing old state-machine definitions. Strong types make prompts, service calls, and outputs visible to Java tooling. Actions remain Spring beans, so dependency injection, transactions, persistence libraries, and unit-test practices are already available.
That design has a learning cost beyond the 376-second install we measured. A team must define preconditions, outputs, goal completion, and approval boundaries well enough for a planner to compose them safely. Names also matter because goals can be exported as MCP tools. The README warns that domain methods exposed with @Tool should be safe to invoke and suggests keeping mutation or deletion behind explicit code actions instead of making those methods directly callable by a model.
What happened when we ran it
Our sandbox installed the project in 376 seconds and completed the build in another 236 seconds. The test step took 635 seconds. Maven Surefire counted 2,123 cases: 2,025 passed, 0 failed, and 98 skipped. That is a strong result for a fresh unprivileged container with 3 CPUs, 10 GB of RAM, no secrets, and JDK 21.
The scan found 5 CI workflow files, no root Dockerfile, and no tests directory, even though Maven discovered the large suite inside module-specific source trees. The skipped cases matter because the README says credentialed integration tests are omitted when their provider variables or services are absent. Our run therefore proves that the available no-secret suite passed. It does not prove OpenAI, Anthropic, Gemini, OCI, Ollama, Vertex AI, or remote MCP behavior.
The first useful agent needs a provider and Spring configuration
The documented examples expect OPENAI_API_KEY; the project recommends adding Anthropic for examples that mix models. Other starters cover MiniMax, Z.ai, OCI Generative AI, Ollama, Docker model services, and LM Studio. The deep-research example also wants web tools through Docker Desktop or another MCP setup. A small demo can start from the Java or Kotlin template, but reproducing the richer examples means coordinating several services.
Stable artifacts are on Maven Central, yet Gradle users still need the Spring Milestones repository because the dependency BOM refers to an experimental MCP BOM unavailable from Central. Our 236-second build succeeded with the repository's own configuration. Consumers should pin Embabel, Spring AI, and milestone dependencies together, then repeat the build from an empty cache. A provider switch can affect structured output and thinking behavior even when application code still compiles.
Human approval state disappears with an autoscaled pod
Issue #1965 identifies a concrete production limit: the only shipped AgentProcessRepository implementation stores state in memory. An agent paused for a form submission remains tied to the pod that created it. If Kubernetes removes that pod, routing cannot restore the process. Teams building long-running approvals must implement a persistent repository or keep that workload off autoscaling infrastructure until the framework supplies one.
Provider edges also need focused tests. Issue #1813 documents a Google GenAI thinking response where typed JSON lived in a later generation, while the framework selected the first thought block. The result was a parse failure despite valid answer content. Version 1.5.1 includes many provider and structured-output fixes, but the open queue shows how quickly those adapters move. Contract tests with your model, options, and response types are more useful than assuming all Spring AI providers behave alike.
Version 1.5.1 is active, while the roadmap stays ambitious
GitHub recorded 4,386 stars, an Apache-2.0 license, and 70 combined issues and pull requests. The repository was pushed on August 24, 2026, and version 1.5.1 was released the same day. That release addressed Bedrock options, provider-independent roles, model credentials, search filtering, Ollama thinking extraction, MCP documentation, and an HTTP components vulnerability. The activity supports continued evaluation, though the combined open count is not a defect count.
Embabel is best treated as an application architecture, not an agent helper to sprinkle into one controller. The 2,025 passing tests give the implementation more weight than its self-described early stage might suggest. Start with one bounded agent, keep execution focused or closed, and test the planner against real domain states. Open execution, durable waits, and broad tool access should arrive only after the team can explain how each action fails and how the process resumes.