Embabel 1.0: Spring Creator’s AI Agent Framework for Java Goes GA

Rod Johnson, creator of the Spring Framework, shipped Embabel 1.0.0 GA, an AI agent framework for Java that uses deterministic Goal-Oriented Action Planning (GOAP) instead of letting LLMs decide action sequences. The release promotes RAG APIs to stable, adds MCP server health via Spring Boot Actuator, A2A protocol support, ONNX for local embeddings, and expanded model coverage including Z.ai GLM and DeepSeek.

Rod Johnson built Spring Framework — the infrastructure running a significant slice of the world’s Java applications. Last week, he shipped 1.0.0 GA of Embabel, the AI agent framework he calls his most important project since Spring itself. If you’re building on the JVM and you’ve been watching AI agent tooling from the sideline because it was all Python-first, that sideline period is over. Why Agents Break Without Deterministic Planning Most agent frameworks — Python or Java — hand planning responsibility to the LLM. You describe available tools, and the model decides what to call next. This works for demos. In production, it produces hallucinated action sequences, untestable flows, and the occasional agent deciding to do something you didn’t intend and can’t explain after the fact. Embabel borrows a different approach from video game AI: Goal-Oriented Action Planning GOAP https://github.com/embabel/embabel-agent . You define what you want to achieve a Goal and what actions are available by annotating methods with pre-conditions and post-conditions. A deterministic, non-LLM planner builds the action sequence from current world state to goal. The plan is inspectable before execution. LLMs handle content work within each action — writing, summarizing, classifying — but never decide what runs next. For enterprise teams that need to explain their AI systems to compliance or audit, this distinction matters enormously. What 1.0 Actually Ships Version 1.0 is the stability milestone the framework has been building toward since Rod Johnson introduced it to the Java community 14 months ago. The headline changes: RAG APIs promoted from experimental to stable — build vector-backed agents on the JVM without worrying the interface changes under you MCP server health via Spring Boot Actuator — your MCP integrations are now visible in the same health endpoint as the rest of your app A2A protocol support — enable the a2a Spring profile and your agent communicates with other A2A-enabled services natively ONNX support for local embeddings — run embedding models locally without an external API call; critical for cost-sensitive or air-gapped deployments Expanded model coverage — Z.ai GLM added, DeepSeek model names updated, alongside OpenAI, Anthropic, Bedrock, Google GenAI, Ollama, and LM Studio MCP tool failures now propagate correctly — pre-1.0, tool errors could silently disappear; now MCP clients see them and can handle them The module list tells you how broadly the team was thinking: agent APIs, A2A, MCP, RAG, skills, a CLI shell, observability, and ONNX — all shipping in 1.0. The Annotation Model Feels Like Spring The API is designed to feel familiar to anyone who has written a Spring service. @Agent is a Spring stereotype annotation — Embabel registers your class as a Spring bean and simultaneously with the agent runtime. You get component scanning, dependency injection, and all existing Spring infrastructure for free. Define actions as annotated methods, set pre- and post-conditions, and the planner handles sequencing. @Agent description = "Writes and reviews technical blog posts" public class BlogWriterAgent { @Action description = "Research and write a draft given a topic" public BlogDraft writeDraft Topic topic { return llmService.generate topic ; } @Action description = "Review draft and return editorial feedback" public Review reviewDraft BlogDraft draft { return llmService.review draft ; } } The planner determines whether to call writeDraft , reviewDraft , or both — and in what order — based on the current world state and the defined goal. You write actions. Embabel handles the choreography. Embabel vs LangChain4j: The Honest Take Java developers will ask why not LangChain4j https://docs.langchain4j.dev/ . It’s a fair question. LangChain4j’s AI Services pattern — define a Java interface, the framework implements it at runtime — is the most Java-idiomatic approach for simpler agent use cases. It supports 20+ LLM providers and 15+ vector stores, and its production guardrails API is mature. If you’re running Spring Boot and building complex, multi-step agent flows that need to be explainable and testable, Embabel is the cleaner fit. If you’re not on Spring, or you need maximum provider flexibility and a battle-tested guardrails layer, LangChain4j is still the right call. These frameworks aren’t competing at the same layer — Spring AI https://spring.io/projects/spring-ai handles model integration at the primitive level, and both Embabel and LangChain4j build agent orchestration on top with different design philosophies. Getting Started The requirements are deliberate: Spring Boot 3.5.15 or the latest 3.5.x release, Spring AI 1.1.7, Java 21. The Embabel team maintains Java and Kotlin template repositories on GitHub https://github.com/embabel/embabel-agent and a step-by-step guide on the official docs site at docs.embabel.com https://docs.embabel.com . A Spring Boot 4 + Spring AI 2.0 migration guide is already on the project wiki — the team is thinking about longevity. Embabel 1.0 means Java shops can adopt this without hedging. The RAG interfaces are stable, the MCP and A2A integrations work as expected, and the Spring ecosystem carries over without modification. The Python-first narrative for AI agents has dominated long enough. On the JVM, there’s now a first-class answer.